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

121–130 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#121

Post by kaba0 »

geodel wrote: post #63
otterley wrote: post #58

Earlier quoted context omitted.

I’m a little confused. Why is creating a new Java object via “new” a sin? After all, it’s right there in Chapter 1 of any Java tutorial.

Just to clarify it is not my opinion. It is the groupthink of enterprise Java programing where reading Java tutorial itself would be obscure thing. Everything has to be looked from "framework" perspective. Framework says 'new' is bad so it is bad, dependency has to be constructor/setter injected by DI container so that's how it has to be.

No framework says `new` is bad. Feel free to grep for new in any framework application. But if one uses DI, than do use it for classes that ought to be injected. But inside methods of course one can and do use `new` many times over.

Re: Jodd – The Unbearable Lightness of Java

#122

Post by kaba0 »

overgard wrote: post #32
benhoyt wrote: 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…

It definitely has a benefit at scale. I’m not sure what application were you developing, but the amount of time a single instance was changed into an interface because the client wanted the n+234th little change in this special star constellation.. with DI you don’t have to write any more code, you can even use different implementations per environment (@Profile), so this is not accidental complexity in most cases. Sure, if you need a 100 lines web server that prints hello world it is an overkill, but the correct tool for the job..

Re: Jodd – The Unbearable Lightness of Java

#123

Post by kaba0 »

throwaway894345 wrote: post #8
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.

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.

How about learning about the tools you use beforehand?

You don’t sit into a car without any knowledge about it and blame it that it is magical.

Re: Jodd – The Unbearable Lightness of Java

#124

Post by kaba0 »

oaiey wrote: post #100

Speaking of lightness: Is it just me, or is the Java folder-per-namespace thingy a huge turn-down when it comes to lightness?

Why exactly? I think the two concept is very meaningfully merged. For simple programs you don’t need multiple namespaces so you have a single folder, for more complex one, tree hierarchies are good for both namespaces and folders.

Re: Jodd – The Unbearable Lightness of Java

#125

Post by kaba0 »

vturner wrote: post #33
adrianlmm wrote: post #28

>Book book2 = new JsonParser().parse(json, Book.class); why not: JsonParser().parse (json)

JsonParser() is Scala syntax. Not sure how you'd accomplish that in Java and as for parse Java's generics are erased at compile time.

Parent just missed the new keyword, and generics can work based on return type as well with the above syntax. It has nothing to do with erasure, we are at compile time.

Re: Jodd – The Unbearable Lightness of Java

#126

Post by jcelerier »

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…

> 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

Re: Jodd – The Unbearable Lightness of Java

#127

Post by ulrikrasmussen »

sorokod wrote: post #119

Looks nice and clean. It does seem to be maintained by a single person (at least the JSON subproject [1]) which will be a major turn off for adoption by an "enterprise" [1] https://github.com/oblac/jodd-json

First thoughts: the JSON subproject seems to be very unprincipled. The documentation documents general usage through a few examples, but it doesn't really give you a good idea of the semantics of the library. It appears to scan your objects using reflection for things that it determines to be fields (what are the criteria?), but for some reason does not serialize collection types by default because "This plays well with some 3rd party libraries (like ORM) where collections represent lazy relationships". The library is configured by modifying the state of global objects which is just a disaster waiting to happen.

Re: Jodd – The Unbearable Lightness of Java

#128

Post by heurisko »

bedobi wrote: post #112
heurisko wrote: post #106

Earlier quoted context omitted.

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

> Spring documentation is and has always been poor and the sheer volume of outdated documentation

Spring documentation is excellent. I had to learn Spring as a PHP developer, so I put the documentation onto a Kindle and read it. It's also versioned, so you don't need to read out of date versions:

https://docs.spring.io/spring-framework/docs/

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

Spring Boot allows you to write full application tests that will boot it up on a random port with the @SpringBootTest annotation, as is covered by the excellent documentation

https://spring.io/guides/gs/testing-web/

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

You can use whichever.

> anyone who uses any other framework is just stubborn and wrong.

Not at all. Spring Boot is just a great solution, that's all. It's got strong support from a company, lots of documentation and first class support for testing. It also allows you to easily swap out different underlying technology, eg. you can switch from Jetty or Tomcat, Liquibase to Flyway.

It's a disservice to persuade businesses to use smaller projects that don't have a comparable level of support, or flexibility.

Re: Jodd – The Unbearable Lightness of Java

#129

Post by tpxl »

heurisko wrote: post #102
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…

> Errors are indecipherable being swamped by thousand line framework exception trace Don't you just look at the top lines?

If you're lucky and the exception happens in your code directly. If not you're gonna have about 30 lines of interceptors and generators and whatnot before you get to your class. If you call ClassA::foo from ClassB::bar you'll get about 5 lines of interceptors between foo and bar in your stack trace. Debugging is also a nightmare in IntelliJ as step-into and step-out will go through all those interceptors.

Re: Jodd – The Unbearable Lightness of Java

#130

Post by touisteur »

epse wrote: post #114
kaba0 wrote: post #108

Earlier quoted context omitted.

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

Looks like an IDE / language server that unrolls the annotation generated code might be what's missing here. I like my abstractions to be hidden, but I like to be able to peek under the hood. That's one of the problems of C++ templates, sometimes I want to look at the expanded code.

The GNAT Ada compiler has an option to output a much-simplified code. Not compilable Ada, but very inspectable unrolled, expanded code. Makes for a great teaching tool. Aaaaaaah this generic mechanism does that!

Edit: link https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ug... look up -gnatG[=nn]... Good stuff.

Post reply on HN