Hacker News new | ask | show | jobs
by merlindru 1 day ago
java the language is amazing

the problem with it is entirely cultural. why is `IStatusChangeEntityCreationManagerFactory` everywhere?

and why are the frameworks so huge and all encompassing? i think batteries included rails-style frameworks are great, but when i wrote Java, it didn't feel like rails at all

none of these are language problems

7 comments

I know and like Java for almost 30 years now. It is amazing how carefully the language is beeing refined. For the cultural aspect, yes, that is sadly true, but I have the feeling that the culture changes. More and more developers realize that there is a better way now (e. g. records instead of dumb classes full of getters and setters). Maybe the main problem is bloated frameworks and their stickyness. The Helidon framework, for example, is a breath of fresh air compared to Spring. Go developers complaining about huge Java frameworks and boilplate could be happy with it.
IMHO, the main reason why Spring is huge is because it has grown organically to encompass many of the business cases/issues that one may encounter in both depth and breadth. So the http framework supports almost everything you may ever need and there is integration with every database, middleware, infra like kubernetes. (One can debate about the quality of all the lesser used modules but the main modules are pretty okay.)

On the other hand I have used Quarkus which was great until it wasn’t because a certain http feature wasn’t supported or we needed integration with an unsupported database. In enterprise that is enough reason to just choose for the batteries included option and lift along on improvements of the main framework.

> or we needed integration with an unsupported database

How difficult is/was it to add a custom integration?

Just adding the bare bones integration wasn’t that hard. The trick comes from ensuring all the observability is wired correctly, that it fits in the framework usage, works good with graalvm, and other “non-functionals”.

At this point the work is typically more than you want a single team to maintain. Unfortunately, in many large enterprises it is just easier and more efficient to grab a bigger framework than trying to organise sharing the custom integration in the organisation.

+1 for Helidon (https://helidon.io/) - such a great framework, especially the SE variant. Powerful, modern, fast, modularised, and easy to understand.

I'm back on Spring for work reasons but use it for all my side-projects.

i am building my own framework on top of it[1]. the biggest thing for me was it was rewritten on virtual threads from grounds up. no vertx. no netty, lesser indirections.

1. https://github.com/sku0x20/stopgap

I was not aware of Helidon. Looks nice at first sight!
This is specifically Spring culture, not Java culture in general. I don't tend to see this outside of Spring. Maybe back in the J2EE days, but that community seems to be more or less dead.

Java is a big tent. Yeah there are some parts that deserve this kind of mockery.

The Rails equivalent is over-metaprogramming. "I solved it with method_missing." I've worked on code like this in real life. TBH I'd rather have the inane verbose class names.

I**Factory existed long before spring came around
I-prefixing interfaces is a practice from Microsoft's COM, and to this day still isn't part of Java culture, despite the efforts of subversive dotnet renegades.
Yes, more common is

  Manager     // interface

  ManagerImpl // class
Yeah, Ruby code bases are generally harder to maintain than Java ones.
I have an opinion on why. If you were in that world 25+ years ago, you'll be familiar with the landscape. There were a dozen popular application servers, each with 15 versions in the wild, all running on premises, and you had to ship software to customers who had wildly different operations. It helped. It's verbose. As you said, this mostly attributable to JEE and projects that traded build time complexity and home-grown code for abstraction complexity.

I had to support systems from IBM, BEA, Apache, Red Hat, SAP, and some I'm certainly forgotten. Then there were the piecemeal systems. OSGi made an appearance. Then you have databases from Oracle, Microsoft, and IBM. Identity and auth was the wild west, with countless SSO vendors, wacky LDAP implementations, wackier SAML implementations, Kerberos, Ping... Despite that, it was pretty feasible to build and ship the same artifacts and configure things at the site.

Most languages simply don't have all the frameworks that were created specifically for use in an enterprise context. There's cobol and there's maybe C#, Java and then a long tail of everything else.

A lot of the Java stuff actually came out of the Smalltalk community. IBM used to employ a lot of these people and they brought their enterprise stuff with them when things like Enterprise Java Beans became a thing. And because IBM was there, you got everybody else showing up as well. That's why Oracle bought Sun as well to get access to that juicy market.

IBM could have picked any language. But Java was kind of there and new at the time and it kind of did the job. So that's what they jumped on. MS stole a bit of the thunder with dot Net a few years later which is why C# is also very common in that space. But besides that there isn't a whole lot that has similarly wide adoption. Client side is a whole different story of course.

And the reason stuff gets complicated is that there is a lot of design by committee going on in this world by parties that are mutually adversarial and have big budgets.

So, this particular feature comes out of at least 15 (I think) years or so being debated in that sort of committee. It kind of predates the whole inception creation of things like Kotlin. I was at a 15 year birthday party for that at the Jetbrains office in Berlin a few weeks ago. Debates about value classes in the Java community probably go back to last century.

> Most languages simply don't have all the frameworks that were created specifically for use in an enterprise context

And yet a lot of enterprises have done without in other languages.

There's always this comment on every Java post. I expect the average HN member to be someone on the team who is either leading their projects or plays a significant role in driving the design of the software. You set the culture for your own projects. I've lead the development of some massive Java apps and all have had simple and clean architecture. I've never seen IStatusChangeEntityCreationManagerFactory or anything like it even once in any of my projects, but perhaps that's because the last time I used Spring was ~17 years ago. Most of my recent projects are using Quarkus, which is still a relatively large framework. But our codebase is designed in such a way that we're not tightly coupled to Quarkus.

I have seen a surge of overly complicated PRs now that we're in the AI era, but it's our job to be the gatekeeper and push back on this crud from entering the codebase. And that's likely true of any language.

I have never run into code like that in any of my jobs.
Show me where IStatusChangeEntityCreationManagerFactory is in the language. Or the standard libraries. Or anything like it
Spring is not Java. It's also one of the most complex projects out there.
> Or anything like it
Spring isn’t the language or standard libraries.
Ok, it's possible that my bilingual ahh is misunderstanding the comment. Maybe we can try to come to an understanding?

I read that comment as "Show me where [long classnames] are in the language, standard library or <relevant ecosystem project>."

Spring is one of the biggest java libraries and quite widely used. I think it fits rather nicely, even if the example itself is fairly old.

lol it’s so long it overflows the window and breaks the css on my phone.
it's not, that's my point