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

81–90 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#81

Post by bedobi »

geodel wrote: post #29
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…

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…

I'm in an enterprise and have successfully lobbied people to use anything other than Spring. Such organizations and teams while rare do exist so don't give up hope! (or just move to a more progressive org)

Re: Jodd – The Unbearable Lightness of Java

#82

Post by yCombLinks »

dehrmann wrote: post #38

A lot of this looks like functionality offered by other, more popular libraries. Jodd JSON looks functionally (and syntactically!) similar to Jackson, but Jackson has a lot more users: https://mvnrepository.com/artifact/org.jodd/jodd-json https://mvnrepository.com/artifact/com.fasterxml.jackson.cor...

Literally every common enterprise problem has a java library over a decade old. Jodd seems to be aiming to be lightweight and fast, not solve new problems necessarily.

Re: Jodd – The Unbearable Lightness of Java

#83

Post by specialist »

geodel wrote: post #61
wtetzner wrote: post #51

Earlier quoted context omitted.

As someone who dealt with a ton of Spring in the recent past, I completely disagree. First of all, thread pools are part of the standard library. Spring adds little to no value on top of it. Second, reinventing some of that stuff is absolutely worthwhile, because Spring's library design/implementation is not very good. Finally, when I had the opportunity to start a new Java project, I opted to not use Spring. I final…

Well you are missing one of the great feature of Spring framework: Converting compile time errors in to runtime exceptions. Jokes apart you are absolutely right about non-spring based services. I did same using plain Java + embedded tomcat for some services. No cargo-cult like endless decorative packages and classes. Exactly same result as you observed. Less code, fast to start and vastly improved error management.

> Converting compile time errors in to runtime exceptions.

Heh. Stealing this. Short, sharp, undeniable.

I usually say something snarky like "Spring is an exception obfuscation framework" or "...flow of control obfuscation framework".

Re: Jodd – The Unbearable Lightness of Java

#84

Post by TedDoesntTalk »

lmm wrote: post #57
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…

Spring Boot is not the same thing as Spring, and is indeed recapitulating all of the mistakes of EJB (I guess it's been long enough that the new generation of developers doesn't know about the problems). You can still use vanilla Spring though.

Spring Boot has remoting like EJB did??

Re: Jodd – The Unbearable Lightness of Java

#85

Post by guelo »

WatchDog wrote: post #54
guelo wrote: post #48

Earlier quoted context omitted.

Is what you're thinking of equivalent to deep argument passing? I've seen it done where you pass around a global Factory object that can provide dependencies. It's basically rudimentary DIY DI.

