Hacker News Reader

I agree. I find the VM stuff the most facinating too, but I think you're underestimating the incredible impact language changes have had and continue to.

Language changes don't aren't just bells and whistles. Lambdas changed how nearly every API works and record types have the opportunity to make a huge difference. Sure var was smaller, but it's been refreshing.

I also think you're underselling how conservative the old minor patches used to be. With major versions this frequent LTS atleast sets a reasonable cadence for planning and movement. 6 months is hectic.

6 months is not hectic, because the new feature releases are not major releases. In fact, major releases are gone, the last one ever being 9.

Up until JDK 9, there used to be patch releases every couple of months, and big feature releases (which used to be called "limited updates") every six months. In addition to bug and security fixes, those included large, potentially disruptive features — like JavaFX and support for Linux on Arm in 7u6, Java Flight Recorder and Mission Control in 7u40, AppCDS in 8u40, and even support for Mac OS and a new GC algorithm in 7u4. Those releases also stopped getting patches after six months, when the new one was released, i.e. there were no more patches for 8u20 once 8u40 came out. Now, despite having major, disruptive features, those "limited update" releases were not allowed to change the Java SE spec, so they couldn't change the language or the library API. There were serious problems with the old model, so Oracle decided to do away with major releases altogether. To do that, they relaxed the limitation on spec changes in the six-monthly feature releases, and also changed their name. Instead of 8u40, 8u60 etc., they now get a new integer number. If you don't want to use new API and language features (you can even turn them off with the --release flag), those releases are almost the same as they used to be. If their six-month cadence between 8u40 and 8u60 was good enough for you back then, there's no reason it shouldn't be now.

(I work on OpenJDK at Oracle, but speak only for myself)

Man, I disagree. For large enterprises, six months is a ridiculous pace to package/distribute a new major version. The fact that it is just enhancements does not matter. It may seem simple, but most implementations have that integer as part of the deployment path. The aggressive deprecation/removal in the 'major' six month cycle has been rough. If this is my local workstation, no worries. It creates chaos on work systems, however.

(Did a decade+ at Oracle, and now at a shop three times its size. You should understand inflexibility and moving at the speed of business. :P )

There still are quarterly patches to the LTS releases (7u241, 8u231, 11.0.5), with the next batch due the second week of January for all the LTS versions - 7/8/11 on the Oracle side, 8/11 on the Adopt OpenJDK, and other OpenJDK implementations possibly supporting all three. Almost every other organization I've talked with is sticking to the LTS, with plans to jump from JDK 11 to JDK 17 when it comes around. (and hearing the woes of all the folks still trying to get past JDK 8)

> six months is a ridiculous pace to package/distribute a new major version

I agree, which is why we've done away with major releases altogether. There have been feature releases every six months with major new features for over ten years now. All that's changed is that we've changed how they're named and removed the major releases. And if you've found it acceptable that the 8u20 feature releases stopped getting patches after six months, and upgraded to 8u40, it shouldn't matter much that we now give those versions an integer number. Not only do you not need to package a new major release every six months, but you don't need to package a new major release ever again!

Your assumption that it's significantly harder to switch from 11.0.2 to 12 than it is to switch from 11.0.2 to 11.0.3 does not seem to be based on any data we've seen. Most organizations that can do the latter can do the former. Not only the result will be cheaper and easier overall, but you'd get to enjoy all the performance and serviceability features even if you don't want to use new language/library features.

> Almost every other organization I've talked with is sticking to the LTS, with plans to jump from JDK 11 to JDK 17 when it comes around.

That will change soon (it already is changing), as more people understand the new model and the change to the version names. However, even if you are certain that your choice of LTS is justified (and I must say that it doesn't seem like you fully understand the new model yet -- which is OK, many don't, and it will take time), you must test your code on the current JDK. Updating from 11 to 17 without doing that is taking a huge risk. You will see features disappear without deprecation warnings.

> However, even if you are certain that your choice of LTS is justified (and I must say that it doesn't seem like you fully understand the new model yet -- which is OK, many don't, and it will take time), you must test your code on the current JDK.

