Please stop incrementing the classfile version number when there are no format changes

Cédric Champeau cedric.champeau at gmail.com
Fri Oct 11 14:15:42 UTC 2019


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
>


More information about the jdk-dev mailing list