23 ms·

Jodd – The Unbearable Lightness of Java

177 points by datalist 5y ago

adrianlmm 5y ago
>Book book2 = new JsonParser().parse(json, Book.class); why not: JsonParser().parse<Book>(json)
- vturner 5y ago
  JsonParser() is Scala syntax. Not sure how you'd accomplish that in Java and as for parse<Book> Java's generics are erased at compile time.
  - kaba0 5y ago
    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.
- chii 5y ago
  the `<Book>` generic type doesn't translate to anything at run time, so you cannot actually parse the json out as a book class, unless you already knew it was going to be a Book. The parse() method cannot be generic over all possible inputs as is - unless the user also pass in the `Book.class` parameter!
  - vbezhenar 5y ago
    You can use something like `new JsonParser<Book>(){}.parse(json)` Not saying that's a good idea, though.
- dehrmann 5y ago
  Type erasure.
hocuspocus 5y ago
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.
- throwaway894345 5y ago
  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.
  - throwaway1492 5y ago
    What does “operate” mean in this context? I’m generally curious why one should consider this comment to be anything other than low effort flame bait?
    - throwaway894345 5y ago
      Operate means “run the service”. If you need to configure things which aren’t well documented, it’s nice to be able to look at the code, but the DI frameworks obscure the code path. This is pretty straightforward; no idea why this would seem like flame bait—I didn’t even realize this was something people held deep emotional attachments to.
  - kaba0 5y ago
    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.
    - deleted 5y ago
      [deleted]
    - throwaway894345 5y ago
      I read all of the documentation for the service that I operate--per my other comment (https://news.ycombinator.com/item?id=29973282 https://news.ycombinator.com/item?id=29973282), often times things aren't well-documented and it's crucial to be able to look at the source code to figure out what something does (e.g., how is a configuration parameter used? what are its valid permutations?); however, when the source code is obscured by gratuitous complexity then it imposes a high cost on the user and in the case of DI frameworks, that gratuitous complexity comes with no discernible benefit (a car offers me something of value to justify its learning curve). Personally I'm of the opinion that a person shouldn't have to be a seasoned Java developer to use so many tools that are implemented in Java (or any other language, for that matter).
Zababa 5y ago
Looks nice, and reminds me of the ecosystem around Quarkus. I have two questions: 1) Is this compatible with GraalVM? I'm mostly asking this out of curiosity. 2) Is it using "modern" Java features? Records, pattern matching, optionals.
kitd 5y ago
Looks good. Is there a "Getting Started" guide or a list of examples anywhere? I'm on mobile so may have missed them. All I could see were links to the separate component docs.
- ivanche 5y ago
  It seems every project has its own documentation (powered by GitBook), for example https://lagarto.jodd.org/ https://lagarto.jodd.org/, https://http.jodd.org/ https://http.jodd.org/ etc.
mooreds 5y ago
Past discussions: https://news.ycombinator.com/item?id=9278704 https://news.ycombinator.com/item?id=9278704 (2015) https://news.ycombinator.com/item?id=20063945 https://news.ycombinator.com/item?id=20063945 (2019)
- dang 5y ago
  Thanks! Macroexpanded: The Unbearable Lightness of Java - https://news.ycombinator.com/item?id=20063945 https://news.ycombinator.com/item?id=20063945 - May 2019 (6 comments) Jodd – The Unbearable Lightness of Java - https://news.ycombinator.com/item?id=9278704 https://news.ycombinator.com/item?id=9278704 - March 2015 (108 comments) Java lightweight framework - jodd - https://news.ycombinator.com/item?id=4084498 https://news.ycombinator.com/item?id=4084498 - June 2012 (33 comments)
