Moving Java Forward Faster
mreinhold.org
Moving Java Forward Faster
1–10 of 84 posts
Re: Moving Java Forward Faster
#2See also:
* Accelerating the JDK release cadence http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe...
* Faster and Easier Use and Redistribution of Java SE https://blogs.oracle.com/java-platform-group/faster-and-easi...
Oracle will also ship binary distributions of OpenJDK, and OpenJDK will become the canonical JDK distribution.
Re: Moving Java Forward Faster
#3> To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form $YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9.
Shouldn't those version numbers be 2018.3 and 2018.9? Have we learned nothing from the Y2K bug?
Re: Moving Java Forward Faster
#4>So, let’s ship a feature release every six months.
I agree with the proposed plan, when I worked on the JVM, there was a mad dash to get features in by a certain date, otherwise you'd have to wait till the next release of Java to ship your changes.
From interacting with the service teams (L3 and above) customers prefer new features in a new version of Java, with the long release cycles, you have to ship new features in a service packs which made the service team queasy.
It also removes the stigma that Java and its ecosystem is slow compared to V8, .NET and the other platforms.
Re: Moving Java Forward Faster
#5I'm fully in support of defined, rolling release trains. 6 months is a good start considering where they're coming from. I feel like that's still slightly too long though, and is one of the things I wish the Go team would change. The Go team's argument is that it takes time to fully test features before being able to release them, which I understand, but that's the whole point behind a multiple release train model.
But I digress. Faster Java & JVM updates will help Kotlin out as well moving forward. :)
Re: Moving Java Forward Faster
#6As long as they stay away from the lambdas and FP trainwrecks that was 8.
Re: Moving Java Forward Faster
#7Slow releases weren't the only problem. Sometimes they even promised things that one year into development would be candidly postponed of other two years. I can't recall of any project being managed as poorly.
Re: Moving Java Forward Faster
#8As long as they stay away from the lambdas and FP trainwrecks that was 8.
I can't tell if you're being sarcastic, but I'm guessing you aren't. Anyway, from a full time Java developer's perspective, lambdas and the FP stuff added to Java 8 have sort of been a holy grail. Filtering with streams have single-handedly made my life as a developer measurably easier, but then again I'm a back-end web dev so it comes up a lot. If you're a Java developer, I'd strongly recommend going back and trying some of these features because they really are quite nice once you get the hang of them.
Re: Moving Java Forward Faster
#9> To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form $YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9. Shouldn't those version numbers be 2018.3 and 2018.9? Have we learned nothing from the Y2K bug?
I don't really think that applies? If anything, you know that you can add 2000 to the version version number to get the year.month... if we're to the point where that rolls over, I think we have much bigger problems.
Re: Moving Java Forward Faster
#10I'm fully in support of defined, rolling release trains. 6 months is a good start considering where they're coming from. I feel like that's still slightly too long though, and is one of the things I wish the Go team would change. The Go team's argument is that it takes time to fully test features before being able to release them, which I understand, but that's the whole point behind a multiple release train model. B…
> Faster Java & JVM updates
More likely faster updates will be to Java itself, while JVM enhancements will be limited to LTS.
Pattern matching and data classes, for example, will arrive far sooner in Java than value types in the JVM.