Java call stack – from HTTP upto JDBC as a picture (2006) • Hacker News Board

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#41

Post by Erlich_Bachman » Thu, Mar 08, 2018, 8:56 AM UTC

gambler wrote: post #32

p2t2p wrote: post #16

Like what is the problem? Thanks to this stack trace your business logic fits into two lines. Do you want to have lines and lines of your own transaction manager? Lines and lines of your own DI framework? Do you suggest to write a HTTP web server yourself? Why don't we count stack frames in kernel space? And what do we have in JVM underneath us? And libc/Win32 layer? I'm really annoyed by this kind of things like the…

> Thanks to this stack trace your business logic fits into two lines. Two function calls for business logic, a hundred dependency libraries, thousands of lines of stateful "initialization" code outside of the stack and a fuckzillion XML files for configuration. But yeah, everything's great!

In one case you have to write two lines, because you care about the business logic. That's two lines to maintain, debug, explain to other programmers, staticaly check, etc. etc.

And instead you want to switch to what? Writing 20 lines of that same logic + implementing stuff that has already been better implemented in all of the libraries, by better programmers (because they were able to focus and specialize on that one thing)?

For what? A 2% increase in wall-clock speed? There is a 1 in a hundred applications where this matters. What matters in others is maintainability and development speed. Development is expensive. CPU time is cheap.

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#42

Post by ceronman » Thu, Mar 08, 2018, 9:01 AM UTC

This looks like the perfect example to illustrate the point that Rich Hickey tries to make in "Simple made easy" [1].

This huge call stack has been designed to make your life as a developer easy but the price you pay is an enormous amount of complexity.

I've been working a lot with a similar Java web stack and I feel how painful this complexity is. What is worse, is that I think that a lot of this complexity is incidental. There are libraries and frameworks designed to make some things easier, but in the process end up creating a lot of problems that then requires another library or framework to overcome that problem which also has other problems and so on... The result is a huge stack like this.

One concrete example of this is Hibernate. A tool designed to make it easier (apparently) to work with databases, but in the end create so many problems that the medicine ends up being much worse than the disease.

Resolving an HTTP request that returns a the result of a database call should not be this complicated! HTTP is simple! Why do we need so many calls to so many things. I'm not advocating for a flat stack of course, but certainly a stack this deep is a clear sign that something is wrong.

I very much agree with Rich Hickey, we need to stop thinking about how to make things easier and start thinking how to make them simpler.

[1] https://www.infoq.com/presentations/Simple-Made-Easy

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#43

Post by sgt » Thu, Mar 08, 2018, 9:01 AM UTC

yazr wrote: post #4

meddlepal wrote: post #3

Earlier quoted context omitted.

While that's entirely true, the glueing of those frameworks together is very common in the Enterprise Java development space especially around 2006 when this was taken. I'm a big fan of the JVM and the Java ecosystem but in many ways the JVM ecosystem is split into two worlds: frameworks or libraries. This would be an example of a framework heavy development model where god knows what is going on between the outside…

> common in the Enterprise Java development space especially around 2006 Can you mention which frameworks and glues are common today ?

http://vertx.io/ is extremely powerful and relatively popular. We've used in production for years. Note that it is a non-blocking framework so there is a bit of a learning curve coming from e.g. Java EE.

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#44

Post by bullen » Thu, Mar 08, 2018, 9:42 AM UTC

My application server has 8 methods from thread to your code: http://test.rupy.se/?id=2

And an integrated distributed async-to-async database that is just as shallow: http://root.rupy.se

Feel free to use it: http://github.com/tinspin/rupy

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#45

Post by realharo » Thu, Mar 08, 2018, 9:48 AM UTC

ceronman wrote: post #42

This looks like the perfect example to illustrate the point that Rich Hickey tries to make in "Simple made easy" [1]. This huge call stack has been designed to make your life as a developer easy but the price you pay is an enormous amount of complexity. I've been working a lot with a similar Java web stack and I feel how painful this complexity is. What is worse, is that I think that a lot of this complexity is incid…

>This huge call stack has been designed to make your life as a developer easy but the price you pay is an enormous amount of complexity.

This particular problem could be solved by just having a good filtering UI.

You don't have to analyze the stack in its raw text form.

That being said, I agree that complexity in the Java world is often much higher than it needs to be, and sometimes the tradeoffs are not worth it.

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#46

Post by Macha » Thu, Mar 08, 2018, 10:28 AM UTC

jimbokun wrote: post #28

p2t2p wrote: post #16

Like what is the problem? Thanks to this stack trace your business logic fits into two lines. Do you want to have lines and lines of your own transaction manager? Lines and lines of your own DI framework? Do you suggest to write a HTTP web server yourself? Why don't we count stack frames in kernel space? And what do we have in JVM underneath us? And libc/Win32 layer? I'm really annoyed by this kind of things like the…

