Yeah. Java is pretty boring but I wouldn’t recommend for the majority of cases.
Please don't take it the wrong way, but the days of XML for everything are long gone, and for years in Java it's been XML for nothing as a counter reaction.
You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners.
Java hasn't used XML in ages and you cannot fault it for legacy apps. You could similarly complain about the horror of EJBs -- sure, but the industry has moved on and acknowledged they were a mistake.
I think plurality of situations it's actually used for currently would be a better standard than what you're advocating for.
This has the advantage that the merits people judge things on, and the experience they will most likely have using it will line up.
The downside is that, the merits used may differ a bit between markets or industries, but I'm personally ok with that.
Imagine if I complained about Linux and all I used as an argument was the Unix Haters Handbook.
Imagine if I complained about Windows and the most recent version I had used was Windows 95.
If you want to be able to know the theoretical things you could do with the language, I think your definition is right.
If you want to know the most likely experience you would have using the language, I think mine is right.
I think it also depends on what circumstances you're using the language. Spinning up a new project probably lends itself more towards your definition. If you're looking to join an existing project, mine is probably more useful.
Java is a pretty solid tech and the JVM is one of the best runtimes in the world. But it does offer you infinite possibilities to write awful code and that made me less interested in it with time.
I am saying that when I was contracting with Java some years ago it was a complete crapshoot: you could get an almost brand new project with a lot of thought put in that made it a pleasure to work on, or you could get an ancient EJB mastodon that made you want to slit your wrists.
And that gamble still exists if you want to contract with Java. A lot of preliminary negotiations have to be done in order not to find yourself in a situation where you should have charged $30k a month due to the insane amount of digging you have to do just to make the thing accept one new feature.
It's much less annoying than "exciting" episodes and habits:
- let's see if our SSL certificate has been actually updated on all servers in the cluster
- let's find out what I need to restart after deploying my web app update
- who knows what the classpath loading order will be this time; if it's broken you can try a restart
- finish the test quickly before the sysadmin committee begins an application server upgrade and everything goes offline for as long as it takes, hopefully only a few hoursFor me, part of "boring" is being like a 2x4 or a claw hammer: simple, solid, reliable, well understood. A lot of the Java world is nothing like that.
If you start creating something called AbstractMonthlyBillingReportAggregatorFactory that inherits from AbstractBillingReportFactory that inherits from AbstractReportFactory all of which implement a Report interface, things have gone unsalvageably far off the rails to be useful any more.
It’s fair to say you could do this same thing in C++ or Python etc., and sometimes that does happen. But just anecdotally observing this in many companies, it happens _on purpose_ with Java all the time, but much less so in other ecosystems. In other systems it’s just much easier to get things done without resorting to tons of inheritance misdirection, and many great common libraries already solve problems in those ecosystems with minimal inheritance bloat, giving lots of easy to follow examples.
These are fashions in the software engineering world. Had Ruby dominated the development world at the time Java did, you would have seen the same enterprisey patterns.
For an article about "stick to boring and reliable" there seems to be too much push back against Java. I understand the psychological processes involved: stick to boring unless it's the one technology one personally finds unpalatable -- for me that would be COBOL or ColdFusion (and yes, I'm aware Java has been compared to COBOL by proponents of trendier technologies! :P )
If a language supports what I would call “lightweight OO” - extremely low boiler plate, zero required OO constructs (purely optional), and language features that render the concept of dependency injection intrinsically obsolete (because mocking can be done purely through introspection at no cost), then that flavor of OO is well suited for business problems.
It has less to do with things like JVM or GC oddities, because those can be straightforwardly engineered around. It’s more about what non-negotiable commitments to specific patterns or strategies come along with the language choice.
Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender.
Conversely, I think C# is an ecosystem that suffered the same limitations as Java but found ways to extend and reinvent that make it more attractive now, though still far behind Python, C and C++.
and
> Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender.
You seem to be talking out of principle instead of actually having hands-on experience developing large systems in Java. To be honest, it doesn't seem you're familiar with the language or the platform.
I'm not interested in debating your theoretical preconceptions.
You seem likewise uninformed about functional programming and how it has been used to write extremely high-performance fintech systems.
In any case, that Java's OOP cannot be successfully deployed for business software is counterfactual. Anyone insisting on that point is unfamiliar with Java.
Is the reason a mystery? Java is the language that got a multibillion dollar marketing pitch at its inception. It was designed to be in "the enterprise" from day 1.
Strong disagree. This is exactly what most of the Java world is like: well understood and reliable. I wonder if people who say things like you did actually use it for their day jobs, or rely on things people using other technologies claim in their blogs.
TBH, this is exactly what the Java world is like. There are not many surprises in Java land. The language isn't getting fantasy land changes on a daily basis. There are libraries that haven't been updated in years because there hasn't been a need to update them - they just work. People want to leave Java because it's boring.
Is Java perfect? Of course not, no language is perfect. But, Java is the closest thing to a boring 2x4 the programming world has ever invented.