Hacker News Reader

Comment by scaladev | Hacker News Reader

Just out of curiosity, are there any Java web frameworks with reasonable stack depths? After working on .NET Core codebases for several years (which rarely have more than 4-5 calls within the framework itself) I was shocked to see stack dumps from a Spring application I've been working on. Three to four nested exceptions, with up to 100 nested calls (and sometimes more) within each one. If you don't have a smart IDE folding the less interesting parts (and copious amounts of amphetamine), it's simply unreadable.

View on HN

Spring is the poster child for abstraction gone wild. Famously: https://docs.spring.io/spring-framework/docs/3.0.6.RELEASE_t...

Haha, I think the worst part of that unintended joke is that the class description starts with Convenient. I wonder if the author of that text noticed how weird the whole thing is?

"Convenient proxy factory bean superclass for proxy factory beans that create only singletons."

in poker, you are sometimes faced with a shitty decision on the river, but the mistake was made preflop

In some future decade, when Banks start trying to migrate their "Enterprise Java" systems, anyone that can make sense of that bizarre and rather absurd model of computation is going to get well compensated.

How many COBOL programmers do you know who drive Ferraris?

None, I guess they didn't make it complicated enough!

Keep in mind that Spring was originally a reaction to the extreme complexity of Enterprise Java. I still remember a talk where they said everything would just be simple POJOs: plain old Java objects.

It was certainly well marketed. But in reality, Spring is also too complex. It has far too much dynamic dispatch, byte-code weaving magic and runtime failure. This is now causing them problems with GraalVM and fast startup times needed for cloud.

There is an architectural error in Java frameworks that I've noticed. (Other languages have it too, just nowhere near as common.)

Basically, the error is that when some system uses virtual function calls via an interface, what that's really saying is that: "This can be changed at runtime."

So if there's some function "void foo( IBar bar )", then what that's really saying is that "bar" can change at runtime. Literally a different implementation from call-to-call.

Is that actually required?

In 99.9% of such function calls, no: the implementation of IBar will always be the same concrete class.

To see a language that has gone to the opposite end of the spectrum, take a look at Rust. It use a lot of parametric typing, which is very flexible, but by default tends to use compile-time static types instead of run-time dynamic types.

Java never went down this path because it added parametric types very late in its design.

C# had parametric types in v2.0, which is when it started getting popular.

Rust had it from the beginning.

For some odd reason, Go still doesn't have parametric types (they call it generics), yet it seems to have remained surprisingly sane despite supporting generic interfaces.

https://golangnews.org/2020/11/experimenting-with-go-type-pa...

Do you have any idea what they did right that Java lacked?

My guess it’s the different idea of what an interface is and how errors are signaled.

An interface in Go can be defined by the client code and types just need to implement the functions. In Java Interfaces need to be defined before any code can use it. And exception handling makes code hard to reason about because it introduces hidden control flow.

I think Generics don’t give you that much leverage. Without them you need to duplicate the code for each type or class, but duplicated code is much easier to work with. Yes, it’s not really dry, but copy paste and search/replace is something which increases developer productivity, fixing bugs in code with too many generics decreases it.

And one thing to keep in mind: historically a lot of interfaces in Java were necessary because Java had no lambdas. In Go functions are first class citizens and you don’t need an Interface just to dynamically call different functions.

The appeal of generics is in writing data structure libraries that are primarily abstract containers. With parametric typing you can bind the contained type early, rather then being bound through runtime indirections and checks like a dynamic type system, handles to another container, interface compatibility, or other such tricks.

That's an important role, especially in performance-sensitive domains, but outside of that, it never seems to work very well, which makes it a easily misused feature in every language I've used that offers it. Go's original design basically took the form of offering this for the built-in structures but not letting you roll your own, ushering you towards interfaces if you really needed it, and because Go makes interfaces convenient, it mostly works.

I agree, the native array and dictionary support in go makes it easy to forget that they don't have generics.

BTW, as an example of generics abuse, crypto++ comes to mind. It's such a huge pile of templates referencing each other and exceptions being used to control the command flow, that I was once hired as a freelancer just to link the whole thing into a static library, because the company using it was unwilling to deal with the source code, but needed it for FIPS compliance.

It's an incredible engineering feat that they managed to let you mix and match cryptographic functions and containers and storage formats as you see fit, but having a C++ stack trace with 5 abstract templates in it makes it very painful to debug if stuff goes wrong.

Thanks for pointing out lambdas. I hadn't considered them, but I wholeheartedly agree :) My go projects tend to have small helper lambdas and lots of defer calls, which are effectively lambdas, too. Without them, I'd need a lot more source code and/or an IDisposable interface for pretty much every io class.

golang is basically Java pre-generics. Working with large golang codebases is quite annoying and error prone, partly due to the lack of generics. They didn't get it right at all.

Having built an offline-capable distributed database in go, I noticed that even "larger" projects in go tend to be a lot less source code than building something similar in Java.

And maybe that's just my personal style, but to me defer is much more important than generics.

I can't even remember how often I've had to debug Java bugs where someone forgot to close a ResultSet for an SQL query... And then you leak memory so badly that restarting tomcat with a daily cron is still not enough :(

With defer, you can expect people to write the cleanup code immediately after opening something, which makes it much easier to confirm that you're not leaking resources.

Java already solved this with try-with-resources, which the linter or IDE can warn you about (because the instance has to inherit from `AutoCloseable`). Not so with golang's defer, where it is much more likely that the developer can forget to call it.

Reply on news.ycombinator.com