The problem is it can be extremely difficult to map those stack trace calls to concrete Java code, because so much of a Spring application is generated from an annotation, or code getting called simply because a dependency exists on the classpath. Sometimes classes appear out of thin air, with no Java code existing for them at all, summoned into existence by some annotation somewhere. Object Oriented Programming has…

Before annotations, it was XML so you have to go back a while before it gets simpler.

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#47

Post by kuschku » Thu, Mar 08, 2018, 11:15 AM UTC

jimbokun wrote: post #28

p2t2p wrote: post #16

Like what is the problem? Thanks to this stack trace your business logic fits into two lines. Do you want to have lines and lines of your own transaction manager? Lines and lines of your own DI framework? Do you suggest to write a HTTP web server yourself? Why don't we count stack frames in kernel space? And what do we have in JVM underneath us? And libc/Win32 layer? I'm really annoyed by this kind of things like the…

The problem is it can be extremely difficult to map those stack trace calls to concrete Java code, because so much of a Spring application is generated from an annotation, or code getting called simply because a dependency exists on the classpath. Sometimes classes appear out of thin air, with no Java code existing for them at all, summoned into existence by some annotation somewhere. Object Oriented Programming has…

Java has annotations, C/C++ has macros, every language from Lisp to Rust to Scala has some form of macros or annotations.

These can often be very powerful, but of course debugging is more complicated.

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#48

Post by gerbilly » Thu, Mar 08, 2018, 1:27 PM UTC

ceronman wrote: post #42

This looks like the perfect example to illustrate the point that Rich Hickey tries to make in "Simple made easy" [1]. This huge call stack has been designed to make your life as a developer easy but the price you pay is an enormous amount of complexity. I've been working a lot with a similar Java web stack and I feel how painful this complexity is. What is worse, is that I think that a lot of this complexity is incid…

>One concrete example of this is Hibernate. A tool designed to make it easier (apparently) to work with databases, but in the end create so many problems that the medicine ends up being much worse than the disease.

Sure.

At our startup we had the choice to let 20 programmers write custom individual SQL statements for 100s of CRUD operations, or create entities and let Hibernate generate them for us.

We used hibernate and it has worked out well.

I can't imagine how it would have been to debug 100s of bespoke SQL queries and associated object mapping code, each written in the developers unique style after a few years.

That would have been fun.

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#49

Post by le-mark » Thu, Mar 08, 2018, 2:00 PM UTC

ceronman wrote: post #42

This looks like the perfect example to illustrate the point that Rich Hickey tries to make in "Simple made easy" [1]. This huge call stack has been designed to make your life as a developer easy but the price you pay is an enormous amount of complexity. I've been working a lot with a similar Java web stack and I feel how painful this complexity is. What is worse, is that I think that a lot of this complexity is incid…

Resolving an HTTP request that returns a the result of a database call should not be this complicated! HTTP is simple! Why do we need so many calls to so many things. I'm not advocating for a flat stack of course, but certainly a stack this deep is a clear sign that something is wrong.

Http is pretty simple, executing sql queries against a database is simple-ish (close those connections!). Authentication, authorization, marshalling, unmarshalling, transaction boundaries, ..., are not so simple, especially not when all taken together.

People bemoan java as you are doing here, but the reality is other languages and frameworks, any that attempt to address the same problems and concerns have the same level of complexity. Java has the advantage of kick ass tooling, debugging, and monitoring infrasture, a lot in the jvm itself (visualvm).

Re: Java call stack – from HTTP upto JDBC as a picture (2006)

#50

Post by BenoitP » Thu, Mar 08, 2018, 2:17 PM UTC

userbinator wrote: post #24

p2t2p wrote: post #16

Like what is the problem? Thanks to this stack trace your business logic fits into two lines. Do you want to have lines and lines of your own transaction manager? Lines and lines of your own DI framework? Do you suggest to write a HTTP web server yourself? Why don't we count stack frames in kernel space? And what do we have in JVM underneath us? And libc/Win32 layer? I'm really annoyed by this kind of things like the…

Why don't we count stack frames in kernel space? And what do we have in JVM underneath us? And libc/Win32 layer? You even mentioned it yourself: this is the additional overhead added by the Java ecosystem on top of what may already be a pretty large stack of stuff. (From what I've seen, libc is pretty shallow. The majority are either leaf functions like strlen(), or Even if the overhead is not much to a machine, it i…

> libc is pretty shallow. The majority are either leaf functions like strlen(), or I'd wager that the JIT in OP's picture will transform that huge call stack into something What remains though, is the huge context carried around such a stack; and I'm quite excited at what the Loom project [1] could yield to tackle that.

Such huge call stacks are a good sign to me. I don't want to implement all the corner cases of all the RFC I rely on; and it is great that library implementors can organise their code well. In the end the JIT will adapt my program to the currently used corner case, and prune everything else.

[1] http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.htm...