Please stop incrementing the classfile version number when there are no format changes (original) (raw)
Cédric Champeau cedric.champeau at gmail.com
Fri Oct 11 14:15:42 UTC 2019
- Previous message: Please stop incrementing the classfile version number when there are no format changes
- Next message: Please stop incrementing the classfile version number when there are no format changes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi folks,
There are different issues mixed in here. As Brian said, this is not a new issue. The newish thing is the pace at which this is happening (every 6 months), which makes it harder for our users because they need to upgrade Gradle versions more frequently (of course, nobody forces them to upgrade to a newer JDK but that's what everybody encourages them to do).
Regarding Gradle, there are different pieces in play:
- the Groovy runtime, which itself uses ASM. This is, sometimes, a problem, which requires us to upgrade the Groovy version. Since we often saw regressions in the Groovy runtime we tend to be picky on updates. However, for folks using the Kotlin DSL, this is not a problem.
- Gradle runtime: as Rémi said, you can run Gradle on JDK 11 and fork compilation to use JDK 7 to 13 (yes, we still support 7). However, there's an additional thing in play here.
- Gradle performs bytecode analysis, to extract the public API of compiled classes and allow compile avoidance (avoid recompiling downstream dependencies if nothing changed in the public API). For this, we use ASM too, and every change in the class format forces us to upgrade ASM. This is the most problematic bit, because even if you fork compilation, we can't analyze the generated class files (because it's done in the snapshotting phase which is in the Gradle process itself).
So in practice, yes, Gradle is affected by this fast pace, so it would help if class format versions were updated "if there's a change". Now I'm not qualified to tell when such a change is relevant, just wanted to give more details.
FWIW, Gradle 6 is planned to be released this month, with an RC next week.
Le ven. 11 oct. 2019 à 15:58, Dalibor Topic <dalibor.topic at oracle.com> a écrit :
On 11.10.2019 15:15, Dalibor Topic wrote: > On 11.10.2019 14:45, Mike Hearn wrote: >> We tried our app with Java 13 but discovered Gradle doesn't work, so we >> can't build it. > > I would suggest asking about timing of Gradle support for JDK 13 at the > Gradle project. > > Gradle was made aware of issues with JDK 13 EA builds on March 4th: > https://github.com/gradle/gradle/issues/8681 . Judging by the answer in > https://github.com/gradle/gradle/issues/8681#issuecomment-532507276 > support for JDK 13 would be scheduled for Gradle 6.0. > > Unfortunately, I'm not aware of a public schedule for Gradle releases > like we have for the OpenJDK, so it's not possible to tell when it would > be available. Fwiw, the Gradle 6.0 release nightly builds seem to include support for JDK 13, according to https://docs.gradle.org/release-nightly/release-notes.html#java-13 . cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Consulting Product Manager Phone: +494089091214 tel:+494089091214 | Mobile: +491737185961 tel:+491737185961 | Video: dalibor.topic at oracle.com <sip:dalibor.topic at oracle.com> Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRB 246209 Geschäftsführer: Ralf Herrmann <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
- Previous message: Please stop incrementing the classfile version number when there are no format changes
- Next message: Please stop incrementing the classfile version number when there are no format changes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]