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.
Jodd – The Unbearable Lightness of Java
21–30 of 239 posts
Re: Jodd – The Unbearable Lightness of Java
#22I 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...
Re: Jodd – The Unbearable Lightness of Java
#23To 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
#24Earlier 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?
Re: Jodd – The Unbearable Lightness of Java
#25I 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.
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
#26Earlier 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.
Re: Jodd – The Unbearable Lightness of Java
#27I 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.
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
#28why not: JsonParser().parse(json)
Re: Jodd – The Unbearable Lightness of Java
#29I 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…
Re: Jodd – The Unbearable Lightness of Java
#30Earlier 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…
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.