It's really very simple, no you don't need to pass around a factory object. You just have a class/classes that construct/wire all of your singleton objects and passes the required dependencies into their respective constructors as necessary. Here is a contrived example of what the wiring code might look like for a web app that uses a database. public static void main(String[] args) { MyConfig config = readConfigFile(…

Unless WebServer is the only class that needs dependencies you're either going to have to pass those dependecies repeatedly from class to class or you're going to have a global factory that provides the dependencies to everybody.

Re: Jodd – The Unbearable Lightness of Java

#86

Post by singron »

benhoyt wrote: post #25
stickfigure wrote: post #18

Earlier quoted context omitted.

Sure, and eventually you end up rebuilding an [ad hoc, informally-specified, bug-ridden, slow] DI container because: * Static references become a tangled mess, and you start wanting some structure around that. * You have to answer "how does ABC component get access to DEF?" for increasingly difficult combinations of ABC and DEF. Excepting Spring, pretty much all Java DI containers are lightweight.

Why do "static references become a tangled mess"? In my (limited) experience with runtime DI libraries (albeit in Go) they turn clear, IDE- and debugging-friendly code where the compiler tells you at compile time if you got it wrong ... into a hard-to-debug magical soup. With static, using-the-language dependency injection, isn't the question of "how does ABC component get access to DEF?" answerable with the normal I…

"static" in java DI can refer to setting global variables with singleton instances. E.g. java logging libraries usually do this so that you don't have to DI everywhere you want to log. In Go, some packages do this like flag and log. In Rails, this is so common that it replaces DI entirely, but I usually didn't feel like rails suffered from it.

I think what you are referring to is just manually doing DI. I.e. you defined constructors that accept dependencies and then call them all in a main function. I think this is tolerable if your codebase is structured for it. In typical java codebases, it gets ugly really fast. IMO this is caused by a general proliferation in the number of classes (due to class-per-file among other reasons), as well as a tendency to never use "static" DI. As an extreme example, if you needed to inject a logging dependency, then almost all code would need to be part of the DI graph. In a typical web backend, you might DI the sql connection pool. This causes basically all code to need DI since it either uses sql or has a transitive dependency that uses sql. IMO injecting the connection pool is not useful since it's not useful to write tests where you inject anything other than a real sql connection.

Re: Jodd – The Unbearable Lightness of Java

#87

Post by geodel »

specialist wrote: post #83
geodel wrote: post #61

Earlier quoted context omitted.

Well you are missing one of the great feature of Spring framework: Converting compile time errors in to runtime exceptions. Jokes apart you are absolutely right about non-spring based services. I did same using plain Java + embedded tomcat for some services. No cargo-cult like endless decorative packages and classes. Exactly same result as you observed. Less code, fast to start and vastly improved error management.

> Converting compile time errors in to runtime exceptions. Heh. Stealing this. Short, sharp, undeniable. I usually say something snarky like "Spring is an exception obfuscation framework" or "...flow of control obfuscation framework".

> Heh. Stealing this...

Yeah, please popularize it. In my case I am unable to make management see reason. If more devs become vocal about it make it a trend, it will be a good thing to happen.

Re: Jodd – The Unbearable Lightness of Java

#88

Post by benhoyt »

singron wrote: post #86
benhoyt wrote: post #25

Earlier quoted context omitted.

Why do "static references become a tangled mess"? In my (limited) experience with runtime DI libraries (albeit in Go) they turn clear, IDE- and debugging-friendly code where the compiler tells you at compile time if you got it wrong ... into a hard-to-debug magical soup. With static, using-the-language dependency injection, isn't the question of "how does ABC component get access to DEF?" answerable with the normal I…

"static" in java DI can refer to setting global variables with singleton instances. E.g. java logging libraries usually do this so that you don't have to DI everywhere you want to log. In Go, some packages do this like flag and log. In Rails, this is so common that it replaces DI entirely, but I usually didn't feel like rails suffered from it. I think what you are referring to is just manually doing DI. I.e. you defi…

Ah, that explains the confusion. Yeah, I didn't mean static as in the "static" keyword in Java / C++, but as in specified in the statically-typed code. Defining constructors that accept dependencies -- exactly. Ah yeah, I can see how Java exacerbates things here with the one-class-per-file rule -- ugh.

Go doesn't require one class (well, type or struct in Go) per file, and has much more flexibility in how you build packages as a result. I think it's a good thing that dependencies like the logger and the database are passed around explicitly: I've learned the hard way that "explicit is better than implicit" even when it means a bit more boilerplate.

Re: Jodd – The Unbearable Lightness of Java

#89

Post by benhoyt »

stickfigure wrote: post #36
benhoyt wrote: post #25

Earlier quoted context omitted.

Why do "static references become a tangled mess"? In my (limited) experience with runtime DI libraries (albeit in Go) they turn clear, IDE- and debugging-friendly code where the compiler tells you at compile time if you got it wrong ... into a hard-to-debug magical soup. With static, using-the-language dependency injection, isn't the question of "how does ABC component get access to DEF?" answerable with the normal I…

There are lots of reasons why static references are undesirable, but some of the more serious are: * Static dependencies make testing harder, no question about it. This is mediated in dynamic languages like Ruby by mocking statics. While you can actually do this in Java with Powermock, avoiding mocks entirely is even better. If you can't use a real object, use a fake that implements the relevant interface. * Statics…

Just a note: I overloaded (excuse the pun) the word "static": I didn't mean the "static" keyword, but "statically compiled/typed". So it doesn't mean singletons, just that you pass dependencies as explicit arguments to constructors and functions.

Re: Jodd – The Unbearable Lightness of Java

#90

Post by dep_b »

hocuspocus wrote: post #6

I haven't really touched Java in a while but I don't get why you'd want a lightweight DI container . You can just build your object graph and pass dependencies manually if you want a lightweight approach, no? That's just the way people do it in most languages.

Not using Java but generally in OO languages I ended up passing forward dependencies in grouped and themed classes like LoginDependencies, InboxDependencies etcetera. Everything under an Interface so you just mock whatever you need. Never ran into serious issues.

Of course logging might be static but “true” dependencies like networking classes never are.

Post reply on HN