191–200 of 356 posts
What are some good primers to understand the prominent new Java features? Not just in 20, but since, say, 8. Asking as someone who would like to be cursorily familiar with Java, but does not use it day to day. I'm very familiar with things like auto type inference, pattern matching, multi-line strings and structured concurrency from other languages, so I'm not looking for an introduction to Java. I'm looking for some…
Earlier quoted context omitted.
My codebase at work is written in Java 8, I honestly don't see what other benefits upgrading the language would bring. There's already so much business code written in the old Java 8 style (which works), don't go trying to change how the code is written now. To me Java 8 is simple and boring like Go, with some imperfections like the lack of a native map data type. I'd still upgrade for the new VM's better performance…
I unfortunately encounter this mindset so much in Java programmers, and the similar "we don't need no feature X" even if the feature has proven themselves for a long time in a large amount of languages. I'm hesitant to bring it up, but I see a lot of Blub Paradox [1] among Java programmers. Heck, a lot of places disallow `var`, while over here in Kotlin-Python-Rust-C#-Typescript-Go-etc-land that's been the default si…
Records are nearly useless to me. Immutability is great, but I need a way to derive new sets of information based upon an set of information. And the only way to do that is bug prone.
Text blocks are nice for writing SQL queries and other multi-line things. But I'm not sure how often I actually use it.
Switch expressions are nice because it gets me compile time checking for things I would previously use a runtime check for. Other than that, as they currently exist, they're meh.
Sealed classes are something I've not had a use for. Maybe libraries will eventually make good use of them.
So I would say there's some nice QOL things in here. But I think "incredibly useful" is overselling it.
The thing is, lots of these things are built to support a longer term roadmap towards better support for data oriented programming. I think that is a worthwhile goal to drive for - and the sum of the parts (many of which are still in preview) will be less than the whole together - but we don't have the whole, yet. That, to me, would pass the "incredibly useful" bar.
Earlier quoted context omitted.
Big reason is security patches. But if the services are running in a VPN and don’t interact with outside world, it’s fine
My understanding is that jdk8 has support from Oracle until 2030.
Earlier quoted context omitted.
Almost. The Java module system (introduced in Java 9 and enforced in Java 11) still plagues companies and/or slow-to-update libraries. Particularly companies that have written a lot of their own in-house libraries and such. Custom libraries have, unfortunately over the years, picked up the bad habits (by forking/following public libraries) relying on reflection and packages that shouldn't be directly used (sun.* pack…
In the latest LTS those all can still be enabled, so while it is a serious problem when they are finally removed, for now it's not really a good reason to block an upgrade.
But yes, maybe not a good reason to completely block an upgrade. It's just postponing the pain, though.
its amazing how much the world hasn’t been able to keep up with java. github PRs still have no syntax highlighting support for record and var
Admittedly I couldn't figure out exactly what repo is being used for Java's syntax highlighting since vendor/README.md says Java is using tree-sitter/tree-sitter-java and grammar.js in that repo appeears to already include references to record.
languages.yml [1] shows ace_mode java, and ace editor's java_highlight_rules.js doesn't mention record anywhere. I'm not clear if github is using ace editor or code mirror, since both are mentioned there.
Hopefully this helps get started on improving the poor syntax highlighting experience.
[0] https://github.com/github/linguist/blob/master/CONTRIBUTING....
[1] https://github.com/github/linguist/blob/c34f887f48d81e2ed42b...
[2] https://github.com/ajaxorg/ace/blob/a2e89b94b4dcdff28bf3c8f4...
Earlier quoted context omitted.
With all my love for .NET, why not continue Java with its new features when it fits to your developer base, existing products etc. Give it one or two more years and Java is where C# is ... also aesthetically. As did JavaScript.
The feature that everyone is excited above - switch statement with pattern matching - has been available in C# for 6 years now.
Earlier quoted context omitted.
I'm personally not so sure. We already had something like that before (M:N threads), and the world moved away from it, towards letting the kernel manage everything (1:1 threads). So I'd expect instead that operating system kernels gain whatever features are missing for scaling to a higher number of threads, and everything once again goes back to each programming language thread corresponding to one kernel thread.
M:N is not the interesting aspect of virtual threads at all, automagically turning blocking operations into non-blocking is - which has not really been tried before (with erlang and go being the first).
I think what you probably had in mind is that C libraries of the 90s that did M:N threading didn't turn blocking operations into non-blocking?
Using blocking operations to switch contexts is really nothing new. Heck, the cooperative multi-tasking systems of the 80s (Mac, Amiga) all essentially did that for processes (not threads), and so did Unix in the 70s.
Note all the new cool stuff is incubator and preview status and I'm a little worried that this will still be the case for the JDK 21 stable release.
I really hope to see the SIMD vector related improvements come through, I know there are some independent JDK code bases that have more evolved SIMD support, but for a lot of big data processing tools, switching away from jdk based languages appears to be the way SIMD related performance improvements have been realized because of this missing crucial feature set. JDK 11 was when this stuff was first in development, a…
And here I am still on Java 8 :/
My codebase at work is written in Java 8, I honestly don't see what other benefits upgrading the language would bring. There's already so much business code written in the old Java 8 style (which works), don't go trying to change how the code is written now. To me Java 8 is simple and boring like Go, with some imperfections like the lack of a native map data type. I'd still upgrade for the new VM's better performance…
New features done right improve simplicity by abstracting away complexity or need to reinvent the wheel. For example Go devs having wrote their own list .map() functions is absurd.
Earlier quoted context omitted.
I mean, that's OK though. Not sure why this is considered such a bad thing. You're missing out on some new language features, sure, but Java 8 is still reliable and rock solid. There's lots of companies that have hesitation or even inability to upgrade, hopefully there's at least some initiative and/or direction to do so. A company that is head-in-sand deliberately not upgrading from Java 8 is one thing. A company th…
There's very little reason not to upgrade from Java 8 at this point. Everything should be a drop-in replacement and there are significant performance benefits (garbage collection is leagues better) to doing so. The bigger problem is that a lot of places are stuck on Oracle JDK - 8u252 is the last free version so a lot of places just decided they'd never upgrade, nor do they want to look at whether Temurin or Coretto…