Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lombok makes Java cool again

bytes.grubhub.com

Post reply on HN
Print view View original

111–120 of 239 posts

Re: Lombok makes Java cool again

#111

Post by Terr_ »

twblalock wrote: post #18
LeanderK wrote: post #2

I think java made some wrong decision, with bigggest one being very pragmatics generics-addition, resulting in trouble down the road like List not being possible. But I don't think checked exceptions are one of them ;) I don't like too much flexibility in a language that has strong types. If you undermine the type-system, why not code in python? But some additions of Lombok seem worthwile.

The problem with checked exceptions is that any method can throw runtime exceptions, whether it declares checked exceptions or not. So the presence or absence of "throws" does not really change your approach to error handling. An exception might happen either way, so you need to exercise the same level of care either way. Furthermore, checked exceptions force you to bubble up implementation details all the way up to…

Your second paragraph has a direct-equivalence to complaining about return-types and advocating that everybody should just specify "Object" to make things easier.

( https://imgur.com/iYE5nLA )

In both cases it's about constraining and describing the results from a method. The only difference is that most developers are so much more accustomed to thinking and coding along the happy-path, where they will willingly do all the exact same architectural tasks.

Seriously, read these three variations aloud and see how they sound:

>> return-types force you to bubble up implementation details all the way up to the interfaces

>> if any implementation of an interface might return Foo, you need to put that in the method signature in the interface

>> You can be clever and wrap it in a custom return-type that exposes the same level of abstraction as the interface, but that's not a whole lot better than just using Object

I'm willing to bet you can think of a slightly-incredulous answer to each of those, right? Perhaps something along the lines of "no they don't", "yes that's normal" and "WTF of course you should."

Re: Lombok makes Java cool again

#112

Post by flukus »

noir_lord wrote: post #31
mohaine wrote: post #12

My main issue with Java is all the annotation based programming. Some of these are nice and can make the easy case super easy but if you need go even slightly off the easy path you seem to quickly loose all the time gained on the easy path. i.e. @GET(url=" http://host/users/$userid" ) public abstract User getUser(String userid) isn't that much easier than the python requests version but much harder if you need to add…

I actually ran into a useful case for annotations in Java the other day. Compile time dependency injection (Micronaut framework). Not something I have a use for but it's clever. https://micronaut.io/

It's not exactly a new thing though, it's always been possible in a variety of ways, from build steps to pre-processor macros. Annotations mostly just do what macros or code generators have always done.

Re: Lombok makes Java cool again

#113

Post by darkpuma »

fogetti wrote: post #103
zestyping wrote: post #83

Reading this just reminds me of all the terrible things about Java. The lack of reasonable default string representations, comparison and hashing methods, etc. are all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. It's as though Java programmers are so deep in the grips of Stockholm Syndrome that ordinary, sensible behaviour seems amazing and "cool". This i…

I am sorry to disagree but if you think that the iterator or visitor pattern or the state pattern or abstract factories are only bound to Java than you have a very low skills/understanding of those patterns and you really don't understand their importance and/or applicability.

The majority of design patterns only exist because of the limitations of single dispatch. Java is far from the only single dispatch object system, but his criticism is still valid.

Re: Lombok makes Java cool again

#114

Post by bobthepanda »

twblalock wrote: post #104
bobthepanda wrote: post #61

Earlier quoted context omitted.

IIRC @Builder.Default only makes them immutable if you also specify that the variable is final.

Yeah, but what if I want to build an object with @Value on it, which makes all variables final, and I want to specify a default value to be used only if the user does not provide one to the builder? That's not possible. A builder is just a fancy alternative to a constructor. It is possible to set the value of a final field in a constructor, and it is also possible to have another constructor in the same object that s…

Can't you just use @Data and @Setter(AccessLevel.NONE)? That's effectively the same as using final but without the keyword.

Re: Lombok makes Java cool again

#116

Post by kbp »

zestyping wrote: post #83

Reading this just reminds me of all the terrible things about Java. The lack of reasonable default string representations, comparison and hashing methods, etc. are all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. It's as though Java programmers are so deep in the grips of Stockholm Syndrome that ordinary, sensible behaviour seems amazing and "cool". This i…

> When design patterns came along, Java folks talked about them as though they were a wonderful new invention. But they only exist because Java is so clumsy that it needed crutches to do things that had been easy and natural in other languages for years; someone merely came along and gave the crutches names.

Design patterns are a useful way of thinking about any sort of design, not even just in programming. Novels and paintings have them, too, so does your favourite language. There will always emerge from experience particular ways of using your medium, and having names for those patterns can actually be pretty useful for thinking about them and structuring them into a good design (like how SICP talks about knowing a spirit's name gives you power over it). You can't avoid using design patterns; someone just might not have come along and named them yet, or you might not be aware of them.

The GoF book itself actually discusses this in the first chapter a bit, here's a relevant part:

Point of view affects one's interpretation of what is and isn't a pattern. One person's pattern can be another person's primitive building block. For this book we have concentrated on patterns at a certain level of abstraction. [...] Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called "Inheritance," "Encapsulation," and "Polymorphism." Similarly, some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor.

Re: Lombok makes Java cool again

#117

Post by jhomedall »

fraggle222 wrote: post #91
zestyping wrote: post #83

Reading this just reminds me of all the terrible things about Java. The lack of reasonable default string representations, comparison and hashing methods, etc. are all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers. It's as though Java programmers are so deep in the grips of Stockholm Syndrome that ordinary, sensible behaviour seems amazing and "cool". This i…

You either like strongly typed object oriented langs or you don't. If you do, then a bit of verbosity is really nothing. If there are actual lang improvements beyond saving me a few characters, I'll take them.

A language being strongly typed does not require verbosity.

See, for example, F#, Scala, or Haskell.

Re: Lombok makes Java cool again

#118

Post by dionian »

mohaine wrote: post #12

My main issue with Java is all the annotation based programming. Some of these are nice and can make the easy case super easy but if you need go even slightly off the easy path you seem to quickly loose all the time gained on the easy path. i.e. @GET(url=" http://host/users/$userid" ) public abstract User getUser(String userid) isn't that much easier than the python requests version but much harder if you need to add…

while I agree with your point, you should have seen the garbage that annotations replaced...

Re: Lombok makes Java cool again

#119

Post by cakeface »

platelminto wrote: post #6

I'm interested in the downsides of using Lombok, since the article seems to only focus on its positives and makes it seem like I should download it and start using it right now. Is there anyone here with Lombok experience that wants to share any issues they've run into while using it? All I can think of right now is the fact that the source code isn't compatible with Java.

I dislike Lombok. One reason I dislike it is that it makes IDE navigation, even with a required Lombok plugin, more difficult. A common task in a Java IDE is finding usages. It's harder with Lombok. Generally it's just more friction than plain Java code.

I also don't like that the generated code is not checked in or visible. It makes code review harder. In theory you can have magic change to all Lombok classes just by upgrading the library.

Also it doesn't pass the cost/benefit test for me. Adding Lombok adds complexity to your code, build system, and IDE. What do you get? Slightly shorter classes? Less characters? Most of this code can be generated by the IDE.

I'll give Lombok one win. It will keep equals and hashcode up to date if you add properties. That's a pretty common error.

As others have said, Kotlin is the best alternative. But even without Kotlin I skip Lombok happily.

Re: Lombok makes Java cool again

#120

Post by kodablah »

hota_mazi wrote: post #72
kodablah wrote: post #10

Earlier quoted context omitted.

> I don't think checked exceptions are one of them While they may not have been the wrong decision, empirical evidence continually shows they add a syntactical burden many devs just work around (e.g. just wrap in a RuntimeException anyways). It's understandable why most modern languages don't consider predictable exceptions as part of the function signatures (though many discourage exceptions altogether in all but th…

This is similar to saying that since error codes are ignored by most developers, functions shouldn't bother returning them at all. Error conditions captured in the type system are a vital part of making code robust. The fact that some developers don't know how to properly handle these error cases doesn't change anything to the soundness of checked exceptions.

> This is similar to saying that since error codes are ignored by most developers, functions shouldn't bother returning them at all.

It's not like saying they shouldn't return them (unchecked exceptions exist), it's like saying they shouldn't be forced to check the error code or declare that they will return that error code themselves. Checked exceptions aren't sound when in practice the same ones are reused to mean many things. And we shouldn't pretend deciding whether an exception should or shouldn't be checked is an objective choice applied the same way across the ecosystem.

Post reply on HN