HN Gopher Feed (2017-09-06) - page 2 of 10 ___________________________________________________________________
Moving Java Forward Faster
89 points by pron
https://mreinhold.org/blog/forward-faster___________________________________________________________________
filereaper - 4 hours ago
>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.
EddieRingle - 4 hours ago
I'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. :)
virtualwhys - 3 hours ago
> Faster Java & JVM updatesMore 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.
mreinhold - 2 hours ago
No, JVM enhancements will not be limited to LTS. If anything
it's best to merge them long before an LTS, so that they're
well-baked in the LTS itself.
virtualwhys - 1 hours ago
My point is that "smaller" features like pattern matching and
data classes will land in Java well before big ticket items
like value types; not that JVM enhancements will be strictly
limited to LTS.Of course, you have the inside word: when are
value types coming to the JVM? Hopefully by Java 10.
aardvark179 - 1 hours ago
Minimal value types will arrive as an experimental feature
at the VM level real soon now, language and library support
will take a lot more work.
tetha - 2 hours ago
As I keep saying, more and smaller releases cause a constant, low
amount of pain. That's good, because you avoid the teeth-yanking
bullshit of deploying 6 month of care-free development to prod. And
even though I hope the OpenJDK community develops more responsibly
than my devs, but the point still stands given scaled time frames.
newforice - 3 hours ago
As long as they stay away from the lambdas and FP trainwrecks that
was 8.
callinyouin - 3 hours ago
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.
newforice - 2 hours ago
You seem to have jumped to the conclusion that I haven't tried
the FP features. If I hadn't tried them, I wouldn't be
criticizing them. If I wanted to work in FP style, I would
choose an FP language; not encourage a traditional, solid
language to be perverted to do something that is completely
against the nature and design of that language.
jswizzy - 38 minutes ago
FP and OOP are compatible styles. In fact, I would argue that
FP is more object orientated than procedural code such as
loops.
shock - 2 hours ago
Since lambdas and streams are optional, what is your critique
of them?
sscarduzio - 3 hours ago
Slow 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.
exabrial - 1 hours ago
If you've never had a chance to meet Mark in person, he is an
incredible guy and a really nice person. Totally on-board with this
idea. The execution is going to be the tricky part.
doodpants - 4 hours ago
> 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?
organsnyder - 2 hours ago
Only if the first number is constrained to two digits. The
release from March of 2100 would be 100.3, which would work just
fine.
swsieber - 3 hours ago
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.
fauigerzigerk - 2 hours ago
Imagine the shock when our descendents wake up on Jan 1 2118 and
all their systems are accidentially running on a 100 year old JVM
:)
pron - 7 hours ago
See 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.