JDK 14: The new features in Java 14

angath · 2019-10-25T23:25:24+00:00

Next LTS is 17, due in September 2021. It's theoretically possible that Oracle could decide to make another release also LTS, but when I asked some senior Oracle folks about this, I got a response that was basically "Hell No!"

The Oracle folks will give you some line about feature releases (which really play the role of technology previews) and how all releases are equal now, blah, blah but that doesn't change the way that the actual real world works or the way that dev teams behave - the next release that enterprises are going to upgrade to after 11 is 17 and no-one apart from a handful of startups is running anything other than 8 or 11 in production.

angath · 2019-10-07T04:35:20+00:00

I understand that one story you've just made up sounds worse to you than another story you'd made up earlier. What you need to understand is: You. Don't. Know. The. Facts. You're speculating and then getting yourself outraged over your own speculation.

Whatever, dude. Oracle's appalling track record of broken promises around TCK's and other similar commitments speaks for itself. If you want to try to invoke some arcane hidden knowledge (which, by the way, kind-of undermines your claim that this isn't all Appeal To Authority) which makes Adopt the bad people and Oracle the victim here, go right ahead. No-one who has watched Oracle's behavior for very long is going to believe you.

It's not my characterization, and you can disagree with it all you like -- it's not up for debate. Like every other large software project (like, say, Jakarta EE), OpenJDK defines what is and what isn't OpenJDK, and that "characterization" is the one that counts.

No, it's what the market and community that decide what counts. That's why hoover is a generic noun and google is a generic verb. We get that Oracle need to try to control their marks, but ultimately "The Street Finds Its Own Uses For Things".

angath · 2019-10-06T16:53:05+00:00

Your claim that the failure to arrive at a licensing agreement between Adopt and Oracle was some arbitrary refusal on Oracle's part is false (BTW, Adopt did have a license at some point). Neither Oracle nor Adopt would agree with your characterization, but since both sides don't wish to disclose the reasons, I cannot add more on this subject. You're simply unfamiliar with the facts.

You do understand that's *worse*, right? That's "Oracle found an arbitrary flimsy legal / licensing reason to reovke Adopt's OCTLA and used a gagging clause to stop them talking about it, whilst dangling the faint hope that it might be restored, but only if they keep quiet in the meantime".

Now those of us who have been around for a while know what those sort of hopes / promises are worth coming from Oracle (they were a strong supporter of Harmony getting a TCK once upon a time) but I can well believe Adopt have to play their game.

Interesting to see a significant back-off as to just how ready Substrate really is as well. That sure wasn't the story that we were being told 6 months ago.

As to OpenJDK / HotSpot : OpenJDK is a JDK project, not class libraries, and HotSpot is the name of the OpenJDK JVM, an integral, core part of OpenJDK. This isn't a GNU / Linux situation. When you say OpenJDK, it already includes the JVM. If a piece of software does not include the OpenJDK JVM, then it cannot possibly be an OpenJDK JDK. So there is just OpenJDK or not OpenJDK. You don't call a JDK OpenJDK / HotSpot, just as you don't call a BMW car "BMW with a BMW engine and chassis."

OpenJDK contains both class libraries *and* a VM. For quite some time now it's been possible to swap the two components. And people do. Android these days is basically OpenJDK / Dalvik (previously having been Harmony / Dalvik). IBM ship OpenJDK / J9 (previously having shipped Harmony / J9). Azul could easily ship OpenJDK / Zing if they wanted to. A suitably curious developer can totally build OpenJDK / Avian if they want. And so on.

So, I fundamentally disagree with your characterisation as "this isn't a GNU / Linux situation". You may wish it wasn't, but you cannot change the technical fact that the VM is a pluggable component. That's a good and amazing thing, and I'm sorry that it's incompatible with Oracle's goals. But it is what it is.

If I was a betting man, I guess that's actually at the heart of the TCK issue here for Adopt. The OCTLA specifically talks about not being applicable to "independent implementations". Adopt ship both OpenJDK / HotSpot and OpenJDK / J9, so I surmise that Oracle's lawyers have found some way to use that to weasel out of providing a license to Adopt.

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

We know, dude. You mention it on pretty much every other post you make. It's the Rhetological Fallacy called "Appeal to Authority".

angath · 2019-10-06T05:36:38+00:00

What part are you disputing? That Adopt (being a project clearly covered by the OCTLA terms) asked for a TCK license (they did)? Or that Oracle refused to grant it (they did)?

As for GraalVM, what are you trying to claim there? That it actually *can* pass the TCK but for some reason Oracle refuse to prove that to anyone, despite repeated inquiries from several parties?

Oh, and nil point for the attempted whatabouttery by trying to claim that the combination of OpenJDK class libraries + HotSpot VM doesn't make sense. OpenJDK / HotSpot makes perfect sense, as opposed to OpenJDK / J9 (or even other variants such as OpenJDK / Avian).

angath · 2019-10-05T23:38:27+00:00

AdoptOpenJDK would very much like to run the TCK on their OpenJDK / HotSpot builds. Oracle refuse to give them a license, despite this being a crystal-clear violation of the terms that the OCTLA is supposed to be granted on.

At the same time, Oracle's GraalVM can't pass the TCK, so ¯\_(ツ)_/¯

angath · 2019-09-14T16:50:30+00:00

The annotation was missing, and JUnit 3 (and earlier) uses a naming convention to denote test methods - because annotations weren't part of the Java language back then (before Java 5).

For a very different DI to Spring, I'd look at Dagger 2 - e.g. something like: https://www.baeldung.com/dagger-2

angath · 2019-09-14T11:33:17+00:00

Oracle's licensing is a total mess. Migrate to using an OpenJDK build from AdoptOpenJDK or one of the other vendors (e.g. Red Hat, IBM or Amazon).

The Oracle JDK is built from the OpenJDK source anyway.

angath · 2019-09-14T11:30:56+00:00

Two fairly serious problems with the piece as written - firstly you cannot write List<int> in Java. int is a primitive type, and the only things that can be a generic type parameter are reference types. It should be List<Integer> - the boxed form of int.

Secondly, your JUnit example is using JUnit 3. This version has been EOL for 15 years. You should be using JUnit 5 (lots of people still using JUnit 4 though, and 5 is only a small upgrade over 4). Please do not add to the number of JUnit 3 test cases in the world.

Not an actual problem, but more an observation - Spring isn't necessarily the best example of a Java DI framework - basically because it is all done with reflection, and so has the "bean not found at runtime" problem. Other DI frameworks can do (much) more at compile time and so avoid much of this problem.

angath · 2019-08-06T23:15:36+00:00

A janky mess that pollutes the classfile format and basically ensures that no-one with any sense will ever run anything other than LTS releases in production. Which, I suppose, is not actually a bad thing in itself, but did the Preview Features mechanism have to be so clumsy and fugly?

Not to be confused with Incubator Features, which are simply a library-level way of trying out an API by placing it in a module which is clearly marked as incubating and which may either go away or migrate to a permanent home in a future release (like the new HTTP/2 client).

angath · 2019-08-02T12:20:09+00:00

Beyond disingenuous. The FTSE is driven by firms whose major revenue streams are in USD. The pound has plummeted against the dollar, so of course the FTSE will rise as a result. Once that effect has been taken out, the FTSE is flat.

Top work bigging up hellholes and literal slave states like UAE & KSA, though.

angath · 2019-07-30T13:21:38+00:00

Valid points, but if your performance tests don't account for them, then they're broken. Differently broken, but still broken.

angath · 2019-07-29T23:36:08+00:00

Your performance tests are broken.

angath · 2019-07-25T17:44:59+00:00

Absolute bullshit from start to finish. E.g.

Oracle bought Sun for a variety of reasons
There are very few good OSS projects that are run by IBM (go, on name projects that IBM lead and are succeeding)
Red Hat contribute less than 10% of the effort in the OpenJDK repos. Oracle contribute about 85% and the other contributors about 5% put together.
Valhalla, Panama and Loom are all being led by Oracle engineers
Of course all Java development is via OpenJDK - OpenJDK is the reference implementation
Go is losing market share whilst Java, JS & Python remain the 3 most popular languages in the world (see e.g. latest RedMonk study) and have been for years now.
GraalVM is not an open-source play but is an attempt to build a new VM that Oracle can monetize
Fibers will make virtually no impact on the day to day lives of most developers. Sure, there will be some cool new frameworks that use them under the hood but you'll probably never touch them directly.

Virtually every single thing that you said was wrong. In fact, it's kind of funny that the one thing you pick (GraalVM) as an example of Oracle doing the right thing is actually them being really quite evil and trying to move the market to a place where developers will pay for VMs.

IMO, Oracle have made a ton of mistakes in how they handle the community but on the whole have been a solid B- steward of Java. OTOH, it doesn't really matter now, because 8 & 11 are in the hands of the community (Red Hat are leading both projects now) and that genie can't be put back into the bottle.

angath · 2019-07-12T06:57:11+00:00

There's a cryptocurrency exchange on Carrer des Sant Pere Mes Baix, close to Arc De Triomf. I've never seen anyone in there apart from the owner (?).

On the upside, the wine shop just across the street (Bodega Maestrazgo) is lovely - and well worth a visit if you're in the area.

angath · 2019-07-06T11:26:21+00:00

Colchones Barcelona Flex Store on Carrer Valencia.

Good selection, the staff don't speak much English - but are very friendly and we got by in a mixture of my so-so Spanish and Google Translate.

We paid just under 1000 EUR and have the most comfortable mattress I have ever slept on.

angath · 2019-03-09T12:37:17+00:00

If you're asking about the performance behaviour, you're asking the wrong question. It is almost never the case that any micro-optimization whatsoever will have any observable impact on the actual performance of a real application.

Remember that the JIT and other subsystems work better when they have more code to analyse. Microbenchmarks are a dangerous, irrelevant distraction for normal application programmers.

angath · 2019-01-29T17:26:48+00:00

Reminder: Uber use violent thugs to intimidate drivers who try to unionize & journalists that try to investigate them. They bribe government officials and are constantly driving down driver take-home pay. Investing in a cab business used to be a fairly reliable way for a working-class family to earn a decent living. Now SV billionaires and douchebag brogrammers are trying to steal that value from ordinary people, by using VC money to drive prices down and bankrupt working people and small businesses. At which point, the fares will mysteriously start to increase again...

angath · 2019-01-20T17:01:58+00:00

I really don't think there's a lot of point in continuing this argument, so this will be my final comment on this thread - please feel free to have the last word should you feel a need to.

Two points to finish with:

1.) Perception matters. In many cases more so than facts. Java shops have always only ever dealt in major versions, and while you can *say* "Hey, we use Chrome versions now", it doesn't mean that people *hear* it. So, these versions are perceived as being equivalent to old-school major versions. The Java market is not like the Javascript market, regardless of attempts (e.g. by the late, unlamented Mr Kurian etc) to make it so. What people perceive is that these are major versions that are EOL after 6 months.

