Java 22 Released

[jimbokun]

Maybe my favorite feature in this release:

https://openjdk.org/jeps/463

Finally solves the inscrutable Hello World program!

Yes, it's just ergonomics for early beginners. But could be the difference in whether or not someone new to programming sticks with Java or not.

[HackerThemAll]

C#'s got even better version of this feature since Nov 2021. Hello world is just a true one-liner.

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...

[coldpie]

I 1000% agree. Though, a favorite early programming memory of mine was when static methods finally clicked and I went back and looked at all that boilerplate that meant nothing to me and it all became crystal clear what it meant and why it had to be like that.

[sireat]

Actually a nice feature.

This solves the public static void main string args issue.

Still if I need JVM then Scala or Kotlin are still preferable over Java.

Obligatory Java for the Haters in 100 Seconds: https://www.youtube.com/watch?v=m4-HM_sCvtQ

[okeuro49]

I really dislike this feature.

It's better to just say "we will come to this concept later", rather than make a fake syntax that does this (taken from the JEP) behind the scenes:

new Object() { // the implicit class's body }.main();

It adds more confusion, as you are left explaining that you could not really run an instance method without instantiating the class -- it was just something fake for beginners.

[carimura]

The thought process leading up to this work

https://openjdk.org/projects/amber/design-notes/on-ramp

[Almondsetat]

My first Java programming course went over in detail about that piece of code and in a couple of hours taught me a lot of important Java concepts right away. Consider me not enthused about it.

[cryptos]

This is nice for beginners, but the confusion is only postponed, because then you'd have to learn why you need to write a class as a container for static methods and that these methods must be static. So, the Java developers created another special case in the language.

Compare that with Kotlin where you have top-level functions, so that `main` is just like any other function.

[int_19h]

They almost caught up with C#, which ditched requisite class declarations years ago. Although C# went one step further and allowed top-level code outside of methods, so that hello world is now:

   Console.WriteLine("Hello, world!")

[lotsoweiners]

That sounds a lot like Top-level Statements in the .Net world. Personally I don’t use that feature because I’m old and get confused if things are magic but can certainly see the benefit for the newer devs.

[bitwize]

This is exactly what I've been calling the "public static void main problem" for years (and an illustration of why I thought something like BASIC or Python should be everyone's first programming language). Neat to see the Java team come up with a solution for it. But "public static void main" runs deeper, and has to do with immediacy: shortening the time between the programmer giving instructions to the computer and seeing the results of those instructions being executed. It makes the smallest possible Java program greatly simpler and absent unusual comments that beginning programmers might struggle with; but there's the issue of the compilation step as well! If they make Java REPL-driven they might well have a winner!

[bheadmaster]

Good that they got rid of the class/public static void/string[] Args boilerplate, but if they just went one step forward and declared implicit main function as top-level scope of a file, we could've got to a Python level of tersity. Just imagine!

    System.out.println("Hello world!");

[dajt]

I really doubt that. Java is complicated enough that it's not beginner friendly even if you don't have to write the class to put main into.

Given these are still methods of classes this JEP seems pointless to me. Not having to write class x {} isn't a great time saver.

[aembleton]

Maybe in another ten years they'll remove System.out.println and allow for a simple println to be used.

Or maybe we'll all move to Kotlin by then.

[jonahbenton]

With respect, not hostile to beginners but adding complexity to the build to support this kind of implicit sugar, when beginners are 100% going to be using AI to write code and answer questions- seems like not the right tradeoff in 2024.

[fuzztester]

Well, they reduced a few lines of boilerplate for hello world Java program, while adding many many paragraphs of text to explain it. ;)

[kyawzazaw]

love this!

[AtlasBarfed]

Java continues to evolve to a bad Groovy.

[ecshafer]

It isn't a "Sexy" PL change, but a full foreign function interface will be a huge change. In my experience, relying on the old java JNI based libraries seems to be one of the biggest things that break in upgrades. So I am hoping this will reduce the maintenance burden of Java.