spuz 5y ago
I wonder if someone can recommend a lightweight http server library? I like Javalin but it's based on Jetty which is a fully JavaEE compliant framework and includes support for things like OSGI which I don't need. With the whole Log4j situation, I'm re-evaluating some the libraries I've previously relied on.
- mooreds 5y ago
  We looked around since we wanted to move off Tomcat and decided on Netty: https://netty.io/ https://netty.io/ I'm not on the engineering team so can't speak to the cost/benefit, but it seems to have been a pretty successful transition.
  - winrid 5y ago
    EDIT - it seems maybe I was wrong here Netty copies the response body when sending to each client, so it's not as lightweight as I've found. For streaming large response bodies, it does not work well. I haven't found a good Java alternative yet (probably will switch to C++ and uWS...)
    - WatchDog 5y ago
      Netty core is about as close to the metal as networking gets on the JVM. It's abstractions are built over a zero-copy capable byte buffer, and there is generally a lot of care taken to avoid copying where possible. I haven't used the websocket codec, but I'm sure the maintainers would welcome a patch that removes unnecessary copying.
      - deleted 5y ago
        [deleted]
      - winrid 5y ago
        Here's what I was thinking of, under "Vert.x Memory Usage": https://www.tikalk.com/posts/2018/04/30/vertx-memory-usage-with-intensive-network/ https://www.tikalk.com/posts/2018/04/30/vertx-memory-usage-w... Quote: "But how does Netty do things so fast ? One of the reasons is that it is using native memory pool to store network buffers. If you did some file reading or network action with Vert.x you probably used io.vertx.core.buffer.Buffer class. This class is actually a wrapper around Netty io.netty.buffer.ByteBuf class. Why am I telling you all this ? Let assume that you have a service where clients are downloading 20Mbyte files. Netty will have to allocate at least 20Mbyte for every connected client." Although this may be an issue with how Vert.x is using Netty. I have to dig into it more.
icatch17 5y ago
ferdowsi 5y ago
I really like the Go-like simplicity of these libraries, without the cursed architecture astronomy from the 2000s. In general it's interesting times for Java. With all of language improvements from Kotlin/Scala, and upcoming Go-like concurrency it really feels like a renaissance for the language.
- UncleOxidant 5y ago
  > it really feels like a renaissance for the language. So is this the 2nd or 3rd Java renaissance?
  - vbezhenar 5y ago
    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.
    - vips7L 5y ago
      I’m actually looking forward to Valhalla more than Loom I think.
- lopatin 5y ago
  "upcoming Go-like concurrency" can you elaborate on this? Java will have CSP at the language level? I find it hard to believe.
  - erik_seaberg 5y ago
    Project Loom’s virtual threads (without dedicated OS threads and stacks), which will hopefully relieve devs from manually doing a CPS transform of procedural code into chains of futures for thread pool workers to complete.
MichaelMoser123 5y ago
I remember the days, when the Spring framework was advertised as a lightweight alternative to Enterprise java beans (ejb); now Spring outgrew the pretence of being lightweight, don't know when that happened. A year and a half ago, i got back to work with java and spring boot, and i was overwhelmed by the prevalence of annotations in spring boot. To cope with all this, i wrote this little project: https://github.com/MoserMichael/ls-annotations https://github.com/MoserMichael/ls-annotations It's a decompiler that is listing all annotations, so it becomes easier to grep a text file in order to detect the dependencies between annotations. it is using the asm library https://asm.ow2.io/ https://asm.ow2.io/ to inspect the bytecode files, so as to extract the class signature, along with the reference and declaration of annotations included in a classpath, or class files included within a directory structure. A limitation/feature is, that it is inspecting already compiled bytecode files.
- geodel 5y ago
  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 framework.
  - MichaelMoser123 5y ago
    Another big difficulty is the handling of depedencies, as spring boot is bringing in gprc, jpa, jdbc and countless other libraries. One really needs a dedicated team to figure out all these issues!
    - geodel 5y ago
      Very true! But management is sold on "best practices" from VMWare suits. So any practical difficulty is just an excuse for not learning the latest, Next generation technologies.
    - 5y ago
