Live data from Hacker News

Java 22 Released

mail.openjdk.org

151–160 of 178 posts

Re: Java 22 Released

#151
post #75

Earlier quoted context omitted.

I see Manifold as a huge leap past previous tools Immutables or Lombok. I understand there's a use case where you want to add these language features to an existing code base. But for the most part if you want the language features on the JVM, you should probably just use Scala. That gives you a set of established patterns, best practices, libraries, and a community of users. If you want type safe SQL in particular,…

> just use Scala Scala is a dying language, anyone boarding that ship is making a mistake. Anyhow, I prefer Java supplemented with powerful features Scala doesn't have, such as type-safe SQL. > If you want type safe SQL in particular, you can pry JOOQ out of my cold dead hands. Jooq isn't bad, but it's not SQL, it's Java trying to be SQL. Manifold lets you write type-safe, native _SQL_ of any complexity directly in y…

> Jooq isn't bad, but it's not SQL, it's Java trying to be SQL.

Can you elaborate on this? I have been using JOOQ for years (with Kotlin), and I have never had any issues with it "trying to be SQL".

Re: Java 22 Released

#153

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-o…

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.

For sure, Java developers need to use a tool like yours to distribute their app. My experience with some Java applications was that running it triggered an attempt to download (I assume) the JRE, which I cancelled as I didn't know the source of download and didn't want it to download some PUA or malware. (I remember JRE for windows used to bundle some browser toolbar on windows). Hence my attemt to install it myself beforehand. But, since Oracle has stopped distributing latest JRE through Java.com for macOS, I looked for it in MacPorts. And it is really confusing - for example, if you look at the OpenJDK-Zulu port that you recommended - https://ports.macports.org/port/openjdk21-zulu/details/ - it has 4 variants:

1. Applets ( Advertise the JVM capability "Applets".)

2.BundledApp ( Advertise the JVM capability "BundledApp". This is required by some java-based app bundles to recognize and use the JVM.)

3. JNI ( Advertise the JVM capability "JNI". This is required by some java-based app bundles to recognize and use the JVM.)

4. WebStart ( Advertise the JVM capability "WebStart".)

- what the heck? I think I am better off without Java. :)

Re: Java 22 Released

#154

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.

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.

Re: Java 22 Released

#155

Earlier quoted context omitted.

Groovy itself is a bad Groovy.

bad opinion is bad I get gradle is a disaster (but that's more of a poorly managed and evolved DSL problem) But ... does anyone use Spock and think "groovy sucks"? Yeah, I doubt it.

Raises hand Here! I have to work with Spock on a Java codebase and I think groovy sucks ;-)

Re: Java 22 Released

#156

Earlier quoted context omitted.

But Java has all those features...?

Oops, sorry those are features java "stole" from groovy. Java has the nullsafe operator now and the elvis too, doesn't it? I don't use the spaceship operator much, implicit sorting works pretty well. Groovy's closures have a lot less GOTCHAs. They simply work as expected, at least to me. Half the time I use java closures and I get complaints in compilation that I don't get in Groovy, but maybe they've improved closur…

> Oops, sorry those are features java "stole" from groovy.

Well, yeah? Java's explicit strategy for the last few decades is to let other languages experiment, then implement the ideas that worked out once the dust has settled.

Re: Java 22 Released

#157

Why would I use Java 22 over Kotlin?

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.

Re: Java 22 Released

#159
post #122

Earlier quoted context omitted.

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

Android?

Android OS layer has zero Kotlin, and Google had to backtrack on their decision to let Java languish, as the Android ecosystem started to lose out on Java ecosystem, thus ART is now updatable via Play Store since Android 12, and Java 17 LTS is the latest supported version.

Kotlin is only used on Jetpack Compose and a couple of AndroidX libraries, that you have to ship alongside the application. And as alternative to Groovy on Gradle build scripts.

I expect this year's GDC to announce Java 21 LTS support.

Re: Java 22 Released

#160

Earlier quoted context omitted.

Groovy itself is a bad Groovy.

bad opinion is bad I get gradle is a disaster (but that's more of a poorly managed and evolved DSL problem) But ... does anyone use Spock and think "groovy sucks"? Yeah, I doubt it.

Yeah I use Spock and Groovy all the time, good god does it suck big ones.
Post reply on HN