RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version

Alan Bateman Alan.Bateman at oracle.com
Fri May 29 18:29:12 UTC 2020


On 29/05/2020 04:52, Mandy Chung wrote:
>
>
> On 5/28/20 5:44 PM, David Holmes wrote:
>>>
>>> This is to validate the given version.  The runtime will check if 
>>> preview feature is enabled when such class file is loaded.   I will 
>>> make a comment to make it clear.
>>
>> Okay but I thought the intent here was to pre-validate the version 
>> information so that when these bytes get passed to ASM you don't have 
>> to worry about the IAE that will be thrown by ASM if there is 
>> actually a problem.
>
> Yes it is.  ASM does not check if preview features are enabled or not 
> neither.  When a class file depending preview features is passed to 
> VM, the VM will throw an exception if preview features are not enabled.
>>
>> Maybe the only real solution here is for ASM to be more specific with 
>> the exceptions it throws. :(
>>
>
> This was discussed.
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066734.html
>
>>
>> Sure but we provide that kind of cross-package access all the time. 
>> We also have JAVA_MAX_SUPPORTED_VERSION in the ModuleInfo class. 
>> Seems messy to add yet a third place where we need to determine what 
>> the current major version number is.
>>
>
> Ah, that's another place.  I think it's better to add 
> VM::isSupportedModuleDescriptorVersion and remove these constants.
>
>> That aside isn't the minor version, as set in java.class.version 
>> guaranteed to be zero?
>>
> This is set at build time.   The minor version is zero for the current 
> versioning scheme.

I went through webrev.02 and the only issue is the magic is read as a u2 
when it should be u4, otherwise looks good.

-Alan



More information about the core-libs-dev mailing list