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

211–220 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#211

Post by jcelerier »

pgwhalen wrote: post #174
jcelerier wrote: post #126

Earlier quoted context omitted.

> I consider DI a valuable pattern, but I've never experienced anything close to this need. Literally every non-toy software I had to develop in my life required that lol

Do you seriously allow users to configure which logging framework is used through a UI? Perhaps I’m misunderstanding what you’re saying.

in my case it's more often which audio, gamepad or graphics backend but yes, I actually had the log backend configuration request once ! (wanted to choose to log stuff in text files or websockets depending on the case, for a GUI app ; there was an explicit requirement that the entire software could be configured and used with only a mouse, no keyboard so many configuration menus were needed)

Re: Jodd – The Unbearable Lightness of Java

#212

Post by bedobi »

bigbluedots wrote: post #166
bedobi wrote: post #158

Earlier quoted context omitted.

> @SpringBootTest Oh what do you know, yet another annotation... I'm literally looking at the docs for @SpringBootTest ``` @SpringBootTest public class SmokeTest { @Autowired private HomeController controller; @Test public void contextLoads() throws Exception { ... } } ``` This is case in point of what I'm saying - I highly doubt this actually spins up a full fledged app. + where is the controller coming from? It's n…

What do you recommend instead?

A good first framework to wane off Spring is DropWizard. But there are countless others and they all do more or less the same thing, except much better, and with far less complexity, than Spring.

Re: Jodd – The Unbearable Lightness of Java

#213

Post by lmm »

heurisko wrote: post #103
lmm wrote: post #57

Earlier quoted context omitted.

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 is not the same thing as Spring Spring Boot is an opinionated way to configure Spring applications. > recapitulating all of the mistakes of EJB Which mistakes is it repeating?

> Spring Boot is an opinionated way to configure Spring applications.

If by "configure" you mean "make arbitrary changes to the behaviour of". Spring Boot adds a bunch of spring-boot-specific stuff that can't be replicated in vanilla Spring and isn't supported for use outside Spring Boot (e.g. @ConditionalOnMissingBean and friends are explicitly not supposed to be used in non-boot Spring configurations). This is a long way away from just sugar for an ordinary Spring configuration.

> Which mistakes is it repeating?

- Huge and incomprehensible

- Components can refer to other components in ways that are completely invisible in the code

- No way to understand your application's behaviour by just looking at your code, because it can vary drastically depending on the things that are instantiated by the container at runtime. (In EJB this was container-provided services, in Spring Boot it's configurations that are automatically instantiated if they're present on the classpath, without the application ever referring to them at all)

- In practice applications depend on implementation details of the framework and cannot safely upgrade or migrate

Re: Jodd – The Unbearable Lightness of Java

#215

Post by bedobi »

pgwhalen wrote: post #202
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.

Agreed! I lost patience with the backwards Java community long ago, there's no arguing with them, they refuse to even consider trying anything other than what they're used to, so what's the point. Better to move on and leave them to it.

Re: Jodd – The Unbearable Lightness of Java

#216

Post by pgwhalen »

bedobi wrote: post #215
pgwhalen wrote: post #202

Earlier quoted context omitted.

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.

Agreed! I lost patience with the backwards Java community long ago, there's no arguing with them, they refuse to even consider trying anything other than what they're used to, so what's the point. Better to move on and leave them to it.

One thing that gives me hope is that the actual language designers have the right view on it, and I think are guiding the community in the right direction without explicitly condemning the way a lot of things are currently done (which would be a political nightmare).

For instance, records are a step away from mindless getters and setters - but rather than just add the syntactic sugar of properties, they introduced immutability as well.

Re: Jodd – The Unbearable Lightness of Java

#217

Post by stickfigure »

ragnese wrote: post #177
stickfigure wrote: post #98

Earlier quoted context omitted.

I did a fair bit of work in Go at Pivotal. I found Go anything but readable - a comical amount of boilerplate (especially around error handling), incredibly wordy constructs for simple tasks like making http requests, and the language is almost overtly hostile to functional programming (no generics!). I use Go as a "better C". Though I'm honestly disappointed with even that. My current company, we built an image proc…

> I did a fair bit of work in Go at Pivotal. I found Go anything but readable - a comical amount of boilerplate (especially around error handling), incredibly wordy constructs for simple tasks like making http requests, and the language is almost overtly hostile to functional programming (no generics!). Are you saying that Java is better about any of that?

Yes, absolutely. Java has had a competent implementation of generics since 2004 (Java 5) and really embraced functional programming in 2014 (Java 8). Any application of significance will require more LoC in Go than Java, hands down.

Just compare Java streams with Go container classes. Go's aren't typesafe (though that will hopefully change when generics are officially released) and almost every operation requires imperative code. And endless `if err != nil return err` every time you want to call a function - which actually destroys useful stack information.

I won't apologize for the crap Java code out there - but you can write crap in any language. Modern Java is capable of producing pretty, svelte code.

Re: Jodd – The Unbearable Lightness of Java

#218

Post by bedobi »

pgwhalen wrote: post #216
bedobi wrote: post #215

Earlier quoted context omitted.

Agreed! I lost patience with the backwards Java community long ago, there's no arguing with them, they refuse to even consider trying anything other than what they're used to, so what's the point. Better to move on and leave them to it.

One thing that gives me hope is that the actual language designers have the right view on it, and I think are guiding the community in the right direction without explicitly condemning the way a lot of things are currently done (which would be a political nightmare). For instance, records are a step away from mindless getters and setters - but rather than just add the syntactic sugar of properties, they introduced im…

For sure, it's great that people like Josh Bloch, Brian Goetz (and many others) have been very aware of and trying to address all the problems and endorse (and enforce) solutions to them (for decades at this point)

but as much as I hate to say it it feels like it's a bit too little too late :/

and there's still this bizarre situation where seemingly most of the Java community is still living in the 90s

oh well ¯\_(ツ)_/¯

Re: Jodd – The Unbearable Lightness of Java

#219

Post by int_19h »

eximius wrote: post #27
WatchDog wrote: post #15

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…

The solution in other languages is to use a DI framework written for them. Which one doesn't have any? In .NET, the basic DI interface (imports/exports etc) is even part the standard library as System.Composition.

Re: Jodd – The Unbearable Lightness of Java

#220

Post by ragnese »

eximius wrote: post #201
ragnese wrote: post #178

Earlier quoted context omitted.

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…

Definitely a preference thing- no doubt.

But thank you for responding anyway.

(As a clarification, in case it's needed: I obviously didn't LOVE it when I had to update 20 ctors after changing a somewhat fundamental "service" to need a new dep. My point was that, even as painful as that was, it wasn't that bad and it's usually much less bad than that.)

I guess the (philosophical) difference comes to this statement:

> The intermediate classes that _do technically depend on FooService because BarService does_ - the intermediate classes don't care!

I can definitely understand what you're saying there, but it's interesting to me that I don't see it that way. I think I'm just less pragmatic and more... "academic" (?) about how I read and understand my own code. If X depends on Y and Y depends on Z, I'm comfortable with X explicitly depending on Z because I imagine "inlining" Y's functionality in X. Either that or you turn Y into an interface and then X only depends on IY. But, my brain just likes the explicit continuity I guess.

Cheers!

Post reply on HN