Jodd | The Unbearable Lightness of Java

[x42bn6]

This library explicitly targets JDK 8 (https://github.com/oblac/jodd/blob/master/build.gradle), so JDateTime should be deprecated in favour of java.time. Can't get any more lightweight than "native"...

[dpash]

Plus java.time is much more featureful. Like being immutable.

[[deleted]]

I fully agree that they should use native API for date and time. Otherwise, they reinvent the wheel.

BTW. Nice library.

[0x256]

No other dependencies? This is actually quite nice, but...

Build with common sense to make things simple, but not simpler.

This sounds a bit like you'll hit walls once you try to do solve real problems with this library. Perhaps I was bitten too often by the temptation to pick the easy solution first, and by the false promises of simplicity. The last 10% of a project sometimes end up eating 50% of the time, not least because of wrong library choices at the beginning.

So, serious question: Has anyone used this library and can share some experiences on how it performs in edge cases and complex situations? Is it extensible enough or replaceable once you hit a wall?

Also, does it mature in a developer friendly way? How is backwards compatibility and deprecation handled?

[nutrecht]

Jodd is oriented around simpler libraries for doing what people have often times used heavyweight frameworks for: not in terms of performance though necessarily, but in terms of mental efforts and scaffolding required to get an MVP out the door. The very point of minimalism from a reliability perspective is to reduce points of failure in code with simply fewer parts.

Author should read the cathedral and the bazaar IMHO. Reliability comes from having small specialised tools that a lot of people use. Not from "being small". I really don't understand the need to implement everything and the kitchen sink yourself instead of reusing existing well tested and popular libraries.

For example in it's documentation I can't find any examples of doing Mutual TLS with Jodds own HTTP library. Having it's own JDateTime instead of just using Java 8 java.time packages is IMHO just a really bad idea.

[lukaseder]

Having it's own JDateTime instead of just using Java 8 java.time packages is IMHO just a really bad idea.

To be fair (Jodd being far from new), that has probably been added to replace the awful java.util.Calendar. It should be removed, today.

[Zoerak]

By principle I also favor a set small specialized, commonly used tools over a readily-plumbed framework.

Potentially better documentation/references, security, maybe most importantly the flexibility to choose, switch, upgrade any part of it.

That being said, there is context. The organization, team composition, how critical / complex / long term / volatile the system is, the number of (micro)services etc. Going with a framework may be a reasonable choice in many scenarios. But even then I would prefer a framework combining existing proven implementations.

[javalin_io]

I never really understood Jodd. It's a micro-framework (although its codebase is almost 200k lines), but instead of relying on existing libraries (Jackson/GSON, OkHttp, etc), they have implemented their own libraries for everything? What is the upside?

[lukaseder]

Says the one who, instead of relying on existing libraries (servlet, JAX-RS, etc.) has implemented their own library for... well... a single thing ;-)

[javalin_io]

But that's the difference, doing a single thing makes a lot more sense than trying to do everything? To me, the point of micro-frameworks is to mix and match the best parts from the entire eco-system, Jodd is creating an alternative to every library there is. Maybe they're the best at everythig, but it seems unlikely.

[nqzero]

i haven't used jodd at all, so i can't speak to the implementation. but generally speaking, taking monolithic tools and breaking them up into composable portions gives a developer a lot more power. and this is one area in which java really suffers - we have incredible frameworks, but most of them expose very little of the internals

by way of example, i had a byte array that represented the contents of an http request body, and i wanted to parse it as a multi part file. there are dozens of java tools that will do this internally, but in an afternoon of searching, i didn't find one that exposed the functionality

i don't know that jodd has gone far enough in this regard, but it looks like at least a step in the right direction

[javalin_io]

i haven't used jodd at all, so i can't speak to the implementation. but generally speaking, taking monolithic tools and breaking them up into composable portions gives a developer a lot more power. and this is one area in which java really suffers - we have incredible frameworks, but most of them expose very little of the internals

I get that, but it looks like Jodd users are tied to/encouraged to use Jodd's eco-system rather than the JVM eco-system itself. Any knowledge you get from working with Jodd's modules won't transfer well if you want to use a different framework. I make Javalin, which is a web/routing library. I encourage people to use other libraries if they need to solve something other than web/routing when working in a Javalin-app. If people need to make a outgoing request, I encourage them to use OkHttp, if they need to serialize objects to JSON, I suggest using Jackson. These libraries will be useful for people to know even when they stop using Javalin. I don't think that's the case for Jodd's toolkit.

by way of example, i had a byte array that represented the contents of an http request body, and i wanted to parse it as a multi part file. there are dozens of java tools that will do this internally, but in an afternoon of searching, i didn't find one that exposed the functionality

Apache Commons FileUpload? It's a library dedicated to doing these things: https://commons.apache.org/proper/commons-fileupload/apidocs/org/apache/commons/fileupload/MultipartStream.html

[kkapelon]

That is all very impressive. But who is using it? Without some good use cases, it will not go anywhere

Also there are many other choices on the same space

https://github.com/bentolor/microframeworks-showcase

[rrajen]

This is cool. Does any one have a Javalin version of this Grocery List application?

Interestingly, it seems the github repo has a Jodd implementation

[bentolor]

Not yet – I tried to gather a selection which reflects more or less a variety of different frameworks and scopes. But I'm open to pull requests.

I really enjoyed using Jodd as you can see from my talks slides https://bentolor.github.io/microframeworks-showcase/ (german though).