Live data from Hacker News

Java 18 / JDK 18: General Availability

mail.openjdk.java.net

41–50 of 304 posts

Re: Java 18 / JDK 18: General Availability

#41
post #20

Earlier quoted context omitted.

Oracle's builds of Java are open source as well. The OpenJDK codebase is shared across all of the vendors that provide builds.

Thanks! So why would I pick Oracle's implementation?

Mainly if you want long term support from Oracle. Many enterprise systems are very slow to update. So they can't manage to upgrade before the LTS version goes out of support. So instead of paying to developers to continuously update the code base they pay Oracle to keep supporting the "out-of-free-support" versions of the JVM.

Re: Java 18 / JDK 18: General Availability

#42
post #20

Earlier quoted context omitted.

Oracle's builds of Java are open source as well. The OpenJDK codebase is shared across all of the vendors that provide builds.

Thanks! So why would I pick Oracle's implementation?

If you need to run Oracle apps like EBS. They only work on their release, not openjdk.

Side note: Avoid EBS at all costs if you can, unless you like spending money on consultants and like crappy obfuscated processes.

Re: Java 18 / JDK 18: General Availability

#43

This is tangential and possibly too open ended to be productive but worth a shot anyway. Why is Java so popular? I know of a major Silicon Valley company that's migrating their backend to it. Why Java over other languages? Or maybe there's not really other viable options? I'm speaking as someone who spent the last 6 years focused on frontend web technology.

Using backend technology:

- Java has great ecosystem support

- JVM is very performant

- Java has well understood quirks

- Reasonably mature build system

- Good deploy story

I wouldn’t use Java for a web server but I like it very much for many other things.

I think Scala + Play does a good job for JVM web frameworks but I’d use a Typescript thing (or just Rails)

There are downsides to Java. Bit and byte manipulation are annoying, for instance. But I’m still happy with it.

Re: Java 18 / JDK 18: General Availability

#44
post #40
post #22

Earlier quoted context omitted.

The language is simple. Reasonable performance, lots of opportunities to tune that performance without changing code. Great error handling. Works across all platforms in most cases. The tooling has a long standing reputation for being incredible, given what Eclipse and Jetbrains have done for the community. It integrates nicely with native code, and is easy enough to interface with (compared to e.g. Node.js and pytho…

Great error handling? What does that mean? Checked exceptions seem cool at first, but are really just nonsense… as your only real way of dealing with this is: 1. Catch, log and rethrow, or 2. Wrap as a runtime exception (so you don’t have to change every method signature up to main()) Sure, there’s option 3: catch and handle… but this is used 1/50 times, and the ergonomics of (2) overwhelm the utility of this. BTW, v…

Was referring more to structured stack traces. You're able to shoot yourself in the foot in any language's error handling system - quite trivially at that.

Re: Java 18 / JDK 18: General Availability

#45
post #4

Here's the openjdk page which includes links to details of all new features: https://openjdk.java.net/projects/jdk/18/

This one looks interesting: "JEP 400: UTF-8 by Default": https://openjdk.java.net/jeps/400 It sounds like a good idea, but I can imagine lots of downstream breakage, some of it not immediately obvious, with apps that make bad assumptions. Edit: The risks section of the linked doc above does explain some of that, and there is some notable risk.

> It sounds like a good idea, but I can imagine lots of downstream breakage, some of it not immediately obvious, with apps that make bad assumptions.

You're not wrong, which is probably why they did it in this release.

JDK 17 was an LTS release, and 18 isn't. The next LTS will be JDK 21 in September 2023:

* https://www.oracle.com/java/technologies/java-se-support-roa...

This presumably gives folks times to adjust before jumping between LTSes in production.

Re: Java 18 / JDK 18: General Availability

#46
post #26

This is tangential and possibly too open ended to be productive but worth a shot anyway. Why is Java so popular? I know of a major Silicon Valley company that's migrating their backend to it. Why Java over other languages? Or maybe there's not really other viable options? I'm speaking as someone who spent the last 6 years focused on frontend web technology.

I think it has a relative speed performance over languages that are interpreted (runtime). It also has an ecosystem of tooling to monitor and profile built both into the JDKs and by teams across Silicon Valley (eg first class bazel support). I’m in one of these companies now, and while I’m certainly productive using Java, it’s also got huge downside in the community which these companies don’t really care about. Neve…

Actually, i like it for basic desktop apps, because it just works, and i stay clear of the last 12 years of front-end dumpster fires, where nothing that is over 18 months old, can build, compile or get support anymore. In my day job, I inherit "fun" tasks as 'get this thing someone glued together with webpack4 and frontend-du-jour to work with webpack5 in 2022. Java thank you, any day of the week.

Re: Java 18 / JDK 18: General Availability

#47
post #14

This is tangential and possibly too open ended to be productive but worth a shot anyway. Why is Java so popular? I know of a major Silicon Valley company that's migrating their backend to it. Why Java over other languages? Or maybe there's not really other viable options? I'm speaking as someone who spent the last 6 years focused on frontend web technology.

Because Java is stable and mature, has well-understood performance, is statically-typed, has a proven track record when it comes to backwards compatibility, is reasonably fast and has lots of library and tooling support. Additionally lots of people know it. Some complain about verbosity. It's really a non-issue particularly in a modern IDE and not worth making a language decision over. Not everything has to be new an…

Definitely an issue in 8. My hack is to call everything an `int`, write the statement, and go back and let IntelliJ handle the proper name, adding the import, etc.

I understand though, that in more recent versions of Java this is taken care of for you.

Re: Java 18 / JDK 18: General Availability

#48
post #20

Earlier quoted context omitted.

Oracle's builds of Java are open source as well. The OpenJDK codebase is shared across all of the vendors that provide builds.

Thanks! So why would I pick Oracle's implementation?

I personally haven't had a reason to use Oracle's because I like having the latest version and any actively maintained LTS versions available for development and would prefer to use one vendor for all of them. Eclipse Temurin and Azul Zulu are the two I've personally used, but I'm not aware of any technical differences. They should all work the same since they're built from the same code.

Most of the big vendors are running the TCK tests to certify compatibility as well.

Re: Java 18 / JDK 18: General Availability

#49
post #44
post #40

Earlier quoted context omitted.

Great error handling? What does that mean? Checked exceptions seem cool at first, but are really just nonsense… as your only real way of dealing with this is: 1. Catch, log and rethrow, or 2. Wrap as a runtime exception (so you don’t have to change every method signature up to main()) Sure, there’s option 3: catch and handle… but this is used 1/50 times, and the ergonomics of (2) overwhelm the utility of this. BTW, v…

Was referring more to structured stack traces. You're able to shoot yourself in the foot in any language's error handling system - quite trivially at that.

But the problem is that checked exceptions create the same “what color is your function” problem for errors.

Re: Java 18 / JDK 18: General Availability

#50
post #20

Earlier quoted context omitted.

Oracle's builds of Java are open source as well. The OpenJDK codebase is shared across all of the vendors that provide builds.

Thanks! So why would I pick Oracle's implementation?

Ignorance of the Supreme Court decision that Java API copyrights are not enforceable.

https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....

Post reply on HN