dehrmann 5y ago
A lot of this looks like functionality offered by other, more popular libraries. Jodd JSON looks functionally (and syntactically!) similar to Jackson, but Jackson has a lot more users: https://mvnrepository.com/artifact/org.jodd/jodd-json https://mvnrepository.com/artifact/org.jodd/jodd-json https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-core https://mvnrepository.com/artifact/com.fasterxml.jackson.cor...
- yCombLinks 5y ago
  Literally every common enterprise problem has a java library over a decade old. Jodd seems to be aiming to be lightweight and fast, not solve new problems necessarily.
rammy1234 5y ago
Nothing can be light forever unless it is opinionated
gautamdivgi 5y ago
I have used https://sparkjava.com/ https://sparkjava.com/ when I still did Java some years back. It was as thin as they come and a real joy to get started and going.
bedobi 5y ago
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, Spring and more Spring, and while it's "easy", it's not simple- there's a lot of magic. I'm glad to finally be in a team where people are open minded enough to look outside the Spring bubble. TBH these days, we don't even use Java anymore, we use Kotlin + Arrow which is amazing.
- pgwhalen 5y ago
  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.
  - bedobi 5y ago
    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.
    - pgwhalen 5y ago
      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.
      - 5y ago
oaiey 5y ago
Speaking of lightness: Is it just me, or is the Java folder-per-namespace thingy a huge turn-down when it comes to lightness?
- kaba0 5y ago
  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.
- vbezhenar 5y ago
  You're not forced to use packages, there's anonymous package for simple small apps.
sorokod 5y ago
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 https://github.com/oblac/jodd-json
- ulrikrasmussen 5y ago
  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.
  - sorokod 5y ago
    "just a disaster waiting to happen" - if I was the maintainer, I would appreciate a test that demonstrates the failure scenario.
bayesian_horse 5y ago
Knock-Knock who's there? ... Long Pause ... Java!
ivanche 5y ago
Very impressive that all of this is maintained by a single person in their free time! His blog (only Serbian, sorry) is at https://oblac.rs/ https://oblac.rs/
sitta 5y ago
Spring is certainly a divisive topic, and I think it's hard for people on different sides to fully understand each other's experiences. I have used Spring for years. Yes, there are some things I don't like about it, for instances Spring Boots overeager auto configuration, but it provides an unparalleled level of flexibility and productivity. I have never encountered a behavior in Spring that I have not been able to read the source and figure out what's going on and then change the behavior to be what I want. Spring is absurdly flexible and you only need to use the parts that you want. A few years ago, I decided to try an alternative and wrote an app in Vert.x with no Spring. It worked fine, but it was a hell of a lot more work than leveraging the Spring ecosystem. I later rewrote it using Boot, and it works better, is easier to understand, and uses less code. Have you seen Spring Data JDBC? It's such a good idea that saves so much boilerplate and I'm not aware of anything else like it. It threads the needle between rolling your own SQL and descending into the hell of a full on ORM. Anyway, the closets I can come to understanding why people hate Spring so much is to consider my own opinion of Rails. I don't like Ruby and I don't like Rails. I hate all of the magic and I don't want to learn it. But, I'm sure, like Spring, it's enormously productive if you do understand what it's doing and how to use it.
- ragnese 5y ago
  I think you hit the nail on the head with your reflection on your attitude with respect to Ruby on Rails. From my point of view, Java is an anemic language, and the "cure" appears to be to introduce a bunch of annotation-magic frameworks (Spring + JacksonXML + Hibernate/JPA/JDBC/whatever + Lombok?) that each have their own magic and inconsistencies, to the point that your Java code is more of a configuration file than actual logic (which sounds great), but with the downside that you don't actually know where anything is actually implemented and have little idea about what can fail and where. As a "polyglot" dev, I just don't have the time or patience to learn all of the magic on top of the language itself. On the topic of Vert.x, it's definitely a different philosophy than Spring, as you experienced. I'm honestly not sure what domains Vert.x would be superior in, but it seems like it's way overkill for your typical mostly-crud backend app. Vert.x is less of a framework and more like a "build-your-own-framework" toolkit.
