Impact of six month releases

David Holmes david.holmes at
Mon Nov 6 01:33:50 UTC 2017

My apologies Goetz, what I stated was incorrect for some of the flags ...

On 6/11/2017 11:05 AM, David Holmes wrote:
> Hi Goetz,
> On 3/11/2017 8:23 PM, Lindenmaier, Goetz wrote:
>> Hi,
>> 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.
> 8173421 is NOT deprecating stuff, it is removing flags that are as-of 
> JDK 9 (if not earlier) completely unused - that is what "obsolete" means.

Some of the GC flags were deprecated in 9 and expired in 10:


Normally you would expect to step through deprecated -> obsolete -> 
expired in subsequent releases. However the GC team decided it was 
appropriate to remove them more aggressively (though the only difference 
between obsolete and expired is whether the flag can appear on the
command-line without causing an error).

Of course at the time this was pushed there was no knowledge that 10 
would be anything other than the next major release.

The argument being made now is that a product flag deprecated in one LTS 
release, should not be made obsolete until the next LTS release, and 
then expired in the following LTS release. Personally I feel that would 
be far too limiting and defeat the primary purpose of having six month 
releases as we would need to keep the code pertaining to those flags for 
many years. As a case in point it may be that the changes to GC that are 
already in JDK 10 would not allow for the restoration of the flags that 
have been removed.


> David
> -----
>> 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,
>>    Goetz.
>>> -----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