Would love to see more visualizations of other frameworks in their respective languages. I wouldn't be surprised if they were just as big.
Java call stack – from HTTP upto JDBC as a picture (2006)
31–40 of 63 posts
Re: Java call stack – from HTTP upto JDBC as a picture (2006)
#32Like 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!
Re: Java call stack – from HTTP upto JDBC as a picture (2006)
#33Earlier 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 ?
I feel like I get pretty far with just https://javalin.io/ or http://sparkjava.com/. They're pretty similar but Javalin is being built by a maintainer of Spark and inherits many of the lessons learned from it.
These are basically thin wrappers on Jetty.
SQL: Mybatis or JDBI.
SQL Migrations: Flyway
JSON: Jackson, usually
Redis: Jedis
Re: Java call stack – from HTTP upto JDBC as a picture (2006)
#34I’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.
Re: Java call stack – from HTTP upto JDBC as a picture (2006)
#35This is beautiful. Working with ES2015 async await style promises on the server now... you don’t even get valid stacks.
Yep, a totally simple stack you can follow. Wouldn’t it be nice in the async world.
Re: Java call stack – from HTTP upto JDBC as a picture (2006)
#36Like 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…
"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. "
This isn't just a Java thing. I've seen plenty of TDD code written with other languages where there is basically the same thing (so the code can be "testable"), but also with heaps of redundant tests that just add dependencies and maintenance overhead without providing much value.
Re: Java call stack – from HTTP upto JDBC as a picture (2006)
#37Like 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!
I'm genuinely curious here: what would you propose as an alternative?
Re: Java call stack – from HTTP upto JDBC as a picture (2006)
#38Like 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!
It's called abstraction for a reason. Do you write your system code from scratch each time?
Re: Java call stack – from HTTP upto JDBC as a picture (2006)
#39Earlier quoted context omitted.
> 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!
It's called abstraction for a reason. Do you write your system code from scratch each time?
It's called abstraction, but at some point that becomes a euphemism for obfuscation.
Re: Java call stack – from HTTP upto JDBC as a picture (2006)
#40Like 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!
Spring Boot uses Java configuration. Using the default in memory database, you can create a crazy callstack like that by adding a single line to enable the transaction annotation.