- newtwilly 5y ago
topkekutelep 5y ago
Is this the true Java framework we were promised Spring would be

177 points by datalist 5y ago

adrianlmm 5y ago

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

vturner 5y ago
JsonParser() is Scala syntax. Not sure how you'd accomplish that in Java and as for parse<Book> Java's generics are erased at compile time.
- kaba0 5y ago
  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.
chii 5y ago
the `<Book>` generic type doesn't translate to anything at run time, so you cannot actually parse the json out as a book class, unless you already knew it was going to be a Book. The parse() method cannot be generic over all possible inputs as is - unless the user also pass in the `Book.class` parameter!
- vbezhenar 5y ago
  You can use something like `new JsonParser<Book>(){}.parse(json)` Not saying that's a good idea, though.
dehrmann 5y ago
Type erasure.

hocuspocus 5y ago

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.

throwaway894345 5y ago
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.
- throwaway1492 5y ago
  What does “operate” mean in this context? I’m generally curious why one should consider this comment to be anything other than low effort flame bait?
  - throwaway894345 5y ago
    Operate means “run the service”. If you need to configure things which aren’t well documented, it’s nice to be able to look at the code, but the DI frameworks obscure the code path. This is pretty straightforward; no idea why this would seem like flame bait—I didn’t even realize this was something people held deep emotional attachments to.
- kaba0 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - throwaway894345 5y ago
    I read all of the documentation for the service that I operate--per my other comment (https://news.ycombinator.com/item?id=29973282 https://news.ycombinator.com/item?id=29973282), often times things aren't well-documented and it's crucial to be able to look at the source code to figure out what something does (e.g., how is a configuration parameter used? what are its valid permutations?); however, when the source code is obscured by gratuitous complexity then it imposes a high cost on the user and in the case of DI frameworks, that gratuitous complexity comes with no discernible benefit (a car offers me something of value to justify its learning curve). Personally I'm of the opinion that a person shouldn't have to be a seasoned Java developer to use so many tools that are implemented in Java (or any other language, for that matter).

Zababa 5y ago

Looks nice, and reminds me of the ecosystem around Quarkus. I have two questions: 1) Is this compatible with GraalVM? I'm mostly asking this out of curiosity. 2) Is it using "modern" Java features? Records, pattern matching, optionals.

kitd 5y ago

Looks good. Is there a "Getting Started" guide or a list of examples anywhere? I'm on mobile so may have missed them. All I could see were links to the separate component docs.

ivanche 5y ago
It seems every project has its own documentation (powered by GitBook), for example https://lagarto.jodd.org/ https://lagarto.jodd.org/, https://http.jodd.org/ https://http.jodd.org/ etc.

mooreds 5y ago

Past discussions: https://news.ycombinator.com/item?id=9278704 https://news.ycombinator.com/item?id=9278704 (2015) https://news.ycombinator.com/item?id=20063945 https://news.ycombinator.com/item?id=20063945 (2019)

dang 5y ago
Thanks! Macroexpanded: The Unbearable Lightness of Java - https://news.ycombinator.com/item?id=20063945 https://news.ycombinator.com/item?id=20063945 - May 2019 (6 comments) Jodd – The Unbearable Lightness of Java - https://news.ycombinator.com/item?id=9278704 https://news.ycombinator.com/item?id=9278704 - March 2015 (108 comments) Java lightweight framework - jodd - https://news.ycombinator.com/item?id=4084498 https://news.ycombinator.com/item?id=4084498 - June 2012 (33 comments)

spuz 5y ago

I wonder if someone can recommend a lightweight http server library? I like Javalin but it's based on Jetty which is a fully JavaEE compliant framework and includes support for things like OSGI which I don't need. With the whole Log4j situation, I'm re-evaluating some the libraries I've previously relied on.