[DarkNova6]

Boring changes like these are what keeps Java interesting.

New and shiny syntax sugar becomes stale real quick.

[krzyk]

Linkable features https://openjdk.org/projects/jdk/22/

For me personally the most interesting one is JEP461 (Stream Gatherers) https://openjdk.org/jeps/461

This will allow addition of interesting stream operations.

[cryptos]

This is indeed nice. However, static extension methods would have made this feature simpler (and more generic).

[cryptos]

Although I like Kotlin better, I'm really impressed how Oracle continues to improve Java. Some developers think Java is an old, cumbersome language, but it is indeed such a productive language and ecosystem with outstanding quality! Java has quite good support for functional programming, concise and immutable structs (called "records"), pattern matching, string templating, virtual threads, structured concurrency (preview for now), a vast ecosystem with outstanding quality, world class documentation, a fast and robust runtime and so on.

Even after nearly 30 years, Java is still a good choice to start something new (e.g. a startup).

[munksbeer]

It is very trendy to hate java. Which is actually a good thing, because it means I get to continue to enjoy working with java alongside sensible professional developers, who quitely get on with writing excellent code and creating industry leading systems with java. Less competition for the roles and I don't have to work with fanboy types.

[oaiey]

Foreign Function Interface is one of the key advantages what C# had over Java (e.g. against huge APIs like Android or macOS). I am really curious how this JEP turns out.

[neonsunset]

Small correction: FFI in Android land is abysmal, to get decent performance when accessing all kinds of system APIs you almost always end up having to write helpers in Java, to try to alleviate the pain of JNI as much as possible (it is still significant).

Interop with iOS OTOH is a breeze, some of the APIs may require newer Swift Library Evolution ABI (direct calls to Swift exprots, without going through C/objC) but .NET is getting it in .NET 9 (the first and only platform to have it at the moment of release).

[adra]

I started to tinker with this new API last week. I definitely think it's a lot better than needing to self compile a lot of the bindings yourself which will certainly bring more from the community into the feature than were here before.

That said, you really need to write a bunch of boiler-plate to implement useful things in java-like paradigms in the library today. Just as an example, I wrote up a sane windows _getcwd() stub and it's like 30 lines to implement correctly (properly freeing the buffer when I'm down with it)

My pet project is to see if I can write automatic stubs around calls based on published API info and sources, so that at least some of that platform binding lift isn't just for those with non-trivial knowledge of C. Well, that's the hope anyways.

[soulbadguy]

The FFI is also an artifact of CLR type system and the ability of have proper stack value based types.

[MaxBarraclough]

For anyone reading, here's a link to the page with detail on this project: https://openjdk.org/jeps/454

[zbentley]

It's definitely exciting and a big step forward from JNI/JNA.

However, I am a little concerned about the heavy emphasis on library unloading in the JEP. Unloading is famously fraught and unsafe for wide swaths of common libraries ... or maybe I'm overfitting due to recent trauma[1] and everything will be fine.

1. https://gist.github.com/thomcc/8c4a8003cf1a282949a539e899cb4...

[ackfoobar]

It worked great for me. I had long wanted to rewrite a Python lib in Kotlin, since the Python part of the lib is slow, and it does not support multi-threading.

But the ugliness of JNI stopped me. Then I tried FFI in Java 21, with jextract it was amazing.

I wasn't aware of FFI at first, but the finalized version of virtual threads made me check the Java release notes.

[preommr]

It's kind of startling to see how many places still use Java 8, estimated at ~1/3 of projects according to a survey i just googled. And something like half that still use java 11.

[MBCook]

8 reached EOL in the last year or two. I think 11 is still under LTS.

Part of the problem is the changes made between 8 and 17 could be incredibly disruptive depending on your libraries.

If they had stuck to not using sun.* stuff you were pretty safe, but a few very popular things did.

