Java 16 | Hacker News Reader

Java 16

jdk.java.net

410 pointsJCWasmx86310 comments

Lots of shiny new toys to play with :) I like playing with new features and pushing to silly limits. Here's some fun things you can do now:

Compiletime checked state machines with Sealed Classes [preview feature] https://benjiweber.co.uk/blog/2020/10/03/sealed-java-state-m...

Autobuilders, Mixins, Conversions & more with Records https://benjiweber.co.uk/blog/2020/09/19/fun-with-java-recor...

Pattern Matching fun https://benjiweber.co.uk/blog/2021/03/14/java-16-pattern-mat...

If you enjoy pattern matching in Java, I would recommend checking out the latest & greatest that C# has to offer as a comparison:

https://docs.microsoft.com/en-us/dotnet/csharp/pattern-match...

Being able to combine pattern matching with switch expressions has allowed us to construct extraordinarily concise state machines for our UIs.

I used Java a lot and like some aspects. But I think C# is way ahead in some important ways and Java is playing catch-up

Java is really conservative language-wise while C# is pretty much add everything you see, reminiscent of C++.

Also, a significant part of Java development happens at the runtime level, where I would wager the catch-up is in the opposite direction, in some areas by quite large margins.

C++ had shoddy foundation where adding more stuff is far from trivial.

Not considering async/await (because I'm not really a fan), they're neck-and-neck in my opinion. I don't think C# has been as careful with its abstractions and the general aesthetic of the language to the degree that Java has; but in many cases you can almost compile a block of Java as C# and vice versa. I think the primary differentiator is what toolchain/ecosystem you prefer, and I'm solidly on the Java side of that line.

That being said, I'm currently getting paid to write C#, so if you've got any resources for converts, I'd love them! :)

What do you think is more elegant in Java than C#? I like both but I think things like LINQ, delegates, reflection, nullabity and even properties are much cleaner in C# vs streams (exceptions?), consumer<T> (weird names. accept? not invoke?), erasure and then just in general its not as nice, Optional<T> (its nullable?!), and getters/setters (I don't want to code gen this away).

> What do you think is more elegant in Java than C#?

Broad availability of third-party libraries? Java Flight Recorder? IntelliJ? Multiple build system options including first-class support for Bazel, Gradle, and so on. (Msbuild gets old quick...)

That said, personally I prefer TypeScript over all of the above if performance isn't an issue. ;-)

We're talking about language design choices not ecosystem.

Even still, libraries are not a problem. Nothing you can't do in C#. You should check out Rider. Bazel and Gradle are cross platform as well.

Flight Recorder is good. I'll give you that. The .NET debugging tools are top notch...on windows. JFR wins out handily until the Linux tools reach parity. Though, again, this is all ecosystem and not language design.

You'd love Kotlin then

>I don't think C# has been as careful with its abstractions and the general aesthetic of the language to the degree that Java has

You say "careful", others would say "stubborn". The refusal to add things like operator overloading lead to a much less aesthetically pleasing language to read and write.

I can understand the resistance to traditional operator overloading, but something like implementing a Monoid interface which specifies operator methods might work. I think the sort of value types that people are likely to implement with Valhalla will make the case for this much stronger.

They keep playing catch up with each other, in different ways across the eco-system and language features, since they exist.

Or just use Scala and stay on JVM. You can even easily mix Scala and Java classes within the project.

Nice, but I still prefer Rust's match syntax. It feels natural and ergonomic.

Nice to see that Records are finally out of preview. But note that Sealed Classes are still in Preview mode and are subject to change (or removal) in newer versions.

Removal is not likely, nor is major change. Most likely some minor changes.

Love the state machine example :)

Very cool to see that Scala continues to have a huge impact on Java’s roadmap.

Records and Sealed Classes are borrowed from Scala.

Could be not the best news for new Scala adoption, but good news for developers having better abstractions in Java

Edit: Kotlin, and other languages should also mentioned since they also include similar features. I still think Scala has had the most influence over the years.

We see similar developments with C# borrowing features from F#, with records in v9, pattern matching, etc.

While it's good for C#/Java, it does make it harder to push for adoption for a language such as Scala and F#. Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly?

> Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly?

This won't always apply, but sometimes (many times?) there's a software endeavor that permanently feels on the margins of a programming language's capabilities, whatever that means. You may forego market share in order to be 5 or 10 years ahead of current practice. In other words, the mainstream isn't converging to a stable F# / Scala / whatever. It's lagging behind. It's not the last time that a mainstream language adopts a feature that has been available for years in a more fringe ecosystem.

In practice, I'm sure the most important thing is humans and their skill, so mainstreamness matters. But if you can somehow be less sensitive to that, you may reap a lot of benefit from using Foo before it was cool.

Another thing to note that cutting edge languages do not always deliver great features , they also deliver with great frequency half baked features to be discarded or deprecated in few years. Also since most effort spent on language , tooling remain primitive and slow for long time.

So I do not see them a sure win for projects I work on.

FWIW, I feel that way about Scala, but not F#.

The only big F# feature I know of that's fallen out of favor is type providers, and, IMO, that's not because the feature was half-baked so much as because it was one of the many casualties of .NET's transition to being a truly cross-platform toolkit.

Because Scala is a truly innovative and experimental language that came out of a programming language research group. That's why there's a lot of features that didn't play out well in real-world. F# started out as .NET rendition of OCaml. Most languages initiated by large crops don't try to be innovative, rather they take approaches introduced by different niche languages (many of them are only for research purpose) and incorporate to their language. Languages that try cater to a large audience should be adopting features from experimental languages.

F#'s relationship has been vastly overblown. The truth is that they're about as closely related as C# and Objective-C. In the same way that the overlap between C# and ObjC is basically just the C bit, the overlap between F# and and OCaml is basically just the ML bit. (Actually, even less than that.) You could say that it was inspired by OCaml, but it includes almost none of what makes OCaml OCaml, and adds a lot of its own new ideas.

Great point about half-baked features. The investment boils down to risk-reward. Can we say that the features that are introduced into Java at this point are features that have stood the test of time in other languages?

I have already used `records` in some project I work on. To me it does not look too clever / funky. It still looks like very obvious Java code but little more concise.

>Why bother investing in the languages with a much smaller market share when the big boys adopt good bits and pieces from them constantly?

because if you know exactly what you want to do there's no reason to settle for the second best thing. If you want F#, no harm with going exactly with F#.

I talked to a bunch of Jane Street engineers once and the consensus seemed to be that Ocaml, despite its very small footprint, actually helped them attract the kind of people who were super enthusiastic about building really good stuff with a good technology, so it actually made recruiting for them easier.

> actually helped them attract the kind of people who were super enthusiastic about building really good stuff with a good technology, so it actually made recruiting for them easier.

Sounds like a strong case of selection bias.

There is no shortage of people who are super enthusiastic about building really good stuff with good technology, and it's hard to believe that it's easier to hire Ocaml engineers than other languages.

I really don't want to sound elitist, but there is the issue that probably 90% of people who have ever written code for money know enough Java to get by and credibly claim they can do it on a resume. Just the ubiquity in university intro courses and enterprise use means everyone gets exposed to it.

On the other hand, if you see someone took the time to learn OCaml, I think you can be reasonably well assured they legitimately love programming. Signal value jumps from "this person has ever programmed" to "maybe this person has a real passion for it."

Agreed. I worked with a team who was heavily into scala and one of their beliefs was that all the smartest people want to work on scala, thus having the company use scala will filter only the smartest people to want to work for us.

I can only comment on C# / F#.

The C# versions of F# features tend to be pretty clunky compared to the F# versions. This is because F# was designed for them from the beginning, rather than having them tacked on. Functional programming is getting easier in C#, no question about that, but honestly, it still kind of sucks. And the OOP-minded C# devs on your team still won't be able to make sense of your code that leverages all these fancy new features anyway.

What fancy features won't we understand?

I think some things about functional programming make code feel cleaner, but I don't like it enough to use F# or Haskell.

If you do stuff like this: https://weblogs.asp.net/dixin/category-theory-via-csharp-7-m...