mooreds 5y ago
We looked around since we wanted to move off Tomcat and decided on Netty: https://netty.io/ https://netty.io/ I'm not on the engineering team so can't speak to the cost/benefit, but it seems to have been a pretty successful transition.
- winrid 5y ago
  EDIT - it seems maybe I was wrong here Netty copies the response body when sending to each client, so it's not as lightweight as I've found. For streaming large response bodies, it does not work well. I haven't found a good Java alternative yet (probably will switch to C++ and uWS...)
  - WatchDog 5y ago
    Netty core is about as close to the metal as networking gets on the JVM. It's abstractions are built over a zero-copy capable byte buffer, and there is generally a lot of care taken to avoid copying where possible. I haven't used the websocket codec, but I'm sure the maintainers would welcome a patch that removes unnecessary copying.
    - deleted 5y ago
      [deleted]
    - winrid 5y ago
      Here's what I was thinking of, under "Vert.x Memory Usage": https://www.tikalk.com/posts/2018/04/30/vertx-memory-usage-with-intensive-network/ https://www.tikalk.com/posts/2018/04/30/vertx-memory-usage-w... Quote: "But how does Netty do things so fast ? One of the reasons is that it is using native memory pool to store network buffers. If you did some file reading or network action with Vert.x you probably used io.vertx.core.buffer.Buffer class. This class is actually a wrapper around Netty io.netty.buffer.ByteBuf class. Why am I telling you all this ? Let assume that you have a service where clients are downloading 20Mbyte files. Netty will have to allocate at least 20Mbyte for every connected client." Although this may be an issue with how Vert.x is using Netty. I have to dig into it more.

icatch17 5y ago

ferdowsi 5y ago

I really like the Go-like simplicity of these libraries, without the cursed architecture astronomy from the 2000s. In general it's interesting times for Java. With all of language improvements from Kotlin/Scala, and upcoming Go-like concurrency it really feels like a renaissance for the language.

UncleOxidant 5y ago
> it really feels like a renaissance for the language. So is this the 2nd or 3rd Java renaissance?
- vbezhenar 5y ago
  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.
  - vips7L 5y ago
    I’m actually looking forward to Valhalla more than Loom I think.
lopatin 5y ago
"upcoming Go-like concurrency" can you elaborate on this? Java will have CSP at the language level? I find it hard to believe.
- erik_seaberg 5y ago
  Project Loom’s virtual threads (without dedicated OS threads and stacks), which will hopefully relieve devs from manually doing a CPS transform of procedural code into chains of futures for thread pool workers to complete.

MichaelMoser123 5y ago

I remember the days, when the Spring framework was advertised as a lightweight alternative to Enterprise java beans (ejb); now Spring outgrew the pretence of being lightweight, don't know when that happened. A year and a half ago, i got back to work with java and spring boot, and i was overwhelmed by the prevalence of annotations in spring boot. To cope with all this, i wrote this little project: https://github.com/MoserMichael/ls-annotations https://github.com/MoserMichael/ls-annotations It's a decompiler that is listing all annotations, so it becomes easier to grep a text file in order to detect the dependencies between annotations. it is using the asm library https://asm.ow2.io/ https://asm.ow2.io/ to inspect the bytecode files, so as to extract the class signature, along with the reference and declaration of annotations included in a classpath, or class files included within a directory structure. A limitation/feature is, that it is inspecting already compiled bytecode files.

geodel 5y ago
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 framework.
- MichaelMoser123 5y ago
  Another big difficulty is the handling of depedencies, as spring boot is bringing in gprc, jpa, jdbc and countless other libraries. One really needs a dedicated team to figure out all these issues!
  - geodel 5y ago
    Very true! But management is sold on "best practices" from VMWare suits. So any practical difficulty is just an excuse for not learning the latest, Next generation technologies.
  - 5y ago

dehrmann 5y ago

