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

201–210 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#201

Post by eximius »

ragnese wrote: post #178
eximius wrote: 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…

I'd say that the only one of your listed solutions-in-other-languages that is actually a valid solution is deep argument passing. And I fail to see why it's a problem. If your FooService depends on a BarService, which depends on a BazService, and BazService needs a database connection, then that means your FooService really does also depend on a database connection. Hiding that information, to me, seems like a mistak…

Ultimately, I think thisnis going to come down to preference.

I would prefer not to have to fix 20 constructors.

It's tedious and time consuming. The intermediate classes that _do technically depend on FooService because BarService does_ - the intermediate classes don't care! It clutters the code everywhere else for minimal benefit.

Manually, you see all your dependencies just shy of main where the binary initializes them all and starts passing things down. In DI, you have a module file somewhere with them all.

Re: Jodd – The Unbearable Lightness of Java

#202

Post by pgwhalen »

bedobi wrote: post #79

This is great. Java BADLY needs to shed weight and verbosity and in general just catch up with the times. Having used not only traditional Java and Spring (including "modern" Spring boot) but also alternatives, like eg DropWizard, I MUCH prefer the alternatives. DropWizard in particular seems to me a more neutral collection of some of the best tools for each job, and it's both simple and easy. Spring is just Spring,…

Java’s verbosity/abstraction problem is unfortunately not due to the language or libraries at this point as much as it is the programmers - the hardest thing to change. You need only to look around this thread to see Java programmers who can’t imagine writing a useful application without a DI framework that supports runtime implementation swapping, or aspect oriented programming.

Re: Jodd – The Unbearable Lightness of Java

#203

Post by kaba0 »

ragnese wrote: post #193
kaba0 wrote: post #182

Earlier quoted context omitted.

I don’t think that it is any easier in other languages either — object serialization, conversion between language’s object/json/xml/etc, and database access with object relational mapping is just complex. You can make the trivial way trivial, but you have to expose the hard ways as well and that will not be pretty either way. For what it worth, java has a really high quality ecosystem for all these things - I would b…

> I don’t think that it is any easier in other languages either — object serialization, conversion between language’s object/json/xml/etc, and database access with object relational mapping is just complex. You can make the trivial way trivial, but you have to expose the hard ways as well and that will not be pretty either way. I agree that these things are just complex. But, what's interesting to me is that I fully…

Thanks for the non-flame-baity answer! Hopefully I wasn’t too emotional in my previous reply, because it unfortunately does happen from time to time.

Regarding Jackson and JPA the only thing I can tell about these is that their age shows, and they come from a domain and age where the (in my opinion, bad) POJO and Java Beans conventions originate. So I fully agree that things could be much better, and hopefully there will come a renaissance replacing these tools with modern java equivalents, that don’t rely on runtime magic as much, and will use the modern datetime APIs by default, etc. Serialization is especially in need of a huge revamp, hopefully records will make it much better.

Regarding ORMs, have you by chance tried JOOQ? You may prefer it over JPA.

Also, just a small note on Rust - I find it to be an excellent language, but I really don’t think it fights in the same domain as Java. Systems programming is fundamentally different. So writing a huge business application in Rust (or in C++, equivalently) is a suicide mission in my opinion — initial write time may indeed be low for an experienced Rust dev, but with the often changing client requirements that mandate quick changes touching everything, the low level details that leak into the high level view of the app will slow one down (now you also have to change the memory model because this lifetime has to be extended, etc). But I only mention that as an explanation for why Rust is not a replacement for the huge, ever-living business app domain (at least for me)

So all in all, I think that Java fights a good fight, it remains religiously backwards compatible which is painful at times, but is perhaps the biggest value there is; but it is improving with a huge pace with records, sealed classes (giving us algebraic data types), upcoming `with`ers will provide a good syntactic sugar for “modifying” immutable objects, and full-blown pattern matching is coming built on top of these. But the real deal happens under the hood, Loom will make blocking codes magically non-blocking and Valhalla tries to heal the rift between primitives and objects and will provide excellent performance boost. So the part I actually like and defend about Java is this one, not the historic baggage it comes with. But I also work on CRUD apps, and that’s not an exciting domain no matter what.

Re: Jodd – The Unbearable Lightness of Java

#204

Post by vips7L »

jupp0r wrote: post #70
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.

Dependency injection does not have to be dynamic, it can totally be done at compile time. Boost DI is an example: https://boost-ext.github.io/di/

There’s plenty of Java frameworks that are compile time too. Quarkus, Avaje Inject, etc all do their wiring at compile time.

