Live data from Hacker News

Java 20 / JDK 20: General Availability

mail.openjdk.org

291–300 of 356 posts

Re: Java 20 / JDK 20: General Availability

#291
post #270

Earlier quoted context omitted.

> Everything should be a drop-in replacement This is not true for many applications. Due to the removal of many APIs from the JDK with Java 9, I needed the following dependency artifactIds to be able to move a JEE application with SOAP web services to Java 11: jaxb-api, jaxb-core, jaxb-runtime, istack-commons-runtime, jboss-jaxws-api_2.2_spec, glassfish-corba-omgapi, jboss-annotations-api_1.2_spec, activation, jboss-…

Are you really actually using CORBA? That would be heartwarming if so. Maybe just RMI over IIOP?

It's far less exciting I'm afraid: we use [0] to generate our DB IDs and it implements org.omg.CORBA.portable.IDLEntity.

We could fork it and remove the interface or switch to ULID[1] instead.

[0] https://github.com/stephenc/eaio-uuid/blob/master/src/main/j...

[1] https://github.com/ulid/spec

Re: Java 20 / JDK 20: General Availability

#292
post #61

As a Clojure programmer, I don't care about any of the Java language features or improvements, but I'm super happy that I'm getting a state of the art JVM that is continuously developed, maintained, extended and optimized, over a time scale of decades. This is incredibly useful: having a good VM to run your code in, with good modern garbage collectors, is not an obvious thing (as many other languages have learned). T…

Any user of a guest language should care about what the "systems" language of the platform offers, if nothing else, to understand those stack traces, and FFI to platform libraries.

Re: Java 20 / JDK 20: General Availability

#293
post #216

Earlier quoted context omitted.

Im what aspect is the VM “far superior”? Where are CLR’s state-of-the-art GC or low-level GC? Or does it have observability tools like JFR?

I do not use C# (in fact, I do my best to avoid Microsoft products). But I can tell you that there are obvious workarounds C# employs to work around its lackluster GC. Stack allocation and spans immediately come to mind. As far as I know, Java offers no way to mark objects as stack-allocated, but C# does. Spans in C# allow programmers to produce subarrays without copying. Enums in C# are stack-allocated, unlike Java.…

But these are all tredeoffs, that make C# almost as complex as C++. Sure, there are cases where these low-level optimizations allow for better performance, but don’t forget that the more things we specify, the less freedom does the runtime have. SQL is a good example here, it specifies the what and not the how, and this makes a good db very hard to beat on complex queries.

The way I have seen it described somewhere: C# has a slightly higher performance ceiling, but a naive application may very well run faster in Java.

Re: Java 20 / JDK 20: General Availability

#294

Could the pundits of HN please compare this release with Kotlin?

Picking the release notes apart: - ScopedValue (Incubator). Seems like a replacement for ThreadLocal that is intended to be a bit less dangerous (it is notorious for leaking memory and file handles). The Kotlin equivalent would be CoroutineScope. I'd say the latter is the cleaner solution. And probably ScopedValues came into existence for the same reason (co-routines & structured concurrency kind of breaking ThreadLo…

Most Kotlin users don't get anything from JVM, as the majority target Android, and Google doesn't care that much about keeping Java up to date, even the latest LTS updates, are partial support.

Re: Java 20 / JDK 20: General Availability

#295
post #118

Earlier quoted context omitted.

Awesome but today this would be a different story line ... maybe: two old conservatives (Java and C#) re-inventing themselves to fight against the hipsters (Go, Swift, JS, ...) ;)

JS is older than C#.

While true, the hipster languages are the reason why minimal APIs came to be.

.NET is loosing people to the "cool languages" in regards to younger generations.

Re: Java 20 / JDK 20: General Availability

#296
post #263

Earlier quoted context omitted.

The problem of scaling threads up further is fundamental and not really solvable by more kernel features. JVM virtual threads can be efficient because the runtime has complete knowledge of the executing code and stack layouts, how the heap is laid out, how the GC works and it can control how code is compiled. The kernel can't do any of these things - it has to assume a process is a black box that could do anything wi…

> JVM virtual threads can be efficient because the runtime has complete knowledge of the executing code and stack layouts, how the heap is laid out, how the GC works and it can control how code is compiled. Forgive me for staying doubtful, but I recall hearing this same "the JVM can be very fast and efficient because its JIT has complete knowledge and control" spiel back in the 90s, and back then, anyone could clearl…

But the kernel doesn’t know the semantics — can that blocking call be turned into a non-blocking, or is blocking the wanted functionality here?

Re: Java 20 / JDK 20: General Availability

#297
post #145

Structured concurrency looks a lot like C#'s Task library without the async/await sugar but with the exact same footguns. Joining into a synchronous function is an anti-pattern in C# because you consume threads. This seems to be the same, except with the assumption that virtual threads are fine.... But that's not an assumption that can be made by the method writer, right?

Tasks aren't threads in TPL.

Re: Java 20 / JDK 20: General Availability

#298

Earlier quoted context omitted.

As another Clojure programmer, I say you should care about developments in Java. After all, the Java module system is precisely why classes became minefields with clojure.core/bean -- illegal reflective accesses and what not. As someone else noted in this comment section, a lot of useful Clojure libraries are wrappers over Java libraries. So improvements to Java used in these libraries are good for you, too.

The Java module system is a problem on Java as well. They defined "module" in the narrowest terms possible (API visibility) without addressing any of the modularization problems Java developers have to deal with every day, so we end up with another layer on top of the layers of third-party dependency management systems, package repositories, and runtime class loaders that we are forced to use to have a semblance of a…

> They defined "module" in the narrowest terms possible (API visibility) without addressing any of the modularization problems Java developers have to deal with every day

What other way would be possible, how would you solve it?

Re: Java 20 / JDK 20: General Availability

#299
post #265

Earlier quoted context omitted.

There are java desktop applications, e.g. IntelliJ, SQLDeveloper, etc.

IntelliJ is one of the few GUI apps on my work laptop, but my company is encouraging everyone to use JetBrains Gateway with a remote server farm instead (which sort of seems like a browser DOM only for their IDEs). When a backend needs an internal UI here, it's always a Javascript app in a browser.

Desktop apps are a niche, but a well-needed niche. Plus it’s not like there isn’t already a huge amount of Java desktop apps, and those are all running in X instead of Wayland.

Re: Java 20 / JDK 20: General Availability

#300
post #252

Earlier quoted context omitted.

I just wish records had an easy way to facilitate and/or associate a builder with them. Wishful thinking, out of scope for what they are. And of course, it's not hard to write a FooBuilder that's defined to help construct a Foo record. If Java records could be told to have a private constructor, I'd be completely satisfied with them. I just don't like the ability for callers to be able to directly instantiate a recor…

I wanted to experiment with creating a "Rust-like" option and result type for Java and so figured that I would need records and pattern matching for this and I ran into exactly what you are talking about here with records and public constructors. My solution was to create a sealed interface that permitted the None and Some records as the only classes to implement it. Those records are not available outside the packag…

This is not really pattern matching, that’s just a regular old if-else.

https://news.ycombinator.com/item?id=35133670

This is absolutely possible in Java and the only less-than-ideal part is the generic type having to be specified in the None case (but a trivial method fixes that as well)

This can be used just like rust and similar languages:

  switch (option) {
    case Some(var x) -> println(x);
    case None -> // TODO
  }
Hell, you can just further pattern match inside Some, like `Some(Point(var x, var y))`
Post reply on HN