A lot of this looks like functionality offered by other, more popular libraries. Jodd JSON looks functionally (and syntactically!) similar to Jackson, but Jackson has a lot more users: https://mvnrepository.com/artifact/org.jodd/jodd-json https://mvnrepository.com/artifact/org.jodd/jodd-json https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-core https://mvnrepository.com/artifact/com.fasterxml.jackson.cor...

yCombLinks 5y ago
Literally every common enterprise problem has a java library over a decade old. Jodd seems to be aiming to be lightweight and fast, not solve new problems necessarily.

rammy1234 5y ago

Nothing can be light forever unless it is opinionated

gautamdivgi 5y ago

I have used https://sparkjava.com/ https://sparkjava.com/ when I still did Java some years back. It was as thin as they come and a real joy to get started and going.

bedobi 5y ago

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, Spring and more Spring, and while it's "easy", it's not simple- there's a lot of magic. I'm glad to finally be in a team where people are open minded enough to look outside the Spring bubble. TBH these days, we don't even use Java anymore, we use Kotlin + Arrow which is amazing.

pgwhalen 5y ago
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.
- bedobi 5y ago
  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.
  - pgwhalen 5y ago
    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.
    - 5y ago

oaiey 5y ago

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

kaba0 5y ago
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.
vbezhenar 5y ago
You're not forced to use packages, there's anonymous package for simple small apps.

sorokod 5y ago

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 https://github.com/oblac/jodd-json

ulrikrasmussen 5y ago
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.
- sorokod 5y ago
  "just a disaster waiting to happen" - if I was the maintainer, I would appreciate a test that demonstrates the failure scenario.

bayesian_horse 5y ago

Knock-Knock who's there? ... Long Pause ... Java!

ivanche 5y ago

Very impressive that all of this is maintained by a single person in their free time! His blog (only Serbian, sorry) is at https://oblac.rs/ https://oblac.rs/

sitta 5y ago

Spring is certainly a divisive topic, and I think it's hard for people on different sides to fully understand each other's experiences. I have used Spring for years. Yes, there are some things I don't like about it, for instances Spring Boots overeager auto configuration, but it provides an unparalleled level of flexibility and productivity. I have never encountered a behavior in Spring that I have not been able to read the source and figure out what's going on and then change the behavior to be what I want. Spring is absurdly flexible and you only need to use the parts that you want. A few years ago, I decided to try an alternative and wrote an app in Vert.x with no Spring. It worked fine, but it was a hell of a lot more work than leveraging the Spring ecosystem. I later rewrote it using Boot, and it works better, is easier to understand, and uses less code. Have you seen Spring Data JDBC? It's such a good idea that saves so much boilerplate and I'm not aware of anything else like it. It threads the needle between rolling your own SQL and descending into the hell of a full on ORM. Anyway, the closets I can come to understanding why people hate Spring so much is to consider my own opinion of Rails. I don't like Ruby and I don't like Rails. I hate all of the magic and I don't want to learn it. But, I'm sure, like Spring, it's enormously productive if you do understand what it's doing and how to use it.

ragnese 5y ago
I think you hit the nail on the head with your reflection on your attitude with respect to Ruby on Rails. From my point of view, Java is an anemic language, and the "cure" appears to be to introduce a bunch of annotation-magic frameworks (Spring + JacksonXML + Hibernate/JPA/JDBC/whatever + Lombok?) that each have their own magic and inconsistencies, to the point that your Java code is more of a configuration file than actual logic (which sounds great), but with the downside that you don't actually know where anything is actually implemented and have little idea about what can fail and where. As a "polyglot" dev, I just don't have the time or patience to learn all of the magic on top of the language itself. On the topic of Vert.x, it's definitely a different philosophy than Spring, as you experienced. I'm honestly not sure what domains Vert.x would be superior in, but it seems like it's way overkill for your typical mostly-crud backend app. Vert.x is less of a framework and more like a "build-your-own-framework" toolkit.
newtwilly 5y ago

topkekutelep 5y ago

Is this the true Java framework we were promised Spring would be