Live data from Hacker News

Java 22 Released

mail.openjdk.org

91–100 of 178 posts

Re: Java 22 Released

#91
post #75

Earlier quoted context omitted.

As a modern language Java is still quite feature deficient. But you can use compiler plugins like the manifold project[1] to level up. 1. https://github.com/manifold-systems/manifold

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

Re: Java 22 Released

#92
post #55

Earlier quoted context omitted.

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

Not just value types, but also: 1. Pointers to the same (and not just references to objects). 2. Unions (via explicit-layout structs) 3. Function pointers. 4. C-style varargs. To be fair, not all of these have been exposed in C# historically even though CLR had them all along. Most notably, unmanaged function pointers took over 20 years. And since most people look at CLR through the prism of C#, they aren't necessari…

Indeed. The CLR from its inception implemented a lot of features for helping native inter-op. I would guess that msft did make the effort simply because of their large legacy c/c++/win32 code base.

It's a shame really that msft stewardship of the .net/clr was so lacking. Of all the modern virtual machine clr us pretty much up there

Re: Java 22 Released

#93
post #20
post #9

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.

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

Have you looked at Microsoft's Win32 API metadata package [0]? They're using it to generate C# and Rust bindings, and other people have targeted other languages.

[0] https://github.com/microsoft/win32metadata

Re: Java 22 Released

#94

Earlier quoted context omitted.

Boring changes like these are what keeps Java interesting. New and shiny syntax sugar becomes stale real quick.

As a modern language Java is still quite feature deficient. But you can use compiler plugins like the manifold project[1] to level up. 1. https://github.com/manifold-systems/manifold

Manifold isn't Java.

Re: Java 22 Released

#95
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

For reading it, I believe that. For authoring it, yikes it is slow. I'd guess due to all the implicit and implied and coercion and ... and ... and. Now I'm cognizant that I'm running my mouth without trying it on 1.9.x and a similarly recent IJ so maybe it got infinitely better, but my life experience with languages is that they only get more fancy swooshings not QoL improvements due to Moore's Law and yearly refresh cycles

I was/am always glad to pay that tax because non-null-by-default and the vastly superior val/var keyword pairs are totally worth it but it for sure is not a drop-in replacement in team environments. I am already constantly battling the vscoders (to say nothing of vimers) whining that "IJ is too slow for my eeee-leeeet typin'"

Re: Java 22 Released

#96
post #12

Earlier quoted context omitted.

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

I'm really happy they are reconsidering the syntax. Thanks for the link

It sound like they're only reconsidering the prefix, not the backslashes, or am I misreading it?

So we're not getting "hello $name" but rather than STR."hello \{name}" they're now considering $"hello \{name}".

Re: Java 22 Released

#97

Earlier quoted context omitted.

How so? I don't think there are many good things to say about Groovy, but I generally agree with most new features introduced to Java. What do you think Groovy does better?

- String interpolation - triple-quote strings / blocks - minimal class boilerplate (this posting) - closures (Java closures are worse IMO) - usable hashbang for UNIX - I think java has strings in switch now, don't they? Do they have expressions? WAIT, does Java STILL force you to write getter/setters?

Hashbang aside this is a solid description of a base feature set of C# :D

Re: Java 22 Released

#98

Earlier quoted context omitted.

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.

> Java keeps chasing mistakes like green threads If by green threads you mean virtual threads in JDK 21 could you please elaborate why they are a mistake? I'm not a Java developer but from what I see new concurrency model allows to write much more efficient network software - OS threads are expensive (in terms of RAM/CPU) and to handle many thousands of network connections (C10k problem) you have to either throw a lo…

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 expectation that all libraries play nice with their scheduler. They also try to hide FFI starvation by effectively running each FFI call in a dedicated OS thread[0].

There's also gevent/greenlet, which tries to bolt "colourless" M:N scheduling onto Python. It hasn't exactly taken the Python world by storm either, despite being far older than their native asyncio support.

Overall, I'd consider all three implementations of the approach to be dead on arrival.

[0]: See https://stackoverflow.com/a/28356944, it's a bit obfuscated but the overall effect is the same

Re: Java 22 Released

#99

Earlier quoted context omitted.

How so? I don't think there are many good things to say about Groovy, but I generally agree with most new features introduced to Java. What do you think Groovy does better?

- String interpolation - triple-quote strings / blocks - minimal class boilerplate (this posting) - closures (Java closures are worse IMO) - usable hashbang for UNIX - I think java has strings in switch now, don't they? Do they have expressions? WAIT, does Java STILL force you to write getter/setters?

A form of string interpolation is in this release.

Re: Java 22 Released

#100
post #79

Earlier quoted context omitted.

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…

Java 8 allows access to unsafe methods, which despite being meant for internal JDK use only, have been widely used in external projects. Newer Java versions do not permit the use of unsafe except for the JDK itself. It wasn't ever part of the public API that's promised to never break, and JDK developers were annoyed that it being used meant Java got perceived as unstable, and it's gone in more recent versions.

I thought the issue was not Unsafe methods (which are only just now starting to be marked for removal) but rather various bytecode weaving libraries like javassist. As the JDKs progressively enforce bytecode verification more strictly these libraries sometimes run afoul of the new restrictions. (I speak from a little experience here, managed a somewhat involved upgrade path from 7 to 8 way back in the day which had this issue.)
Post reply on HN