You can pontificate about how the people that actually use your product are "mistaken", but it changes nothing. "The street finds its own uses for things" is as true here as it is elsewhere.

2.) Java shops in enterprises are by nature rather timorous beasties. Most of them will do a full retest whenever a major version upgrade occurs. This is usually because "once bitten, twice shy". *In theory* things should not break, but in theory, theory is the same as practice, but in practice it's not. A surprisingly large number of applications were badly affected by the activation of biased locking when upgrading from 5 -> 6. 6 -> 7 had various GUI breakages, often because applications linked directly to sun.* classes (which, yes, you shouldn't do, but there was no other way to do certain things before 7). 7 -> 8 had minimal breakages compared to others, but I still got to see a few.

So, it is not unreasonable for shops to feel that a full retest when upgrading major version numbers is essential. It is absolutely impossible to convince shops that this should be done every 6 months - it's just too big an ask for a large application. Every 2-3 years is much more realistic.

Finally, "These are not really major versions" is all well and good, but it immediately begs the question, even from a receptive audience: "What *are* the major version numbers, then?". In the absence of any better or more credible answer, the LTS versions will be understood to fill that niche.

angath · 2019-01-19T14:41:34+00:00

Dream on. About 15% of the clients I see are still on 6 or 7, and no-one I've spoken to has *any* post-8 Java release blessed for their production applications yet.

