Impact of six month releases

Lindenmaier, Goetz goetz.lindenmaier at
Fri Nov 3 10:23:55 UTC 2017


I share the concerns mentioned in this thread.
I just picked up work on our internal "next Java release after 8"
project, which now has been relabeled from '9' to '11', 
and has been delayed the third time now.

The first change I looked at was " 8173421: Obsolete and expired 
flags for JDK 10 need to be removed and related tests updated".

I think this change needs to be redone:  First it needs to 
be reverted, then one needs to replace '9' by '11' and '10'
by '17'.  Thus, the flags can be removed in jdk17 only,
which is in 2021.

I appreciate that Java moves forward faster, as adding 
JEPs as "286: Local-Variable Type Inference" need not
be delayed as long as it would have been in the old
release rhythm.
But deprecating stuff can only be done in the LTE releases, 
as most users will only see these.

We are happy that one of our larger products will go to 8
next year, finally!  For another product the installed base currently
is 6: 5%, 7: 65%, 8: 30% ... Other teams that had planned to go to 9
now will wait until 11. We, the JVM team, would like to see 
faster adoption of new Java version, as we don't like to keep 
supporting the old releases. But now the next LTE will be delayed 
another year. And adoption of JDK11 by these products
will be even harder if there are lots of sudden incompatible
changes ... and here sudden means from one LTE to another,
no matter how much time there is between LTEs.

Best regards,

> -----Original Message-----
> From: jdk-dev [mailto:jdk-dev-bounces at] On Behalf Of
> Ryan Schmitt
> Sent: Freitag, 3. November 2017 01:21
> To: Stephen Colebourne <scolebourne at>
> Cc: jdk-dev at
> Subject: Re: Impact of six month releases
> I have similar concerns along these lines. For example, JDK9
> introduced the "one plus three back" policy for cross
> compilation, such that javac in JDK9 can now only target JDK6
> and newer. Under the old release schedule, "one back plus
> three" could easily cover a decade's worth of JDKs, but now
> that window will shrink to approximately two years. There are
> similar questions around JDK deprecations: how long do my
> dependencies have to migrate to VarHandles and StackWalker?
> Three years or six months? Will we continue to have a new
> bytecode version with every release, or will the classfile
> format only be incremented as needed?

More information about the jdk-dev mailing list