(Note this is horrible because C# does not support this style well, in F# it's idomatic)

But it's fine, we don't really care about language adoption if the best most supported most tested most hiring languages swallow their features, right ?

What matters is what we do with the language, more than the name of it no?

The problem (as I see it, anyways) is that the 'big boys' that I referred to in my initial comment have been around a long time (2000 for C#, 1995 for Java) and over that long history, have had a slew of language changes. They are starting to suffer from the same problem that C++ suffers from, where every shop defines their own subset of the language with which they use. Meanwhile, the languages that they graft features from (e.g., F#) tend to be smaller and more coherent with respect to the feature set.

But that’s the great thing about java, it is still a pretty lean language even with its age.

And even C#, which has grown a lot, tends to have pretty orthogonal features, so that you don't end up too often in C++'s problem that every feature interacts with every other feature and complicates it.

Really sorry to ask the dumb question here, but what is V9? A cursory Google search didn't show me anything about e.g. a major update to the V8 JavaScript engine?

UPDATE: Ah, C# v9.0 thank you all.

I meant 'v' as in 'version' of C#, here's a good reference on it: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...

"We see similar developments with C# borrowing features from F#, with records in v9, pattern matching, etc."

Parsing that sentence the subject is C# and F# is referenced, but the subject of the sentence didn't change, it remained C# thus logically v9 applies to it.

C# 9.0: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...

it is a C# language version. https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...

They meant version 9 of C#, the language.

No bother, beyond learning new concepts.

In the end platform languages always take the most relevant pieces from the guest languages, which eventually fade away.

Semi sad state of the universe

This is why it's so important to have different programming languages! Sometimes it's hard to do things differently when you are just looking at your own programming language, and the tools it has available to it. Not everyone programming language needs to be a behemoth to be useful to other people. I say keep making new an interesting programming languages! It will only lead to better programming languages over all

> Records (...) are borrowed from Scala.

I think records already existed in FORTRAN and other languages like ALGOL-60. C has structs, too.

Yes you are right, records have been around for a long time.

COBOL was a popular, very early language supporting hierarchical data of different types. This dates back to approximately 1960.

FORTRAN didn’t have records other than I/O “records” (at least for the first 20 years). ALGOL-60 didn’t have records. Algol-68 did have records, however Algol-68 wasn’t in very widespread use. I never had an opportunity to use it; compiler technology at that time wasn’t really ready for such a challenging language. Algol-68 may not have had widespread use, but a number of it’s features made their way into influential languages like C, Pascal, and Simula. These languages did have records.

As I recall, IBM’s PL/1 did have records, I seem to recall using them in the 70’s in a PL/1 program. PL/1 was kind of an amalgamation of FORTRAN and COBOL’s features.

In the end... Pascal was/is hugely influential, and, yeah, it called these kinds of things "Records." But the funny thing is it's been so long since I wrote Pascal or Modula-2 that when I first heard the term "Record" in the context of Java I never made the connection.

I think it's fair, though, to say that it's likely that the implementation and/or semantics may be more based on other JVM languages, who have to work on Java's terms.

In particular, I'm talking about the fact that Java doesn't really have "copy types" or "pass by copy" or whatever. So, sure, C has struct, Swift has struct, etc, but Java can't really model its version off of the way those work.

I think the reaction has been more to Kotlin than Scala.

Arguably, Kotlin took some of the better ideas from Scala.

Arguably? I'd say it's rather obvious, but overall they're different languages with different goals.

To be fair, “arguably” has come to mean “no doubt.”

You are thinking about "unarguably". ;)

No, I was talking about the now usual in the English-speaking practice amplification of its meaning as "can be supported or shown by persuasive argument", e.g., That is arguably the best book on the subject.

https://www.thefreedictionary.com/arguably

I’m more a Scala dev than Kotlin

Think it’s safe to say both influenced Java’s Record, shoulda mentioned Kotlin too.

Kotlins data class is functionally basically the same as a lombok @Data class used in Java. Why Java didn't keep the name "Data class" I don't know.

"Data" is such an overloaded and vague term, anyway. Almost all classes have "data", so what the heck is a "data class"? Is it one that only has data (not behavior)? Nope- these can have arbitrary methods.

So, I'm kind of glad they didn't use it. (But, to clarify, I really don't care what color the bike shed is)

I'm more wondering why they didn't go with "struct" or "value class", especially because the latter is exactly what we've been calling "class whose equals() is defined by content rather than identity" for many years.

Because while in the end project valhalla will not call them value classes, it is a sort of an overloaded term.

Structs/value types can be mutable, records are not. They are basically tuples with names. And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.

> Structs/value types can be mutable, records are not.

Fair point about record fields not being reassignable (not the same as immutable for others reading this).

> And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.

Well, sure. All non-primitives are passed by reference. That doesn't stop them from being referred to as value types.

But in light of your first point, I agree that choosing a totally new term probably makes sense.

I saw someone recently post the idea that Java/Scala/F# almost functioned as LTS/Stable/Dev in reference to how these languages were sharing impact.

I think the person actually said Java/C#/F#.

But in any case, I'm thinking that the real timeline is more that Java is prioritizing features that are most attractive from Kotlin, which borrowed the ideas from Scala. But Scala never got super popular, so there was not much pressure or "proof" that these were good ideas until everyone fell in love with Kotlin.

I think Kotlin is more at risk than Scala on the server at least. Scala still has a lot of advanced features that sets itself apart. Kotlin is a better Java but Java is catching up fast.

Agreed. But Kotlin 1.5 will have enough interesting stuff with the new inline class and const methods that I think it'll keep its appeal for quite some time.

Developing now 80% in Kotlin and 20% in Java (on backend), I really think the main advantage of Kotlin over Java is nullability. You can use @Nullable/@NotNull annotations in Java, but nullability being a part of the type system in Kotlin is better. I also love being able to create simple functions and add extension methods to existing classes. But still, nullability is the strongest advantage of Kotlin and I don’t see how Java will address it.

Agreed about nullability. And Java will never fix it fully or I'll eat my hat.

... but, you have to be pretty damn good to win out over the native language of a platform. And if it were just Kotlin today vs. Java 16, I think Kotlin is a much nicer language, but it doesn't really differentiate itself that much. Sure, it's syntax is much nicer, but you still basically have the same semantics as Java. You have classes; everything is a reference; no const/immutable data; no (good) general way to clone things; you have the same-ish type system with inheritance and interfaces, but no type classes; still have weird shit like sized numeric types with over/underflow; exceptions for error handling; etc.

At least Scala has monads and type classes, so you can say it actually has some expressability that Java truly doesn't. I'm not sure that Kotlin has that. Clojure is a totally different beast that really doesn't directly compete over Java devs, IMO. It just happens to use the JVM as a platform.

Yup, clojure people have no love for jvm. It's a source of libraries, period.

But I fear kotlin will fall in-between all the platforms they try to support, and will end up comparatively bad on all. Like, you can’t really target both your coroutines on each platform as well as project loom properly, same with project Valhalla and the like.

Why can't coroutines take full advantage of Loom's green threads on JVM and do other stuff on Native/JS/whatever?

I generally agree that being multiplatform is a lofty goal. And as much as I like Kotlin, it clearly inherits some of Java's (IMO) deficiencies. I'm not sure why I'd want those deficiencies exported to my native code when I could use lots of other nice languages.

I think Loom can be abstracted away by Kotlin quite easily. Valhalla on the other hand won't work at all. You won't be able to have inline classes in android/older Java versions. Even more - specialized generics.

I hope they're subsidizing the Scala project, and Kotlin too. Nothing better for a dominant player than having other people scout the territory for you.

I think millions of man hours went in JVM development will count for lot of subsidy.

I spent a few years moving to Scala but have come back as Java really does everything I want now. Just Akka is a bit clunky.

Besides Scala, I feel both Kotlin and Rust have been heavily influenced by Scala.

Why not Kotlin, C#, F#, ML and so many other languages?

Man, I hope the migration to Java 11 that my infrastructure team started 18 months ago is going okay.

Can't read whether this is sarcastic or tongue in cheek ;-)

Java 11 is the newest LTS release. The next LTS release will be Java 17. Many companies won't touch anything that isn't LTS. There are still a large number of companies staying on Java 8 :shrug:

LTS doesn't exist within OpenJDK. LTS only exists if you're paying a specific provider for it.

Then what does AdoptOpenJDK mean when they label 11 a LTS release? https://adoptopenjdk.net/index.html

LTS is more than support, it provides mental stability that you don't have to update every 6 months.

OMG I'm old. I thought that Java 9 would be next version.

yeah I'm confused too, so its because Java 9 officially came out September 2017 and they've been releasing very fast but have completely ditched semantic versioning

chart here https://en.wikipedia.org/wiki/Java_version_history

Java 8 → Java 11 → Java 17. Those are the LTS releases. If you want to follow a release cadence similar to Java 5 → Java 6 → Java 7 → Java 8, that's what you'll track.

The intermediate releases can be used to test against, but adopting them too soon often means tackling lots of issues in your dependencies. And updating your application servers to a new major Java version every six months is not something you can do easily coming from older Java versions. It's not impossible, but it may require a different deployment strategy and may not benefit you much over going from LTS to LTS.

I think that there is also an unspoken feeling that the LTS releases are more stable, which again may be due to the libraries you depend on not always being as well tested on the intermediate releases. I think a lot of Java developers burned their fingers on Java 9 and 10 and are now sticking to the LTS releases, but that is just my gut-feeling.

Not quite.

LTS doesn't mean anything if you mention just the Java versions.

This is not e.g. Ubuntu LTS.

In java you have different vendors that provide LTS and you need to pay for it.

Oracle, Redhat, etc. provide LTS versions (and those happen to be 8, 11, but don't have to be).

And there is one more sortof LTS: latest java version, because it always gets all the security and other bugfixes. Right now it is Java 16.

I struggle to imagine any meaningful definition for LTS that includes "tracking latest" except by coincidence (during the window of time when the most recent release is an LTS release).

Most recent java version is supported for 6 months and then the next one.

Think of Java versions as patch releases for Java 8. There are minor changes between releases.

Sure, but that's regular releases, not LTS

OpenJDK's supported/not-supported classification seems to match and would appear far more reasonable.

If you're doing green field JVM developer and NOT using big frameworks like Spring or an app server it is pretty safe to use the intermediate releases.

... if you're willing and able to update your entire app to a new JDK the month it comes out.

This is where I hope Java adopts the .NET support lifecycle. .NET also has (relatively) fast-paced releases now, once per year with LTS every other year, but the prior non-LTS is supported for 3 months after the next one comes out. That's still pretty aggressive, but it's very doable with a modern app to upgrade within 3 months.

With Java, JDK 15 support ends this month, the same month that JDK 16 comes out. Not just that, but we're halfway through the month already. So if you're on JDK 15, you now have only two weeks to upgrade and still be supported, according to their official schedule.

https://www.oracle.com/java/technologies/java-se-support-roa...

Edit: I may have been too generous in my reading of their support roadmap. It seems like the previous non-LTS version is immediately out of support as soon as the new one "supersedes" it.

Spring supported each and every java release between 9 and 16. With one release being supported a month later (don't remember which).

I know because I use Spring (and hibernate) and everything just works.

(If you are on the most recent Spring version)

Uh, probably just my narrow corporate world view but... is there any serious development in java NOT using Spring?

Time for me to learn so let me rephrase this question! Those who use java without EE or Spring framework, what are your go-to libraries? What are you using for DI / REST / ORM / Auth etc?

> is there any serious development in java NOT using Spring?

Yes. And I don't just mean people doing Android development.

1) DI: Don't always need DI. For things like injecting values from config, it's really unnecessary given that we have very good control over production, down to building our boxes from a playbook. For things like mocks, plain old Java suffices -- you can roll your own (actually, someone in your team just needs to do it once and it keeps getting improved/forked). Guice exists as a fallback.

2) REST: Jersey + own libraries on top, Retrofit. Using Spring for REST is probably the poorest use for Spring, for me.

3) ORM: you can use "just" JPA. Don't always need an ORM either -- the strategy varies depending on the requirement. Although for some projects I have used Spring Data JPA because it seemed like the easiest path. At least Spring was localized to that artifact.

4) Lots of good OAuth2 libraries as well as things like pac4j. If you're wondering about Spring Security, it's definitely one to consider if you're doing lots of webapps in Java. But in a polyglot environment, a lot of Java code just handles APIs while node handles the UI.

