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

Jodd – The Unbearable Lightness of Java

jodd.org

Post reply on HN
Print view View original

161–170 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#161

Post by ajuc »

stickfigure wrote: post #66
yencabulator wrote: post #56

Earlier quoted context omitted.

The trick is to not encourage that many things-that-create-things-that-create-things. That's a uniquely Java problem. https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

If you take the single responsibility principle even as much as half-seriously, the problem domain more or less decides which things will create which things. If your software platform can't support that, you get spaghetti mess when programmers inevitably build workarounds.

When I debug a well written C/C++ code usually the callstack is about 10 levels deep.

When I debug a well written Java code usually the callstack is about 50 levels deep.

It's not because of the Single Responsibility Principle.

Re: Jodd – The Unbearable Lightness of Java

#162

Post by amarant »

epse wrote: post #114
kaba0 wrote: post #108

Earlier quoted context omitted.

And in 99% of cases that little microservice will suddenly need thread pooling, logging, some more advanced db management or God help some random messaging service and you are back to re-implementing the myriad features of spring in a shittier way. It is not an accident that things like ruby on rails are popular. These are well-tested toolboxes with a solution for almost every conceivable problem. There are exception…

I don't think people have any issues with the fact that spring is batteries included. It seems to me (and this is my personal experience too) that the large amounts of abstraction and indirection through annotations makes the code very hard to parse. It makes it hard to create a mental graph of how it all works together

My experience is that it's not only the usage of annotations, but the way Spring handles/implements those annotations which is confusing.

As an example, Micronaut[1] also uses annotations a lot, but their implementation is a lot easier to reason about, because there is less indirection with proxy objects and other weird stuff that Spring uses.

Micronaut does not implement nearly as many annotations as Spring though, which basically means less functionality pre-built. I'm not sure that's a bad thing, but it could be.

[1] https://micronaut.io/

Re: Jodd – The Unbearable Lightness of Java

#163

Post by [deleted] »

ajuc wrote: post #161
stickfigure wrote: post #66

Earlier quoted context omitted.

If you take the single responsibility principle even as much as half-seriously, the problem domain more or less decides which things will create which things. If your software platform can't support that, you get spaghetti mess when programmers inevitably build workarounds.

When I debug a well written C/C++ code usually the callstack is about 10 levels deep. When I debug a well written Java code usually the callstack is about 50 levels deep. It's not because of the Single Responsibility Principle.

[deleted]

Re: Jodd – The Unbearable Lightness of Java

#164

Post by cies »

MichaelMoser123 wrote: post #23

I remember the days, when the Spring framework was advertised as a lightweight alternative to Enterprise java beans (ejb); now Spring outgrew the pretence of being lightweight, don't know when that happened. A year and a half ago, i got back to work with java and spring boot, and i was overwhelmed by the prevalence of annotations in spring boot. To cope with all this, i wrote this little project: https://github.com/M…

Annotations are a band aid. They easily move what otherwise were compile time errors into runtime errors. The advantage of using them is that you have to write less (repetitive) code.

I prefer code without them. They add magic. I dont like magic in my code.

Re: Jodd – The Unbearable Lightness of Java

#165

Post by cies »

kaba0 wrote: post #108
geodel wrote: post #29

Earlier quoted context omitted.

Indeed. I have a dozen or so microservices supported by team. Most are SpringBoot a couple of them I wrote myself with plain java and embedded tomcat. Needless to say Springboot stuff is rather complicated for such a simple business functionality. Errors are indecipherable being swamped by thousand line framework exception trace. But being an "enterprise standard" framework all projects must be move to this turd of a…

And in 99% of cases that little microservice will suddenly need thread pooling, logging, some more advanced db management or God help some random messaging service and you are back to re-implementing the myriad features of spring in a shittier way. It is not an accident that things like ruby on rails are popular. These are well-tested toolboxes with a solution for almost every conceivable problem. There are exception…

> It is not an accident that things like ruby on rails are popular.

Now if we could have that without the magic (neither from annotations nor from open classes), and with strong type safety and proper sum types... That'd be great!

Re: Jodd – The Unbearable Lightness of Java

#166

Post by bigbluedots »

bedobi wrote: post #158
heurisko wrote: post #128

Earlier quoted context omitted.

> Spring documentation is and has always been poor and the sheer volume of outdated documentation Spring documentation is excellent. I had to learn Spring as a PHP developer, so I put the documentation onto a Kindle and read it. It's also versioned, so you don't need to read out of date versions: https://docs.spring.io/spring-framework/docs/ > This is different to eg DropWizard where you actually boot the app (no dif…

> @SpringBootTest Oh what do you know, yet another annotation... I'm literally looking at the docs for @SpringBootTest ``` @SpringBootTest public class SmokeTest { @Autowired private HomeController controller; @Test public void contextLoads() throws Exception { ... } } ``` This is case in point of what I'm saying - I highly doubt this actually spins up a full fledged app. + where is the controller coming from? It's n…

What do you recommend instead?

Re: Jodd – The Unbearable Lightness of Java

#167

Post by ragnese »

kaba0 wrote: post #138
stepbeek wrote: post #131

Earlier quoted context omitted.

I found the real challenge to be that it's very difficult - if not impossible - to determine how spring functions simply by reading code and using it. In simpler libraries or frameworks, I normally just read the source to understand how I should be using it. With Spring, I've had to spend a lot of time reading and re-reaading docs to understand what's going on. I think that this is sometimes a hard shift for develope…

