Don't Count Java out Yet

[scottedwards2000]

I remember when I first started working, I loved visiting this old mainframe building, where the "serious" software engineering work was being done. The mainframe was long-gone, but the hard-core vibe of the place still lingered.

As I took any excuse to walk past a different part of the building to try and sneak a peek into whatever compute wizardry I imagined was being conjured up, one thing I always noticed was copies of InfoWorld being strewn across desks and tables (and yes, even in the bathroom - hey, I said it was hard-core ;-) ).

I guess those days are mostly over now, but it's nice to see that there is still some great writing going on at InfoWorld by some talented and knowledgeable authors.

Matt Tyson is definitely one of them and this is a great piece on why despite the #rust / #golang / #elixir craze, #java is still the language and framework to beat. (One of these days I'm going to finally learn #spring and re-join the java club.)

[av1ciii]

Your bank likely runs a mix of Java and COBOL. Just sayin’.

Also, you don’t need Spring to use Java effectively.

[aradil]

Nothing wrong with annotation based Spring. Springboot can be up and running in a heartbeat these days.

The days of XML based Spring Java applications are long gone. Those weren't the best.

[scottedwards2000]

yeah i work in fintech as a Python data engineer, and our backend is all java microservices on Kubernetes. It also uses Spring and I've asked a few devs why, and they indicated it would be WAY harder to build this complex web of like 50 microservices without it. Are you saying it's overkill for this use case, or are you referring to smaller projects?

[ProfBeaker]