Anyhow, this isn't to hate on Spring or anything -- I use it if it adds value. This is more about not taking the the complexity hit if you can help it. It also makes the code a bit more straightforward and readable.

Different needs for different domains. For example, there's an old pack of machine learning code that I maintain, and it (and a bunch of other Java code that I see from other institutions) does not use or need DI, ORM, Auth nor proper REST, they typically handle processing of non-database data with no or minimal web interaction, and plain old objects are fine for that - if we started from scratch and chose Java instead of some other language, we would still not use Spring for that.

Google used Guice for DI (Or Dagger2 sometimes), rest is it's own thing, orm is "there is no ORM go write your spanner queries", and Auth is it's own thing.

Note that blindly following LTS is not a great idea for many teams that deploy applications (as opposed to libraries), including teams working in large companies, if you have access to modern CI/CD tooling. Personally, I'd let production stay a little behind the latest release but always run a task on my build server to build and test my code on the latest JRE.

If you read Ron Pressler's comment on Reddit[1], the recommendation is

> In any event, the default position should be to keep up with the current JDK as much as possible (it's OK to skip a version or two), and consider LTS only if there is some specific difficulty preventing you from doing so. As I said before, the "current JDK" upgrade path is designed to be the one that is overall the cheapest and easiest for the vast majority of users -- easier and cheaper than the old model.

For users who are happy with the current JDK language level, newer releases also have JRE improvements:

> ...those users should [also] prefer the current JDK, too, as that is the easiest, cheapest update path. Also, new feature releases contain performance and monitoring improvements (e.g. JFR, ZGC, AppCDS in the last few releases) that may be of interest even when users are not interested in new language/library features.

> The problem with LTS is that it's costly (costlier than the old model): on the one hand, the risk of a breaking change in an LTS patch is no lower than in a feature release, and on the other hand, the patches no longer contain many gradual implementation features (that you use without knowing). In addition, the OpenJDK development process revolves around feature releases without regard for LTS, so features can be removed without notice in an LTS release. This makes an LTS->LTS upgrade more costly than in the old model.

> LTS is designed and is advisable for companies that prefer a costly, but well-planned, three-yearly upgrade process.

> Even if you've carefully considered the options and decided that LTS is the right approach for you, you are strongly advised to test your app against the current JDK release to reduce the cost of an LTS->LTS upgrade.

> It's true that upgrading from 8 to post-9 can be non-trivial (9 was the last ever major release), but once you do that, you have an update path that ensures you'll not have a major upgrade ever again.

Java upgrades inside enterprises cost time and money, no sense in taking that cost if you can help it, and many engineering teams with good DevOps can easily dodge this cost.

[1] https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i... , https://www.reddit.com/r/java/comments/c5pl1q/adoptopenjdk_i...

If you're using "application servers" and not containers then definitely do not touch intermediate releases.

Why?

I would say, try it out and see.

And what do you do if you "try it out" and some months later you identify a problem? Then you have to rewrite all the code without the new features to go back to the LTS version, and likely you'll have to downgrade or even swap out some of your dependencies. That's painful and expensive, there needs to be a very good reason to justify that risk.

You don't need to downgrade dependencies, libs are at 8 and 11 right now and support up to 16 (e.g. jackson is I think at Java 7, and supports records from Java 16).

What kind of problem could you identify? Same might happen with LTS release (e.g. I had it in JDK 8, suddenly I wasn't able to use some crypto libs).

Fixes always go first to JDK latest, and then are backported to 11 and 8.

If you're using JBoss/Wildfly the recommendation is to stick to the LTS. The last JDK supported is 13 since 14 removed some API's and the team is still working to fix it.

Basically there's six month feature releases but every five or six releases there's going to be an LTS release. Most companies use the LTS releases. Next big LTS release is later this year.

If you mention LTS you have to mention also vendor that provides it.

Without it the only LTS is current java version: 16 right now and 17 in 6 months.

LTS stands for long term support. Nobody provides that for java 16

OpenJDK provides that for 6 months. And then 6 months for a 17, and so on.

That's not "long term".

Huh? There's like several LTS vendors: Oracle, Amazon, and Azul to name a few.

Yes, but when someone mentions LTS many think ów like Ubuntu LTS or like Linux kernel LTS versions - that is free of charge long support.

And many Java devs employers don't pay for LTS.

So ad 1 and 1 and you get a false claim that any java 11 version is an LTS, which is not true.

I recommend the "inside Java" podcast. Its from the java developer team at Oracle and worth a listen.

https://inside.java/podcast/#:~:text=The%20Inside%20Java%20P...!

their blog post as well: https://inside.java/2021/03/16/the-arrival-of-java16/

Thanks. Was a good show, though nothing super informative.

As a student most of the way through a Java course, I'm wondering what Java is still used for. Java applets are dead, Android is moving on to Kotlin (apparently Google got in legal trouble with Oracle even though Java is "open source?"), and I can't think of any desktop applications that use Java anymore. Java is supposed to be able to "run anywhere," yet C++ is more portable because it doesn't require the JVM to run.

Yet clearly I'm mistaken, since Java is still one of the most popular languages.

Edit: also please help me understand - do I have to pay for a license even though Java is open source? Is this normal for other languages too?

>As a student most of the way through a Java course, I'm wondering what Java is still used for.

A huge majority of all code behind services, websites, and businesses you interact with every day. From Google, Facebook, Apple, and Twitter to your bank, and from Android to you favorite new unicorn. Of the top 25 unicorns "20 use Python; 19 use Java; eight use Kotlin. Coinbase was the only top-ten unicorn found to use Swift." [1]

And that's just startups and FAANG. On top of that, every enterprise, government organization, and financial organization also uses tons of Java with the exception of Microsoft shops, which use C# in its place (or also use C# on top of Java).

Think of it this way: you know how C# is a big industry? It's #5 in the TIOBE index. Java is #2, and has been between bouncing between #1, #2, and #3 spots for decades.

And on top of Java there's the JVM, which also powers Kotlin, Clojure, Scala, Groovy, and other languages...

>Java applets are dead

Java applets have been dead on arrival. It was just a fan around 1997-1999 and not that succesful even then (I was there). They were never a big part of Java's allure.

>Java is supposed to be able to "run anywhere," yet C++ is more portable because it doesn't require the JVM to run.

That's a non-sequitur.

[1] https://insights.dice.com/2019/07/12/python-java-kotlin-skil...

> Java applets have been dead on arrival

The only successful Java applet I know was Runescape (if that was an applet? it ran in browser), an RPG game that ran in Java in the browser, for 15 years or so roughly afaik, today they switched to a non browser based client instead.

Other Java applets almost never worked for some reason. Like, sometimes I'd visit a website about some mathematical topic, and the whole browser would hang while some java applet demonstrating the math was supposedly loading, and then most of the time it didn't actually work.

Don't know about "successful" or "useful", but the Java Applets on Complexification were some of the most beautiful software I've ever seen: http://www.complexification.net/gallery/

The first "real" Java program I wrote back in 1997 was a huge applet. It was the replacement for an existing X Windows application, with 42 screens. The applet itself worked great, but the networking technology at the time was such that when all the users on a network segment started their browser and launched the applet, it bogged things down to a crawl. Still, when it was loaded it was amazing (for 1997). It looked almost exactly like the original application, and updates were as easy as putting a new jar file onto the web server.

Roughly 20 years ago we embedded Java applets inside a HTML-based online help. This turned the help from a reading resource (which tells you where to find certain preferences) into an actually interactive resource, composed from the same applets that also formed the Application itself.

Worked like a charm. I have yet to see anything similar to that.

The only applet I know of outside the early few years of hype that still works and does something useful is Falstad's circuit simulator. https://www.falstad.com/circuit/

Actually that one has been rewritten in JS! The fast loading and no gray screen gives that away :D

There's a link to the original Java version below, that one doesn't work for me anymore, I no longer have a java-enabled browser

>* The fast loading and no gray screen gives that away :D*

Well, plus the fact that no modern browser runs Java applets...

> still

It's a very popular backend language. Ironically, "run anywhere" isn't much of a requirement for backend development.

> C++ is more portable because it doesn't require the JVM to run.

For backend development, this isn't much of an issue either way. These days, the main advantages C++ has to Java is startup time and no GC pauses.

It's also not as portable as you'd think. Take a look at cross-platform C/C++ projects and you'll see a lot of special cases for particular platforms.

Java's popularity mostly boils down to it's mature, has a large ecosystem, and is adequate for a lot of things. Unless you're writing an iPhone app or system-level code, it's unlikely to be a bad choice.

> Ironically, "run anywhere" isn't much of a requirement for backend development.

If you’re using Java, you can develop on macOS, deploy on Windows Server, then switch to Linux on AWS Graviton and M1 Macbook. Without a singe recompilation.

With graal vm java apps compiled to native have amost 0 startup time

There are no GC pauses issues practically now and for years. Language startup is also not all that much issue.

I'd say they're at a point where they're not a problem for most use cases, but if you're trying to get p9999 latency down, you might have to start looking at them.

The default GC has ridiculously good throughput with modest latency (10ms for quite large heap sizes), but there are also alternatives like ZGC and Shenandoah that optimize for latency instead, and they promise <10 ms latency, but in practice they are around 3-4 ms. At which point, not running a real time OS, you will get bigger hiccups from the OS scheduler.

Also, for very different use cases like soft real time, there are specific JVMs with real time guarantees.

Here is a great post about it: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1

And in JDK 16, ZGC has concurrent thread-stack processing, which typically reduces GC pauses below 1 ms

https://openjdk.java.net/jeps/376

https://youtu.be/88E86quLmQA?t=1525

Vast majority ( if not All ) of Fortune Global 2000 use Java as their Main Programming Language for their BackEnd.

And this isn't changing anytime soon. Their initial investment, continue investment and Java Ecosystem itself are still marching forward. I dont see any language ecosystem that could match or challenge Java any time soon. Remember you only see Java Haters on HN and Reddit. In the Real World it is all about Business Values Delivered and Get Shit Done.

JVM in itself is a monster with State of the Art GC and JIT.

All of the above means there is a positive feedback loop into making Java better. And there are things that were in the work for 10 years ( Like GraalVM ) before hitting mainstream. And many more to come.

> C++ is more portable because it doesn't require the JVM to run

Java is portable BECAUSE of the JVM. If a new computer architecture hits the scene, once someone writes a JVM for it your .class files will run on it (probably).

Your C++ program, however, will definitely not run and you'll need to recompile it with a compiler that targets that new architecture.

The same compiled Java code will(should) run on a Mac or a PC or any Linux box, but you need a different executable for each target with a C++ program.

The JVM isn't portable. That needs to be recompiled for each new target, but your Java .class files are portable.

For a couple decades, x86 was absolutely dominant and there were no new architectures of any importance outside specific niches. Once you dealt with the OS specific oddities (which java also helped with), C++ was highly portable.

> For a couple decades, x86 was absolutely dominant

On the desktop and servers, maybe. But there is more in heaven and embedded than is dreamt of in your philosophy.

I work in embedded. Embedded Java has always been a huge set of tradeoffs, which is why it never took off outside of application platforms like mobile phones and set-top boxes.

If you wanted the full fat SE Sun/Oracle JVM you were pretty much stuck with power or ARM, and even then you had to be careful. Remember the portability disaster that was symbian and Java ME? These ISAs weren't exactly the low end of the embedded market at the time either. The farther away from x86 you got the less portability you could actually take advantage of.

> Remember the portability disaster that was symbian and Java ME?

Don't forget Java Card in that list. Which Oracle still tries to claim as a Java portability win, even though it doesn't support basically anything. And I don't mean missing standard libraries, I mean like it doesn't support char, double, float, and long, or multidimensional arrays. Support for int is even optional. Doesn't support exceptions and you can't even assume it has a garbage collector. Among many other limitations.

> but your Java .class files are portable.

No, they aren't, they regularly have non-portable dependencies or assumptions about the environment.

For example, it's more or less impossible to write a Java program that runs on Windows, Android, and iOS - the 3 most popular OS's. You have completely different UI support between Windows & Android, and there's not really any JVM for iOS (there's AOT, but now you're not even pretending to run a .class file)

So to make a "portable Java" program you're already stuck compiling it 3 times for the 3 major OS platforms, but without anything helping you to actually specialize for a platform like exists with C++. Making Java less portable in practice than C++.

Toss in that other popular platform, web, and the "portability" of Java gets even worse compared to others like C++.

> For example, it's more or less impossible to write a Java program that runs on Windows, Android, and iOS

Not only is it possible, it happens all the time.

The entire Maven Central repository, which contains tens of thousands of JVM libraries, is usable on all the platforms you just listed.

If that's not portability, I don't know what is.

Maven runs on 1 out of the 4 mentioned platforms. There are no Android, iOS, or web builds of Maven.

Maven is used to ship dependences for the other platforms, but it is not run itself on those other platforms. Shipping an Android-specific library on Maven isn't magically portable (which is what's common here - OS-specific libraries on Maven). It's still Android-specific.

All Android builds use Gradle and download their dependencies from Maven Central.

I have no idea what you're talking about.

Let me repeat this: all Windows, macOS, Linux, and Android apps that use Maven or Gradle to build ALL download their dependencies from Maven Central. These are the very same libraries, same bytecode.

For example, do you use Mockito? You will download that exact same library from Maven Central regardless of the platform you are building on.

When people call .class files portable, they mean between platforms that have a JVM available and can pass the TCK.

Platforms that do not aim to do that are not really relevant.

That's like saying C++ exe's are portable if you just ignore all platforms that don't have an NT kernel.

Market share determines a platform's relevance to portability claims, not its intention towards the JVM.

I see that your goalposts in this discussion are also highly portable.

Java is used all over the place for various backend applications, e.g. data processing, web backends. It's fast, well documented and has a great standard library and ecosystem. In many of these applications you control the deployment environment, so making sure that your container has the JVM isn't an issue.

Except for "Java applets are dead", everything else you wrote is wrong :-)

