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

Java 17 / JDK 17: General Availability

mail.openjdk.java.net

Post reply on HN
Print view View original

211–220 of 251 posts

Re: Java 17 / JDK 17: General Availability

#211

Post by slowmotiony »

kjeetgill wrote: post #109
azalemeth wrote: post #103

I would like to ask a question, in order to elicit the detailed and considerate comment that HN is known for. It's not intended to inflammatory in any way shape or form! I am not a Java developer. I am one of those users who has a bad memory of using Java desktop apps in ~2001 where they ate a ton of ram, seemed horrendously slow, and had example "Hello Worlds" that are reminiscent of Enterprise FizzBuzz [1]. At some…

For the most part, the various JDKs not really different. They're builds of the same OpenJDK repo. They occasionally have a few small changes, maybe with a few extra bugfixes new or a backported. The one small difference between compiling it yourself is that Oracle does control the TCK, a test suite for the binaries that Azul and others might use but not open to you.

I've got a task at work to install Oracle WebLogic and migrate a legacy app from an older OAS instance. The Weblogic installer didn't even run on OpenJDK, it specifically checked for it and crashed with a "OpenJDK builds are not supported" error. No idea why that is since I read everywhere that they're essentially the same thing.

Re: Java 17 / JDK 17: General Availability

#212

Post by stickfigure »

BoyRobot777 wrote: post #203
stickfigure wrote: post #191

Earlier quoted context omitted.

Still way too much typing compared to lombok's @Value @With.

This will be solved[1]: record Point(int x, int y) {} Point p = new Point(1, 2); Point pp = p with { x = 3; } [1] https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

Interesting. It's ok. It seems like they're adding this syntax just to avoid extra copies eg, `p with {x = 3, y = 4}` instead of `p.withX(3).withY(4)`. I really don't mind the later.

My gut feel is that records break encapsulation and will make refactoring slightly more difficult than the equivalent lombok value class. But if this gets more people making objects immutable, I'm all for it.

Re: Java 17 / JDK 17: General Availability

#213

Post by sverhagen »

titovodka wrote: post #125
stickfigure wrote: post #107

Earlier quoted context omitted.

Interesting but the "Isn't this just multiple return?" section seems to completely miss the point. I don't see any examples of what multiple-return would look like. And multiple-return is what I want. At first glance, it looks like this (sure, more powerful) pattern matching system is not going to satisfy my desire for a compact syntax that lets me do the equivalent of this typescript: const [foo, bar] = getMeTwoThin…

I might not be aware of best practices. What are the benefits of having a multiple return type function? I just assume that one can use an object if this is needed throughout the whole code.. Or maybe create an arraylist if possible and return that?

Using the object(/class) as you say is the probably "the Java way" to do this, given their historical "everything is an object" stance (which has been eroded a bit, though, with some of the functional support). But it sure is nice to do a multi-returns, here and there, without having to create another class. A class which required you to write boilerplate (getters/setters). Maybe records are some sort of compromise. Probably a non-compromise for people who like the multi-returns.

Re: Java 17 / JDK 17: General Availability

#215

Post by rowland66 »

slowmotiony wrote: post #211
kjeetgill wrote: post #109

Earlier quoted context omitted.

For the most part, the various JDKs not really different. They're builds of the same OpenJDK repo. They occasionally have a few small changes, maybe with a few extra bugfixes new or a backported. The one small difference between compiling it yourself is that Oracle does control the TCK, a test suite for the binaries that Azul and others might use but not open to you.

I've got a task at work to install Oracle WebLogic and migrate a legacy app from an older OAS instance. The Weblogic installer didn't even run on OpenJDK, it specifically checked for it and crashed with a "OpenJDK builds are not supported" error. No idea why that is since I read everywhere that they're essentially the same thing.

I believe that when you license Weblogic from Oracle, the Weblogic license includes a license for the Oracle JVM it runs on. So there is no reason to run Weblogic on another JDK/JVM. I assume that Oracle requires their JDK/JVM for Weblogic to keep support simpler.

Re: Java 17 / JDK 17: General Availability

#216

Post by ivan_gammel »

stickfigure wrote: post #209
ivan_gammel wrote: post #204

Earlier quoted context omitted.

TBH both approaches are just poor design of the object model. The one from my link is a clever but inefficient way to manipulate records (reflection), the one with Lombok is creating redundant interfaces without business meaning. A record with few business methods is lean enough and ensures that only valid transitions can happen.

Eh? This is pretty good: Colour changed = colour.withRed(5);

Every method of your API must serve some business purpose. "With" methods and setters generated or written "just in case" often do not have one or they are being used only in tests, which would be insufficient justification for having them. Does your code really need to change individual components of the color? If it is not a graphic editor, probably not and those methods will be redundant.

Re: Java 17 / JDK 17: General Availability

#217

Post by syncsynchalt »

filereaper wrote: post #102

I've been out of the loop with the Java ecosystem, but has the transition from Java 8 to 11 completed where most of folks here work? I was also curious about large ecosystems like Hadoop and their moves from 8 to 11.

Anecdote: We _just_ fixed our last JDK11 blocker here at $corp (the groovy 2.x runtime was holding us on JDK8). Our new quality gates are likely going to keep us closer to the latest and greatest, so I don't see a lot of problems with us jumping to JDK17 sooner than later.

Re: Java 17 / JDK 17: General Availability

#218

Post by syncsynchalt »

tathisit wrote: post #84
ianpurton wrote: post #53

I'm curious if it would be possible to remove null from Java. There's already support for Optional. I mean I guess a lot of code would stop compiling, or could it be deprecated somehow.

Kotlin does it, but it's next to useless because the ecosystem makes heavy use of null.

Kotlin is my suggestion too.

Kotlin (or any other JVM variant that does non-nullability in a seamless way) and coding guidelines should get you 90% of the way to a null-free world.

Re: Java 17 / JDK 17: General Availability

#219

Post by excerionsforte »

hyperpape wrote: post #20

On its own, the features specifically for Java 17 aren't obviously that compelling, but the important thing is that Java 17 is an LTS, the last one of which was Java 11, 3 years ago. Since many organizations, including mine, stick to LTS releases, that means a lot of developers will get a big change in what they can do sometime in the next few months as they upgrade to the LTS. Among other things, this means that we…

You also get better NullPointerException messages, which to me have been super helpful during development. https://openjdk.java.net/jeps/358

Re: Java 17 / JDK 17: General Availability

#220

Post by syncsynchalt »

grishka wrote: post #58
ianpurton wrote: post #53

I'm curious if it would be possible to remove null from Java. There's already support for Optional. I mean I guess a lot of code would stop compiling, or could it be deprecated somehow.

Not without changing everything in significant ways. There are two distinct kinds of types in Java: objects, including arrays, and primitives. Objects are represented as pointers, and those can be null — that's their default value. And multiple pointers can point to the same object. Primitives (int, long, boolean, char, byte, short, float, double) are "value types", they can't be null, are copied on assignment, and h…

Java could adopt swift-like `Object!` typing for non-nullable variables and spread that guarantee through the compiler and JVM runtime.

I don't think it's a technical impossibility, but it's more likely to be solved by a JVM-based language like Kotlin than it is to get it adopted into the Java mothership.

Post reply on HN