Live data from Hacker News

Jodd – The Unbearable Lightness of Java

jodd.org

41–50 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#41
post #25

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…

> but I must be missing something here.

As a Java developer for all my career here is my take. In Java world there is this cultish cottage industry of "frameworks" for all sorts of work. Most Java developers are not expected to write plain code with JDK standard + some external libraries. Creating an object via "new Obj()" might cause programing universe to collapse so DI framework is must for enterprise Java developers.

If I were to tell at work that Go has inbuilt http server where we could implement a few handlers and have a basic service running. They would not be shocked that a http listener could be this simple but rather ask "Does Go bundles "weblogic/websphere/tomcat/netty" server with it or else how can it work? Same with testing, no understanding on how, what is to be tested but everything about "JUNIT/Mockito/Mockster/SpringUnit" or whatever.

There is no requirement for understanding basic concepts for testing, client/server, dependency, error management etc. So even basic functionalities are understood in terms of a branded framework. This is their main frame of reference.

Re: Jodd – The Unbearable Lightness of Java

#42

Earlier quoted context omitted.

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.

But how do you handle configuration then ? At some point you want a user-facing UI where the available features (which are generally classes) are listed and the user can choose the feature, say which log backend is enabled, without having to change code - that's the whole point of it. (And the most tedious code to write by hand - a complete waste of time)

> But how do you handle configuration then ?

In the main method, then you can pass the configured values wherever you need to when new-ing classes.

> At some point you want a user-facing UI where the available features (which are generally classes) are listed and the user can choose the feature, say which log backend is enabled, without having to change code - that's the whole point of it. (And the most tedious code to write by hand - a complete waste of time)

I consider DI a valuable pattern, but I've never experienced anything close to this need.

Re: Jodd – The Unbearable Lightness of Java

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

Another big difficulty is the handling of depedencies, as spring boot is bringing in gprc, jpa, jdbc and countless other libraries. One really needs a dedicated team to figure out all these issues!

Very true! But management is sold on "best practices" from VMWare suits. So any practical difficulty is just an excuse for not learning the latest, Next generation technologies.

Re: Jodd – The Unbearable Lightness of Java

#44
post #27

Earlier quoted context omitted.

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.

> Just call `new` yourself, instead of having the framework do it for you.

But at that point, why would I want to?

There are reasons I wouldn't want to, but there is no inherent value, to me, in manually calling new.

Re: Jodd – The Unbearable Lightness of Java

#45

I really like the Go-like simplicity of these libraries, without the cursed architecture astronomy from the 2000s. In general it's interesting times for Java. With all of language improvements from Kotlin/Scala, and upcoming Go-like concurrency it really feels like a renaissance for the language.

> it really feels like a renaissance for the language.

So is this the 2nd or 3rd Java renaissance?

Re: Jodd – The Unbearable Lightness of Java

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

In my experience most DI just interferes with being able to use the IDE to track down instantiations. Ive worked on these projects that basically have these fancy runtime things to answer questions that could be answered by the IDE if it werent so obscured. I remember one project we had a fancy thing to generate a graphviz graph, and it was like neat, but we could just use find all references if we just called new. T…

> I remember one project we had a fancy thing to generate a graphviz graph, and it was like neat, but we could just use find all references if we just called new.

Ha. Calling `new` would either be an absolute enterprise Java sin or an obscure aracana. Some people are quite proud of the fact of converting compile time errors to runtime exceptions. Because you know "best practices" and all.

Re: Jodd – The Unbearable Lightness of Java

#47

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…

the pernicious thing about spring is there appears to be 15 different ways to do the same thing. Everyone's idea and enhancement request was thrown in. Plus things got left in that should have been deprecated after better ideas came along or the java language improved to allow new techniques.

I'm glad someone is working on a light weight replacement to spring. I had some ideas on a light weight DI framework but never got around to it.

Re: Jodd – The Unbearable Lightness of Java

#48
post #27

Earlier quoted context omitted.

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.

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.

Re: Jodd – The Unbearable Lightness of Java

#49
post #27

Earlier quoted context omitted.

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.

When you have lots of things-that-create-things-that-create-things, this gets tedious really fast. DI frameworks exist because they result in a lot less code that does nothing but pass dependences along.

This reminds me of SQL/ORM debate. "Just use SQL!" Sure, until you get tired of typing the same SQL over and over and realize you can cut out most of that crap by adding an ORM.

Re: Jodd – The Unbearable Lightness of Java

#50
post #27

Earlier quoted context omitted.

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.

My company chose exactly this design for several of our microservices. It is now almost universally considered to have been a mistake.
Post reply on HN