Android is not moving to Kotlin: Kotlin is simply supported as a first class language in Android. Most of Android itself is written in Java and while it's clear that an increasing number of Android developers are switching to Kotlin, Java will never stop being supported on Android.

The legal battle between Google and Oracle has nothing to with Google using Java.

You can use Java for free and without any licensing concerns (use Open JDK).

C++ is less portable than Java precisely because Java runs on a JVM.

Java is used a LOT on the back-end still.

Yes, golang is shiny new thing, but there is TONS of boring back-end done in Java.

Whole Alibaba runs on Java, for example. I know of some companies (won't share names but fill in the blanks) that used to be Go shops, that were eaten by Alibaba and they migrated from Go to Java.

Wouldn't agree on the GO statement, yes GO is great in terms of performance but it still lacks some important language features AFAIK no generics, no proper exception handling. I honestly don't know how the GO ecosystem is, but I can't imagine it's as mature as java. Perhaps I'm wrong tho

> no proper exception handling.

That's just like saying Go does not have application servers, DI, IOC, ORM frameworks, runtime reflection and so on. Different languages have different ways of achieving user requirements. It is not one-to-one matching.

> ... I can't imagine it's as mature as java.

Yes, depending on perspective, not as mature or not as fossilized as Java.

I’ve removed that part of the post as I don’t want to make this about go :)