Then somewhere in there a lot of the common server stuff moved from javax.* over to jakarta.*.

Both were needed and very good, but could turn into dependency nightmares. So depending on your app/stack it wasn’t an easy transition.

17 is fantastic though, especially coming from 8. I’m excited about what’s already in 21 (latest LTS) and coming in the next LTS after that.

[fngjdflmdflg]

Wasn't the whole point of Java never releasing a 2.0 that there would never be breaking changes? Seems like something went very very wrong with Java if the state they are in is that the language refuses to make breaking changes and the developers refuse to take up the supposedly non breaking updates due to breaking changes based on the comments I'm seeing here. So the language never improves as much as it can and the developers never update anyway making the whole point of non-breaking changes moot.

[adra]

I'm dragging my new company's codebases from 8 to 17 from soup to nuts. It's not always just about the language update, but all the old legacy crust that accumulated since java 8 that prevented anyone else to do it. My PRs are terrible and necessary.

[elric]

Wait until you hear about COBOL still being used.

Snark aside, the problem with Java in the enterprise is that Oracle provides support for mind-bogglingly ancient versions (if you're willing to pay them). This disincentivizes companies from upgrading, ends up frustrating their developers, and has probably contributed to the negative reputation that Java has in some corner of the net.

I get that tracking the current version isn't feasible for most companies, especially if software isn't their core business. The Java folks do their best to make upgrades painless, but the longer you wait, the more painful it gets.

[BroomOfSYS]

Unbelievable! It is a strong signal that people don’t care and technical leadership is bad. Always the nonsense excuses of having to work on a “legacy” codebase for more than ten years with a team of 3 developers and 4 analysts.

[Nullabillity]

In practice, Java is the language of legacy and Android.

Java 8 keeps working, while "modern" Java keeps chasing mistakes like green threads. If anything, I'm more baffled by 9+ having a non-neglegible market share at all.

[jmyeet]

Examples [1] of these features.

[1]: https://www.happycoders.eu/java/java-22-features/

[thisislife2]

Now this may seem like a silly question, but if I only want to run Java apps on macOS, what should I install from MacPorts? Searching for "JRE" gives no results. Searching for OpenJDK gives various options including:

- OpenJDK21: https://ports.macports.org/port/openjdk21/details/ , - openjdk21-zulu: https://ports.macports.org/port/openjdk21-zulu/details/ - openjdk21-oracle: https://ports.macports.org/port/openjdk21-oracle/details/

each of them having so many variants (see the links). What variant needs to be installed to just run a Java app?

[mike_hearn]

Usually Java apps come with Java these days, like how there's no independent way to run Electron apps, it just comes with the download of the app itself. There are tools that make it easy like jpackage and (toots my own horn) https://www.hydraulic.dev

If you want to just quickly run a fat jar then any will work. "openjdk21" is fine. The Zulu variant comes with JavaFX which simplifies things if your app needs that.

[didip]

Sweet, G1 keeps getting better for free. Time to cut a new build tag for this.

[pkphilip]

Interesting to see the developments on the String Templates API using the STR and fmt template processors.

[ludovicianul]

It gets interesting: https://mail.openjdk.org/pipermail/amber-spec-experts/2024-M...

[melling]

“Vector API (Seventh Incubator)”

Seven iterations? What is going on with vectors in Java?

[GreenToad]

"Vector API" is universal api for SIMD. It will probably remain in incubator until valhalla delivers value types.

[voidfunc]

My understanding is it depends on Valhalla (value classes) and they basically keep updating it as that project changes.

[MrBuddyCasino]

The Foreign Memory API is in the works since 2014. They are just very diligent and careful.

[exidex]

They said it is waiting for some feature from project Valhalla. Not sure which one though

[neonsunset]

If you're interested, there already is a somewhat similar language that offers first-class support for these.

[geodel]

It will go on until 'value classes' are incorporated in Java

[grumpydude]

Unrelated to Java, but it’s so refreshing to see a simple HTML page for once

[jsnelgro]

Why would I use Java 22 over Kotlin?

[cupofjoakim]

To me the question "Why would I use X over Y?" in programming space is a bit redundant. Why would I use Kotlin over Closure? Why would I use Groovy over Scala?

Even only considering JVM languages you run in to way too many options for the question in itself to be worth your time as a serious discussion.

IMO - use whatever you and your team like best and that suits your needs. Java is great for hiring new devs and is arguably the most well established in an enterprise settings.

If you want an actual answer: Personal preference.

[pjmlp]

Kotlin is a guest language, doesn't have nothing to call their own as platform.

[bitcharmer]

You still need the JVM to run Kotlin. Also performance.

[jsnelgro]

The downvotes are unfortunate. To clarify I wasn't trying to start a flame war.

I was hoping someone would answer with concrete technical tradeoffs and comparisons e.g. compile times, null safety, common footguns, personal experiences, etc.

I was recently asked for a comparison between Kotlin and modern Java by a team that's considering a migration of their legacy Java service. I haven't kept up with Java's changes, so didn't have an offhand unbiased comparison to share.

I've worked on backend Kotlin and Java codebases for the last five years and have introduced Kotlin to dozens of teams across my company. Nobody I've introduced Kotlin to has ever ended up preferring Java or switching back to it. There's been initial skepticism at first (reasonable), but after working in Kotlin for a week or two, I've seen even the staunchest Java devs proclaim they're never going back.

To the point on personal preference, I think it's a factor but I don't think it's _the answer_. It's a blanket statement that ignores important details. Languages have different affordances, features, paradigms, and patterns that lead you to develop and think in different ways. Some differences like null safe types are obvious improvements for a large codebase with many contributors. The feature catches real bugs and makes the system easier to build and maintain.

I think there's a lot of warranted skepticism of JVM languages that aren't Java, but something about Kotlin feels very different. For comparison, I've worked with Scala (Spark) and played around with Clojure in my free time.

I'm not sure what feels so much better compared to other JVM languages, but if I had to guess I'd say it's an emergent quality from a few things JetBrains has done really well. In particular:

- The 100% Java interop claim is real. I've only had minor hiccups with Lombok - The ability to incrementally adopt Kotlin in an existing Java codebase - The IDE support in IntelliJ IDEA is unbelievable. The suggested refactorings subtly teach you the language - Null safety lets you focus on domain modeling and business logic instead of error handling and validation - Kotlin's backwards compatibility. New versions never seem to break anything. And they even provide refactoring actions in IntelliJ to automatically update deprecated usages - Very few significant paradigm shifts. Kotlin doesn't force you to totally change your Java code to fit a functional style or anything like that. It just tries to make safer code easier to write - The political stability and longevity gained from Android's blessing as a first-class language makes Kotlin feel like more than just another JVM language. There's Kotlin running on billions of devices. That's a pretty big ship to turn around, sink, or replace

To summarize, Kotlin just feels like the elephant in the room. Aside from low-level changes like new FFI possibilities and GC improvements, it's not clear to me what value Java upgrades add in comparison to Kotlin—especially in regards to new language features and syntax.

Anyways, hopefully this followup post starts a more fruitful discussion. I asked this question in earnest based on my personal experiences and observations. If you haven't tried Kotlin yet, I'd suggest cracking open an IntelliJ scratch file and test driving it yourself.

[cgijoe]

So does this fix the crashing issue with macOS Sonoma 14.4? https://arstechnica.com/gadgets/2024/03/usb-hubs-printers-ja...

[kaba0]

I doubt Oracle would fix it, as this is definitely a kernel bug that breaks userspace. It is part of the POSIX spec what the JVM relies on, and MacOS is supposedly POSIX-compliant. So it should be Apple that fixed their bug.