Review Request for MVT incubator module
maurizio.cimadamore at oracle.com
Fri Sep 15 17:48:20 UTC 2017
On 15/09/17 18:46, mandy chung wrote:
> On 9/15/17 7:01 AM, Maurizio Cimadamore wrote:
>>>> * I also tried several test scenarios in which custom annotations
>>>> ValueCapableClass were used instead of the 'official' one in the
>>>> incubator module, but I have not been able to come up with any real
>>>> issues - my concern was that the analysis that the VM applied to the
>>>> annotation is mostly textual, but there seem to be a couple of saving
>>>> factors: (i) if the EnableMVT flag is not used, the VM will not even
>>>> attempt to look at annotations, (ii) when the flag is used, the
>>>> incubator module (which is added automatically when the flag is set)
>>>> will automatically supplant any classes coming from the classpath - so
>>>> the right VCC will be used. In short, I have not been able to make the
>>>> VM 'trip up' on some maliciously written fake VCC anno. Which is good.
>>> maybe, create an annotation VCC in its own module, and use jlink to
>>> create your own jdk that included the module ?
>> That's what i did (more or less), but since MVT support add the
>> incubator module by default, you end up with split package issues as
>> you'd have jdk.incubator.mvt in two modules.
>> If EnableMVT is not passed, the VM will not even bother looking at
>> the annotation...
> Yes. jdk.incubator.mvt is added to the boot layer when the flag is
> set and that would catch any split package.
> I could further tighten up the check. The runtime checks if a type is
> value capable class if it is annotated with @VCC. We could ensure
> that comes from jdk.incubator.mvt which is tied with java.base and
> jdk.incubator.mvt must be the one built with java.base.
I think for now we're good - I really just wanted to make sure that we
had some basic bases covered, and it seems we do!
More information about the valhalla-dev