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 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 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

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.

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

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

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
  }

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
  }

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

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).

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.

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.