Hacker News Reader

Comment by fedeb95 | Hacker News Reader

Java doesn't have a cultural problem. People need to understand that Java culture is almost entirely enterprise culture. Don't want a language influenced by that for your project? There are plenty out there, pick one

View on HN

It has a culture of over-engineering, just look at Log4J or Spring with its AbstractSingletonProxyFactoryBean's. More complicated and far more adhoc than any abstraction should be.

Log4j is too simple to use and configure - what exactly is over-engineered and why we as users would even care if it's overengineers somewhere under the hood?

It's hard to criticize Spring Core - it's too mature and popular to worry about some edge-cases where it didn't fit the developers view of the world. As with any other software - don't use it, or improve the existing one (and Spring Core is open-source), or write your own. But now it's de-facto the foundation of the Java programming landscape.

> what exactly is over-engineered and why we as users would even care if it's overengineers somewhere under the hood?

Log4J has been a major embarrassment for the Java community. I suggest you Google it, if you don't know why.

> It's hard to criticize Spring Core

Spring Core is at best a dynamic (reflection based) band-aid to work around Java's lack of expressiveness. It comes at a significant complexity cost and loss of static guarantees. You cannot both love Spring and Java. So which is it? :)

Oh, please, ok, there was a security flaw - how does it prove that it is over-engineers? If anything it is too flexible and gives developers too many features so that one of them was compromised.

> If anything it is too flexible and gives developers too many features

Over-engineering: "the act of designing a product or providing a solution to a problem in an elaborate or complicated manner"

And that is very much false in case of log4j, it’s likely you just have a mismatch regarding the requirements of enterprise logging — far from trivial.

Of course log4j is an overkill for a simple terminal app that could just write to stderr/out just fine. But it is not an overkill at all for an enterprise business app doing millions of transactions each second with multiple instances, with n+1 kinds of config requirements. So for you to be able to call it over-engineered by your definition you would have to know whether the implementation it provides is more complicated than necessary, which I’m fairly sure you can’t know without having taken a look at the actual code.

There is essential and accidental complexity as two terms for a reason.

Log4J doesn't just log strings, it has an evaluator that can execute the strings and invoke arbitrary code. There is no enterprise that needs this feature. Describe the actual problem, and let's work out how it can be solved without stuffing a new programming language into a string.

>> a major embarrassment for the Java community

Nope, it was not

"The Log4j Vulnerability: Millions of Attempts Made Per Hour to Exploit Software Flaw - Hundreds of millions of devices are at risk, U.S. officials say"

https://www.wsj.com/articles/what-is-the-log4j-vulnerability...

How is a library with flaws most of us is not using an embarrassment to the whole community?

> If you cannot admit this, then perhaps you are part of a "cultural problem"?

I'm sorry, but this edit from you is just stupid.

Not as stupid as claiming it's just another security flaw. Some of us also aspire to better.

Yes they had vulnerability. It is embarrassment when you have too many of them or when you dont fix them.

The "hundreds of millions of devices are at risk" thing happened only because log4j is used a lot. That is pretty much opposite of embarrassment.

> what exactly is over-engineered and why we as users would even care if it's overengineers somewhere under the hood?

Well, just last year we found out that you could remote load class files based on log string substitution. This was especially bad if your service logged web requests.

Seems like you haven’t yet had to deal with clients that require very very specific logging practices, e.g. banks.

Believe me, there is very little in spring/java ee that is completely without reason, they didn’t just like overabstracting shit for giggles.

Yes I have worked for many banks and even written Log4J loggers that log to chat channels. But I can still admit that Log4J is over-engineered and that a security flaw was inevitable. Log4J doesn't just log strings, it has an evaluator that can execute the strings and invoke arbitrary code. Are you telling me that your bank needed that feature?

That doesn't seem to be a problem for users of those libraries: there's an hidden assumptions in the post, that every person on this planet approaching Java has to take part in its use cases. Especially FP enthusiasts and hobby projects developers. If it's engineered to where it is, some call it "over", others call it "just righty"

The blog author is a contributor to cats-effect, if you want to have a look at complicated and adhoc abstractions, look no further. One person's AbstractSingletonFactory is another person's Kleisli monad transformer.

> One person's AbstractSingletonFactory is another person's Kleisli monad transformer

Perhaps these are both the same thing.

Maybe :) But I would suggest that the abstract algebra and category theory would probably be a more worthwhile investment longer term than learning about Spring Beans.

Those are very intertwined though. It's a helix of complexity and technological cynicism.

Reply on news.ycombinator.com