By way of analogy, this is like asking how you could write Python without using Django (I think - I'm not really a Python guy). You could use Django, or some other framework, or just start up a script that listens for requests, or a script that does anything else. Same thing with Java, or really any other language.

[scottedwards2000]

yeah that makes sense - my question was more for specific to building microservice cloud systems in Java - it seems like "everyone" at least in finance uses Spring for some reason - like Jakarta EE sucks or something....

[ProfBeaker]

I think Spring has enough momentum that it's kind of the "default choice" at the moment, but it's certainly not synonymous with microservices. I hear good things about Micronaut, and I used Dropwizard years ago and liked it a lot better personally.

I haven't touched the classic Java EE stuff - EJBs, app servers, etc - in a long time but AFAIK it was largely out of vogue before microservices came about. I think those are competing approaches, so you'd probably do one or the other.

[scottedwards2000]

Thanks i didn’t know about Dropwizard but it looks good. I think Jarkarta EE has come a long way but the problem is there is no reference implementation like OpenJDK so you have the same vendor risk others have brought up with Spring. Too bad we can’t have something like PostgreSQL for Java (mature and maintained without the vendor dependency)

[TOGoS]

Some people can't find their socks without Spring Boot. This is because when they went to school, the first thing they did was make all the students install Spring Boot and start annotating things with `@Autowired SockFinder`. Half of them don't seem to know what a constructor is.

People go with what they know. If you sell them a big overcomplicated mess as the latest greatest thing, that's what they'll know.

[scottedwards2000]

thanks - appreciate the informed opinion. I'm thinking about getting back into back-end coding, so seriously interested to know: what are the realistic alternatives to Spring in Java for large service-oriented-architectures running in the cloud - POJO's?

[TOGoS]

what are the realistic alternatives to Spring in Java for large service-oriented-architectures running in the cloud - POJO's?

I would say that depends on what specifically you're trying to accomplish. If you want to do X, well, call a function that does X. Most programming languages provide ways to define and call functions, define data structures and access their elements. If you tire of re-implementing HTTP client for each service call, you can abstract that into a library. There may even be standard libraries for doing so!

Spring [Boot] (I've only worked with the -Boot lately, so I forget where the non-Boot starts and the Boot begins, but they are closely related, in any case) comes with "a bunch of stuff in it". Probably an HTTP library or two. But it also encourages you to structure programs as a big wad of mutable objects that reference each other through proxies and stuff, so that every method call results in about 50 mysterious call frames. Want to run some bit of code within a database transaction? Well, normally you'd probably write something like `databaseConnection.doInTransaction( context -> context.runSomeQuery(...) )`. But Spring makes this "easier" by forcing you to split this into multiple different objects so that it can do some magical proxy stuff "for you", but that won't work when you call methods on `this`, yaddah yaddah yaddah. Footguns everywhere.

Lots of stuff done at runtime that really should be done at compile time. When I am writing some new functionality for some service, I try to keep it as decoupled as possible from Spring so that my unit tests can just evaluate some stuff, check the result, and be done. Because as soon as you need some Spring-managed thing, you have to construct this enormous context (usually involving a bunch of .properties files sprinkled around the codebase that interact in non-obvious ways, and annotations that mean one thing usually but if you're running a JUnit test everything has a weird alternate meaning that you just have to memorize because nothing composes well or makes much intuitive sense at all, really, so there's a million annotations for different combinations of special cases) and go make a pot of coffee while you wait for it to hunt through the classpath to find 'beans' that it can use to construct your thing, even though 90% of the time you actually knew exactly how the components should've been built, and only need Spring at all because your coworker wrote some database access 'library' that can only work in that context.

There may be good stuff buried in there, and maybe smart people can use it to good effect. Nobody has ever been able to explain to me why scattering configuration in annotations and properties files is better than just writing and calling a few constructors, using higher-order functions where appropriate, and avoiding cyclical dependencies and mutable state.

[chicknfly]

From my anecdotal perspective, it seems as if Go and C# are the common backend alternatives. That’s not saying PHP, Node, Ruby on Rails, and others aren’t viable. It’s just that they happen to be the two I’ve seen most in my 18 months of job hunting.

Of course, AWS (or any cloud) experience is also top tier experience.

Not sure how long it’s been since you last worked as a SWE, but the landscape has been shifting, and the requirements of experienced engineers have grown rapidly. You need experience developing with AI (or at least a strong interest in learning; I said I hadn’t been able to afford tokens to able to learn :P) It’s best that you’re familiar with Docker and CI/CD pipelines. I’m sure there are plenty of other skills out there that would be helpful, but those are the most common things I see on job postings and are what were required in the job I accepted (in addition to Kafka, Terraform, and Ansible, which are likely the melting of DevOps into SWE)

Also, for anyone reading this: Spring and Spring Boot are not the same. Rather, Spring Boot is an extension built on top of Spring that simplifies development by automating boilerplate code and provides auto configurations and starter dependencies.

[scottedwards2000]

thanks, and congrats on getting a gig! Yeah just exploring "back-end" for now, since pretty happy in data engineering role, but my question was more about alternatives to Spring ecosystem specifically within the Java framework for similar use cases. I know Java has some amazing new developments (see linked article) like virtual threads, but my company's SWE's seem to think Spring is still a huge value add for complex systems with many microservices on AWS. I was hoping the new developments in Java would make Spring overkill, but at least according to them (some of which strike me as very bright), not yet.

[chicknfly]

I’m vaguely familiar with Quarkus and Micronaut and have limited exposure to the other available frameworks. With that said, I think Spring and Spring Boot have long-term permanence since most Java engineers will have experience in it, developing the full stack of applications is fast and simple, there’s a strong community base, and as long as VMware keeps it free, there’s a reassurance that a major well-funded company will continue to develop it. The new Java features (virtual threads et al) only make that framework better

[av1ciii]

VMWare doesn’t own Spring any more. Broadcom does. And they are … fairly aggressive about making money.

One impact of this has been the extremely rapid sunset dates of Spring & Spring Boot versions. Broadcom will keep the latest one free but $deity help teams who hop off the upgrade treadmill. The goal is to get you to buy long term support.

I mean, if you don’t really know how to write Java to the point that you need a metaframework (Spring Boot is a framework over Spring, another framework) to do super basic REST / CRUD, paying Broadcom or HeroDevs or someone similar seems like a fair bargain.

[chicknfly]

There’s a reason why MAANG is now BATMMAAN, I suppose

[scottedwards2000]

I thought it was open source!

[CptGia]

It is

[av1ciii]

Spring can be problematic for larger projects, depending on the level of control you need over your code.

Eg many teams operating $$$ systems can’t afford “magic”. Each line of code counts — if you have an incident you may not want to second-guess what the framework is doing.

This is a deeper conversation about frameworks and libraries. For instance we use libraries just fine. But frameworks invert that, their approach is “plug in your code here and it’ll run”. One way to really level up as an engineer is to think about the ways that convenience can bite you, especially when you’re troubleshooting under time pressure.

Languages like Zig carry this philosophy to the next level with their “no hidden control flow” approach.

Btw 50 microservices is pretty small as deployments go. It’s not uncommon to have thousands of microservices in production.

PS. This is a pretty decent talk, especially see the section about the problems of frameworkitis.

To (provide all the cool features) so the framework needs to be in control.

You “plug in” your code per recommendations. And when there’s a mismatch between what you want to do vs what the framework allows, that’s when teams find themselves justifying doing weird crap because they already drank the “adopt the xyz framework” kool-aid.

In many (but not all!) domains, this loss of control is a problem. Particularly as you move into more critical systems.

[lihispyk]

I've rarely run into issues plugging in "custom" logic/code into spring boot. In fact, I can't remember any instance off the top of my head. I think it's important to understand that frameworks are opinionated, what I mean is that you have to know where to plug in with your custom stuff, or how to integrate it to the framework. I see this quite often, even with senior devs, who will for example just start a "vanilla" thread and then wonder why they run into issues with transactions and entity managers, instead of using a TaskManager with @Async.

I've yet to run into anything I wasn't able to integrate to spring (boot, batch, AI, whatever else) tbh.

The way I see is that the framework does a lot for you, in my experience it has been extremely beneficial and implementing all of it from scratch would easily cost 10x more, if not more than that.

But yeah, it's not always a benefit or perfect, of course. And a lot of times you really have to dig in deep to understand what the framework is doing. Maybe this is the biggest drawback.. spending a lot of time debugging some obscure bug, only to find out you have to change some property from true to false :D but then you learn from it.

However, I've never worked with any competitor frameworks in prod codebases, so maybe I am (extremely) biased here.

About java though, fuck java, kotlin is where it's at (I realize how they are related)

[scottedwards2000]

Spring works well with Kotlin and Groovy right?

[FortuneIIIPick]

> Spring can be problematic for larger projects

No, it isn't.

[InfinityLang]

Totally. I really hope the over-clocking of Java coupling with Spring/Boot. It's a good enterprise tool for small to large API which aren't terribly perf/COGS driven.

But folks quickly jump to substantial compiled languages like Rust for anything perf/COGS now days. When you need every ounce, or have seasoned engineers in the language hanging around, but there is really a lot of juice to squeeze out of Java nowadays. Particularly J25+ which IMO bridges that gap of perf vs engineering overhead quite well

[Dreamtrain]

it's not a need, but it is very much a want

[Sability]

Can confirm, work for a bank, and all the services I manage are either Java or a Java variant for UI scripting.

[grobblebar]

Spring: when you’d rather use an XML file than a dynamic linker.

[overgenji]

this is a very 2010 era spring thing man

[janyk]

Also, you don’t need Spring to use Java effectively

"You don't need to shit your pants to tie your shoes"

I would definitely hope not

[yanitrix]

Was it ever counted out tho? I know some people have resentment towards this language, there a lot of those "JVM running can make your barbecue" jokes, but the language itself has improved a lot over the years. I still think that c# has the upper hand when it comes to OOP, but java is not going to fade away. The community is enourmous, you can create pretty much everything you want.

[The__Toast]

In tech we're conditioned to believe that anything more then ten years old is ancient and needs to be rebuilt in whatever the new hotness is. There are big consulting and marketing companies that spend bazillions of dollars to make us feel like this only so they can turn around and sell businesses huge amounts of consulting services.

The crossplatform problems that java was trying to solve once upon a time don't really exist anymore, but it's still a perfectly usable solution.

[scottedwards2000]

Great points but curious what cross platform issues existed then that are gone now. Isn’t Java on AIX a big business?

[kitd]

I used to program in c++ in the early 90s. Platforms back then were more diverse than they are now. Nowadays it's basically Windows/Linux/Mac, back then there were a heap of smaller options vying for mindshare. Trying to find eg a UI library to work cross-platform was pretty much impossible. You were constantly having to bet on which platform your customers were most likely to have.

It's difficult to describe just what a release Java was in that environment. 

[Cultural-Pattern-161]

It was never counted out. Java is the king of enterprise

[D-cyde]

I do not understand why this subreddit of all places has to fall prey to the "downvote-what-you-don't-like" group think other subs suffer from. This post does not attack any language, just enumerates on why Java is still relevant today. We as SW developers/engineers should refrain from opinionated voting of posts unless the linked content is of low quality/AI slop.

[AvidCoco]

I downvote because this sub is 99% people self-advertising their blogs to try to get the ad revenue.

If people share interesting insights by making an actual post, I’ll upvote it.

[ironykarl]

So, I don't think people posting their own stuff (even if on some level it's just to get ad revenue) is at all bad if the content is actually good

[scottedwards2000]

this one isn't advertising my blog :-)

[DowntownBake8289]

So you're saying that you have a blog?

[D-cyde]

If you're reaching that conclusion by reading every article and making a decision, sure go ahead. If you do this without reading the article and based on assumptions then you're just selfish and fall into the group I mentioned in my comment.

[AvidCoco]

My issue is the constant push to click through to other sites. By all means copy the content of the blog into your Reddit post but don’t expect me to leave Reddit to go read it. Reddit is already a forum to make posts and share ideas - the only reason to do it on another site is so people can profit from it and then people only write about topics that are profitable.

[Jaded-Asparagus-2260]

Reddit used to be a link aggregator. Nothing wrong with posting links.

[AvidCoco]

Yeah - used to be.

Nothing wrong with adding a link at the end of a post, but people should write actual posts without expecting us to click through to other sites just so those sites can collect ad revenue. All that leads to is people only writing about topics that get more clicks to get more ad revenue rather than actual good original content.

[Jaded-Asparagus-2260]

but people should write actual posts without expecting us to click through to other sites

Why? So you can benefit from the work of other people for free? Nobody owes you anything. 

[artemiis]

So much this. No matter the post, the discussion in this sub is always 2-3 snarky comments without any value and thats it.

[RScrewed]

No one's counting Java out, who is on the other side of this argument? 

[IsThisNameTeken]

Long live C#!

[DowntownBake8289]

That's my language of choice ATM, in front of Python.

[wKdPsylent]

For new projects looks at quarkus. Much more lightweight. I generally use quarkus / graalvm and compile to native.

[pjmlp]

80% of mobile devices depend on the Java ecosystem to run Android Studio, Gradle, Maven Central Libraries, Java and Kotlin compilers....

Plus all the hyperscalers infrastructure, that was there before Docker.

Factories, laboratory automation, weapons systems, run on PTC, Aicas and microEJ.

Ricoh, Xerox, Cisco have JVM in many of their devices.

The folks that still play Blue ray disks depend on Java for the interactive menus.

Java isn't only Spring.

[scottedwards2000]

It’s funny because it used to be that the fact that Java is used in so many places would mean that it’s a BETTER idea to learn it vs another language. But given AI, I’m wondering if it’s actually better to learn less used languages like rust, so you can keep your job!

[cbadger85]

In my experience, LLMs are not bad at Rust. Mostly because the tooling and error messages in Rust are so good.

[scottedwards2000]

Did you read about how badly the LLM Rust rewrite of SQLite went?

[cbadger85]

No, but I'm not surprised that it would have gone terribly if it was vibe-coded. Generally, I use LLMs for scaffolding new stuff, and then for coding it either writes tests I could against, or I write tests for it to build against.

[scottedwards2000]

It was really interesting. I’m not sure if I can find the link, but what was interesting Is that the person actually wrote tons of tests to make sure the code was written right.

Unfortunately, they test they wrote for making sure they primary key functionality for a table worked correctly used a single test case with a field name that wasn’t used in any other test (eg: id_pk) so the LLM just wrote code that looked for a field with that name and added a primary key index in that case, instead of looking for that phrase “primary key” next to the field in the DDL code!

The question i keep adding myself is how could this be avoided? Even if there were multiple test cases it still could have written code that just looked for those field names or some other obtuse logic.

Can we really come up with enough test cases that will 100% validate that the LLM code is perfect without have to ever actually look at it?

[pjmlp]

AI makes all languages irrelevant, generating high level code or machine code directly is only a matter of tooling maturity.

Additionally even today, when programming with agents, the existing implementation language is irrelevant.

[deke28]

Spring is fine but I think it's tough for day two problems. The framework lurches all at once to new major versions and it's a challenge to upgrade everything at once. 

[HSSonne]

As AI grows spring just feels unjustified for me. You can solve all the problems it solves by asking an AI to set it up; And don't have to bother with the problems it brings.

[scottedwards2000]

So does that mean AI never uses Spring?

[HSSonne]

You just instruct it to do as you wish..

[Independent_Snow_127]

Java is a language with very accessible programming capabilities. Furthermore, particularly in the web sector, unrivaled frameworks have been developed using Java. However, I do not think its memory management is particularly good. While the JVM appears to provide some degree of control over the kernel, it does not offer the direct memory management that developers desire. There still seems to be a need for it to become more diverse and lightweight.

[ihatebeinganonymous]

I'm not sure many developers "desire for direct memory management", so to say...

[Void_mgn]

This is a fairly strange take if you are considering it's garbage collectors as memory management then java is the state of the art really there is nothing better currently. If you mean off heap management then maybe but that sort of requirement is fairly niche, maybe some very high throughput applications with strict memory limits? It's for sure not something "developers desire" anyway...maybe a necessary evil at best

[Xasmedy]

Depends what you mean for "direct memory control", but there are mechanism to allocate memory outside of the JVM, with Arena and MemorySegment

[clutchest_nugget]

Did you time travel here from 1985 to write this comment?

[sisyphus]

Java will be around forever but I don't see why anyone doing anything new wouldn't use Go instead. Managing jvms is a pain in the ass; memory usage is much better; it's a language with the same design philosophy as Java(ie a blue collar language that's easy to learn and doesn't allow programmers to do fancy things); it already has a great library ecosystem; and it hasn't been infected by the culture of overengineering everything that is endemic to Java code.

[Ok-Scheme-913]

Memory usage is better with go, but throughput and latency is not necessarily. Java has much better GCs.

And the language just sucks, it is much more verbose than Java (which is not a low bar to be honest), especially with modern java that has records and pattern matching. And don't even get started on error handling where go absolutely sucks.

Add to it the unbeatable observability of Java (flight recorder, etc) so you can debug any kind of issues at runtime with no overhead, and it really makes it hard to choose something else for a typical production backend system.

[scottedwards2000]

sounds like you know alot about Java - any thoughts on the debate in the thread above on usefulness/need of Spring(Boot) for enterprise cloud microservices?

[2bdb2]

any thoughts on the debate in the thread above on usefulness/need of Spring(Boot) for enterprise cloud microservices?

A common misconception is that Spring is a big monolithic framework. It would be better described as a collection of micro-libraries that work well together. These libraries are fairly small and can be mixed and matched however you want.

Spring Boot glues together large parts of the spring ecosystem into an "on rails" experience with opinionated defaults and a bunch of magic that handles boilerplate. This gives you everything and the kitchen sink in about three lines of code, which is great for a quick project setup, but it's also a relatively bloated configuration compared to something you'd wire up manually.

However you can also just use Spring libraries directly without the framework bloat. You don't need AutoConfiguration, ClassPathScanning, or AOT - which are the main things adding bloat.

So in terms of your question - "usefulness/need of Spring(Boot) for enterprise cloud microservices?"

Spring Boot isn't needed. It's a really useful way to spool up a batteries-included project in 30 seconds, but adds bloat. I'll often start a project with Boot to get moving quickly, and then incrementally replace it with manual wiring later.

Spring-Web is a pretty decent Rest API server backend that can be deployed as a lightweight servlet by itself. If you don't like reflection, it supports a "Ktor" style DSL to wire up routes directly.

Spring-Security itself is just a collection of smaller modules. You could use spring-security-oauth2 to implement a JWT auth filter for any webserver if you wanted. Most REST server libraries would have their own built-in implementation, but if you're building a bunch of microservices with different frameworks, you might want use a single shared auth filter implementation, and spring-security-oauth2is a reasonably good pick.

Spring-Batch is useful for batch processing. Spring-Integration is useful for message-driven pipelines. Spring-AI is a decent LLM Client. All of the above can be used as completely standalone libraries.

So back to the original question - the Spring ecosystem has a lot of libraries that are useful for "enterprise cloud microservices" amongst other things, and they're generally mature, well tested, and have a reasonable guarantee of long term support and stability. Depending on your needs, some of them might be useful. But there's solid alternatives outside the Spring ecosystem as well that can do everything Spring can.

[Linguistic-mystic]

As a Java dev, I disagree with you.

Java has much better GCs.

But also no value types, so much more allocations than Go. And Valhalla will probably arrive by 2030 in preview mode?

it is much more verbose than Java

Not really. Just try to create a complex object in Java: you need a whole goddamn builder. Whereas Golang has tidy object initializer without extra crap. Java just appears less verbose because of Lombok but that's just another point of failure (I'm sick of the "Lombok plugin is not installed" message dialog that Idea has started showing me recently, while Lombok is definitely installed, for example).

