Java 21 will be released on September 19, 2023, supporting record patterns in switch blocks and expressions. Such syntax is monumental (At least, in Java land). It marks the point where Java could be considered to properly support functional programming patterns in ways similar to Kotlin, Rust, or C#. And it marks the first point where I can say, as a Kotlin developer, that I feel jealous.
I’ve got nothing to say about matters such as these, so I’ll just quietly back away and let you all handle it.
I actually used to care about java, especially good were the multiplatform aspects of it. But once oracle took over they broke literally every single java application I needed by forcing new security policies on them (IIRC it was around java 1.8).
I don’t actually mind new security defaults as long as the owner has the final say on when to use them, but when I’m literally forced to run old versions because oracle unilaterally pushed it’s own policies without owner permission, well that’s no longer a platform I find suitable for corporate work. And it wasn’t just me, some of the businesses I worked with also found that oracle broke old legacy proprietary java applications with no replacements available so they too were forced to freeze java upgrades to retain compatibility with business critical software.
Sun would not have been so reckless, but then what did they know: Sun is defunct and Oracle has replaced them 🙁
Regarding new java features, meh, oracle burnt that bridge for me and given the choice I don’t see myself going back again.
Java still has an amazing eco-system with lots of libraries and scales extremely well for corporate applications. We can run our Java Application on a 1 CPU/2GB system as well as on a 128 CPU/512GB server and it scales linearly until IO limits hit. Hard to beat in this area.
Where we have lost hard to R/Python is in the area of statistics and that’s a sad thing.
Anderas Reichel,
Arguably this usually has more to do with how the applications are written than the programming language used. It’s not really the language that effects scalability so much as how much code can run in parallel without synchronization/serialization bottlenecks. For example, you could say PHP application servers can scale from 1 CPU to 128 CPUs, and it’s true, they can…depending on what the code does.
I had a bad experience with a python project because it was mired by the transition from 2.x to 3.x where everything broke at an API level and we were hitting glitches around python’s new asynchronous model. The events just wouldn’t come through consistently and we were forced to deal with it using a watchdog to kill and restart the python process. I was also disappointed with the performance we were getting in python. As an experienced C programmer, I probably had unreasonable expectations for a scripting language, but even PHP has a code compiler with very respectable performance. The python code wasn’t that performance critical but it still had noticeable slow downs at the time.
I should cleanse my palette and try it again to see if things have gotten better. Though I probably would only use it as a glue language rather than something for writing software from the ground up.
> Arguably this usually has more to do with how the applications are written than the programming language used.
You are correct in theory and as you program does not do anything substantial.
But as soon as you program has many functions (as in mathematical calculations) with many long living objects the language matters a lot (or rather the capacity of the VM and the GC).
> I had a bad experience with a python project because it was mired by the transition from 2.x to 3.x where everything broke at an API level and we were hitting glitches around python’s new asynchronous model.
You are right again, Python is terrible especially for maintenance and corporate deployment. Using Python or R is our very last resort, but in finance maths there are just not good Java libraries for simple things like a distribution fitting. And it is a shame that Java lost its dominance in that area.
I’d still like to push back on this. Nearly any programming language should scale up to the natural limits of the OS/hardware as long as they don’t do anything that causes cpu cores to stall execution. Java or not, using shared resources, semaphores/mutex, accessing ram across NUMA nodes, etc will reduce scalability. Just as an extreme example, even a language as horrible as bash should nevertheless scale fairly well on a NUMA system as long as the CPU activity on one core doesn’t interfere with other cores. Mathematically intensive calculations in and of themselves don’t impede scalability.
Garbage collecting is certainly a facinating subject. Not only are there many GC implementations, but there are many programming methods to mitigate GC cycles and the performance characteristics naturally depends on application characteristics, object lifetimes, how many heap allocations are needed, the use of object pooling, etc. Sometimes GC applications are more efficient than unmanaged applications that alloc/free their own memory, but sometimes not.
I haven’t tested any of these recently, but it’s interesting to note the list of GC used by java.
https://developers.redhat.com/articles/2021/11/02/how-choose-best-java-garbage-collector
I’m actually curious how features like thread local storage play with java’s garbage collection.
https://dzone.com/articles/painless-introduction-javas-threadlocal-storage
In C we can implement local allocators in terms of thread local storage, which is extremely efficient as it allows us to allocate and free heap objects independently of other threads. However in java I’m not certain how thread local objects get garbage collected. The GC would have to guarantee that no other thread has a reference to the object. Do you know how this works?
Did they finally get around to implementing TCO?
More info available here: https://wiki.openjdk.org/display/mlvm/TailCalls
The JVM can’t be considered a serious runtime for functional languages until they get around to implementing such key features. The .NET runtime is still a better option if you would like use functional languages. They even have first class functional support through F#. The CLR has been built from the ground up for true multi-language support from the ground up.
The TCO has been a long awaited feature for Clojure and Scala. The JVM has always been a Java language only runtime. With Oracle just ignoring proposals to expand JVM capabilities for more languages, you’re better off using other options.