Re: Jodd – The Unbearable Lightness of Java

#205

Post by yencabulator »

kaba0 wrote: post #198
yencabulator wrote: post #192

Earlier quoted context omitted.

So, COBOL? That's an argument that works in a historical moment of Java legacy, until it doesn't. Monzo is an example of a bank writing everything in Go.

Good luck with that for them.. Java is in the unique position of excellent performance (state of the art GC, very good JIT compiler) and observability with no-overhead real time options. Due to the language having multiple implementations of a standard and it being one of the top 3 biggest ecosystem, it is nothing like Cobol. You can say it is legacy for 3 decades to come, but it will not die. Hell, it improves with…

Now you seem to have switched the conversation of "Java projects tend to be overly complex" to "Java is great". Common talking point, and you have a lot of people who will agree with you, but pretty much unrelated to the topic.

Re: Jodd – The Unbearable Lightness of Java

#206

Post by [deleted] »

mslate wrote: post #92
geodel wrote: post #41

Earlier quoted context omitted.

> 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 develop…

Just to echo this is similar to my experience. Java development culture that I have known in the work place is extremely coddled by their frameworks. It is hard for them to open the terminal and execute their application JAR from the command line--only ever from the IDE. Oh wait--they need Tomcat/Apache & a few hours of dealing with classpath issues.

[deleted]

Re: Jodd – The Unbearable Lightness of Java

#207

Post by kaba0 »

yencabulator wrote: post #205
kaba0 wrote: post #198

Earlier quoted context omitted.

Good luck with that for them.. Java is in the unique position of excellent performance (state of the art GC, very good JIT compiler) and observability with no-overhead real time options. Due to the language having multiple implementations of a standard and it being one of the top 3 biggest ecosystem, it is nothing like Cobol. You can say it is legacy for 3 decades to come, but it will not die. Hell, it improves with…

Now you seem to have switched the conversation of "Java projects tend to be overly complex" to "Java is great". Common talking point, and you have a lot of people who will agree with you, but pretty much unrelated to the topic.

My original point was that abstractions are not evil, hell, without them we would only have calculators, not computers.

Go not having too high abstraction power, while can be an advantage (as per the creator, not my words, you can throw as many bad developers at a project as you want), but it is a disadvantage as well, because then you will have the logic in distributed places, copied verbatim etc, hindering maintainability, understanding the original intent, new dev onboarding, everything.

Re: Jodd – The Unbearable Lightness of Java

#208

Post by vips7L »

vbezhenar wrote: post #147
UncleOxidant wrote: post #45

Earlier quoted context omitted.

> it really feels like a renaissance for the language. So is this the 2nd or 3rd Java renaissance?

I'd say that first Java renaissance is Java 5 with generics. Second Java renaissance is Java 8 with lambdas. IMO third Java renaissance will be with re-introduction of green threads.

I’m actually looking forward to Valhalla more than Loom I think.

Re: Jodd – The Unbearable Lightness of Java

#209

Post by mmcdermott »

wtetzner wrote: post #51
throwaway1492 wrote: post #20

Earlier quoted context omitted.

This, it’s really exhausting to read this never ending wheel reinvention. Sure any one can use simpler non-spring frameworks, and other “non standard” frameworks and libraries for 1/10 or 1/100 of the functionality, and get 10-100x the bugs and much less or zero support. But we need netty! And then when you add thread pools, jdbc, logging, etc? Yep you’ve reimplemented spring. Just use spring, spend the time to learn…

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…

I've had similar experiences. A few years ago, I wrote a small service in plain Java, no frameworks as part of a quick change to improve performance. It worked and we all moved on. Later it was converted to Spring Boot and it slowed way down.

Re: Jodd – The Unbearable Lightness of Java

#210

Post by yencabulator »

kaba0 wrote: post #207
yencabulator wrote: post #205

Earlier quoted context omitted.

Now you seem to have switched the conversation of "Java projects tend to be overly complex" to "Java is great". Common talking point, and you have a lot of people who will agree with you, but pretty much unrelated to the topic.

My original point was that abstractions are not evil, hell, without them we would only have calculators, not computers. Go not having too high abstraction power, while can be an advantage (as per the creator, not my words, you can throw as many bad developers at a project as you want), but it is a disadvantage as well, because then you will have the logic in distributed places, copied verbatim etc, hindering maintain…

These words are bandied around a lot by people outside the Go community, while the people who end up actually using Go a lot tend to say it's the most readable code they've worked with in their lives. shrug
Post reply on HN