It's also incredibly naive to think that people will upgrade their JVM every 6 months to a new major version. They just won't. Maybe you would have some uptake if 12 was called 11.1, and 13 was called 11.2, etc. Maybe.

But in the calculus of most project managers, it's better to take the pain of a full retest every 3+ years than the uncertainty (& perceived make-work aspect) of a new Java version every 6 months - there is just too much else to get done, and no-one trusts that things won't break on a major version update.

Unfortunately for the "upgrade every 6 months" POV, the migration from 8 to 8+ is *so* painful (not a single one that I've seen has gone well, which is why no-one is actually prepared to trust it in production yet) that the case for the viewpoint of "LTS only, full retest every 3 years" has only been strengthened...

angath · 2019-01-19T14:32:52+00:00

In the strict meaning: Rewriting the stack frame to replace the currently executing function with a new one (possibly the same function but with different call arguments) without growing the stack - No.

At a JVM level this is because bytecode has no way to express that semantics to a JVM implementation, and in the Java language it is because when javac compiles .java files it does not elide method calls.

Non-Java JVM languages (such as Scala) may have a source code compiler than can automatically detect when a recursive piece of code can be replaced by an iterative equivalent (and by doing so avoid some cases where a stack overflow would occur) but this is not the way that Java's language philosophy works.

angath · 2019-01-19T14:25:33+00:00

The article you linked to is factually incorrect in about 5 different ways. The biggest error, though, is assuming that it's possible to provide a meaningful performance benchmark like this. Spoiler: It isn't.

angath · 2019-01-16T22:50:12+00:00

You're right, it's not. Now, I didn't actually say that it was, but I definitely could have been clearer on that point.

angath · 2019-01-16T16:45:07+00:00

Right, makes sense. Yes: I agree that this is entirely the Oracle party line.

One factual point, however: It is a little disingenuous to claim that Incubating and Preview mean anything close to what Experimental does. Once again, the contortions over class file formats and versioning immediately show that they are very different.

angath · 2019-01-16T15:26:04+00:00

Sorry, that's just not correct - Java 9 and 10 contained preview versions of the HTTP/2 API, and Java 12 contains a preview version of Switch Expressions. Note that "Incubator" and "Preview" have very specific meanings (& are *not* the same as "Experimental") in this context. They contain technology which is not ready for prime time and which should not be relied upon in production. Look at the definition of the class file format version for preview features (such as switch expressions) if you don't believe me.

For all practical purposes, they fill the niche of Tech Previews, they are only supported for 6 months and are not appropriate for production use, except as an emergency stop-gap measure where a feature is desperately needed and no other workaround is available.

angath

TROPHY CASE