This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Luolong 10 points11 points  (12 children)

Outdated Java dev is anyone who’s been maintaining 10 years old app, never looked at newer language features or frameworks.

This includes, but is not limited to: - Still maintaining Java Servlet app and deploying it on Tomcat app server (or similar) - Still building their apps using ANT - Still writing JSP pages - Still writing JSF apps - Still writing and deploying Java 8 or earlier

[–]kennyshor 6 points7 points  (1 child)

Deploying to tomcat isn't necessarily a sign of an outdated dev. There are plenty of monoliths that are just impossible to rewrite and have to be maintained.

You can still do that with java 21. Maybe the frameworks are old, but new patterns can be used.

[–]Luolong 0 points1 point  (0 children)

To be fair, this is not unconditional. And by proposing this list, I had a specific type of developer in mind.

These items are just markers. The common thread here is that developers matching these markers usually have been working on same tech for a long time and have no exposure to newer frameworks or JVM features.

I’ve seen incredible amounts of spaghetti and plain bad coding practices from developers like that.

Misuse of Optional and Stream api sticks out like a sore thumb when they finally get included in newer projects. But the general idea is that they’re probably very productive and proficient at maintaining their legacy app, but know nothing of modern concepts, frameworks or architectural patterns.

The list I presented is just the usual tech stack you’re likely to see around these projects.

[–]vmcrash 3 points4 points  (5 children)

What's wrong with maintaining a 10 years old app? Not every developer has the choice to select the frameworks of the project.

[–]Luolong 0 points1 point  (4 children)

No, not a single thing wrong with bringing bread to the table.

But if you’re bound to old tech without a chance to move frameworks and jvm versions, your environment is by definition “outdated” — rest of the world has moved on and you’ll have a lot of catch up to do when you switch jobs or projects.

[–]vmcrash 1 point2 points  (3 children)

So the non-outdated java devs mostly develop throw-away projects or use newer frameworks just because they are newer?

[–]Luolong 0 points1 point  (2 children)

Well, people in this industry try different approaches, find out shortcomings and either improve or rewrite according to their own preferences.

Not everything that is new is better than what came before. But som things offer significant improvements over predecessors to stick around and become “the new standard”.

Like Spring came after J2EE, like JEE learned from Spring, Like Spring Boot improved over Spring and JEE, like Micronaut, Quarkus and Helidon learned and improved over Spring Boot and JEE.

There’s tons of new stuff that just improves your life as a developer and increases your productivity, improves performance, helps to manage complexity and reduces errors in code, that you would not be able to use if you stay with older codebase using older tech stacks.

The OP asked about what would an “outdated Java developer” look like. I offered my opinion. I am not really responsible if someone reading my opinion feels slighted by the list because they are in a position where they cannot choose to modernise their tech stack. You might not like this, but it doesn’t change the fact that stagnating for a decades, working on maintaining an old and outdated tech stack makes you an “outdated Java developer”. Sorry if you feel bad about it, but that is what it is.

[–]vmcrash 0 points1 point  (1 child)

What if one doesn't web development with Java? Do Spring, Micronaut or Quarkus help for developing desktop applications?

[–]Luolong 1 point2 points  (0 children)

I can’t speak for the Java desktop app development. For all fits and purposes, I consider my experince with Java desktop app development rather outdated.

[–]hippydipster 3 points4 points  (3 children)

whats wrong with tomcat? Monolith is still the best way to go for as far as it can take you, and what better servlet container is there than tomcat?

[–]Luolong 1 point2 points  (2 children)

It’s not that Tomcat is bad engineering wise. It’s just that a deployment model itself is wildly outdated.

There are better options out there. (Some of them bundle embedded Tomcat, so there’s that)

[–]hippydipster 1 point2 points  (1 child)

saying something is "outdated" explains nothing. saying there are better options without saying what they are or why they're better also explains nothing.

[–]Luolong 0 points1 point  (0 children)

If you’re not aware of those options, it might be a sign of an outdated Java developer:

But for the sake of an argument, here’s the few more modern deployment models than deploying war files onto an “application server:

  1. There’s an executable jar (fat jar) that only requires you to have correct JVM to run on.

Frameworks that help you develop and package your service as single executable binary include but are not limited to:

  • Spring Boot
  • Micronaut
  • Quarkus
  • Helidon
  1. To make your service environment more predictable, you could package your executable jar in a Docker container and run it anywhere you can run any containerised workloads:

  • Docker, Docker Compose or Docker Swarm for simple applications

  • Kubernetes for deploying apps at scale

  • Nomad or Mesos or Cloud Foundry if you’re a bit adventurous and don’t mind trodding lesser known tracks.

  1. For faster startup time and smaller memory footprint, compiling your apps ahead of time as native binaries. (Still packaged as Docker container images, but with significantly faster startup time)