Java 17 / JDK 17: General Availability • Hacker News Board

Re: Java 17 / JDK 17: General Availability

#41

Post by shellac » Tue, Sep 14, 2021, 3:08 PM UTC

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…

> the important thing is that Java 17 is an LTS

That's not _strictly_ true.

Java 17 is a release of the reference implementation, but there are a number of distributions from a variety of vendors.

Oracle are going to provide long term support for their distribution, and it sounds like many will follow their lead. (If you are going to provide LTS it would be a little perverse to be out of sync with other providers of the same software)

So, for all practical purposes, it is an LTS. But check with your vendor.

Re: Java 17 / JDK 17: General Availability

#42

Post by stickfigure » Tue, Sep 14, 2021, 3:08 PM UTC

geophile wrote: post #18

vips7L wrote: post #12

Earlier quoted context omitted.

Primitive classes are being worked on in Project Valhalla.

I think this statement has been true since about 2014. Structs are nice, as they allow for control over locality, to a degree that is simply not possible in Java currently. But there is a second effect, which is possibly more important: If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to…

Alternatively: This is such a (potentially) big change, it's important to get right. I'd be disappointed if an inadequately-baked solution gets rushed in.

Another way of looking at it: This is fundamentally just a performance optimization. Java performance is already exceptional for most of Java's popular use cases (business processing). While valuable, I don't think this one feature is quite as important as you consider it.

Re: Java 17 / JDK 17: General Availability

#43

Post by vips7L » Tue, Sep 14, 2021, 3:14 PM UTC

kasperni wrote: post #39

Some other news in relation to the release: - (Proposal) Moving JDK LTS versions to a two year cadence [1]. Java 21 will be next LTS instead of Java 23. - Oracle JDK is now free for commercial and production use [2]. - A new Java developer site [3]. [1] https://mreinhold.org/blog/forward-even-faster [2] https://blogs.oracle.com/java/post/free-java-license [3] https://dev.java/

2 year LTS is exciting! Hopefully the other vendors follow suit.

Re: Java 17 / JDK 17: General Availability

#44

Post by vips7L » Tue, Sep 14, 2021, 3:15 PM UTC

hyperpape wrote: post #26

geophile wrote: post #18

Earlier quoted context omitted.

I think this statement has been true since about 2014. Structs are nice, as they allow for control over locality, to a degree that is simply not possible in Java currently. But there is a second effect, which is possibly more important: If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to…

I haven't been following it incredibly closely, but I have checked in from time to time. It's a hard problem, but there's a lot of real progress ( https://github.com/openjdk/valhalla-docs/blob/main/site/desi... ). I'd wager that it will ship by the next LTS, in 2024.

2023 (hopefully)! They're proposing moving LTS to 2 years instead of 3.

Re: Java 17 / JDK 17: General Availability

#45

Post by stevetodd » Tue, Sep 14, 2021, 3:16 PM UTC

Some highlights since the last LTS (JDK 11):

  Language Features
  394: Pattern Matching for instanceof
  395: Records
  306: Restore Always-Strict Floating-Point Semantics
  409: Sealed Classes
  361: Switch Expressions
  378: Text Blocks

  Language Features in Preview (behind a flag)
  406: Pattern Matching for switch
  412: Foreign Function & Memory API
  414: Vector API

  Tooling
  392: Packaging Tool (jpackage)

  JVM
  386: Alpine Linux Port
  391: macOS/AArch64 Port
  340: One AArch64 Port, Not Two
  388: Windows/AArch64 Port

(Source: https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11)

Re: Java 17 / JDK 17: General Availability

#46

Post by rnikander » Tue, Sep 14, 2021, 3:17 PM UTC

I'm guessing that Loom (lightweight threads) is not in this yet. It looked like a nicer way to handle "async" code, but I wonder about the implementation difficulty.

Re: Java 17 / JDK 17: General Availability

#47

Post by shawnz » Tue, Sep 14, 2021, 3:21 PM UTC

shadycuz wrote: post #24

jsiepkes wrote: post #8

Earlier quoted context omitted.

Starting from 1.6 they only showed the minor version number. So 1.6 = Java 6, 1.8 = Java 8, etc. I always assumed this was because .net (arguably it's main competitor) was churning fast through version numbers and they "wanted to keep up".

Ahh so 17, is 1.17? I swear I googled this like 2 months ago and the first 2 or 3 links weren't helpful so I gave up. Thanks!

Effectively yes, but the "1.x" format is deprecated since Java 9 and not used anymore, whereas versions 5 through 8 used both notations.

See https://openjdk.java.net/jeps/223#Dropping-the-initial-1-ele...

Re: Java 17 / JDK 17: General Availability

#48

Post by stingraycharles » Tue, Sep 14, 2021, 3:22 PM UTC

shellac wrote: post #41

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…

> the important thing is that Java 17 is an LTS That's not _strictly_ true. Java 17 is a release of the reference implementation, but there are a number of distributions from a variety of vendors. Oracle are going to provide long term support for their distribution, and it sounds like many will follow their lead. (If you are going to provide LTS it would be a little perverse to be out of sync with other providers of…

I just checked but Oracle, OpenJDK, Azul, and Amazon are all going to consider 17 an LTS. So it seems like a reasonable assumption.

Re: Java 17 / JDK 17: General Availability

#49

Post by avodonosov » Tue, Sep 14, 2021, 3:22 PM UTC

exabrial wrote: post #37

avodonosov wrote: post #23

I am skeptical about the "strong encapsulation" and in general, of all cases whey people tell me about something: "you don't need it, it's better for you to do it other way". Usually I know better what I need. There were cases when I needed to access the internals, e.g. fixing a prod issue. A quote from Thinking Forth comes to mind: > The newest traditional languages (such as Modula 2) bend over backwards to ensure t…

In that case, I think a Java Agent is better suited to your needs. We have one we wrote that will intercept a class load and hot-patches the byte code. This allows us to fix bugs in 3rd party software or the JDK itself until fixes can be released upstream and we don't wish to release an internal version of an artifact. Not something we use exclusively for obvious reasons, but it's a handy tool to have in the toolbox…

I multiple cases that I had Java Agent would not help.

Re: Java 17 / JDK 17: General Availability

#50

Post by avodonosov » Tue, Sep 14, 2021, 3:22 PM UTC

danogentili wrote: post #33

avodonosov wrote: post #23

I am skeptical about the "strong encapsulation" and in general, of all cases whey people tell me about something: "you don't need it, it's better for you to do it other way". Usually I know better what I need. There were cases when I needed to access the internals, e.g. fixing a prod issue. A quote from Thinking Forth comes to mind: > The newest traditional languages (such as Modula 2) bend over backwards to ensure t…

Fixing a prod issue by bypassing encapsulation and other programming practices sounds very much like accumulating technical debt. Encapsulation may be a lot more verbose, but it remains the best way to isolate software modules, to write better tests, and improve the overall reliability of software.

It was a one-time script, no debt.