Impact of six month releases (original) (raw)

David Holmes david.holmes at oracle.com
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:

AutoGCSelectPauseMillis UseAutoGCSelectPolicy UseParNewGC ExplicitGCInvokesConcurrentAndUnloadsClasses CMSMarkStackSizeMax CMSMarkStackSize G1MarkStackSize ParallelMarkingThreads ParallelCMSThreads

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

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 openjdk.java.net] On Behalf Of Ryan Schmitt Sent: Freitag, 3. November 2017 01:21 To: Stephen Colebourne <scolebourne at joda.org> Cc: jdk-dev at openjdk.java.net 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