Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 22 Released

mail.openjdk.org

Post reply on HN
Print view View original

171–178 of 178 posts

Re: Java 22 Released

#171

Post by funcDropShadow »

temporarely wrote: post #110
Nullabillity wrote: post #98

Earlier quoted context omitted.

There were already "user-mode" implementations of asynchronicity on the JVM for years (like Monix, cats-effect, Pekko (fka Akka), etc). Loom has a worse API, is hidden from the user (what's preemptible and what will cause OS thread starvation? who knows!), and effectively ends up infecting the whole JVM with its complexity. Go shares most of those downsides, but as a greenfield project (..heh) there's at least the ex…

Kilim was the first for Java iirc. Interesting point regarding scheduler and the interruptibility of FFI calls. Just thinking about it I don't see how this can be addressed. So definitely interested in learning here: what is the remedy to your criticism here beyond "document behavior"?

> Kilim was the first for Java iirc.

No, the JDK had builtin green-threads behind a command line flag around Java 1.1 on Solaris.

Re: Java 22 Released

#172

Post by mike_hearn »

thisislife2 wrote: post #153
mike_hearn wrote: post #144

Earlier quoted context omitted.

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…

That's a MacPorts thing, I've not seen that before and the Zulu download doesn't seem to have that. And zulu goes in for variants more than most distributors do.

Re: Java 22 Released

#173

Post by pjmlp »

willsmith72 wrote: post #82
sireat wrote: post #58

Earlier quoted context omitted.

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've never seen a java codebase I thought couldn't be better in kotlin

Looking forward to JetBrains proposal to rewrite Java Virtual Machine into Kotlin Virtual Machine, certainly the existing Java codebase would be largely improved.

Re: Java 22 Released

#174

Post by bheadmaster »

aidos wrote: post #57
bheadmaster wrote: post #48

Earlier quoted context omitted.

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

To be that guy, not quite a python level of tersity!

Well, if they added System.out in the default context, it could've been just

    println("Hello world!")
I think that's as far as you can go.

Re: Java 22 Released

#175

Post by KyleBerezin »

thisislife2 wrote: post #153
mike_hearn wrote: post #144

Earlier quoted context omitted.

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…

My personal go-to for mac is the Liberica JDK from Bellsoft.

Re: Java 22 Released

#176

Post by temporarely »

funcDropShadow wrote: post #171
temporarely wrote: post #110

Earlier quoted context omitted.

Kilim was the first for Java iirc. Interesting point regarding scheduler and the interruptibility of FFI calls. Just thinking about it I don't see how this can be addressed. So definitely interested in learning here: what is the remedy to your criticism here beyond "document behavior"?

> Kilim was the first for Java iirc. No, the JDK had builtin green-threads behind a command line flag around Java 1.1 on Solaris.

fibers, not threads (regardless of color). "loom" ..

Re: Java 22 Released

#178

Post by admin00000001 »

owlstuffing wrote: post #91
wmfiv wrote: 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…

once you write jvm language you can't really be dying language. how can yoy die if you can use all jvm tech stack. Its just all about syntax. You can write powerful state of the art software even in brainfuck as long as it compiles to jvm bytecode
Post reply on HN