Live data from Hacker News

Jodd – The Unbearable Lightness of Java

jodd.org

21–30 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#21

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.

Agreed. Stuff like this feels like magic for magic’s sake, and as someone who has had to operate services that use these DI frameworks, they are a big pain.

What does “operate” mean in this context? I’m generally curious why one should consider this comment to be anything other than low effort flame bait?

Re: Jodd – The Unbearable Lightness of Java

#22
post #5

I wonder if someone can recommend a lightweight http server library? I like Javalin but it's based on Jetty which is a fully JavaEE compliant framework and includes support for things like OSGI which I don't need. With the whole Log4j situation, I'm re-evaluating some the libraries I've previously relied on.

If you have Java 11+ I presume you can't get any simpler than a standard library module: https://docs.oracle.com/en/java/javase/17/docs/api/jdk.https...

This comes from way before SE 11. I was using it in 7. The doc says it comes from 6. https://docs.oracle.com/javase/7/docs/jre/api/net/httpserver...

Re: Jodd – The Unbearable Lightness of Java

#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/MoserMichael/ls-annotations

It's a decompiler that is listing all annotations, so it becomes easier to grep a text file in order to detect the dependencies between annotations.

it is using the asm library https://asm.ow2.io/ to inspect the bytecode files, so as to extract the class signature, along with the reference and declaration of annotations included in a classpath, or class files included within a directory structure. A limitation/feature is, that it is inspecting already compiled bytecode files.

Re: Jodd – The Unbearable Lightness of Java

#24

Earlier quoted context omitted.

Agreed. Stuff like this feels like magic for magic’s sake, and as someone who has had to operate services that use these DI frameworks, they are a big pain.

What does “operate” mean in this context? I’m generally curious why one should consider this comment to be anything other than low effort flame bait?

Operate means “run the service”. If you need to configure things which aren’t well documented, it’s nice to be able to look at the code, but the DI frameworks obscure the code path. This is pretty straightforward; no idea why this would seem like flame bait—I didn’t even realize this was something people held deep emotional attachments to.

Re: Jodd – The Unbearable Lightness of Java

#25

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.

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 IDE/language tooling, rather than some magical library's way of doing it? You can just find the calls to a constructor and look at the arguments.

My experience is based on my bad experience with runtime DI libraries, and is definitely biased against them, but I must be missing something here.

Re: Jodd – The Unbearable Lightness of Java

#26
post #10

Earlier quoted context omitted.

EDIT - it seems maybe I was wrong here Netty copies the response body when sending to each client, so it's not as lightweight as I've found. For streaming large response bodies, it does not work well. I haven't found a good Java alternative yet (probably will switch to C++ and uWS...)

Netty core is about as close to the metal as networking gets on the JVM. It's abstractions are built over a zero-copy capable byte buffer, and there is generally a lot of care taken to avoid copying where possible. I haven't used the websocket codec, but I'm sure the maintainers would welcome a patch that removes unnecessary copying.

[deleted]

Re: Jodd – The Unbearable Lightness of Java

#27

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.

I think there are a lot of Java developers, that have just never worked without a DI framework, and just don't have a grasp on just how simple it can be to write code without one.

As someone who hated Java, used it for a few years, and now occasionally misses it...

I only miss DI. I miss being able to say "this system depends on these external things" and having a consistent, convenient way of sharing/swapping/testing those components and dependencies.

The solution in other languages? Unstructured globals, deep argument passing, or monkey patching with mocks?!

Yea, I can write simpler code without DI... By ignoring a bunch of stuff.

Re: Jodd – The Unbearable Lightness of Java

#29

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

Re: Jodd – The Unbearable Lightness of Java

#30
post #27

Earlier quoted context omitted.

I think there are a lot of Java developers, that have just never worked without a DI framework, and just don't have a grasp on just how simple it can be to write code without one.

As someone who hated Java, used it for a few years, and now occasionally misses it... I only miss DI. I miss being able to say "this system depends on these external things" and having a consistent, convenient way of sharing/swapping/testing those components and dependencies. The solution in other languages? Unstructured globals, deep argument passing, or monkey patching with mocks?! Yea, I can write simpler code wit…

You can do DI without a framework.

If you write classes with final fields, with a constrcutor that takes the class' dependencies,and don't use static fields to hold mutable data.

You are doing DI. Just call `new` yourself, instead of having the framework do it for you.

Post reply on HN