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

111–120 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#111

Post by kaba0 »

WatchDog wrote: post #30
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…

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.

Which is the standard way to do DI in Spring as well? It will be just called by reflection instead.

But frankly, how will you call that new if it depends on a class which is a singleton, another which has some more complicated scope so it may or may not have to be reused? DI is not only about calling new..

Re: Jodd – The Unbearable Lightness of Java

#112

Post by bedobi »

heurisko wrote: post #106
bedobi wrote: post #81

Earlier quoted context omitted.

I'm in an enterprise and have successfully lobbied people to use anything other than Spring. Such organizations and teams while rare do exist so don't give up hope! (or just move to a more progressive org)

> I'm in an enterprise and have successfully lobbied people to use anything other than Spring. I was in a team that used Spring Boot for a greenfield project. The documentation was great, there was tons of help of Stackoverflow (as it's Spring) and the consideration given to testing was first class. Deployment was also easy, as we just created a fat JAR. No application server necessary. It was a great place to work.

I have also been in multiple organizations where Spring was used, including "modern" Spring Boot and greenfield projects, and people who knew every nook and cranny of Spring.

I don't agree with any of the things you bring up.

Spring documentation is and has always been poor and the sheer volume of outdated documentation (let alone ways to do the same thing) makes it needlessly difficult to find an answer to any given question.

Differences between the real app and real http requests to the app, and using the Spring test application context and Spring HTTP tests, result in tests misleadingly passing when things are actually broken. (or vice versa)

This is different to eg DropWizard where you actually boot the app (no different to how it does in a real env ie no "test application context") and make real http requests to it. (not some watered down fake Spring HTTP test requests)

Ability to deploy a standalone jar without the need for an application server is hardly unique to Spring.

Add in the horribly, horribly ingrained, unidiomatic ways people use Spring (eg sprinkling field autowiring all over the place instead of instead of using constructor injection) etc etc and every codebase is quickly completely ruined vs if it had been implemented in literally any other framework.

But! Fortunately for you, the Java community has made their choice, and it's not going to change - Spring is the default and correct option, and anyone who uses any other framework is just stubborn and wrong.

Re: Jodd – The Unbearable Lightness of Java

#113

Post by kaba0 »

yencabulator wrote: post #56
stickfigure wrote: post #49

Earlier quoted context omitted.

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.

The trick is to not encourage that many things-that-create-things-that-create-things. That's a uniquely Java problem. https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

Why? With such a well-known framework like Spring, you will get the benefit of any Spring-developer knowing instantly the conventions (which is not true with your in-house conventions where I will have to hunt down where does this class come from, oh this ugly abstraction which is buggy as well), less code is less opportunity to introduce bugs, less thing to maintain. Annotations are basically just a declarative DSL for a significant chunk of your code base.

I really don’t see any cons, other than a slight learning curve (and yeah sure, “developers” that just bash keys will have trouble with understanding what does an annotation do and blindly copy-pasting them can be dangerous but they will also fk-up regular code as well..)

Re: Jodd – The Unbearable Lightness of Java

#114

Post by epse »

kaba0 wrote: post #108
geodel wrote: 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…

And in 99% of cases that little microservice will suddenly need thread pooling, logging, some more advanced db management or God help some random messaging service and you are back to re-implementing the myriad features of spring in a shittier way. It is not an accident that things like ruby on rails are popular. These are well-tested toolboxes with a solution for almost every conceivable problem. There are exception…

I don't think people have any issues with the fact that spring is batteries included. It seems to me (and this is my personal experience too) that the large amounts of abstraction and indirection through annotations makes the code very hard to parse. It makes it hard to create a mental graph of how it all works together

Re: Jodd – The Unbearable Lightness of Java

#115

Post by kaba0 »

yencabulator wrote: post #67
stickfigure wrote: post #66

Earlier quoted context omitted.