Here at Quobyte, we're developing a distributed file system that is partially written in Java. The JVM is rock-stable, fast, and developers are very productive in Java.

I discovered Quobyte today thanks to this comment. I am extremely excited to start exploring your technology.

I am also working on a networked file system solution. My approach is likely fundamentally different. Instead of a single file system to represent file system artifacts across various devices I am using a single simplified data model as an abstraction for all file systems and pairing that with a new security/identity scheme. The idea is to solving for file asset distribution using point-to-point solutions that don't compromise security or privacy.

https://github.com/prettydiff/share-file-systems

I suspect your approach is likely far more stable as I am still working out the kinks in my models, but I supply a complete GUI in the browser that works the same in all browsers on all modern OSs.

> and I can't think of any desktop applications that use Java anymore.

The desktop application everyone has to use to report the income tax in my country is written in Java. Which is nice since it runs anywhere that has a recent enough JRE; in a distant past, before it was rewritten in Java, it was first a DOS-only and then a Windows-only desktop application.

All jetbrains IDEs are JAVA. Webstorm, Intellij etc

I have worked with Java EE (Enterprise Edition) for a few years. Java in the backend is probably the most common one when doing enterprise software.

Lets define it differently: Everything what is not an SAP System and is backend and is not Cobolt, is Java at least for automotive and banking. Automotive -> managing cars, service contracts, financing offers, accessories and for banking -> money management, insurance, contract management etc. You go to a shop and you wanna finance something? Might be a Java backend or Cobolt :D)

Spring/Spring Boot as a Framework got a lot of traction because Java specification process was just way slower and more boilerplate

And yes Oracle got fed up of doing Java for free for too long and if you wanna use an older version of java and still need patches, you will need to pay.

Luckily there is were java actually shows it strength which i have not seen in other languages: You define a specification, you get a reference implementation from someone and then everyone around it starts to build on those specifications.

This allows for different jpa (database access with java) implementations, different application server etc. It also allows for different companies to do their own JVM implementation/maintenance track/version.

From an ecosystem pserpective, the JVM itself (without java) also did a great job and shows how versatile it is. Close to what .net is doing but in a more free version. And you could throw .net/c# into the same similiar category as Java. Language feels similiar and if you are a MS company, you just use C# perhaps. But switching between c# and java is much easier than to other languages.

From all languages i know and worked with, i do like JVM based languages the most. golang is interesting but nothing i would wanna use for a big code base at all. C/C++ i would use if i need to because of tooling features, how you write it and how hard it is to write it good;

Java is fast, java has great tools for a long long time: Great Debugging features, great memory and performance analysis and tools, lots and lots of frameworks and architecture catalog.

PHP is written and used in business context like java but without the benefits of running on the JVM. I don't recommend it. Its not bad, its less boiler plate but its just not a nice well defined well designed language. Most shocking to me was the performance optimizations which were done a few years ago which shows how little interest in that language exists that you can just optimize it that much. What facebook did with PHP was just shitty and weird.

for a while i got confused and thought you were talking about usage of cobalt element in manufacturing of automobiles.

To give you some more details of how Java can be used in the backend, while there's obviously unknown "generic business logic" there's also big name infrastructure pieces you can look up:

- https://en.wikipedia.org/wiki/Apache_Hadoop

- https://en.wikipedia.org/wiki/Apache_Kafka

- https://en.wikipedia.org/wiki/Apache_Cassandra

- https://en.wikipedia.org/wiki/Apache_Lucene

- https://en.wikipedia.org/wiki/Elasticsearch

- https://en.wikipedia.org/wiki/Apache_ZooKeeper

- https://en.wikipedia.org/wiki/Apache_ActiveMQ

Java is not commonly used for consumer desktop applications, where it often is necessary/desirable to invest in fully native apps for Windows and MacOS. But desktop Java is quite common in business desktop applications, for example, medical devices (like radiology image viewers).

I'll give you a bit of advice I give to engineers I mentor. Go to a tech jobs site like dice.com, and put in a technology you're curious about. So, put in java for your zip code. See what jobs are available. Are they back end? desktop? Then you'll find out where java (and any other tech) is used, and how popular it is. For example, how many jobs are there for PHP compared to Java?

I'm not saying you should adapt a technology based solely on the number of jobs...but we all gotta eat. And on the flip side if you see Java jobs decline over the years...time to learn the one that's increasing :)

Java is _very_ prevalent in Financial IT - almost everywhere. C++ is probably the only language in the same league in terms of usage. I have also seen C# lately in bunch of places but mostly middle-office/back-office.

Look into Spring Boot for cloud applications, it’s a big ecosystem

We use it on servicing the backend of an e-commerce website. The code is now 2 decades old and wonderfully refactorable to modern code.

