Impact of six month releases

[Volker Simonis]

On Mon, Nov 6, 2017 at 8:31 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> Hi Stephen,
>
> I fully agree with all the points you've raised. BUT the OpenJDK is not the
> binary Java distribution most people use (similar to that fact that few
> people use a vanilla Linux kernel). It wasn't even available until recently!
>
> The vast majority has always used the Oracle JDK or the JDK that comes with
> their Linux distribution (not to mention all the other commercial and free
> Java distributions which are available as well). All these binary
> distributions are downstream versions of the vanilla OpenJDK project and
> they can all freely choose their support time frame and downport policy.
> Again, as an analogy, just think about how Linux distros support old Linux
> kernels and enhance them with down ports from newer kernels independently of
> the main kernel development. My personal opinion is that we will eventually
> come to a similar model with Java.
>

Thinking more about the Linux kernel analogy, I still think it is
mostly valid, however with one major exception. With the Linux kernel,
a distributor can freely choose to down-port arbitrary features from
newer to older kernels or support old kernel features in newer kernel
versions which don't have these any more by default.

With Java, this would only be possible with non-specification relevant
features (e.g. GC, AOT, CDS, etc). For specification relevant features
(i.e. new APIs, language fetures, etc) that would be not possible (at
least not if you'd still like to call it Java compatible. So for
example, you won't be able to downport "local variable type inference"
from JDK 10 (assuming it will get into there) to 9 if you'd like to
support JDK 9 for some long amount of time but don't want to support
JDK 10. Also, you can't decide for your "JDK N" distribution to still
support a standard API which was removed in "JDK N-1". That's of
course a major drawback compared to the Linux kernel model.

> From my understanding the "new release cadence" step has always been at
> least as much about reorganizing the Java support business as it was about
> innovation. And it seems that others are now slowly realizing this as well
> ;)
>
> Regards,
> Volker
>
>
> Stephen Colebourne <scolebourne at joda.org> schrieb am Fr. 3. Nov. 2017 um
> 17:41:
>>
>> On 3 November 2017 at 09:14, Andrew Haley <aph at redhat.com> wrote:
>> >> I think this is throwing the baby (Java's long standing backwards
>> >> compatibility) out with the bathwater (frequent releases), but I'm
>> >> happy to hear other opinions.
>> >
>> > I don't believe that such worries are necessarily justified.
>> >
>> > We need to be able to roll back mistakes.  The Java tradition that
>> > nothing ever gets removed, no matter how much mistaken, holds back
>> > innovation.  It does this because of a justified fear that if we make
>> > a mistake, we're stuck with it, so we have to be ultra-cautious.
>>
>> I think its more than that. Java's success is built on the broader
>> ecosystem. The JDK itself is an enabler for that. Open source projects
>> have to be able to produce jar files that work on multiple releases of
>> the JDK. Things that prevent that are a big issue.
>>
>> In practical terms I'd argue that:
>>
>> 1) LTS releases define the removal cycle. Code added in a  non-LTS
>> release (n) can be deprecated in the next non-LTS release (n+1) and
>> removed in the release after that (n+2). This works because the code
>> was never in an LTS release. However, code that *was* in the last LTS
>> release cannot be removed until the release after the next LTS.
>>
>> eg. code present in 8 cannot be removed until 12 (as 11 is the first
>> LTS where the deprecation is visible)
>> eg. code added in 12 can be deprecated in 13 and removed in 14 as 12
>> and 13 are non-LTS
>>
>> 2) There should be more than 2 security updates for each release.
>> Without an overlap period, developers are forced to upgrade to the
>> next release immediately it is GA. This does not reflect real-world
>> software development practice. If the non-LTS releases are to be used
>> in production they will need a bare minimum of 4 security updates (one
>> year) to create a time window overlap with the next release.
>>
>> 3) The javac --release flag should work for at least the last three
>> LTS releases. A time-window of 10 years would also be about right.
>> (Its a *really* convenient feature, and if possible I'd prefer it to
>> never lose support for older versions).
>>
>> Stephen