If you take the single responsibility principle even as much as half-seriously, the problem domain more or less decides which things will create which things. If your software platform can't support that, you get spaghetti mess when programmers inevitably build workarounds.

You know, you hear Java repeat things like that a lot, while Go programs just tend to stay simple and readable. It's either the culture or the language causing the problem. shrug

As mentioned, Go is not used for ENTERPRISE APP^TM — Java programs can really hold up under insane abstractions and complexity.

Also, Go has really poor abstracting capability, which may be good for small code bases where having abstractions is a detriment, but abstractions are the only way to handle complexity. If you have the logic spread out over many different parts (or God save us, copied code!), a new programmer will have much more trouble picking up what the hell is supposed to happen.

In the extreme case, compare reading assembly to a high level language. Sure, each instruction is trivial in the former case, but you have no idea what does the whole do.

Re: Jodd – The Unbearable Lightness of Java

#116

Post by kaba0 »

jeffffff wrote: post #64
eximius wrote: post #44

Earlier quoted context omitted.

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

by calling new yourself you get a sane stack trace when something is misconfigured. that alone is worth the tiny additional amount of code in my book.

How is that worthy? You pretty much only have to look at the topmost exception, or at worst the causing one. Whether it has 100 lines after or 3 doesn’t matter, not the slightest.

Re: Jodd – The Unbearable Lightness of Java

#117

Post by jillesvangurp »

hocuspocus wrote: post #6

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.

A good DI framework just saves you from having to spell out all the glue code; or at least minimize that. DIY dependency injection is indeed a useful skill to have with other languages. Unfortunately, it's not what a lot of people do with other languages because they simply don't know that it would help them.

Particularly in the javascript world there seem to be a lot of people struggling to write good, testable code mainly because they make the rookie mistake of not separating their glue code from their business logic. Basically they have bits of code that initialize whatever and they need to put it somewhere and it ends up in the wrong place and before you know it, it becomes impossible to isolate any functionality such that you can actually test it easily without booting up the entire application. Add global variables to the mix and you have basically an untestable mess.

I still use Spring (but very selectively). They've added multiple styles of doing DI over the years, which is confusing. The latest incarnation of that uses neither reflection nor annotations and is very similar to the type of code you'd write manually if you had the time to clean it up and make it nice to use. Another benefit is that it enables native compilation, which with the recent release of spring-native is now a thing people do. Spring is large and confusing but the DI part is actually pretty easy to use. If you've used Koin or Dagger on Android, it's similar to how that works.

Re: Jodd – The Unbearable Lightness of Java

#118

Post by kaba0 »

WatchDog wrote: post #76
erik_seaberg wrote: post #69

Earlier quoted context omitted.

How is it better to make a dev write out that plumbing and others reread it? I’m made of meat, so I want to automate everything we safely can.

Advantages: - Don't need to depend on a DI library, makes code more modular and portable. - Faster application initialization time. - Easy to navigate and understand relationships between classes, good IDE support. - Easier to break apart and test parts of the application. - Easy to understand, don't need to learn the intricacies of a complex DI framework. I'm not saying there is no place for DI frameworks, although…

> don’t need to learn

I know it is a nitpick, but I see this way more often than I should as a main reason to prefer alternatives.

Finding out what gets injected is not particularly hard, especially when only the basic capabilities of spring’s DI is used. In that case it will be almost always the single implementing class of the given type.

Re: Jodd – The Unbearable Lightness of Java

#120

Post by kaba0 »

pgwhalen wrote: post #42
jcelerier wrote: post #34

Earlier quoted context omitted.

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…

What happens with proxied classes? My ClassWithTransactions is actually a subclass of the written one auto-generated by Spring. I can’t inject a new instance of that manually.

And you may say that you don’t need Aspect Oriented programming, but the usual handling of transactions in many other languages without some meta-programming is.. to not handle transactions. Putting a single annotation over a method is imo a very elegant way to handle this needed functionality.

Post reply on HN