Java 22 Released (opens in new tab)

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

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.

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

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.

The thought process leading up to this work

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

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.

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.

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!")

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.

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!

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!");

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.

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.

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.

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

love this!

Java continues to evolve to a bad Groovy.

Boring changes like these are what keeps Java interesting.

New and shiny syntax sugar becomes stale real quick.

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

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.

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

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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

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.

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

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

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.

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.