I’m assuming Amazon? Most of Amazon runs on Java.

Most OpenJDK implementations do not require a license.

There are multiple implementations of the Java VM. Java is designed by a collaboration of companies and OpenJDK is the reference implementation. Based on the license of the company, its implementation is free or not.

Now, Oracle was the biggest and most well known contributor of OpenJDK for a long time (and probably still is). And Oracle did something unusual, which is that they made their own version no longer free. Which is why you are confused. You can still get Java from Oracle, with Long Term Support, but now it is paid support.

The OpenJDK reference implementation is still free, and many companies have made their own tweaks and provide Long Term Support for these versions, mostly because they use tons of Java and/or want others to keep using Java because of its massive ecosystem, for which they can provide consulting/paid support. Note, you can still run these versions commercially, but if you want support you likely have to pay.

The Google issue was that before all this OpenJDK stuff, all designing of Java was done by a single company, Sun, which was bought by Oracle. So a single company designed, developed, implemented, maintained, and built up the ecosystem of Java. This includes years of R&D in what keywords to use, and how classes work, basically the rules of the language. Tons of developers got into Java. And they attracted big customers like banks and governments to pay them for this R&D with support and development. Then came Google and they said, we like this language design and ecosystem and developer skills, but we don't want to pay for that support, so thanks for all the hard designing of your language, but we will create our own implementation and pay you nothing. Basically Google didn't want to pay it's share of the Java R&D. Now things get a bit blurry because of Oracle, which bought Sun, and tried to make a lot more money off Java while reducing R&D spending. So Oracle isn't too popular either.

Things have improved since Oracle decided that Java isn't something to make a lot of money off, and the whole Google debacle. Now Oracle is mostly stewarding the language and other companies are now also contributing features. The past few years there have been some good and strong updates to Java, making it feel more like a leading language than a trailing language.

Basically, get AdoptOpenJDK, latest version if possible, and don't use preview features.

> do I have to pay for a license even though Java is open source?

Most people use free OpenJDK builds (Adopt OpenJDK, Zulu OpenJDK, Oracle OpenJDK to name a few). There are some builds which require license, like Oracle Java. If you need some kind of advanced support, you have that option.

>>I'm wondering what Java is still used for.

A good part of AWS is written in Java. The Hadoop, Storm, Spark, Kafka etc major backend projects are written in Java.

In fact if you are writing anything even half serious. Java is what you chose to write it in.

>>Java is supposed to be able to "run anywhere," yet C++ is more portable because it doesn't require the JVM to run.

Manual garbage collection is long dead, and it won't be revived any time soon. Machines have gotten too fast and resourceful for most of the developer community to give it a serious selection choice for their projects.

Not saying C++ or Rust is dead. They have their place. But they are not going to be used for bulk of everyday projects. That ship sailed long back.

Java is rarely used for sexy stuff like front-ends or (increasingly) apps.

Java is, however, used for services. Bank logins, search engines (Google originally used it), insurance systems.

C#, C++ and Rust are in the same area. But Java, for the most case, has been around longer.

A LOT of companies used it and can't easily switch their codebase to something newer and shinier. And now Java improves with every release they have fewer reasons to move.

> A LOT of companies used it and can't easily switch their codebase to something newer and shinier

I don't agree with that. Spring Boot makes it so easy to write nice backends and a type system is often useful

> they have fewer reasons to move

Move to what btw? NodeJS?

Literally every business that adopted it back in the 90s. Like all of insurance.

Other languages have started to eat into Java's market share, but coincidentally a lot of them run on the same host VM as Java. For instance, Kotlin, Scala and Clojure are more and more frequently seen in backend, web and mobile development.

These languages are definitely much more "portable" depending on what your definition of portability is; the JRE runs on A LOT of systems and abstracts much of the underlying system away for you, meaning that IME you have to write a lot less platform-specific code if you're targeting e.g. Windows, macOS and Linux.

As for your edit, the licensing is a bit complex for Java but TL;DR if you install OpenJDK releases you do not need to worry yourself about licensing.

Your credit card runs Java, that's a fun one

E. g. Backend services for webapps or HFT.

Happy with the number of comments on this release.

HN is a funny place.One day you are convinced no smart person on HN is still writing Java and the next day you see droves discussing about a java release.

A new JVM release is always cause for cheer. The demo language it comes with also keeps getting better :-)

It's a huge win that 'demo language' it comes with pays lots of people's bill. :)

The idea that the tools you use is a reflection of how smart you are is just plain old silly. Most of the work you do in software is language/tools independent. A smart software developer can do great work with almost any tool.

