Live data from Hacker News

Java 18 / JDK 18: General Availability

mail.openjdk.java.net

141–150 of 304 posts

Re: Java 18 / JDK 18: General Availability

#141

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.

First comer advantage. Initial Java was a robust, yet simple, sane build tools, relatively safe, typed language when most everything else was c or c++ and not as "safe" (modern c++ is actually very safe language if you stick to its guidelines however). Over time Java has become almost as complicated as Modern C++ but people picked it up over time mostly. It's still used because it's still a robust general purpose language, tons of libraries, huge corps don't like to rewrite things, and there are lots of Java programmers out there. Don't let the webstack blind you, there is a whole other world out there of backend, embedded, finance, and legacy stuff that hackernews audience is just a small part of.

Re: Java 18 / JDK 18: General Availability

#142
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.

Most of the cases where this breaks anything, are already broken, it's just not visible.

Re: Java 18 / JDK 18: General Availability

#143

It's legitimately fascinating to see the rise of pattern matching, to the point that even Java will have it [1]! Combined with lambdas, this is a different language than the Java 1.5 that I first learned. If you would have told me that this would be valid Java code: static void testStringOrNull(Object o) { switch (o) { case null, String s -> System.out.println("String: " + s); } } I would never have believed you. And…

[deleted]

Re: Java 18 / JDK 18: General Availability

#144

IntelliJ is yet to catchup it seems https://www.jetbrains.com/help/idea/supported-java-versions....

2022.1 is coming shortly. In any case, one can easily specify jdk18 as the platform to use for a project. The IDE might not recognize some syntax, but the code will compile and run just fine.

Re: Java 18 / JDK 18: General Availability

#145
post #6

Is there a reason to use Oracle's closed-source Java implementation instead of the opensource implementations? Asking as someone who's ignorant about Java. edit: per comments below, Oracle's Java is open-source too these days.

[deleted]

Re: Java 18 / JDK 18: General Availability

#146
post #143

It's legitimately fascinating to see the rise of pattern matching, to the point that even Java will have it [1]! Combined with lambdas, this is a different language than the Java 1.5 that I first learned. If you would have told me that this would be valid Java code: static void testStringOrNull(Object o) { switch (o) { case null, String s -> System.out.println("String: " + s); } } I would never have believed you. And…

[deleted]

[deleted]

Re: Java 18 / JDK 18: General Availability

#147

Earlier quoted context omitted.

> Java values backwards compatibility very highly, so if something runs today, it's likely to keep running without modification on future JVMs. Then why do I have to have multiple JVMs installed, which I need to go through via trial-and-error, if I'm given some random java application?

> Then why do I have to have multiple JVMs installed, which I need to go through via trial-and-error, if I'm given some random java application? You don't. Almost any Java program written ever will run on Java 18.

JavaFX isn't guaranteed to be in a JVM. You run into "deprecated" APIs that were removed. JVM options change, and that breaks how things are deployed. If the JVM were a stable target a site like http://whichjdk.com/ wouldn't be necessary.

This is just how things are. It's Java fanfiction to say this isn't the case, and necessitates having multiple JVMs installed.

Re: Java 18 / JDK 18: General Availability

#148
post #86

Earlier quoted context omitted.

Some people like support contracts. It gives you someone to blame when the auditors come knocking.

But does anyone like being involved with Oracle? There are other java vendors that offer support.

Probably not for the most of the tech companies nowadays, but there are still large companies who still uses Oracle products, so they might pay Oracle Java support as a package deal most likely.

I think it'll be very atypical for a companies who doesn't use any of the Oracle product to use proprietary Oracle Java and pay for the support

Re: Java 18 / JDK 18: General Availability

#149
post #87

Earlier quoted context omitted.

Just because something is a well known-flaw doesn't make it a glaring flaw. There's a reason newer JVM languages like Kotlin use == as an alias for equals instead of reference equality.

What if you are interested in reference equality?

In practice, how often are you interested in it? C# has `Object.referenceEquals()` because you _may_ want this sometimes. But to have reference equality be the default for something like `==` is a design flaw. Not one that can be fixed now, of course, but it will continue to cause bugs for years to come.

Sometimes, it happens in core Java libraries themselves: https://bugs.openjdk.java.net/browse/JDK-8274779

https://github.com/openjdk/jdk/blob/722d639fad2e4fc6eb2aabd4...

Re: Java 18 / JDK 18: General Availability

#150
post #105

>JEP400: UTF-8 by Default This changes the default charset of the Java APIs to UTF-8. I read that the Java 8's JVM's internal string representation is UTF-16 [0][1]. Is that still the case after JEP400? [0] https://docs.oracle.com/javase/8/docs/technotes/guides/intl/... [1] http://tutorials.jenkov.com/java/strings.html

Since Java 9/11 (9 is not a LTS), String internals was reworked to use either 8 bits or 16 bits per char. [1] [1] https://openjdk.java.net/jeps/254

BMP forever! The most disgusting thing I've read today.
Post reply on HN