5 ms·

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

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.

modeless 6y ago
Spring is the poster child for abstraction gone wild. Famously: https://docs.spring.io/spring-framework/docs/3.0.6.RELEASE_to_3.1.0.BUILD-SNAPSHOT/3.0.6.RELEASE/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html https://docs.spring.io/spring-framework/docs/3.0.6.RELEASE_t...
- fxtentacle 6y ago
  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."
  - dustingetz 6y ago
    in poker, you are sometimes faced with a shitty decision on the river, but the mistake was made preflop
  - willtim 6y ago
    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.
    - justin66 6y ago
      How many COBOL programmers do you know who drive Ferraris?
      - willtim 6y ago
        None, I guess they didn't make it complicated enough!
    - mcv 6y ago
      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.
      - willtim 6y ago
        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.
deleted 6y ago
[deleted]
jiggawatts 6y ago
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.
- fxtentacle 6y ago
  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-parameters-generics-in-goland/ https://golangnews.org/2020/11/experimenting-with-go-type-pa... Do you have any idea what they did right that Java lacked?
  - rmetzler 6y ago
    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.

modeless 6y ago

Spring is the poster child for abstraction gone wild. Famously: https://docs.spring.io/spring-framework/docs/3.0.6.RELEASE_to_3.1.0.BUILD-SNAPSHOT/3.0.6.RELEASE/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html https://docs.spring.io/spring-framework/docs/3.0.6.RELEASE_t...

fxtentacle 6y ago
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."
- dustingetz 6y ago
  in poker, you are sometimes faced with a shitty decision on the river, but the mistake was made preflop
- willtim 6y ago
  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.
  - justin66 6y ago
    How many COBOL programmers do you know who drive Ferraris?
    - willtim 6y ago
      None, I guess they didn't make it complicated enough!
  - mcv 6y ago
    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.
    - willtim 6y ago
      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.

deleted 6y ago

[deleted]

jiggawatts 6y ago

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.

fxtentacle 6y ago
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-parameters-generics-in-goland/ https://golangnews.org/2020/11/experimenting-with-go-type-pa... Do you have any idea what they did right that Java lacked?
- rmetzler 6y ago
  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.