maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tibor Digana <tibordig...@apache.org>
Subject Re: JDK 13 - Early Access build 17 is available
Date Tue, 23 Apr 2019 10:51:06 GMT
The whole problem I see in Java is that people use "--enable-preview" and
the version of bytecode changed.
This means one JDK version is able to produce two bytecode versions.
Then we receive bugs in ASF Jira but they are not ours.

I remember that JDK development distributions could be downloaded from
Jenkins builds.
So, it would be fantastic situation to put such unofficial features (which
require a switch on CLI) only to SNAPSHOT versions and SNAPSHOT
distribution *(.bin) based on a "development" branch/es.
The release branches (releases/13.1, 13.1.1) should contain only official
features coved by JSL and JVMSec which cannot be taken back once they went
out in an official distribution.

Now the situation looks like you guys cut a "major release having only
minor official changes" hiding "unofficial major features" (Valhalla,
Shenandoah, ...).

I remember a product manager in Oracle says that same versioning principle
will be used in Java as it is know in OSS projects. Now it would mean the
versions 13.1.0, 13.1.1 for me.
If it was like this since of Java 9, we could still have official versions
10.x till now, and other unofficial distributions of binaries released
apart with experimental features where people can try out on their
responsibility.

Think about this model. You can propose it in OpenJdk for instance.
It's just a hint from me.

Cheers
Tibor17

On Tue, Apr 23, 2019 at 12:03 PM Dalibor Topic <dalibor.topic@oracle.com>
wrote:

> On 19.04.2019 22:21, Tibor Digana wrote:
> > Sorry guys but again, what did you change in the language?
>
> Hi Tibor,
>
> there are no language change JEPs (or other kinds) targeted to JDK 13
> yet. There is still almost eight weeks to go until Rampdown phase one
> starts, though. Please see https://openjdk.java.net/projects/jdk/13/ for
> details of the schedule.
>
> Based on the the JIRA status changes, I'd expect to see
> https://openjdk.java.net/jeps/350 as the first JEP proposed to be
> targeted for JDK 13 on jdk-dev after the Easter break, fwiw.
> > I don't see any significant change between Java 9 and 13 because I can
> > simply skip 4 versions...
>
> There are 12 JEPs in JDK 10, 17 JEPs in JDK 11, and 8 in JDK 12, for a
> total of 37 JEPs between JDK 10 and JDK 12. That's roughly 12 JEPs on
> average, which makes individual releases simpler to move on to, as was
> the goal with the new release model:
>
> "The six-month feature releases will be smaller than the multi-year
> feature releases of the past, and therefore easier to adopt."
>
> from https://mreinhold.org/blog/forward-faster
>
> So if you are not seeing significant issues in migrating from JDK 9 to
> JDK 13, then that's going according to plan. ;)
>
> > Does it make sense to cut a release because you have to that you have
> > milestones
>
> Yes, because predictability is a feature.
>
> Since the JDK is not an end unto itself, for a significant part of the
> ecosystem it's important to understand when a new release is planned and
> what shape it will likely take in order to be able to make their own
> plans or adjustments as necessary, in a predictable fashion.
>
> For a deeper discussion of the benefits of the new release cycle, please
> see https://adtmag.com/blogs/watersworks/2019/03/georges-saab.aspx?m=1
>
> Fwiw, some other platform-building communities in the Java ecosystem
> have embraced a regular release cadence, as well - from Eclipse (who led
> the way with their release trains and now moved on to a quarterly
> release cycle), to Wildfly (quarterly), and even OpenLiberty (monthly).
>
> cheers,
> dalibor topic
> --
> Oracle <http://www.oracle.com>
> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | D-22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message