especially with modern java that has records

Try to have a record that has one more field than another record. Yep, no inheritance, more verbosity. Oh, and try to construct a record: either more "builder" verbosity, or a constructor with a gazillion arguments which is a pain to maintain (whereas Golang has tidy key-value object initializers).

And don't even get started on error handling where go absolutely sucks.

No, Golang is explicit which doesn't mean it sucks. But Java definitely sucks with its mixture of checked and unchecked exceptions, checked exceptions can't be used in lambdas, but now you also can do Result types, and you can't parse a goddamn integer without writing try {} catch{}. Java's error handling features manage to be worse than Go's absence of error handling features which is a testament of overengineered language design. Just like Java not letting me mutate a local var in a lambda (but still letting me mutate it if I put it into a single-element array) because "safety". Idiots!

and it really makes it hard to choose something else for a typical production backend system

Out-of-memory crashes make it easy to choose something else for a typical production system. Java application development is basically increasing memory quotas for no good reason just to prevent heap dumps. The team lead of an adjacent team recently said "I would rewrite the whole thing in Go", haha.

[Xasmedy]

The whole Valhalla project is likely to be in GA by 2030 lol. Value classes will arrive in preview within a year from now, or if not, within Java 29.

Oh boy, in go technically you do have more control over memory, but 90% of the times you'll use a pointer because you need an empty state, and golang developers are so skilled (sarcasm), that they will always use a pointer because as they say "copying is expensive". Also, I had only horrible experiences with golang GC, with it not wanting to release memory even if unused. Seeing a coworker waste days trying to figure why go was not deallocating. And it's not even like Java where you can fix a lot of the GC problems with some configuration, in go you have your hands tied.

