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

31–40 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#31

Post by winrid »

WatchDog wrote: post #16
winrid wrote: post #10

Earlier quoted context omitted.

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

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.

Here's what I was thinking of, under "Vert.x Memory Usage": 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.

Re: Jodd – The Unbearable Lightness of Java

#32

Post by overgard »

benhoyt wrote: post #25
stickfigure wrote: post #18

Earlier quoted context omitted.

Sure, and eventually you end up rebuilding an [ad hoc, informally-specified, bug-ridden, slow] DI container because: * Static references become a tangled mess, and you start wanting some structure around that. * You have to answer "how does ABC component get access to DEF?" for increasingly difficult combinations of ABC and DEF. Excepting Spring, pretty much all Java DI containers are lightweight.

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.

The dumb thing is most of the time only one type is ever injected. Its all hypothetical flexibility which has a cost but no benefit

Re: Jodd – The Unbearable Lightness of Java

#34

Post by jcelerier »

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.

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)

Re: Jodd – The Unbearable Lightness of Java

#35

Post by chii »

adrianlmm wrote: post #28

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

the `` 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!

Re: Jodd – The Unbearable Lightness of Java

#36

Post by stickfigure »

benhoyt wrote: post #25
stickfigure wrote: post #18

Earlier quoted context omitted.

Sure, and eventually you end up rebuilding an [ad hoc, informally-specified, bug-ridden, slow] DI container because: * Static references become a tangled mess, and you start wanting some structure around that. * You have to answer "how does ABC component get access to DEF?" for increasingly difficult combinations of ABC and DEF. Excepting Spring, pretty much all Java DI containers are lightweight.

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…

There are lots of reasons why static references are undesirable, but some of the more serious are:

* Static dependencies make testing harder, no question about it. This is mediated in dynamic languages like Ruby by mocking statics. While you can actually do this in Java with Powermock, avoiding mocks entirely is even better. If you can't use a real object, use a fake that implements the relevant interface.

* Statics mean singleton, and that invariant often changes as a product matures. It's very easy to go from "the database" to "a database", and when you have 500 places getting "the database" it's very hard to make that evolution.

* Statics make it very hard to maintain module boundaries, because every static is its own exported interface. In a long-running project, binding tends to get tighter and tighter as every module reaches out for the statics of other modules.

Sure, folks can write bad code with DI systems too. And I'm no fan of Spring - not because of the DI, which is fine, but because of the need to wrap everything else in the universe and now you have to understand both how the underlying thing works and the way Spring changes it. But something like Guice or Dagger is just the right amount of glue to hold a system together, without getting in your way.

Re: Jodd – The Unbearable Lightness of Java

#38

Post by dehrmann »

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/com.fasterxml.jackson.cor...

Re: Jodd – The Unbearable Lightness of Java

#40

Post by MichaelMoser123 »

geodel wrote: post #29
MichaelMoser123 wrote: post #23

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

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…

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!
Post reply on HN