In the financial industry, most server software is still written in Java (unless it's built for high-speed execution).

i make lots of money doing it though

I love the Java website. Strong early-2000s vibes. Still has an XHTML doctype!

And now a 500 database error too!

Wonder what database they are using.

period correct? mysql 5.1

Oh no it was Oracle before Oracle bought MySQL, so it's gotta be Oracle db.

It's probably Postgres on an interim basis, until an army of finance dweebs have calculated the internal licensing cost of using Oracle :)

There is an nginx in front of it. What was wrong with Apache?

Apache feels like a forgotten gem in the ops world. Everyone moved onto Nginx and at some point will run into some use-case that needs a feature that's only in Nginx+. And since Nginx+ is so expensive people end up just patching the OSS Nginx with the modules they need. But that whole time Apache was there with every conceivable battery and feature already included.

Except its configuration language is awful. Nginx is pretty bad too, and then there's Caddy which seems the most tolerable so far. Usability matters quite a lot!

It is probably fairly easy to create a fork of Apache with a better configuration language. The fact that no such fork exist (or more precisely, the fact that you don't mention it, which is strong evidence that you know of no such fork) is evidence that most Apache users are OK with or roughly indifferent toward its conf language. (I know nothing of it.)

I, too, believe that usability matters a lot, and I'm curious what you think of bash.

The "event loop" model in Nginx beat Apache performance wise.

Apache has since added support for the event-based model: https://httpd.apache.org/docs/2.4/mod/event.html

Oh, nice!

And is readable without javascript. Love such pages.

Why they decided to change the keyword rules to use "non-sealed" is beyond me. Surely, there might be other choices? Closed/unclosed? Unsealed?

Yes. It feels out-of-place. All other keywords are like one word: enum, class, public, protected, native, sealed, ...

But looks entirely different: Two words, connected by a hyphen.

But I think, it was done because of backwards compatibility. If they would have called it "closed", it would maybe break hundreds of programs that have methods/variables called "closed"

There was a lengthy discussion some time ago[0]. Quote:

#### Why not "just" make contextual keywords?

At first glance, contextual keywords (and their friends, such as reserved type identifiers) may appear to be a magic wand; they let us create the illusion of adding new keywords without breaking existing programs. But the positive track record of contextual keywords hides a great deal of complexity and distortion.

Each grammar position is its own story; contextual keywords that might be used as modifiers (e.g., `readonly`) have different ambiguity considerations than those that might be use in code (e.g., a `matches` expression). The process of selecting a contextual keyword is not a simple matter of adding it to the grammar; each one requires an analysis of potential current and future interactions. Similarly, each token we try to repurpose may have its own special considerations; for example, we could justify the use of `var` as a reserved type name because because the naming conventions are so broadly adhered to. Finally, the use of contextual keywords in certain syntactic positions can create additional considerations for extending the syntax later.

Contextual keywords create complexity for specifications, compilers, and IDEs. With one or two special cases, we can often deal well enough, but if special cases were to become more pervasive, this would likely result in more significant maintenance costs or bug tail. While it is easy to dismiss this as “not my problem”, in reality, this is everybody’s problem. IDEs often have to guess whether a use of a contextual keyword is a keyword or identifier, and it may not have enough information to make a good guess until it’s seen more input. This results in worse user highlighting, auto-completion, and refactoring abilities — or worse. These problems quickly become everyone's problems.

So, while contextual keywords are one of the tools in our toolbox, they should also be used sparingly.

[0]. https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...

There was a lot of discussion about this and they eventually settled on the hyphen. Consider this our introduction to hyphenated keywords and expect to see a lot more of them in the future.

I made this argument before, but was informed that they have support for contextually distinguishing between names and keywords some time between Java 8 and 10. So while e.g. the introduction of enum did cause all these issues for variables named enum, "var" did not and a hypothetical "closed" would not.

There are plenty of languages which have contextually sensitive keywords for that exact reason. C# (a closer peer to Java syntactically) has contextual keywords including "var" and "notnull": https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

Surely migrating variables named "unsealed" would be fairly trivial?

Following the various openjdk mailing lists is an awesome way of learning about all the considerations that go into making language choices for java. And indeed this was not random, but the result of a lot thinking (as shown in a another sibling post).

It's the same story in C++, co_await, co_yield. The sole purpose is not to break other people's code.

Whenever Swift adds a new keyword, they just add it and break everyone’s code. They do provide migration tools in Xcode though.

C++ has had two-word keywords since the beginning, static_cast, dynamic_cast, etc.

What I truly don't like is C's propensity to add new keywords that begin with an underscore and an uppercase letter. Like _Bool, or _Atomic. (I know the rationale, these can't be used as identifiers due to UB, but it still looks weird to me.)

co_await is so bad that co_X has become a running joke in the C++ community.

I think non_sealed would be better than non-sealed though, because AFAIK there used to be no identifiers with hifen before.

int non, sealed; ?

Oracle had no qualms about breaking a metric boatload of code by shutting down the old sun.* APIs. Their justification was "You were not supposed to use these internal tools", but the reality of the matter is that migrating to a new Java version took lots of code rework.

I'm surprised they were so shy to break code by introducing new keywords, after they wreaked havoc on people's codebases with removing sun.misc.BASE64Decoder etc

Super interested in https://openjdk.java.net/jeps/386 as alpine linux is at the heart of a lot of docker images. We use ubuntu currently as our base image, but tried to use alpine recently and ran into some issues with musl.

Hopefully this version will work better.

I switched to Azul's Zulu[1] build of OpenJDK some time ago specifically for Alpine Linux support and its worked great for me.

[1] https://www.azul.com/downloads/zulu-community/?package=jdk

Cool. I love Alpine, it’s incredibly fast and lean. It’s annoying how much software is incompatible with it, so this should help with that.

I wonder, whether this could be used to compile it for termux. (Android)

You can link musl statically. So, the problems with Glibc wouldn't be there. Maybe you would have to patch musl to make it work on android.

The JEPs/enhancements: http://openjdk.java.net/projects/jdk/16/

The page returned a 500 for me, bad omen for Java 16? :)

The site works great for me.

List of features and explanations with no BS on what's new in Java 16 : https://metebalci.com/blog/what-is-new-in-java-16/

I wish Java had something similar to Properties in Delphi.

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Propertie...

You can have Get and Set methods for properties or even allow direct access to the variable itself.

type TCompass = class(TControl) private FHeading: THeading; procedure SetHeading(Value: THeading); published property Heading: THeading read FHeading write SetHeading; ... end;

Also, properties can be indexed.

type TRectangle = class private FCoordinates: array[0..3] of Longint; function GetCoordinate(Index: Integer): Longint; procedure SetCoordinate(Index: Integer; Value: Longint); public property Left: Longint index 0 read GetCoordinate write SetCoordinate; property Top: Longint index 1 read GetCoordinate write SetCoordinate; property Right: Longint index 2 read GetCoordinate write SetCoordinate; property Bottom: Longint index 3 read GetCoordinate write SetCoordinate; property Coordinates[Index: Integer]: Longint read GetCoordinate write SetCoordinate; ... end;

Properties can also have "property pages" which can show specific user interfaces for viewing/setting these properties.

https://www.delphipower.xyz/guide_8/adding_a_property_page.h...

I have yet to see anything of this sophistication in Java or for that matter in any other component framework.

Records are a cool highlight for this version. https://openjdk.java.net/jeps/395

I am curious where does it leave libraries like Lombok that basically ports a non-record type Java class to make it more record type-e by adding things like @Value, @Data annotations. Are those libraries/frameworks going to become obsolete now?

What's the state of tail call optimization on JVM nowadays?

It's a compiler level thing, not runtime.

ie. Scala has tail call optimization but Java doesn't, but they both run on the same JVM.

That's interesting, I have been under the impression that Scala and Clojure has been limited with this optimization because of JVM.

Still on Java 8 at work :-/

Amazon's version or the for a while now EOL Oracle version? Maybe push to upgrade to something supported :)

A mad scramble to switch to OpenJDK before the Oracle license becomes inconvenient.

Eight's JVM still ships with Minecraft, so that's not necessarily a bad thing. It's battle-proven.

8 is still “modern” Java right? 11 didn’t add a ton ton for most developers.

I'd say that now with 15 adding records and instanceof pattern, Java 8 is finally looking pretty dated!

You're also missing out on var and switch expressions, which are very visible features (as are records and instanceof patterns), so the difference should be obvious between a Java 8 codebase and a Java 15 one.

Var and switch were the biggest from Java 11, along with modules and the new GCs?

I very much like text blocks as well. SQL/JSON can be finally understandable without all the "\n" +

For those who have upgraded, I assume Jigsaw is the main concern?

I've been using Maven and Gradle's toolchains functionality to move individual apps to Java >8 without breaking the legacy apps, works pretty well.

Every thread about new Java version has the same comment all the time. Why share it? What kind of response do you seek?

I think it's interesting to discuss how many are stuck on java8. It was a long time many of us were stuck on java6 or 7, and finally got up to java8. But then when 9, 10 and 11 came no one made an effort to upgrade. Why? And now we're at 15 and people are starting to feel the heat.

We only migrated our main service from 8 to 15 a month ago (AWS deprecation), but still have lots of 8 code laying around (luckily some of the container-features were backported)

> I think it's interesting to discuss how many are stuck on java8. [...] But then when 9, 10 and 11 came no one made an effort to upgrade. Why?

A lot of things broke in Java 9, which was short-lived (both it and Java 10 lasted only six months each), and then Java 11 broke many other things (for instance, it removed all of J2EE). As late as last year, I was still seeing changes in libraries to fix issues with Java 9 or later. It's not that no one made an effort to upgrade, it's that it was a lot of effort, and often required upgrading to later versions of libraries, which have their own breaking changes.

In my experience mst of these changes are simple to add to your projects pom or build.gradle. For instance the removal of the jaxb xml runtime is a simple 1 liner to your project:

    runtimeOnly 'org.glassfish.jaxb:jaxb-runtime:2.3.2'

Speaking from personal experience, the creators of most of the recent JDK versions have made very poor efforts to explain the changes, it's mostly just a list of RFC type documents, and who has time?

An example of something that compares favourably would be Go, where they always blog about the changes, and there's easy to find official language documentation (and not just autogenerated API docs).

Have you tried for example the linked article with all the JEPs listed with lengthy descriptions? And with links to relevant mailing lists if it didn’t satisfy your curiosity?

I just yesterday took the time to go and read through them. And I still consider it awful UI.

- A list of links is not a summary. The list is too short, reading every individual linked document is too long. The format of JEPs tends to bury the lede. As such it feels like wading through mud.

- Changes that affect the programmer experience are mixed at random with changes that affect internal details of the implementation.

- Changes that introduce experimental features are mixed at random with changes that are final.

At a bank, and yes, us too!

What’s the reason for that?

I'm actually stoked for jpackage, muslc and the vector API.

Just finished my CPU architecture and enjoying to see the new trend to adopt vectors again in the USA

Hopefully, there will be a day/release in the Java world when we will be able to write 10x - 20x shorter programs (in terms of LOC) with most mundane stuffs disappearing under the hood. Sighs!!

It will be interesting to see the reaction of project managers some of whom still measure productivity in terms of lines of code/# of commits! (yeah, they do and still exist).

Curious how many folks here experimented with the now depreciated Ahead-of-Time Compilation feature?

I did, the main issue is that jaotc doesn't do any pruning of the unused methods, so it generates too much assembly code. If i remember correctly, compiling just guava was to close to 1 gig.

GraalVM native image is far better, it "compiles" more slowly but the resulting executable is not too big.

I think that is by design due to reflection needs. Hard to prune unused code when it might be called reflectively at any time.

Which is why GraalVM requires you to explicitly mention what types should be available for reflection.

Yea, but that's impractical in a lot of cases where frameworks or large libraries are involved.

There are good frameworks that already work well with GraalVM native, including Quarkus and Micronaut. They avoid reflection altogether in most cases.

Only briefly tested it. I thought RH's Quarkus project made use of it, didn't it? What's the post-16 way of Java AOT compilation?

Graal is a separate project and jaotc did use that. I believe the reason for the “separation” is that the two projects have different priorities and didn’t develop at the same pace. I believe graal is still only at version 11.

But since Java, the language is highly backward compatible, one can trivially use Graal as is (without the preview features though)

I did experiment with it to improve the startup times of one of my applications (Java Swing). The gain was quite small, nearly not noticeable.

Wow, might be time to finally throw out my copy of Java 6 SCJP (Sun Certified Java Programmer)

Someone asked where is Java still used. Well, elasticsearch, signal for android, mockito, j-unit.

Closed source projects include Airbnb, Uber, eBay, Pinterest, Groupon, Spotify, Intel, Symantec

Do you think the "Run anywhere" marketing behind Java is rarely important?

Java programs normally sit on a server, or many servers of the same arch.

The decent thing is that someone can build a JVM for a new architecture and lots of /other/ languages that target the JVM work.

But this seems different from "my program can runs on lots of architectures".

In the 1990s it looked very much as if desktop and server heterogeneity would be the norm. That you'd pick between alternatives like Solaris on SPARC, HP-UX on PA-RISC, Irix on MIPS, Windows on Alpha / MIPS / x86 / PowerPC, MacOS on PowerPC, OS/2 on PowerPC / x86 etc etc.

The designers of Java, as well as software community at large, had dealt with the pain of moving large codebases across platforms and so the WORA promise was very appealing.

It would have been cool if Limbo/Dis would had gotten more attention at the time. To me it looks like a more promising base, and was released the same year as Java. I can't at the moment find under what terms it was released back then, but it's free software now.

> Java programs normally sit on a server

Or an Android smartphone or media streamer (Android TV).

However, those programs won't run anywhere; they need Android.

Java has turned into C. Java programs need a platform-specific set of libraries just like C needs POSIX, or Win32, or VXWorks or ThreadX or whatever.

This is pretty much inescapable.

Java apps are pure Java for the most part, they basically contain no native code, unless for some very specific OS API call (in which case portability is a non-goal) — and the JVM will run any class file thrown at it.

Android is special because it has many many special APIs, so I don’t see your point. Just look at the (unfortunately not too numerous) desktop java apps. The exact same jar from n years ago will just run on all three main OSs.

> Java programs normally sit on a server, or many servers of the same arch.

That's true right now, but it wasn't true in the recent past (SPARC) and it might not be true in the near future (ARM).

Early in my career I was on a team that migrated our Java application from elderly Sun boxes to newer x86 hardware, and it was relatively painless. There's a good chance we'll eventually to the same from x86 to ARM. Most developers will also continue develop on x86 for the foreseeable future.

Java adoption has now reached the release_version / 2 parity :)

Site is dying with 500.

Got the same at first. Reloaded the URL and it came up correctly.

Same experience. A few refreshes and it works.

The beauty of a load balancer ...

Looks like they added sensible no-boilerplate immutable data objects, and are trying to unbox their boxed primitives, yay for common sense at long last.

While they're about it, they should also add immutable/copying data structures.

>While they're about it, they should also add immutable/copying data structures.

They will start with records[1], but I think all value classes (Valhalla) should have this functionality eventually.

You will be able to write:

   record Point(int x, int y){}
   Point pp = p with { x = 3; }

[1]https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

This is definitely good, but I'm also meaning Clojure style lists, maps, etc where you can treat any given copy of the entire data structure as one big immutable value.

It's been a while since I've worked with Java, but I'm surprised and kind of disappointed at the level of callbacks in the example code from the OP.

Interesting. Readibility? Performance cost? Would be nice if you could expand.

We use java 100, called kotlin

Java 16 for what? Does anybody really use > 8 in production?

Who still uses Java 8 in production? That is a serious risk. I thought everyone moved to 11 already.

I use Java 15 in production in 3 projects.

I am pretty sure Red Hat, IBM, and probably other enterprisey type companies backport security patches for Java 8.

Tons of folks in financial IT are on 8 - it is pretty stable and very common target for most of the libraries being used.

We're still on 8 at <bank>

Looks like no type aliases still? Does anyone know if type aliases are anywhere on the road map for Java? Is there some philosophical objection to them?

Considering how heavily they have borrowed from Scala lately, I would have expected them to pick this up. I found them quite useful in Scala (and in Golang as well).

Java is not borrowing from just Scala, it's borrowing from all languages and adding its all twists to things, just like Scala itself has always done (it's cleary inspired by Java itself, ML and Haskell, probably more).