I think this the italicized portion is the disconnect between what Oracle wants Java users to do, and what they'd rather not do. I know the pain of wanting your users to always be on the latest and greatest version, but in my experience, medium-to-large corporates are extremely risk averse and would rather invest time upfront to do testing/qualifying software releases before deploying, then keep that deployment running for as long as possible with the assurance that the configuration is stable (or at least has known & documented failure modes). They understand the new model just fine - they just don't want it. Mostly because it introduces a lot of risk and/or requires continuous qualification, which is not only expensive but completely changes the way they operate.

I understand that, I'm just saying that if your risk calculation concludes that LTS is less risky by default, then it's based on false assumptions, based on misunderstanding. The new feature releases are not major releases. If companies were fine upgrading to feature ("limited update") releases while there were still major releases around, I don't see why they would be more risky now that major releases are gone. I think that people can perceive them to be more risky because they confuse the change to the way those releases are named with the old major releases. For some companies, getting an LTS service is less risky, but not because of some intrinsic quality of LTS but because of their particular internal processes. For a great many companies, sticking to the default, gradual update process is the cheapest, least risky option.

Moreover, there are also special risks to LTS programs, particularly the free ones. A much smaller number of people work on them (about 1/50 of the total number of people working on OpenJDK), and they completely rely on backports from the mainline. So, for example, once the CMS collector is removed from the mainline, it becomes unsupported in some LTS programs (certainly the free ones) because there are no longer fixes to backport, and they don't have the resources to fix bugs without backports.

Finally, you can't talk about risk and treat LTS as a single thing, as the different LTS programs vary greatly in their risk vs. conservativeness. The Oracle LTS service contains almost only true patches: bug and security fixes, like the first two patches for each feature release. Red Hat's LTS/OpenJDK Updates and Azul's Zulu backport huge new features in their "patches." Amazon considers (or considered) taking the current VM and backporting it as a whole to an old JDK version in a "patch."

> I understand that, I'm just saying that if your risk calculation concludes that LTS is less risky by default, then it's based on false assumptions, based on misunderstanding.

I agree with you - and I don't think LTS have less inherent risk. The distinguishing feature of LTS releases is the length of support - you can still release minor versions weekly, but still bless every 25th minor release as the LTS versions and it would work out the same because the users will know that version will get support for X years without full requalification.

You could very well be right about the 3rd-party patches/back-porting (I'll take your word for it, I'm now at the periphery of the JDK world), but their existence could be a sign of how Java users are desperately unprepared to support evergreen releases.

They're not evergreen. The last major Java release was 9, two years ago. Since then, Java has had a perpetual stream of free support.

The very notion of a "support period" becomes less relevant because what is the version that is being supported? It used to be a major release but that is now gone. The old six-monthly feature releases were also "supported" by patches for only six months. There were no more patches for 8u20 once 8u40 came out, and people were fine with that and not desperate at all. So now that we name a version 12 instead of 9u60 it's not fine? If you like, you can think about it as if we're on Java 9 forever, with an eternal support period. It's just that how the versions are named has changed.

People still don't understand the meaning of the new versions and the change to the version naming scheme. With time, they will. In the meantime, some of them still apply old terminology to new concepts and reach wrong conclusions.

> Updating from 11 to 17 without doing that is taking a huge risk. You will see features disappear without deprecation warnings.

If upgrading from one stable release to the next stable release removes features without a deprecation period, something's wrong with the release model.

No, stable releases do get deprecation warnings, but that's not what LTS is. LTS is a service that's added by vendors to arbitrarily chosen versions. In fact, there is no such thing as "an LTS release." You can start offering LTS for JDK 12 tomorrow, making it -- retroactively -- LTS. The OpenJDK development process doesn't take those services into account; in fact the development process has no notion of LTS at all (e.g. can you see LTS mentioned here https://openjdk.java.net/projects/jdk/11/ ?). All feature versions are equal in their stability. LTS is something a release can have, not something it is. All versions between 11 and 17 are stable, and none of them -- including 11 and 17 -- are major releases. Those are gone.

LTS is a service designed for organizations with special constraints, and should be no means be your default choice. Moreover, there are multiple LTS services and they differ quite widely in what they offer and who they're aimed at. Put simply, LTS does not mean what it means in other projects. Do not choose it until you've learned exactly what the new model means and what LTS means.

