Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ptrthomas.wordpress.com

Post reply on HN
Print view View original

21–30 of 63 posts

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

#21

Post by peterevans »

marktangotango wrote: post #17
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…

Debugging these stack traces is easy, just look for your packages and classes, and “caused by”. You should never be debugging framework code. Well almost never.

"Almost never."

In my experience, the code you write within a third-party framework rarely works the way you expect it to the first time. So you often do "debug" the framework, just to see where your code goes while in the framework to see what you missed.

That's not a bad thing, though--it's a great way to learn any new framework!

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

#22

Post by peterevans »

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…

Expressiveness is not always a pure ideal; reducing your business logic to two lines of code comes with tradeoffs. The ways your code work within the frameworks you choose is not always obvious, and when something goes wrong, it's harder to point at one place within your two lines of code and say: this must be it.

The opposite is not, and should not, necessarily that you write your own versions of things; after all, if you did so, you'd still have as deep of a stack trace as you do with the third-party code!

I guess, if I encountered this stack trace, I might say there's something of a code smell there. But, hey--this is also fairly old code, and I suspect things are Better Now, so let's not be so quick to cast stones!

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

#23

Post by burkaman »

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…

I think you're reading into this too much. It's posted because it's interesting, and something Java developers might not think about very often. The author doesn't imply there's any problem.

"Java EE is a lot about abstractions which I have grown to appreciate over the years. However, I find this very difficult to explain to my colleague who sits just across the room – he is a Mainframe veteran with tons of experience :)"

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

#24

Post by userbinator »

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 is certainly going to have an effect on the human who has to figure out what's going on. When you write such code you may not think this way, but every piece of code is a possible place for a bug to be.

From my short experience with Enterprise Java years ago, such deep callstacks are usually symptomatic of code that does far more indirection than actual work --- hundreds of tiny methods that have maybe a statement or two and then call another one. I understand that it might feel good and even better to write code like this, but that simplicity is deceptive: you aren't looking at the whole picture and just focusing on micro-simplicity, when it's macro-simplicity that really counts.

This means that when you're trying to track down a bug, the "interesting parts" are scattered in tiny pieces across dozens of files, and it increases the cognitive overhead significantly in having to piece everything back together. You might not realise that something is wrong until you're deep inside, and then you have to jump back several levels above in the callstack to figure out where things went wrong, seeking in and between files to trace out the execution flow.

I'm glad I don't work on code like this anymore.

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

#25

Post by givehimagun »

peterevans wrote: post #21
marktangotango wrote: post #17

Earlier quoted context omitted.

Debugging these stack traces is easy, just look for your packages and classes, and “caused by”. You should never be debugging framework code. Well almost never.

"Almost never." In my experience, the code you write within a third-party framework rarely works the way you expect it to the first time. So you often do "debug" the framework, just to see where your code goes while in the framework to see what you missed. That's not a bad thing, though--it's a great way to learn any new framework!

Agreed and I will piggyback on top of it. I think we forget how reliable some of the code in this stack is. It's battle-hardened and works extremely well with lots of documentation/help.

There is no sane alternative to this...that is the power of open source where we collectively pool our capacity into something worthwhile to everyone. I want more of it.

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

#26

Post by jdmichal »

peterevans wrote: post #21
marktangotango wrote: post #17

Earlier quoted context omitted.

Debugging these stack traces is easy, just look for your packages and classes, and “caused by”. You should never be debugging framework code. Well almost never.

"Almost never." In my experience, the code you write within a third-party framework rarely works the way you expect it to the first time. So you often do "debug" the framework, just to see where your code goes while in the framework to see what you missed. That's not a bad thing, though--it's a great way to learn any new framework!

Using jBPM, you get a NullPointerException when you use a WorkItemHandler with a BPMN . Not a nice one with a message, either. Had to debug into jBPM to figure out that one.

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

#28

Post by jimbokun »

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 been mostly replaced by Annotation Oriented Programming in modern Java web development.

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

#29

Post by jdmichal »

nickbauman wrote: post #7

The fact that Spring even exists should be a big red flag for the value of static typing. People routinely make mistakes using type systems. And when done correctly I see static type systems work very well solving problems that they themselves created.

The best way to configure Spring beans is through @Bean annotations in code, precisely because it allows for static typing...

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

#30

Post by Floegipoky »

deepsun wrote: post #19
yazr wrote: post #4

Earlier quoted context omitted.

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

dropwizard.io

+1 for dropwizard; Spring is too big, dropwizard is just right. I've always preferred JDBI over JPA too.
Post reply on HN