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