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.
Java 17 / JDK 17: General Availability
241–250 of 251 posts
Re: Java 17 / JDK 17: General Availability
#242Earlier 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?
Re: Java 17 / JDK 17: General Availability
#243Earlier 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?
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
#244Earlier 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.
Meaning .net has nowhere near the "write once, run anywhere" support Java has.
Re: Java 17 / JDK 17: General Availability
#245Earlier 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?
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
#246Oh man, I feel old.
Java 1.0 to 5 was 8 years
5 to 8 was 10 years
8 to 11 was 4 years
11 to 17 was 3 years
Re: Java 17 / JDK 17: General Availability
#247Earlier 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.
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...
Re: Java 17 / JDK 17: General Availability
#248Give me variable interpolation in strings and I'll be happy.
Re: Java 17 / JDK 17: General Availability
#249as 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
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
#250Earlier 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?