Review Request for MVT incubator module
mandy.chung at oracle.com
Fri Sep 15 17:46:42 UTC 2017
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
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.
More information about the valhalla-dev