Review Request for MVT incubator module

[Maurizio Cimadamore]

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 
>>>> 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.
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!

Maurizio

>
> Mandy