groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fo...@univ-mlv.fr
Subject Re: Building Gant
Date Tue, 17 Apr 2018 09:28:12 GMT


----- Mail original -----
> De: "Jochen Theodorou" <blackdrag@gmx.org>
> À: "Remi Forax" <forax@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

Mime
View raw message