Versions 12 to 16 are/will be stable releases.

Language changes are super important when they enable you to program in a new way, or in that way with significantly less boilerplate. For instance, Java 8 enabled new ways of programming via Lambdas and structural typing. You could code in that way before, but anonymous class boilerplate was so high that few bothered, and those that did were hard-pressed to convince their colleagues of its value.

The problem with language changes is that to make use of them, your developer community has to educate themselves on the new features and how to use them. Certain VM changes like new GC algorithms often don't require this, as the basic interface of the GC is the same (clean up garbage for me, thanks!).

I think the next big programming style Java may enable is what I call data-oriented programming, which is enabled via sealed types and pattern matching. This enables you to code the dual of OO, where you have a fixed number of sub-types but an unbounded number of operations. I believe this style of programming is useful far more often than it is used, simply because Java doesn't make it easy to code in this style.

Other future changes I am excited for, but don't expect to get implemented any time soon, if ever, frankly, are:

* Improved native code interop. I consider this to be both a language and VM change. * Improved memory layout control, including stack-allocated types and inlined objects inside of other objects. * project loom for golang-style I/O programming. * full tail recursion. Why was this feature rejected from the VM?

> Other future changes I am excited for, but don't expect to get implemented any time soon, if ever, frankly, are:

Most if not all of them will land in the next few years. In fact, working on those precise features is what most of the OpenJDK team does.

> Improved native code interop. I consider this to be both a language and VM change.

That would be Project Panama, making its initial, partial delivery in JDK 14 (GA next March, EA available now).

> Improved memory layout control, including stack-allocated types and inlined objects inside of other objects.

Project Valhalla. The most complicated of the bunch. Just had a recent major breakthrough, and you can work with the EA release already.

> project loom for golang-style I/O programming.

Working on it :)

> full tail recursion. Why was this feature rejected from the VM?

Not at all rejected. It's still a goal for Loom. We'll just do lightweight concurrency first. Cost/benefit prioritization etc.

Utterly dumb question but why is tail recursion necessary in the JVM given that the compiler is better placed simply to turn recursion into a loop. TR removal should be done best at the highest level I'd think.

The compiler can only make this transformation in special cases, in particular, when it doesn't break any of the JVM's semantics (also, not all recursion is self-recursion, i.e. a tail call to the subroutine you're in). You can't just discard a frame of a call in a tail position, because some security mechanisms require knowing the full call-stack (plus, developers might hate you when their stack traces start missing crucial frames). So we're talking about explicit tail calls, in places that can be checked for the safety of the optimization.

> the compiler is better placed simply to turn recursion into a loop

How do you think it should do this? While keeping the semantics of Java.

> For instance, Java 8 enabled new ways of programming via Lambdas and structural typing

What does structural typing refer to in this context?

> One thing I find a bit disappointing is the focus on language features. Most of the effort in Java goes into the VM and libraries, while keeping the language conservative. This is because VM/library features have a much bigger impact on application quality, and more directly impact the application's users; moreover, it's a strategy that's proven quite successful.

I think people have taken note of the success of Kotlin, and decided that judiciously chosen language features will help user retention/adoption.

The thing I find disappointing is the lack of bytecode changes.

The language changes are all just trivial tweaks to javac. Appreciated niceties, sure, but nothing meaty. The VM changes are then likewise focused mostly on the GC. Again, appreciated, but it's entirely disconnected from the language.

Where's the long-overdue improvements to the bytecode? Where's value types? Where's runtime generics?

It's not true that the VM changes focus mostly on the GCs. There have been significant changes to startup time and low-overhead profiling. And there are constant improvements in the JIT compilers. Project Loom's lightweight concurrency also involves big VM changes, but without any bytecode changes.

Reified runtime generics for reference types is a bad idea; it destroys language interop for very little gain. Value types and specialized generics for value types, on the other hand, are in the works. You can download and play with them here: http://jdk.java.net/valhalla/

> One thing I find a bit disappointing is the focus on language features

Overall, I wouldn't underestimate the importance of syntax features. After all, if a developer likes writing your language, they'll more likely choose it over a different language.

I agree because I use the JVM but I do not use Java. So I care about changes to the JVM and ecosystem but changes to the Java language itself don’t mean anything to me.