
Moving Java Forward Faster - pron
https://mreinhold.org/blog/forward-faster
======
pents90
This may be an unpopular opinion, but I don't want Java to move forward
faster. I don't really want it to move forward much at all unless there is a
huge, tangible benefit from the new feature(s). I am of the belief that
programming languages should be a solid, fixed foundation on which lasting
software can be reliably built. Every time a feature is added to a programming
language, it becomes larger, more complex and harder to learn. Rapid changes
to languages can also result in regrets, and it is essentially impossible to
take something back in language development.

In general, I think too much stock is put into language features, perhaps
because many developers are bored with the actual software they are
writing/maintaining, and so new language features are relatively fun. As a
mental experiment for those who know both Java and Kotlin, or both Java and
Scala: Suppose you were asked to estimate the time required to implement a
system in Java, and you arrived at an answer of 2 months. Now what would be
your estimate for the same system, but written in Kotlin? How about Scala?
Admit that it would be the same. (Well, probably a little longer for Scala,
but just because it takes forever to compile, ha.)

~~~
Latty
I think that _good_ languages offer features that make your code better, not
let you write it faster.

Sure, it may take me two months to write that thing in Scala still, but I'll
have more confidence it will work well, and it'll be nicer to read, maintain
and work with moving forward.

Scala is an interesting example for this, because the language is a grab-bag
of features that definitely can be abused by people who don't know better,
it's definitely easy to write _worse_ code in it.

The reality is there is an easy blueprint for Java, because C# is Java, but
done better. It's moving at a good clip, but the features coming in are very
useful and well thought out.

~~~
crumbles
> I think that _good_ languages offer features that make your code better, not
> let you write it faster.

And _great_ languages let you do both.

~~~
brianwawok
And what do you define as a great language?

Language greatness is pretty subjective and task specific. There are some
languages I will never declare great (i.e. PHP, JavaScript, Ruby), but others
could be great for different tasks..

~~~
crumbles
> Language greatness is pretty subjective and task specific. There are some
> languages I will never declare great

If greatness is subjective AND task specific, then the languages you will
never declare great could be considered great by others for the tasks they
perform. And by your own admission if they were great subjectively AND for a
particular task, that would make those languages great. But, you still claim
that you would never declare them great?

------
filereaper
>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.

------
haglin
This is a major change:

"After JDK 9 we'll open-source the commercial features in order to make the
OpenJDK builds more attractive to developers and to reduce the differences
between those builds "
[http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe...](http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html)

Java Flight Recorder will be open source.

~~~
sitepodmatt
To be honest I didn't even know what Java Flight Recorder was - and I've been
doing Java, Clojure and Kotlin for a number of years. I don't see this being a
major change for those that have always been on OpenJDK

~~~
pjmlp
I use Java since its introduction in 1996, never installed OpenJDK other than
when it came by default on some random Linux distribution.

Java Flight Recorder and Visual VM are great tools, only matched by .NET ones
to monitor application performance.

------
pron
See also:

* Accelerating the JDK release cadence [http://mail.openjdk.java.net/pipermail/discuss/2017-Septembe...](http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html)

* Faster and Easier Use and Redistribution of Java SE [https://blogs.oracle.com/java-platform-group/faster-and-easi...](https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se)

Oracle will also ship binary distributions of OpenJDK, and OpenJDK will become
the canonical JDK distribution.

------
EddieRingle
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
> 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.

~~~
mreinhold
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
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
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.

~~~
hugi
Giggidy!

------
linuxhansl
+1000

We did this (at a much smaller scale) with Apache HBase (starting at 0.94,
which I release-managed). We went to a monthly release cadence.

We saw the frantic last minute commits just before a release (and followed by
multiple smaller releases just after the big release to stabilize the code
base) essentially vanish. If the feature wasn't done, it simply got in a month
later.

For us it required an "transitive compatibility" (i.e. one can go from version
X to version X+3 without upgrading to X+1 and X+2 first), and stable
functional tests, so that confidence in a release is automatic and does not
need to be established manually.

------
karianna
Hi All,

I represent the London Java Community (LJC) on the Java Community Process
(JCP) Executive Committee (EC), aka the Java standards body. I also help run
the Adopt OpenJDK programme for OpenJDK outreach and onboarding new developers
to work on Java itself.

Now that the acronyms are out of the way :-). We're working at the JCP with
Oracle to streamline the standardisation process in order to facilitate these
faster releases and provide other Java vendors the ability to run their
reference implementations against an in flight Technical Compatibility Kit
(TCK), which is what you need to pass in order to call yourself Java.

I'm really, really pleased that Oracle is increasing the cadence. Java 9
allows for incubation modules and so if something isn't ready, it can simply
be put in there for early testing without it impacting the main release.

Some folks asked about alternative platforms. In terms of providing high
quality releases of OpenJDK for alternative platforms we've created a portal
at [https://www.adoptopenjdk.net](https://www.adoptopenjdk.net) with the build
farm run via [https://ci.adoptopenjdk.net](https://ci.adoptopenjdk.net) (code
in various repos at
[https://www.github.com/AdoptOpenJDK](https://www.github.com/AdoptOpenJDK)).
We've only just received the Java Test Compatibility Kit J(TCK) from Oracle
and once we have the binaries tested against that then folks will be able to
get the latest OpenJDK binaries for all of the esoteric platforms (ARM, z360,
AMD variants, AIX, Solaris and so forth).

We'd love for folks with devops skills to come and join us (Docker, IaaS,
Jenkins, make skills welcome).

If you have any specific questions please throw them my way!

------
tetha
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.

------
doodpants
> 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?

~~~
fauigerzigerk
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 :)

~~~
greydius
I just had the horrible realization that java will still exist in 2118.

~~~
goatlover
They'll be running the JVM in a Docker container in Linux written in JS in the
browser compiled to web assembly running on a Rust WebOS. But it will be okay,
because it the hardware will be a 1024 core quantum processor.

------
exabrial
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.

------
s73ver_
It'd be nice, but being an Android guy, I'd see zero benefit, as Google has no
good way to push out updates to their VM.

~~~
haglin
Maybe Google should use openJDK instead of using their own proprietary version
of Java.

No one benefits of fragmentation.

~~~
bitmapbrother
As of Android 7 they do use the OpenJDK. If you're implying that they should
replace the Android SDK/ART with OpenJDK/JVM then that would be foolish. The
OpenJDK and JVM were never designed to work within the constraints of embedded
mobile devices.

~~~
haglin
Why can't Google submit patches to make it work for embedded devices? I don't
see the point of a separate version of Java. Imagine if you could develop
Android apps against the latest version of Java.

~~~
sk0g
And Google should spend their time and money improving Java, owned by a
company that massively sued them?

~~~
pjmlp
Apparently the server team does exactly that!

Search for Google.

[http://openjdk.java.net/projects/mlvm/jvmlangsummit/agenda.h...](http://openjdk.java.net/projects/mlvm/jvmlangsummit/agenda.html)

[http://openjdk.java.net/projects/mlvm/summit2014/agenda.html](http://openjdk.java.net/projects/mlvm/summit2014/agenda.html)

------
sscarduzio
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.

~~~
preordained
Java is the worst managed project you've ever heard of? You must live a
charmed life.

------
newforice
As long as they stay away from the lambdas and FP trainwrecks that was 8.

~~~
callinyouin
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
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.

~~~
shock
Since lambdas and streams are optional, what is your critique of them?

~~~
s73ver_
I'm guessing they work on a team, and other members of the team are using
them.

