201–210 of 304 posts
Earlier quoted context omitted.
Since Java 9/11 (9 is not a LTS), String internals was reworked to use either 8 bits or 16 bits per char. [1] [1] https://openjdk.java.net/jeps/254
BMP forever! The most disgusting thing I've read today.
Earlier quoted context omitted.
Wow, that's a really well-established feature to remove. But reading "JEP 421: Deprecate Finalization for Removal" [1] did convince me it's a good idea to deprecate it. I'm suspicious they'll never ever actually be able to remove them, given the reality of maintaining backwards compatibility. [1]: https://openjdk.java.net/jeps/421
They removed much bigger things, and broke backwards compatibility in much bigger ways. Finalizers aren't really used much in Java except for safety checks ("you forgot to close this object"), which can go missing without breaking things.
Plus most code probably handles this poorly. I suspect it will often result in exceptions opening new files or connection which are just caught and retried forever, resulting in your server locking up after some period of time. If you are lucky it just crashes and restarts. (The ultimate garbage collection.)
Earlier quoted context omitted.
To echo others: relatively good performance, incredible tooling/deployment infra (really best-in-class), intercompatibility with tons of other languages built on top of the JVM such that it can be functional/do actors/whatever your other weird approach is, relatively high productivity due to a large library base (not just the standard library but also a huge amount of stuff written to support android apps), and ease…
> relatively good performance, That's kind of downplaying it right? Outside of "native" languages like C, C++, Rust, fortran, Java blows everything else out of the water.
But that is what I think OP means. It isn't top tier performance, but it is in the second tier which I wouldn't argue for qualifying for "relatively good".
FWIW I find that languages tend to fall into a couple rough performance groups:
- Native at about x1 performance: C, C++, Rust, Fortran
- Compiled GC at about 2x performance: Java, Go, Haskell, Lisp
- Dynamic at 20-50x native performance: Python, Ruby...
JS is a weird one that varies a lot depending on your workload and can sometimes look similar to compiled GC performance.
What's your favorite toolkit for desktop Java applications? I believe JetBrains use Swing and their stuff is pretty great.
Currently fully FRP UI is quite popular (Jetpack Compose, ReactJS etc) but frankly whenever I've read such codebases I've been somewhat unimpressed. You can make JavaFX work that way with a bit of extra utility code, and there are places where that approach makes sense, but fundamentally a well engineered OOP UI toolkit is in its element. The functional reactive approach seems to create quite a few problems. Whether it creates as many as it solves, I reserve judgement as I haven't had a chance to write a large GUI app since they came out. Still, I've written a lot of them in the past and would definitely be tempted to stick with JavaFX despite having worked through the Jetpack Compose tutorials.
Meanwhile, still using Java 8 at work
I see this everywhere. What's the excuse in your case?
If you want to write shared Java libs that work on both client/server, you need to stick to Java 8.
Earlier quoted context omitted.
This one looks interesting: "JEP 400: UTF-8 by Default": https://openjdk.java.net/jeps/400 It sounds like a good idea, but I can imagine lots of downstream breakage, some of it not immediately obvious, with apps that make bad assumptions. Edit: The risks section of the linked doc above does explain some of that, and there is some notable risk.
I wouldn't be surprised if defaulting to UTF-8 inadvertently fixes more problems than it causes.
Earlier quoted context omitted.
They removed much bigger things, and broke backwards compatibility in much bigger ways. Finalizers aren't really used much in Java except for safety checks ("you forgot to close this object"), which can go missing without breaking things.
If you are leaking file descriptors in a production service it will absolutely break things. Generally most servers that aren't pushing the FD limit can get away with delayed reclamation of FDs but if you never claim them you will run into problems. Plus most code probably handles this poorly. I suspect it will often result in exceptions opening new files or connection which are just caught and retried forever, resul…
The only really issue is that you effectively need to litter your code with queue checks, or dedicate a thread to watching them.
Earlier quoted context omitted.
Wow, that's a really well-established feature to remove. But reading "JEP 421: Deprecate Finalization for Removal" [1] did convince me it's a good idea to deprecate it. I'm suspicious they'll never ever actually be able to remove them, given the reality of maintaining backwards compatibility. [1]: https://openjdk.java.net/jeps/421
They removed much bigger things, and broke backwards compatibility in much bigger ways. Finalizers aren't really used much in Java except for safety checks ("you forgot to close this object"), which can go missing without breaking things.
Earlier quoted context omitted.
> It sounds like a good idea, but I can imagine lots of downstream breakage, some of it not immediately obvious, with apps that make bad assumptions. You're not wrong, which is probably why they did it in this release. JDK 17 was an LTS release, and 18 isn't. The next LTS will be JDK 21 in September 2023: * https://www.oracle.com/java/technologies/java-se-support-roa... This presumably gives folks times to adjust bef…
Worth noting that if you can , don’t stay on LTS. It adds cost which many modern teams can avoid[1]. It doesn’t mean enabling Java 18 on Production on day 1, but certainly it means adding a Java 18 compiler to your CI, running tests using Java 18, etc. [1] https://www.reddit.com/r/java/comments/o0m6g8/the_state_of_p...
Even if you don't use any of the new features, there may be deprecation warnings and such that one should be aware of sooner rather than later. Tweaking early to ensure compatibility with current-LTS and future-LTS versions is worth some cycles: if you don't, you'll pay for it eventually when old(er)-LTS is inevitably retired.