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.<p>Among other things, this means that we can begin to use records, pattern matching for instanceof, the shenendoah GC, and more.<p>Links to JEPs for the other releases.<p><a href="http://openjdk.java.net/projects/jdk/16/" rel="nofollow">http://openjdk.java.net/projects/jdk/16/</a>
<a href="http://openjdk.java.net/projects/jdk/15/" rel="nofollow">http://openjdk.java.net/projects/jdk/15/</a>
<a href="http://openjdk.java.net/projects/jdk/14/" rel="nofollow">http://openjdk.java.net/projects/jdk/14/</a>
<a href="http://openjdk.java.net/projects/jdk/13/" rel="nofollow">http://openjdk.java.net/projects/jdk/13/</a>
<a href="http://openjdk.java.net/projects/jdk/12/" rel="nofollow">http://openjdk.java.net/projects/jdk/12/</a>
Some other news in relation to the release:<p>- (Proposal) Moving JDK LTS versions to a two year cadence [1]. Java 21 will be next LTS instead of Java 23.<p>- Oracle JDK is now free for commercial and production use [2].<p>- A new Java developer site [3].<p>[1] <a href="https://mreinhold.org/blog/forward-even-faster" rel="nofollow">https://mreinhold.org/blog/forward-even-faster</a><p>[2] <a href="https://blogs.oracle.com/java/post/free-java-license" rel="nofollow">https://blogs.oracle.com/java/post/free-java-license</a><p>[3] <a href="https://dev.java/" rel="nofollow">https://dev.java/</a>
Some highlights since the last LTS (JDK 11):<p><pre><code> 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
</code></pre>
(Source: <a href="https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11" rel="nofollow">https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11</a>)
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.
Seems that 17 is an LTS release:<p>* <a href="https://www.oracle.com/java/technologies/java-se-support-roadmap.html" rel="nofollow">https://www.oracle.com/java/technologies/java-se-support-roa...</a>
No releases for 17 yet, but checking the site, I discovered that AdoptOpenJDK was moved to the Eclipse Foundation and renamed to Adoptium: <a href="https://adoptium.net/" rel="nofollow">https://adoptium.net/</a>
Great to see there is support for M1: <a href="https://openjdk.java.net/jeps/391" rel="nofollow">https://openjdk.java.net/jeps/391</a>
Reportedly, not much "big new stuff" got into this release (maybe next time), but it's an LTS so it's not the best time for that anyway.
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!<p>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 point in the last 20 years, Java has gone the other way -- it has a reputation (I think) of being "boring", "performant" and used by businesses for doing server-side logic. Still, the only way I interact with it is with the occasional dependency install.<p>I've noticed:<p>-- There are a bunch of different JREs/JDKs, most famously Sun's/Oracle's own Java, OpenJDK, OpenJDK built by Other People™, and Random Other JDKs (Azul; Amazon Corretto).<p>-- People rail against Sun/Oracle and what happened to Java.<p>-- For a bloody long time I had to download the JDK separately and/or type in "agree" into a very un-friendly sounding license at the command line.<p>Can I therefore ask the HN meta-brain to either explain, or point me to a reference that explains:<p>-- What the ideological and <i>practical</i> differences are between the JDKs<p>-- <i>Why</i> there are different JDKs -- I get that that it's good to have different language implementations, but there are really quite a lot!<p>-- <i>What Oracle did</i><p>-- And what was the beef with the whole open-source license was. Isn't opener-better?<p>Thank you!<p>[1] <a href="https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition" rel="nofollow">https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...</a>
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?<p>I was also curious about large ecosystems like Hadoop and their moves from 8 to 11.
Java5 and Java8 were monumental changes to the language… this update probably will have the same legacy. Can’t wait to see the benchmarks out of this bad boy once they get the compilers tuned in.
I understand wanting to remove the overcomplicated Security Manager, but we have one use case which, as far as I can see, has not been mentioned at <a href="https://openjdk.java.net/jeps/411" rel="nofollow">https://openjdk.java.net/jeps/411</a> : we install a custom security manager to prevent the software, when run on a developer machine, from accidentally connecting to non-localhost network addresses (we actually use a whitelist). I wonder how we'll do that after Java 17.
Is there a way to see top new Java features since version X? For example my company is stuck at version 9 I believe, and I’d like to see what I’m missing out of at a glance
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".<p>Usually I know better what I need. There were cases when I needed to access the internals, e.g. fixing a prod issue.<p>A quote from Thinking Forth comes to mind:<p>> The newest traditional languages (such as Modula 2) bend over backwards to ensure that modules hide internal routines and data structures from other modules. The goal is to achieve module independence (a minimum coupling). The fear seems to be that modules strive to attack each other like alien antibodies. Or else, that evil bands of marauding modules are out to clobber the precious family data structures.<p>> This is not what we’re concerned about. The purpose of hiding information, as we mean it, is simply to minimize the effects of a possible design-change by localizing things that might change within each component.
The biggest hinderance to me adopting Java for anything meaningful was the build system. Too much XML and complexity. Maven for packages, ugh. Just give me a modern package manager. Does such a thing exist that is idiot proof?
as a node dev, I see people using typescript with node. I wonder why don't those people just use java ? and let us clay potters shape plain js to our will. rather than pollute the node ecosystem with typescript
Link with respectives JEP [0]<p>[0] <a href="https://openjdk.java.net/projects/jdk/17/" rel="nofollow">https://openjdk.java.net/projects/jdk/17/</a>
Lately I have insight similar to 'what hardware improvements give, software bloat take it away', 'what JDK platforms give third party Java frameworks take it away.<p>I have this misfortune of dealing daily with a nasty Java framework which converts compile time errors into runtime errors, single error trace with multiple stack traces , most of them being from framework itself.<p>One thing that might improve situation is server side libraries instead of framework. However AFAIK there is nothing like that in Java world. Everything is bound to Servlet API at lowest level and app server/frameworks on top of it.
I'm curious if it would be possible to remove null from Java.<p>There's already support for Optional.<p>I mean I guess a lot of code would stop compiling, or could it be deprecated somehow.