Java call stack – from HTTP upto JDBC as a picture (2006) (opens in new tab)

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 they have any meaning except "I don't know shit about how abstractions work in computers"

%s/you/picture author

I'm not sure I really see the problem. They picked a particularly pathological example, with a lot of heavyweight frameworks. It's a choice.

I just counted the frames from my typical stack, a Guice/Hibernate project. It was about 100 lines from a constraint violation handler in the postgres JDBC driver up to Thread.run(). This seems pretty reasonable, especially with the various layers I've added for authentication, declarative transaction management, AOP logging, etc.

Furthermore, IntelliJ is pretty good about only showing me what I care about. Overall I find the debugging experience no worse than Python or Ruby, and much better than exceptions from Python or Ruby native libraries. It's orders of magnitude better than debugging Go, which destroys stack context with every "if err != nil return err".

This is beautiful. Working with ES2015 async await style promises on the server now... you don’t even get valid stacks.

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

I’ve seen this all over the place and it looks like a totally fine reasonable stack trace to me.

Anyway while the stack (hibernate, etc) shown in this stacktrace is still heavily in use, newer async java frameworks/tools usually result in very short stacks for me. Sometimes I get a trace and it’s 5-6 frames. Of course then you may not know how you got there. So it’s really not all that great.

This should be titled "Acegi/Spring/Hibernate" call stack. And none of those technologies are needed to build a JEE webapp.

Rails code can get that deep, the difference being MRI doesn't have an inlining jit...

Not every java web app needs to be this bloated. It's possible (even practical) to build robust, database driven web apps/web services without spring/hibernate and with far shallower stacktraces.

Would love to see more visualizations of other frameworks in their respective languages. I wouldn't be surprised if they were just as big.

Not sure it is any smaller today. Some additional layers not seen are the DTO transformations (not seen because they don't become part of the stack when it's hitting JDBC) but two more major subsystems. Many IDEs now automatically filter out these well known stacks from view.

Personally moving from a mostly Java background to entirely typescript on the backend and front-end.

This looks much worse than it actually is. You could implement it in a much flatter way.

  function HandleRequest(request : Request) : Response
  {
    LogRequest(request)
  
    CheckAuthentication(request)
    CheckAuthorization(request)
  
    var response = DispatchAndHandleRequest(request)
  
    LogResponse(response)
  
    return response
  }

This way you would have no deep stack traces and all would be fine. But only until you need to do some additional work somewhere right in the middle, say patch malformed requests between authorization and dispatch. With the above implementation you would be somewhat screwed, the best you could do would be reimplementing HandleRequest() with your additional step in the middle.

But with implementations like those show in the article you just have a list of steps with a common interface, each step does its work and then the next step gets called. If you need to do something new somewhere in the middle, you just add a new step to the list of steps in the right place and you are done, possibly simply by putting the class name of the new step in a configuration file.

  var steps =
  {
    new LogRequestStep(),
    new CheckAuthenticationStep(),
    new CheckAuthorizationStep(),

    // This stupid XYZ client always sends broken requests.
    new PatchMalformedRequestFromXyzStep(),

    new DispatchAndHandleRequestStep(),
    new LogResponseStep()
  }

  function HandleRequest(request : Request) : Response
  {
    var context = new Context(request)

    foreach (var step in steps)
    {
      step.Execute(context)
    }

    return context.Response
  }

This would still avoid deep stack traces because we are iterating over all the steps but note that with this implementation we would not really be able to abort processing the request somewhere in the middle, say if the authorization check failed, but we could fix this by adding a flag to the context and check it inside the loop after a step executed. But a more serious limitation is that every step only gets one chance to act, note for example that we have two separate steps for logging the request and the response.

Imagine we wanted to log the request duration, then we would need a step getting the current time at the beginning and another one getting the current time after the request was handled at the end. And the first step would have to somehow communicate the processing start time to the second one, possibly by storing it in the context. A much more elegant solution is to organize the list of steps as a linked list with all steps looking like this.

  function Execute(request : Request) : Response
  {
    PreprocessRequest(request)

    var response = GetNextStep().Execute(request)

    PostprocessResponse(response)

    return response
  }

This creates those deep stack traces but it also creates a huge amount of flexibility and extensibility. It surly looks crazy if you do not need it, but when you need it, it is really easy with this model.

OT, but anyone have similar stack traces that show call stacks or abstractions in other layers, down to transistors, up to user?

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

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.