this post was submitted on 22 Nov 2023
39 points (86.8% liked)

Programming

17489 readers
58 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago
MODERATORS
snowe
Ategon
[email protected]
39
Is Java Still Keeping Up with Modern Programming Languages (digma.ai)
submitted 1 year ago by LadyLeeLoosh to c/programming
21 comments fedilink hide all child comments
 

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.

top 21 comments
sorted by: hot top controversial new old
[–] sizeoftheuniverse 30 points 1 year ago* (last edited 1 year ago) (3 children)

Yes it does, the only parts where Java doesn't shine are usually some advanced features that are nightmarish for people who are building tools and libraries:

  • The type system is so 90s and it's kept like that for backwards compatibility.

  • Generics having type erasure is again an improvisation for the sake of backwards compatibility. It makes writing generic code in conjunction with Reflection painful.

  • The lack of control for the memory layout. I mean in most cases you dont need full control, but there are use cases where it's literally impossible to do optimisations that are easy to do in C/C++. You must have faith in the JVM and JIT.

  • Integration with native code is cumbersome.

Other than that Java is fine for most backend work you need to do, except probably for Real Time Processing apps where every millisecond count, but even there there are ways.

You use Java not for the languages itself, but for the tooling and the ecosystem.

[–] [email protected] 6 points 1 year ago

You use Java not for the languages itself, but for the tooling and the ecosystem.

This is why I love Kotlin so much. You can use the Java ecosystem with a modern language.

[–] thtroyer 4 points 1 year ago

Project Panama is aimed at improving the integration with native code. Not sure when it will be "done", but changes are coming.

[–] [email protected] 3 points 1 year ago (1 children)

There is also a big enterprise group who write extra verbose legacy java, vs a more modern light way to write

[–] sizeoftheuniverse 5 points 1 year ago* (last edited 1 year ago)

Yes, i was part of the cult in my early days as programmer. I would endlessly create abstractions over abstractions. But the whole madness started for valid reasons.

Im the early days of Java on the web, you had servlets and JSP. Servlets were miserable to write, and JSPs were basically the java interpretation of having a PHP. Those were the days before JSON and yaml, when XML was king.

So people wanted to abstract their way out of JSP and XML, so they created layers to isolate the nasty parts and make it easier to write actual Java code. So a few ideas emerged/frameworks: ORMs, EJBs, Struts, JSF, template frameworks, and finally Spring which was the lightweight one, if you can believe it. A lot of those ideas coming from the Java world were exported into various other languages in a selective ways.

People experienced with various patterns and frameworks. Eventually Spring won, and then Spring started to use annotations, JSON became more popular, etc., the code became less and less verbose.

Some Java developers never made the mental jump and are still creating huge piles of abstractions because this is what they've learned from their seniors.

[–] [email protected] 22 points 1 year ago (3 children)

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.

[–] [email protected] 10 points 1 year ago (2 children)

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 5 points 1 year ago* (last edited 1 year ago) (1 children)

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 alternative suggestions that are nicer to use in Java?

[–] [email protected] 2 points 1 year 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 4 points 1 year ago (1 children)

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.

[–] [email protected] 5 points 1 year ago (1 children)

Corporate standards.

I'm pushing for no half measures: it's Kotlin or bust.

[–] BlueBockser 1 points 1 year ago (1 children)

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...

[–] [email protected] 1 points 1 year ago (1 children)

Sure but you can also just drop kotlin into any Java codebase. It's a single line maven import and the entire company already uses Intellij

[–] [email protected] 3 points 11 months ago (1 children)

Oh yeah - the seamless Java/kotlin interop is pretty slick, though there are some pitfalls - nullity is one of them. Kotlin treats it explicitly, but when it’s talking to Java, it’s forced to treat it ambiguously unless you wrap stuff in Optional. And then even if you do, some Java lib that you need to plug into your project might not do that, so you’ve got to be careful about managing the interactions between their interfaces in some situations. And then there’s the unfortunate divergence that’s started to occur as newer versions of Java have brought certain features that were first available in Kotlin into Java, but the patterns and interfaces often differ subtly, so you have to worry about that too, especially with less experienced engineers on the team.

Don’t get me wrong - it’s great, and I’ve enjoyed working with it, but if you’re doing an incremental migration, make sure you test the ever-loving shit out of it.

Source: I did an incremental Java -> Kotlin migration on a huge project a couple jobs ago

[–] [email protected] 1 points 11 months ago (1 children)

Yeah it can be slightly hairy because Java does a terrible job with nullability. I've also done an incremental migration of an android codebase to Kotlin.

Personally I think being forced to declare the nullability of a field is something backend developers should do more of. It helps eliminate some of the foot guns that otherwise get built into the code base.

I'm a bit of a kotlin fanboy though, I'll admit.

[–] [email protected] 1 points 11 months ago (1 children)

I 100% agree that explicit nullity is categorically better, and the vast majority of the entire software engineering field does too. The problem lies in the fact that explicit nullity was added in 2014 with Java 8, nearly two decades after Java 1 shipped in 1996. That’s a hell of a lot of technical inertia to overcome.

[–] [email protected] 1 points 11 months ago (1 children)

Yeah especially whether Java "runs on 1 billion devices" 😂

The question is why a new codebase in greenfield is still using basic Java 11 on a new 2023 project.

[–] [email protected] 2 points 11 months ago

lol do NOT get me started 😭

[–] [email protected] 3 points 1 year 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.

[–] tastysnacks 1 points 1 year ago (1 children)

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.

[–] [email protected] 4 points 1 year 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.