In this article, we’ll debunk the notion that Java is a relic of the past and showcase the language’s modern features, thriving ecosystem, and unwavering presence in enterprise and open-source communities.
In this article, we’ll debunk the notion that Java is a relic of the past and showcase the language’s modern features, thriving ecosystem, and unwavering presence in enterprise and open-source communities.
As a software engineer, from experience: yes and no.
The language itself is getting a lot of cool, new, modern features. However, I’ve never had a job where we were using the latest Java version. The most up-to-date JDK I’ve used in work was two major releases back, and most of the time it’s older than that.
I’m curious to hear about yours and others’ experiences with containerizing Java applications in such environments. I used to work in a place that traditionally had such restrictions on JDK versions, but after the internal IT environment moved towards running applications within containers, either on Kubernetes or on public cloud platforms’ container runtimes, that restriction became unnecessary since the application would be shipped to production alongside its compatible JDK.
While there were still restrictions on exactly what JDK you could run for other reasons, such as security/stability, common developer experience, etc, it at least allowed teams to immediately adopt the newest LTS release (17 at the time I left) with little restriction.
These types of threads always has developers stuck with old versions of the jdk. Its amazing to me that many IT departments allow unsupported software on their network.
Allow is a strong word. For many companies, development represents dollars. IT and Security are important, but in these companies if the development group wants old tech they get old tech.