I do not believe they are on the roadmap at all.

What are aliases?

As in Scala:

    // define a type alias
    type UserId = Long

    // can be used as a regular type
    val userId: UserId = 123L
    val userIds: List[UserId] = List(1L, 2L, 3L)

The language is getting fragmented: value-based classes, records. I wish the features were introduced still keeping one kind of objects, instead of splitting the universe into 3 kinds of objects (usual objects, value-based objects, records).

The feature I am awaiting most is the Project Loom.

Yeah, same feeling here. The special-casing feels off. They must have had very good reasons to do that, I just haven't seen them outlined yet.

The new object type being promoted from preview feature is just the record type. Records are still Objects, they just provide a low ceremony way to create an immutable object holding some data.

I see these record classes in the same category as enum objects, an evolution of the language to improve developer ergonomics.

Upcoming is inline-classes (previous called value types.) When this happens we'll have a true "special" kind of Object, one that does not have any identity. The motivation here is mostly performance. The details are available in Brian Goetz "State of Valhalla" update https://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-back...

Even if `record` is a syntactic sugar, I'd better see a canonical constructor added to all usual classes. The constructor parameters are of types of all the fields, in the declaration order. In this case we could say

    class Point { public final int x, y; }

instead of

    record Point(int x, int y) { }

Usual non-record classes would benefit greatly from such a feature too.

Actually, if class fields have different visibility, several canonical constructors are needed. If public fields exist, a constructor that sets all public fields. If protected fields exist, a constructor that sets all public and protected fields. If package-private fields exist - setting all public, protected, and package-private fields. If private fields exist - setting all public, protected, package-private, and private fields.

What remains, is value-oriented versions of equals(), hashCode() and toString() to be defined. Probably better to express as a base class than the new keyword `record`;

    class Point extends Record { public final int x, y; }

A polyfill for such a base class for older Java:

    import org.apache.commons.lang3.builder.EqualsBuilder;
    import org.apache.commons.lang3.builder.HashCodeBuilder;
    import org.apache.commons.lang3.builder.ToStringBuilder;


    class Record {
        @Override
        public int hashCode() {
            return HashCodeBuilder.reflectionHashCode(this, true);
        }

        @Override
        public boolean equals(Object obj) {
            return EqualsBuilder.reflectionEquals(this, obj, true);
        }

        @Override
        public String toString() {
            return ToStringBuilder.reflectionToString(this);
        }
    }

I practice such classes in my code, for constructors, I just don't bother for final (Java does not support it well anyways), and have factory methods in a separate class, so they are out of the readers view.

Adding a new canonical constructor to all classes would very likely have backwards compatibility issues, so we'd likely need some sort of opt-in mechanism. In the end the language designers decided that they wanted to give developers a way to create a very focused kind of object.

This goes into the design motivations: https://cr.openjdk.java.net/~briangoetz/amber/datum.html

Additionally, one less talked about benefit of records is they have a simplified serialization scheme that is safer by default. Records when being deserialized have each of their members read and then the canonical constructor is called, if the values are not valid then the constructor can reject the fields instead of allowing an "impossible" object from being created.

The opt-in (or rather opt-out) could be a presence of user-defined constructor.

The same way as with default no-arg constructor.

Interesting note about serialization. That could also be part of the base class.

What’s the use of forcing everything to be an object?

Reply on news.ycombinator.com