----- Mail original ----- > De: "Jochen Theodorou" <blackd...@gmx.org> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "dev" <dev@groovy.apache.org> > Envoyé: Lundi 16 Avril 2018 22:28:58 > Objet: Re: Building Gant
> On 16.04.2018 21:38, Remi Forax wrote: > [...] >> the support of version 54.0 and only one sentence in section 4.7.25, see >> https://bugs.openjdk.java.net/browse/JDK-8191867 > > that is the only change in bytecode? There have been enough flags in the > bytecode the JVM just ignores, that could have been done here as well - > or do I overlook something important? Compatibility between VMs (Hotspot is not the only one). Being able to say that a module requires java.base with ACC_STATIC_PHASE means that the module will compile with java.base but can run without it at runtime (no java.lang.Object, jikes !), so if a VM really respect the JVMS 9, a user can create a module that works at compile time and fails at runtime, something the whole module system try to avoid. For ACC_TRANSITIVE, it's less an issue, it means that java.base will be re-exported to the modules that requires the module, so those modules will have two java.base, it's just useless. > > Anyway, thanks for the pointer, very appreciated. > > ASM related question: if Java now releases so much more often and is > much more often changing the bytecode version, wouldn't it be an option > to optionally disable the bytecode version check? No :) > Even if that means to fail strangely in another place? For this exact reason, historically we did not have this bytecode version check, and we spend a lot of time to track weird bugs that was just side effects of people using the wrong version. The VM doesn't work if it's not the right version, it no different for ASM. > I don't think a java9 based class reader would have had problems with this > bytecode. Might be this is a > special case of course and might be the next 10 cases are too severe for > this, you know surely better than I do. Its just a thought You're right that java 10 was a minor version update in term of bytecode (mostly because the NestMate feature was moved to 11) but Java 11 is around the corner and a java 9 bytecode class reader will choke on Java 11 class, there is a new constant pool constant, the semantics of the minor version has changed and you have new attributes (NestMate) that change the security checks performs by the VM. > > bye Jochen regards, Rémi
