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

61–70 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#61

Post by geodel »

wtetzner wrote: post #51
throwaway1492 wrote: post #20

Earlier quoted context omitted.

This, it’s really exhausting to read this never ending wheel reinvention. Sure any one can use simpler non-spring frameworks, and other “non standard” frameworks and libraries for 1/10 or 1/100 of the functionality, and get 10-100x the bugs and much less or zero support. But we need netty! And then when you add thread pools, jdbc, logging, etc? Yep you’ve reimplemented spring. Just use spring, spend the time to learn…

As someone who dealt with a ton of Spring in the recent past, I completely disagree. First of all, thread pools are part of the standard library. Spring adds little to no value on top of it. Second, reinventing some of that stuff is absolutely worthwhile, because Spring's library design/implementation is not very good. Finally, when I had the opportunity to start a new Java project, I opted to not use Spring. I final…

Well you are missing one of the great feature of Spring framework: Converting compile time errors in to runtime exceptions.

Jokes apart you are absolutely right about non-spring based services. I did same using plain Java + embedded tomcat for some services. No cargo-cult like endless decorative packages and classes. Exactly same result as you observed. Less code, fast to start and vastly improved error management.

Re: Jodd – The Unbearable Lightness of Java

#62

Post by lopatin »

ferdowsi wrote: post #19

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.

"upcoming Go-like concurrency" can you elaborate on this?

Java will have CSP at the language level? I find it hard to believe.

Re: Jodd – The Unbearable Lightness of Java

#63

Post by geodel »

otterley wrote: post #58
geodel wrote: post #41

Earlier quoted context omitted.

> but I must be missing something here. As a Java developer for all my career here is my take. In Java world there is this cultish cottage industry of "frameworks" for all sorts of work. Most Java developers are not expected to write plain code with JDK standard + some external libraries. Creating an object via "new Obj()" might cause programing universe to collapse so DI framework is must for enterprise Java develop…

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.

Re: Jodd – The Unbearable Lightness of Java

#64

Post by jeffffff »

eximius wrote: post #44
WatchDog wrote: post #30

Earlier quoted context omitted.

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.

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

Re: Jodd – The Unbearable Lightness of Java

#65

Post by lmm »

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.

Plumbing the construction of your object graph manually does not have a particularly high cost/benefit - most of your services are singletons that depend on each other, and it's already clear enough which ones depend on which others without repeating yourself. A very basic "here's a bag of classes that depend on each other, wire them all together and then let me pull out the instances by type" is often worthwhile for avoiding all that boilerplate, even if it does break the rules of the language a little. Something like Picocontainer or even Guice is pretty good IME.

Re: Jodd – The Unbearable Lightness of Java

#66

Post by stickfigure »

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

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.

Re: Jodd – The Unbearable Lightness of Java

#67

Post by yencabulator »

stickfigure wrote: post #66
yencabulator wrote: post #56

Earlier quoted context omitted.

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

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

Re: Jodd – The Unbearable Lightness of Java

#68

Post by WatchDog »

winrid wrote: post #31
WatchDog wrote: post #16

Earlier quoted context omitted.

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

FWIW, here is a fairly minimal example[0] of broadcasting over websockets reusing the same buffer.

I'm not very familiar with vert.x(not a netty expert either), but I think the author of that article is ascribing blame to the wrong place.

[0]: https://github.com/juggernaut/netty-websocket-broadcast-exam...

Re: Jodd – The Unbearable Lightness of Java

#69

Post by erik_seaberg »

WatchDog wrote: post #54
guelo wrote: post #48

Earlier quoted context omitted.

Is what you're thinking of equivalent to deep argument passing? I've seen it done where you pass around a global Factory object that can provide dependencies. It's basically rudimentary DIY DI.

It's really very simple, no you don't need to pass around a factory object. You just have a class/classes that construct/wire all of your singleton objects and passes the required dependencies into their respective constructors as necessary. Here is a contrived example of what the wiring code might look like for a web app that uses a database. public static void main(String[] args) { MyConfig config = readConfigFile(…

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.

Re: Jodd – The Unbearable Lightness of Java

#70

Post by jupp0r »

stickfigure wrote: post #18
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.

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.

Dependency injection does not have to be dynamic, it can totally be done at compile time. Boost DI is an example: https://boost-ext.github.io/di/
Post reply on HN