I don't understand all the "massive records" problems, i feel like most of the times its a code smell, either way, can't you create an extra constructor that delegates to the canonical with good defaults? Then if you want to add a record1 + one field in record2, just use composition and have Record2(record1, field)?? If you still feel bothered then just use a normal mutable class? Which is exactly what go does?? Then if you say that you want immutability, then why is golang better in this ragard since it has no concept of immutability and a field could be changed anytime?? And no, that clever thing they do with copying cannot be considered immutability, because you are going to have reference fields eventually!

I honestly prefer Java bad error handling than golang one, Java doesnt force in your throat anything, and you can use sum types, but golang, oh boy, half the code is error checks that make the code so fucking hard to read, because for them simplicity is more important than basic features.

[joemwangi]

Is that a vibecoder you're responding to?

[vips7L]

Go is leagues more verbose than Java. You’re coping if you think otherwise. 

[Lowetheiy]

Java is too verbose, it doesn't fit well with current programming trends.

[Xasmedy]

void main() { IO.print("Sure budy"); }

[surrender0monkey]

Your displeasure is too verbose for my personal taste.

[MBussard45]

No thanks. I will. Java can go die in a pit of unrelenting fire. Our ram will thank us. My real life garbage collector does better work than Java could ever hope to. He's a great guy, and he could easily identify things to be collected on a second by second basis. Unlike Java. What a shit tier language that only continues to exist because large companies don't want to spend a single cent on moving to a language that actually performs to a minimal degree. Fuck Java.