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
