Live data from Hacker News

Java 17 / JDK 17: General Availability

mail.openjdk.java.net

241–250 of 251 posts

Re: Java 17 / JDK 17: General Availability

#241
post #124

Any news on JavaFX? I know it's developed independently but is it an even option beside Qt, Electron, etc..?

Would be nice if Oracle folded it into JDK again so it will get more love from developers.

If it functioned on mobile+desktop from day one, it could have been the most popular UI framework.

Re: Java 17 / JDK 17: General Availability

#242

Earlier quoted context omitted.

JRE stopped existing in Java 8. The idea now is you "link" a JVM for your app, which customizes and optimizes it. Then you ship both together. It's the fully supported way and has no license implications. Seems like the new Oracle JDK license is a lot more flexible than before. In reality it's kind of cosmetic because lots of people were using the (100% compatible) Amazon or Azul spins, or just regular OpenJDKs.

So the comments above seem to indicate that bundling 'JRE' with an app requires a license. Are you indicating that post-java8 model which builds a 'Custom JRE', and distributing that with your app does not require a license?

Correct. It doesn't count as either a JDK or JRE once linked.

Re: Java 17 / JDK 17: General Availability

#243
post #121
post #62

Earlier quoted context omitted.

I really like the Kotlin approach, where they just embraced null being a fact of life on the JVM/JS and instead integrated nullability into the type-system [1]. C# and Typescript do something similar. So then you get the best of both world, the safety of Optional without the boxing overhead. [1] https://kotlinlang.org/docs/null-safety.html

This really sounds like the way to go, although of course it is too late for Java. Optional feels awkward, and there's no more safety than we already have since the JVM null-checks anyway. if( arg.isPresent() ) ... vs if( arg != null ) ... How is this better?

Luckily it's not too late. A C#/Kotlin approach could be introduced and would not interfere with existing Optional.

The type system would need to be extended with a T? (nullable), T! (non-nullable), smart-casting on null-checks, and with some annotations or a flag to determine if T should be treated as T? or T! and whether you can call methods on it.

> How is this better?

It's not if you use Optional.get, but if you use .map, .orElse and the like the compiler can prevent you from getting NPEs instead of them being runtime.

Re: Java 17 / JDK 17: General Availability

#244

Earlier quoted context omitted.

Thats kind of a hyperbole. .net didn't add support for macOS on ARM64 years ago. .net also didn't implement 2D rendering on macOS via Metal. etc. As a matter of fact .net didn't even support any other platform then Windows until recently.

Also hyperbole, dotnet supported other platforms years ago via mono.

I think I would be generous if I stated 10% of the .net applications ran on Mono instead of MS CLR without source modifications. I even doubt more then 60% of the .net applications ran on .net Core (needed for other platforms then Windows) without modifications.

Meaning .net has nowhere near the "write once, run anywhere" support Java has.

Re: Java 17 / JDK 17: General Availability

#245
post #195

Earlier quoted context omitted.

Don't new programs have to be written to use the new features? elapsed secs binarytrees,java16,7 2.478 binarytrees,java17,7 2.475 binarytrees,java16,3 4.644 binarytrees,java17,3 4.574 binarytrees,java16,2 4.765 binarytrees,java17,2 4.772 binarytrees,java16,6 4.608 binarytrees,java17,6 4.594 binarytrees,java16,4 4.733 binarytrees,java17,4 4.808 fannkuchredux,java16,2 45.438 fannkuchredux,java17,2 43.921 fannkuchredux,…

Can you please compare to 11 or even 8?

Different test hardware as-of July 2020.

Both sets of times could be normalized to the C program times and then compared —

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

— by someone who was interested in that comparison.

Re: Java 17 / JDK 17: General Availability

#247

Earlier quoted context omitted.

Ubuntu's, Alpine's, Debian's, and any Linux distribution that builds and ships OpenJDK from the source (except Red Hat's, of course). Yes, these are "distributions" (binaries) of OpenJDK that do not provide any sort of support, and clearly no LTS flag to them.

Yes and no. Debian's repos provide binaries for multiple version though. Since 11 has been about, Debian testing has always had OpenJDK11 and then of course binaries for newer versions. So they do ship the LTS, you just need to specify the version number, openjdk-11-jdk. They don't tag it as LTS in the package name, but someone who is using java professionally probably knows openjdk-11 is the LTS implementation.

As far as I know, Debian does not have any strict policy or dates for when they will stop building and publishing OpenJDK 11 binaries out of the jdk11u branch in the OpenJDK project.

The jdk11u branch [1] (the source code) is currently steward by Red Hat, SAP employees and other contributors, and both Red Hat and SAP have a support roadmap, which currently goes until at least 2023 (SAP) [1] and 2024 (Red Hat) [2].

So, Debian is not providing an LTS binary. Debian is producing binaries out of the source code maintained by others. Once jdk11u stops receiving updates, Debian also stops shipping updates, because Debian has no LTS commitment.

[1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u

[2] https://blogs.sap.com/2021/07/21/support-extension-of-sapmac...

[3] https://access.redhat.com/articles/1299013

Re: Java 17 / JDK 17: General Availability

#248
post #181

Give me variable interpolation in strings and I'll be happy.

Not a java dev, but i did code in java here and there. What is super odd to me: 1. Java devs are always begging for some silly feature that almost every other pl has. 2. Why not write your own? There is a culture of sorry to use your words: "give me". Programming in java observed by me in the wild is typically assembling huge blocks of framework&libraries&configuration.

Re: Java 17 / JDK 17: General Availability

#249
post #140

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

Define pollute? Provide you with free type hints for your linter/autocomplete while at the same time not taking anything away from your experience? This type of pollute?

Pardon sarcastic tone, but why would typescript be considered a pollutant. I sometimes develop in javasript and enjoy the hints I get now much more.

Re: Java 17 / JDK 17: General Availability

#250
post #65

Earlier quoted context omitted.

This also brings some big gotchas, such as the closing of encapsulation loopholes. Unsafe code and various hacks calling into the JDK will break a lot of programs; so you might be stuck on 11 if you use HBase, Spark, etc.

I must have missed this topic. What are these encapsulation loopholes that are being closed?

The --illegal-access argument is removed, see JEP 403: https://openjdk.java.net/jeps/403
Post reply on HN