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.
Comment on Is Java Still Keeping Up with Modern Programming Languages
gravitas_deficiency@sh.itjust.works 11 months ago
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.
tastysnacks@programming.dev 11 months ago
Kata1yst@kbin.social 11 months ago
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.
sudotstar@kbin.social 11 months ago
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.
huginn@feddit.it 11 months ago
I’m normally working in Kotlin when coding because I do Android development. I’ve had the misfortune of taking up some slack in a greenfield backend project and holy God is it miserable.
Everything is harder to read, every basic data model is 200 lines of getters and setters, multithreading is painful, basic transformers require separate class declarations. And that doesn’t even touch on the horrific experience of using Jackson to handle json serialization.
pprkut@programming.dev 11 months ago
I felt the same way coming back to Java from Kotlin. The more streamlined syntax of Kotlin is so much more comfortable to read and write. That being said, I never had an issue with using Jackson for JSON serialization in Java. I’m curious what issues you have encountered and if you have any suggestions that are nicer to use in Java?
huginn@feddit.it 11 months ago
I’m not sure there’s much that is better or worse than Jackson. When I worked exclusively in Java I was always using GSON and did not remember having so many hoops to jump through. Could just be my bad memory though.
I just feel like when I’m doing Java work I spend 90% of my time on useless boilerplate.
BlueBockser@programming.dev 11 months ago
Lombok will shrink the 200 lines of getters and setters to one or two. It has its own pitfalls of course, but IMO it’s definitely worth it.
huginn@feddit.it 11 months ago
Corporate standards.
I’m pushing for no half measures: it’s Kotlin or bust.
BlueBockser@programming.dev 11 months ago
Definitely agree that Kotlin is so much better than Java + Lombok, but it’ll take a lot of time for all the existing Java projects or migrate to Kotlin or reach EOL. In the meantime, it’s hard to avoid the occasional Java project…