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

171–180 of 239 posts

Re: Jodd – The Unbearable Lightness of Java

#171

Post by cies »

ragnese wrote: post #170
cies wrote: post #164

Earlier quoted context omitted.

Annotations are a band aid. They easily move what otherwise were compile time errors into runtime errors. The advantage of using them is that you have to write less (repetitive) code. I prefer code without them. They add magic. I dont like magic in my code.

I honestly think the big issue here is using Java for these use-cases. I know that sounds flame-baity, but I'm being sincere. Java is a very primitive language. For the vast majority of its life, it's basically been C + basic classes + garbage collection. As a result, it's very verbose, which is totally fine for a low-level language. But, when building large, high-level, business apps, it's just a weird fit. I think…

I disagree here. Having GC, VM, streams, big stdlib, makes is quite highlevel.

It's not very terse (like Ruby maybe), but modern Java is terse enough.

To keep a language small is a good thing: less to remember, easier to join the team. Go, Elm, Reason/ReScript, LISPs all go that route.

Java misses some things badly. Like being able to have a reference to a method (Jodd has a library fix for this). Or like sum types and pattern matching.

But I'm more bitten by features that Java has than what it has not. Overuse of Exceptions (instead of sum types) and Annotations are my biggest pains.

You see a lot of Java's shortcomings properly being addressed in Kotlin. Like the getter/setter story. And "standards" like Bean and XML config have given Java a bad rep.

Re: Jodd – The Unbearable Lightness of Java

#172

Post by geodel »

kaba0 wrote: post #108
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…

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…

Lucky me, there were libraries available, for mail, JMS, Kafka, logging and so on. Also implementing things in shittier way than Spring is difficult feat to achieve for my modest skillset.

However there were some impossibly complex requirement like thread pool and with great effort I was able to found a solution in standard JDK like :

`ExecutorService exec = Executors.newFixedThreadPool(st.threads);`

Spring could have greatly simplified this code I guess.

Re: Jodd – The Unbearable Lightness of Java

#173

Post by pgwhalen »

kaba0 wrote: post #120
pgwhalen wrote: post #42

Earlier quoted context omitted.

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

What happens with proxied classes? My ClassWithTransactions is actually a subclass of the written one auto-generated by Spring. I can’t inject a new instance of that manually. And you may say that you don’t need Aspect Oriented programming, but the usual handling of transactions in many other languages without some meta-programming is.. to not handle transactions. Putting a single annotation over a method is imo a ve…

This is all considerably more abstraction than I have wanted or needed when writing Java. When handling transactions, I’ve passed around the same connection before committing.

Re: Jodd – The Unbearable Lightness of Java

#174

Post by pgwhalen »

jcelerier wrote: post #126
pgwhalen wrote: post #42

Earlier quoted context omitted.

> 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

Do you seriously allow users to configure which logging framework is used through a UI? Perhaps I’m misunderstanding what you’re saying.

Re: Jodd – The Unbearable Lightness of Java

#175

Post by ragnese »

sitta wrote: post #168

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

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.

Re: Jodd – The Unbearable Lightness of Java

#176

Post by stickfigure »

benhoyt wrote: post #89
stickfigure wrote: post #36

Earlier quoted context omitted.

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…

Just a note: I overloaded (excuse the pun) the word "static": I didn't mean the "static" keyword, but "statically compiled/typed". So it doesn't mean singletons, just that you pass dependencies as explicit arguments to constructors and functions.

I do not understand what distinction you're making. In the world of DI, you still have typed constructors and factory methods. It's not like Guice turns Java into Ruby. The only difference is that you don't have to chain together constructor boilerplate - in fact, the static types determine the injections.

Do you object to passing interfaces vs concrete types? That is a wholly orthogonal concern; you make the choice to extract interfaces with or without DI.

Maybe you have an example?

Re: Jodd – The Unbearable Lightness of Java

#177

Post by ragnese »

stickfigure wrote: post #98
yencabulator wrote: post #67

Earlier quoted context omitted.

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

I did a fair bit of work in Go at Pivotal. I found Go anything but readable - a comical amount of boilerplate (especially around error handling), incredibly wordy constructs for simple tasks like making http requests, and the language is almost overtly hostile to functional programming (no generics!). I use Go as a "better C". Though I'm honestly disappointed with even that. My current company, we built an image proc…

> I did a fair bit of work in Go at Pivotal. I found Go anything but readable - a comical amount of boilerplate (especially around error handling), incredibly wordy constructs for simple tasks like making http requests, and the language is almost overtly hostile to functional programming (no generics!).

Are you saying that Java is better about any of that?

Re: Jodd – The Unbearable Lightness of Java

#178

Post by ragnese »

eximius wrote: post #27
WatchDog wrote: post #15

Earlier quoted context omitted.

I think there are a lot of Java developers, that have just never worked without a DI framework, and just don't have a grasp on just how simple it can be to write code without one.

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…

I'd say that the only one of your listed solutions-in-other-languages that is actually a valid solution is deep argument passing.

And I fail to see why it's a problem. If your FooService depends on a BarService, which depends on a BazService, and BazService needs a database connection, then that means your FooService really does also depend on a database connection. Hiding that information, to me, seems like a mistake. Can you articulate why one would prefer not to have FooService explicitly require that database connection, or am I inadvertently arguing against a straw man? If so, please correct me, because I'm asking sincerely.

Of all the time I spend thinking about my code and writing code, I truly can't say that adding a dependency and having the compiler complain until I fix a bunch of constructors has really caused me that much grief. And I'm not going to pretend that it has never been the case that I've had to fix 20 constructors.

Re: Jodd – The Unbearable Lightness of Java

#179

Post by vips7L »

cies wrote: post #171
ragnese wrote: post #170

Earlier quoted context omitted.

I honestly think the big issue here is using Java for these use-cases. I know that sounds flame-baity, but I'm being sincere. Java is a very primitive language. For the vast majority of its life, it's basically been C + basic classes + garbage collection. As a result, it's very verbose, which is totally fine for a low-level language. But, when building large, high-level, business apps, it's just a weird fit. I think…

I disagree here. Having GC, VM, streams, big stdlib, makes is quite highlevel. It's not very terse (like Ruby maybe), but modern Java is terse enough. To keep a language small is a good thing: less to remember, easier to join the team. Go, Elm, Reason/ReScript, LISPs all go that route. Java misses some things badly. Like being able to have a reference to a method (Jodd has a library fix for this). Or like sum types a…

Java has had method references for almost a decade. Pattern matching also was recently released.

Re: Jodd – The Unbearable Lightness of Java

#180

Post by geodel »

pshirshov wrote: post #137
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…

> I have a dozen or so microservices supported by team. Why do you need a dozen of microservices? Why not to use role-based monoliths? Why not to keep your "microservices" as independent modules, pack them as one app and let such app to configure itself with proper set of services and dependencies according to the config or CLI parameters?..

Just a developer there. So not calling shots on overall architecture. And yes we do not need probably 80% of that crap but not in position to make them see reason.
Post reply on HN