I absolutely understand it, but I think the correct, although bit inconvenient approach is the one you mentioned — properly learning the framework either through docs or other materials. Way too many developers try to write spring (but also jpa and many other useful, but complex tool) by trial and error, which let’s be honest, not a good tactic even if one can easily inspect the source. (The recently posted microsoft…

You're, of course, right that you just need to study and learn a complex framework. Basically the same way that you learn a new programming language- they're all different and have different behaviors and idioms (pass-by-copy vs. pass-by-reference, etc).

However, there's another dimension here, and while it's not totally unique to Java, it's definitely present in larger magnitude in Java, in my experience. There are two parts:

1. None of these frameworks are 100% consistent. I haven't used Spring{,Boot} in years, but I can tell you that JPA/JDBC are full of little "surprises" and rough edges, like handling nullable database columns. If you are not careful with your annotations, you'll get a `0` value for your `Int` object field instead of the `null` that was in the database. You can then go for quite a while before you figure out that's what happened. Similarly, JacksonXML has all kinds of little gotchas when it comes to date-time types and timezones, primitives and null-ness, etc.

2. Most projects have more than one of these complex frameworks. See above. I listed JacksonXML and JPA/JDBC. Odds are that you have AT LEAST these three frameworks (including Spring) in your Java project, which means you have to study all three and learn all of their intricacies before being confident in the code you write. That's on top of learning how to write half-decent Java, which is hard enough with its type-erased generics, bug-prone null-handling, and very verbose class definition syntax. If it were just one thing, I'd be sympathetic and tell people to just RTFM. But, unless you plan on only writing Java code for the next decade+, I have come to believe that it's probably not worth it.

Re: Jodd – The Unbearable Lightness of Java

#168

Post by sitta »

Spring is certainly a divisive topic, and I think it's hard for people on different sides to fully understand each other's experiences.

I have used Spring for years. Yes, there are some things I don't like about it, for instances Spring Boots overeager auto configuration, but it provides an unparalleled level of flexibility and productivity. I have never encountered a behavior in Spring that I have not been able to read the source and figure out what's going on and then change the behavior to be what I want. Spring is absurdly flexible and you only need to use the parts that you want.

A few years ago, I decided to try an alternative and wrote an app in Vert.x with no Spring. It worked fine, but it was a hell of a lot more work than leveraging the Spring ecosystem. I later rewrote it using Boot, and it works better, is easier to understand, and uses less code.

Have you seen Spring Data JDBC? It's such a good idea that saves so much boilerplate and I'm not aware of anything else like it. It threads the needle between rolling your own SQL and descending into the hell of a full on ORM.

Anyway, the closets I can come to understanding why people hate Spring so much is to consider my own opinion of Rails. I don't like Ruby and I don't like Rails. I hate all of the magic and I don't want to learn it. But, I'm sure, like Spring, it's enormously productive if you do understand what it's doing and how to use it.

Re: Jodd – The Unbearable Lightness of Java

#169

Post by heurisko »

bedobi wrote: post #158
heurisko wrote: post #128

Earlier quoted context omitted.

> Spring documentation is and has always been poor and the sheer volume of outdated documentation Spring documentation is excellent. I had to learn Spring as a PHP developer, so I put the documentation onto a Kindle and read it. It's also versioned, so you don't need to read out of date versions: https://docs.spring.io/spring-framework/docs/ > This is different to eg DropWizard where you actually boot the app (no dif…

> @SpringBootTest Oh what do you know, yet another annotation... I'm literally looking at the docs for @SpringBootTest ``` @SpringBootTest public class SmokeTest { @Autowired private HomeController controller; @Test public void contextLoads() throws Exception { ... } } ``` This is case in point of what I'm saying - I highly doubt this actually spins up a full fledged app. + where is the controller coming from? It's n…

> Also, what does @SpringBootTest actually do? How does it work? What if I need to do ? Who knows! "Just add the annotation, it's easy!" (but not simple - it's extremely, and extremely needlessly, complex)

You can read the documentation to find out what every annotation does.

https://docs.spring.io/spring-boot/docs/current/reference/ht...

There are several different annotations that you can use to test each particular "slice" of your application, ranging from a fully embedded server, to just testing the controller layer without the embedded server, to just testing the data layer without controllers or servers.

Re: Jodd – The Unbearable Lightness of Java

#170

Post by ragnese »

cies wrote: post #164
MichaelMoser123 wrote: post #23

I remember the days, when the Spring framework was advertised as a lightweight alternative to Enterprise java beans (ejb); now Spring outgrew the pretence of being lightweight, don't know when that happened. A year and a half ago, i got back to work with java and spring boot, and i was overwhelmed by the prevalence of annotations in spring boot. To cope with all this, i wrote this little project: https://github.com/M…

Annotations are a band aid. They easily move what otherwise were compile time errors into runtime errors. The advantage of using them is that you have to write less (repetitive) code. I prefer code without them. They add magic. I dont like magic in my code.

I honestly think the big issue here is using Java for these use-cases. I know that sounds flame-baity, but I'm being sincere.

Java is a very primitive language. For the vast majority of its life, it's basically been C + basic classes + garbage collection.

As a result, it's very verbose, which is totally fine for a low-level language. But, when building large, high-level, business apps, it's just a weird fit. I think that's why we see all of these annotation-heavy band-aids on top of Java (Lombok, Spring, JPA, etc)- it's because Java is actually not the right tool for the job, but instead of migrating (or inventing) a better tool, we just sunken-cost-fallacy ourselves to death.

Post reply on HN