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

51–60 of 63 posts

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

#51

Post by kazinator »

kuschku wrote: post #47
jimbokun wrote: post #28

Earlier quoted context omitted.

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.

> debugging is more complicated

Only if macros are second-class relative to built-in primitives in terms of debug support.

E.g. typical C compiler and debugger not knowing anything about C macros; if we make a loop construct entirely in a C LOOP(...) macro (spanning many lines of the source file), any error within the statements and expressions enclosed in LOOP will be reported against LOOP's line number. Moreover, we will not be able to step through those individual expressions in the debugger.

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

#52

Post by ceronman »

gerbilly wrote: post #48
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…

Thanks for sharing your experience. I have worked in both kind of projects. Both very big and heavy based in database access. One using Hibernate and one using plain SQL. We've had considerably more problems with the added complexity of Hibernate.

Hibernate does not save you from writing queries. You are still writing queries, just in a language different than SQL (e.g. JPA). It's an abstraction layer. The problem is that this abstraction is very leaky, so if you really want to write performant code with Hibernate you do need to understand how SQL and your database works. And if you really understand how it works, you end up realizing that the abstraction is kinda pointless because SQL is already a really fine abstraction over your database.

And if you need to scale, for example working with a replication setup with multiple db servers and having to deal with eventual consistency, then Hibernate really complicates things.

I think Hibernate is a good example of something that makes things easier at the beginning. At the cost of enormous complexity and difficulty in the long term.

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

#53

Post by ceronman »

le-mark wrote: post #49
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, authorizati…

Just to clarify, I am not criticizing the Java language. I'm criticising the use of excessive layered frameworks that increase complexity.

I like Java. It's simple and performant and has excellent tooling. I just don't like that sometimes I see a lot of incidental complexity in its ecosystem.

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

#54

Post by le-mark »

ceronman wrote: post #52
gerbilly wrote: post #48

Earlier quoted context omitted.

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

Thanks for sharing your experience. I have worked in both kind of projects. Both very big and heavy based in database access. One using Hibernate and one using plain SQL. We've had considerably more problems with the added complexity of Hibernate. Hibernate does not save you from writing queries. You are still writing queries, just in a language different than SQL (e.g. JPA). It's an abstraction layer. The problem is…

Let's be clear, this discussion applies to all ORM's not just hibernate. And yes, any team that adopts an ORM hammer and attempts to use it for all database access, is going to have a bad time. Use ORMs for CRUD, for anything else, use SQL. Hibernate actually makes this really easy.

Gavin King:

Well in fairness, we used to say it over and over again until we were blue in the face back when I was working on Hibernate. I even remember a number of times getting called into a client site where basically my only role was to give the team permission to use SQL for a problem that was clearly unsuited to ORM. To me it's just a no-brainer that if ORM isn't helping for some problem, then use something else. [1]

[1] https://www.reddit.com/r/programming/comments/2cnw8x/what_or...

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

#55

Post by klez »

topspin wrote: post #20
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 ?

You can get a long way with just Spark: https://github.com/perwendel/spark

Official website, for those wondering

http://sparkjava.com/

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

#56

Post by commandlinefan »

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…

What I can't fully get my head around is how defensive people get about things like Hibernate. I've tried it out, and it doesn't do much for me, but it doesn't really get in my way, either; I can work just as fast with Hibernate as I can with JDBC. I think part of the reason for that, though, is that I can work at either level; I can work out in my head what Hibernate is doing and work with it rather than against it. Somebody higher up retorted with, "why not just write your own web server?" Indeed, why not? I've done it for relatively simple REST-API type cases; as long as you don't need a lot of the more complex HTTP cases like continuation messages, caching, digest authentication and redirects, why not? It's nice to have everything under your control and it's almost definitely faster than any third-party solution that's going to have been written to deal with dozens of corner cases that aren't relevant to what you're doing.

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

#57

Post by commandlinefan »

asaph wrote: post #27

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.

It's possible, but in my experience, frowned upon for some reason.

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

#59

Post by gerbilly »

ceronman wrote: post #52
gerbilly wrote: post #48

Earlier quoted context omitted.

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

Thanks for sharing your experience. I have worked in both kind of projects. Both very big and heavy based in database access. One using Hibernate and one using plain SQL. We've had considerably more problems with the added complexity of Hibernate. Hibernate does not save you from writing queries. You are still writing queries, just in a language different than SQL (e.g. JPA). It's an abstraction layer. The problem is…

I think ORMs help the most when you have a lot of entities and you need to enable CRUD operations on them.

By all means you can use a combination of raw SQL and an ORM.

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

#60

Post by jimbokun »

kuschku wrote: post #47
jimbokun wrote: post #28

Earlier quoted context omitted.

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.

Lisp macros are still just code, code that executes at compile time instead of run time. Code generated in response to an Java annotation is only loosely associated with the annotation itself.

Annotation Oriented Programming arose out of Java's lack of powerful and general abstractions like first class functions. Lambda syntax for "single abstract method" interfaces has largely addressed that problem, but the use of annotations as the primary higher order abstraction mechanism remains in Spring and similar frameworks.

Lisp macros are part of the day to day tool set of every day Lisp programmers. They should be used with restraint, but can be debugged and analyzed with the same development tools and skill sets as other Lisp code. Java annotations belong much more firmly in the realm of framework authors. Writing Java applications often involves using annotations, but very rarely involves creating annotation and generating code or new behavior based on them.

Post reply on HN