Review Request for MVT incubator module

[mandy chung]

On 9/15/17 7:01 AM, Maurizio Cimadamore wrote:
>
>>> * I also tried several test scenarios in which custom annotations 
>>> called
>>> 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.

Mandy