Lombok makes Java cool again (bytes.grubhub.com)

Checked exceptions have often been presented as a mistake on the basis of the ergonomics and workflow problems they cause, not because they are unhelpful when implemented. The problem is that people don't want to break their flow to deal with them, so they don't deal with them by catching/throwing exceptions improperly.

EDIT: There's also the fact that Java includes unchecked exceptions, so you can already subvert that part of the type system.

I don't really write much Java these days, but I've use at least a few libraries which use checked exceptions in a way that really sapped the fun out of the experience. (And personally I feel it is important for writing code to be fun, because little else of working with computers is.)

I've had both good and bad experiences with checked exceptions - it can really depend on the team!

One of the parts of Lombok that really works well for me is that its notations are completely optional and fit many different levels of granularity as you see fit. Don't want sneaky exceptions? Don't use them!

I mostly end up using it to make my Java code feel like C# though...

The problem with checked exceptions is that they constrain implementations by what possible failure states they could have. I.E. the implementations of an interface with a method in it that declares no exceptions will either never call anything that could throw a checked exception, it will internally handle its checked exceptions, or it will wrap them in an unchecked exception. In practice, the first is a straitjacket, the second leads to ignoring errors you can't propagate, and the third is boilerplate that makes it harder to actually catch the exceptions when you need them.

What would've made them good would be a static analysis of some sort that could divine all possible exceptions thrown by a method call and its dependents based on its code, but in Java a class can always override another class and do something entirely different so that's not possible.

> 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 the most extreme cases).

  list.stream().map(doStuff)

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 the interfaces. For example, if any implementation of an interface might throw IOException, you need to put that in the method signature in the interface. You can be clever and wrap it in a custom exception that exposes the same level of abstraction as the interface, but that's not a whole lot better than just using RuntimeException, and it causes people to try to cast the exception cause.

Checked exceptions don't work right with streams/functional programming. They prevent abstractions that couldn't possibly be aware of custom checked exceptions. That's why Scala doesn't have them.

> auto generate sensible [...] 'hashCode' methods

Unless you're using arrays. They went with "predictable" over "sensible" here.

> is flawless from my experience

As a heavy Kotlin user, I'd say it's far from flawless (not sure if you mean interop or the entirety of the language, but applies to both). I'm often creating and starring YouTrack issues. But yes, it's still a highly recommended alternative to Java.

I agree, it's as easy to tap into your build tool to build kotlin/groovy/scala alongside with java, as it is to tap into buildtool to process the annotations.

Yeah, Kotlin pretty much killed Lombok.

I see Kotlin as a great choice for these who don't want Java verbosity but can't really get used to read Scala.

The same can be said about Scala and Groovy. (Groovy brings in those generators via an annotation)

Kotlin has not flawless integration and some attention is required when writing libraries for Java consumption.

Additionally the JVM wasn't enough for JetBrains and code written for multi-platform has slightly different semantics (see Kotlin/Native and immutable data).

Kotlin is a good alternative on Android due to a frozen Java 8.

Against Java 12 not so much.

It is very hard to displace platform languages when others just feel like guests.

  * Excellent null safety enforced by the type system
  * Data classes reduce boilerplate and bug sources
  * Extension methods
  * Declaration site variance removes a lot of the ? extends T
  * Everything being an expression (if, switch/when) is powerful 
  * Smart casts are useful, especially when combined with subtypes and when (switch)
  * Removal of checked exceptions
  * Inline functions, a good way to work around runtime type erasure
  * Properties, no more getX or setX

Kotlin is great. But go and try to persuade your company to bless another language for production.

It may be easy when your engineering org is 5 persons. It's much harder, genuinely harder, when it's 250 engineers, and an hour of downtime costs hundreds of thousands. Adoption of another language, even clearly superior and interoperable, becomes a large and costly undertaking.

So "just use Kotlin" is not always possible, and I'm thankful to Lombok's authors for their work.

The downside is that you'll need to install it into your IDE. And again when you upgrade it. I guess the version needs to loosely match the one your projects use too. That might not sound like a lot but some colleagues hate that overhead.

I love it though, think I've been using it for at least 8 years now in just about every Java project.

The @Builder annotation has some odd behavior if you want to add default values (it just hardcodes them and you cannot override them!) or extra builder methods.

Actually, anything involving default values seems to be very brittle and difficult to work with -- especially when deserializing objects from JSON.

The @Wither annotation results in methods that do not always make a copy, and sometimes use == instead of .equals when comparing class members. If you call one of the Wither methods and assume you have a copy of the original object, and then you modify that "copy", you might have just created a very subtle bug.

If you are using IntelliJ you can use the Refactor > Delombok menu option to show you the code that Lombok generates. I've been told that does not actually invoke the same code that the annotation processor invokes at compile time, so the results of Delombok might be misleading.

  public class Person {
      private final String name;

      public Person(String name) {
          this.name = name;
      }

      public Person() {
          this("Bob");
      }
  }

  Person p1 = new Person();
  Person p2 = new Person("some other name");

  @Value
  @Builder
  public class Person {
      @Builder.Default("Bob")
      private String name;
  }

  Person p = Person.builder().name("Some other name").build();

I used it extensively while writing Java code at Airbnb. (It came included with Dropwizard, which we used for writing services.)

Some people are uncomfortable with the extensive bytecode manipulation that it does. While Lombok provides annotations, it is not your normal annotation processor. From http://notatube.blogspot.com/2010/11/project-lombok-trick-ex...:

> Project Lombok hooks itself into the compilation process as an annotation processor. But Lombok is not your normal annotation processor... The trick is that Lombok modifies the AST. It turns out that changes made to the AST in the Annotation Processing phase will be visible to the Analyse and Generate phase. Thus, changing the AST will change the generated class file.

That said, we never encountered any Lombok-related problems when running services in the cloud or locally. And the Lombok plugin for IntelliJ is good enough in that the auto-complete will "see" the Lombok-modified version of the file. For example, using the @Value annotation creates an immutable value type, which among other things a) makes every field private and final, and b) generates a getter method for each now-private field. With the Lombok plugin, IntelliJ auto-complete will a) not auto-complete the composed fields which are now private, and b) auto-complete the generated getter methods.

I highly recommend looking past the voodoo bytecode manipulation and using Lombok. The @Value annotation alone is worth the price of admission and made me a more productive programmer.

Just recently removed Lombok from one of our projects. 1. To use it you have to use plugin for each IDE. If project not frequently used, spending time for each developer here doesn't make any sense. 2. Another reason was, person who used Lombok abused all OOP principles. Project became a book of anti-patterns.

Yeah, I use it at a financial services client. A previous architect chose it because it was a pet project of his (he contributed to Delombok).

The premise is fine...I have no problem with it. But the default generation of @EqualsAndHashcode literally pulls in the WORLD to generate the output.

The real world scenario we had was this. Lots of POJOs were created, many were simply but a non-trivial number were NOT. Those POJOs could have dozens and dozens of fields. And if you have a key abstraction with say, 86 fields, things get interesting.

Suppose you don't use @EqualsAndHashCode on one of these POJOS with lots of fields, ALL 86 fields are included in the default equals and hashCode methods. They didn't realize this, or didn't care, and as a result, had some serious performance issues because trying to run hashCode on insert to a map when you're hashing 86 fields together might actually take some time inserting 100,000 records... ugh

So in short, it's OK and useful, but you have to understand the side effects of everything to know if it's the right thing for you.

SIDE NOTE: A POJO with 86 fields can be common in financial services when you are representing various kinds of financial trades where gazillions of things are tracked on them...interest rates of note, ratings, security characteristics, etc. That in and of itself isn't necessarily poor design, although these choices predated me at this company.

You get a more complex (and slower) build. Poorer editor support. It may be hard to upgrade Java version (ie. going from 8 to 11). More string for developers to hang in. I wouldn't use it.

I've heard it makes Kotlin integration a pain also if you are ever planning on that. If your Kotlin code depends on Java lombok classes, the compiler fails. Most people probably don't have this concern, but IMHO a mixed Kotlin-Java project is better than any of the current 'data class' libraries available for Java (Lombok, Immutables, Joda-Beans, AutoValue) ... ymmv, and I'm eager to see what comes of the "data classes in java proposal".

https://cr.openjdk.java.net/~briangoetz/amber/datum.html

One of the issues is that it's tied quite heavily to the Java compiler, so you may need to wait until Lombok supports a new Java version before you can use it.

Also as it is compiler magic, it can be a bit confusing to developers who haven't used it before.

The only downside I've come across was test coverage tools like jacoco can have problems with the auto-generated code (complaining about your tests not covering enough branches of an auto-generated hashCode() implementation, for example). However it seems new-ish versions of jacoco seem to have built support for it.

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.

Using Lombok is relatively simple compared to switching to Kotlin or Scala, I think.

A few annotations don’t seem that much more radical than stuff like AspectJ.

Sometimes just fixing the rough edges with syntactic sugar can provide a lot of value. Like, CoffeeScript got pretty far with that strategy.

Honestly, a lot of the best TypeScript features could be described the way you describe it.

FactoryFactoryStrategyFactoryAgreementChainImplementationProxy

>custom dynamic header

Its just: @RequestHeader("Header") added to the param list.

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/

Yep. I love data classes for the simplicity and utility but pretty soon there are more annotations than java code. In Java I prefer Immutables over Lombok but once you add Jackson annotations, customize the Immutables generated code (@Value.Immutable, @Value.Parameter, etc), add some javax.validation (@NotNull, @NotEmpty) it gets very noisy very quickly. And yet it is still better than writing mutable bean classes by hand IMHO.

Switching to / mixing in Kotlin is worth it just for the data classes at this point (and you get some type-level nullability and `val` instead of `final var` to boot).

https://immutables.github.io/

> My main issue with Java is all the annotation based programming.

That seems like an easy problem to solve. Don't use annotations.

Snark aside, it can be a bit of a tricky balancing act. When there are more annotations than actual code, that's a code smell in my book and something needs to change. Separating concerns usually does the trick. I'm heavy on code generation, so anything that's boring enough to benefit from oodles of annotations will probably end up getting generated based on a 2 line config file or something.

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

How do you feel about Spring? I'm a fan of Java itself as well, but find myself conflicted whenever I use Spring/Boot. It's very nice when it works. But when the magic formula isn't recited correctly....you get frustrated and wind up visiting HN to forget about how unpleasant it is.

ahem

Java made some fundamental design decisions at its inception which look like fairly bad ones from today's perspective. It also introduced flawed versions of features like generics later. It also has some pretty poorly designed core libraries. What about it do you consider cool? I find it hard to think of anything I'd want to take from Java if designing a new language today. Even its bad design decisions have mostly been done better by other later languages like C#.

>What the enterprise has done with it is not cool. Writing apps with layer upon layer upon layer upon layer of abstraction is ... self defeating. Then they'll holler, we need to rewrite it! All in the name of finding that one true architecture that can handle any business CR. Blech.

Those decisions were less to do with personal freedom or program simplicity, and more to do with the realities of large scale enterprise development. You end up having to adopt patterns that make individual programmers replaceable, and allow for a standardized pool of candidates with experience in $X framework. The reality is that most companies building Java software just need to be able to hire an average Java programmer to show up every day and manage their huge tangle of business logic.

> Java the language is cool. What the enterprise has done with it is not cool

This is a re-occuring pattern.

I have seen it happen with C, C++, TP, Clipper, Java, JavaScript, C#, VB, ...

The enterprise environment is quite "interesting", specially when politcs get intermixed with technology.

I kind of agree, but I also find it curiously self-indulgent that as a profession software engineers feel entitled to discard technologies and methodologies because they are "not fun". Can you imagine civil engineers or electrical engineers saying that? They might enjoy working with certain technologies but would consider it highly unprofessional to demand that their projects be "fun" over other considerations.

NB: Groovy might be the closest thing to "LombokScript"

This is from Grubhub, not Instacart.

Is it not the definition of a JVM language?

I think Java is just 99% of JVM languages while other ones together take whopping 1% share of JVM languages.

Kotlin is great and very easy to use if you already know Java.

1073741824 is maximum (signed) integer size divided by 2. This is trying to optimize for the initial size of the set so that it doesn't have to allocate too many elements, since iirc Java's hashsets are backed by a hashmap implementation which has to be sized appropriately.

This, a million times.

In my professional bubble Lombok is completely gone. I'll go as far and say that modern Java does not use Lombok. Smaller, focused libraries like Immutables or AutoValue, solve the problem of boilerplate for data classes.

Lombok tries to do too much across many concerns, in a fairly opaque way, and makes the code and tooling around it more magic than it needs to be.

Skip Lombok. Modern Java is better off without it...

"ML based languages really are an order of magnitude productivity boost."

Is this still true when you consider available libraries, performance, concurrency, build and dependency tools, development environments, and deployment options?

Thanks for that!

Makes clear and explicit the queasy feeling I get from over reliance on Java annotations.

Lisp macros, for example, fare much better in the "means of combination" and "means of abstraction" tests, I think.

I agree, but it's helpful that the things Lombok abstracts away are very idiomatic and straightforward. I would never want to use it to take on anything more complicated.

Maybe you just nailed it on the head for me what I've been trying to state for a while in regards to FP. Expressing complex things like algorithms in functional programming can be beautiful and also incredible in how it adjusts your thinking. Fact of the matter is, I don't solve many complex problems like this. It makes doing tutorials and books fun but when i need to get work i stick to my usual guns

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.

Which design patterns are you thinking of and which languages had them? The original gang of four Design Patterns book is filled with C++ examples, most likely because almost nobody was using Java in 1995 outside of a few people at Sun.

More generally comparison and hashing methods seem like small potatoes compared to locking primitives, portability, and a large, well-documented class library that have made Java ideal for a very large fraction of business applications. There are many things to criticize in Java but the points you list don't seem to be especially important compared, say, to the relatively steep learning curve/complexity vs languages like modern Javascript.

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.

> all glaring mistakes in the language design that have wasted huge amounts of time for millions of programmers.

i would think javascript is the language with which the mistakes wasted the millions in man hours, not java.

The remark about design patterns is not accurate. Design patterns did not originate with Java and aren't specific to that language. The classic book "Design Patterns: Elements of Reusable Object-Oriented Software", by the 'Gang of Four', was written in and about C++. It was published in 1994 and predates Java.

"Design Patterns", both as a book and a concept, is about the recurring patterns found in object-oriented software; it is about the problems that lead to those patterns, and the solutions to them. Although the book itself is rather dated, the patterns described in it remain relevant to most modern languages. Some of those patterns include: Builder, Singleton, Proxy, Decorator, Iterator, Visitor, Prototype (c.f. JavaScript prototypes), Observer, Chain of Responsibility, and more.

Many languages employ these patterns in the design of their standard library. E.g. the Iterator pattern shows up in a large number of language libraries (Python, Ruby, JavaScript, Swift, Rust).

If you search for "Design Patterns in X", for programming language X, you can find quite a lot of literature about how to employ them in any language. For example, see "Python 3 Patterns, Recipes and Idioms" [1], which describes how to employ many design patterns in Python, or "Design Patterns in Ruby" [2]. A lot of modern literature for many programming languages relies on these patterns either implicitly or explicitly.

Most of these patterns do not exist because of language weaknesses, although I would agree that this is true for some of them, such as the Visitor Pattern. Use of the Visitor Pattern is often better replaced with pattern matching in programming languages that have it. However, this isn't true for all of the patterns (e.g. Chain of Responsibility, Facade, Proxy); and even the Visitor Pattern remains relevant to many languages, especially dynamic languages that do not support pattern matching.

Many of these structural concepts were not new, in the sense that they did not originate with the book; but the GoF took the time to assign names, characterize them, and describe the trade-offs involved in using them.

[1] https://python-3-patterns-idioms-test.readthedocs.io/en/late... [2] https://bogdanvlviv.com/posts/ruby/patterns/design-patterns-...

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

You have to look at it from a time when C++ was the mainstream for large scale projects. Java is certainly a god-sent gift to software salaryman all over the world.

>When design patterns came along, Java folks talked about them as though they were a wonderful new invention.

Your history is wrong. Design patterns became popular with the release of the GoF book, which was written using C++ and was published in 1994 -- before Java was even released.

> This is similar to the situation with design patterns. When design patterns came along, Java folks talked about them as though they were a wonderful new invention.

They are/were a bit over-hyped and sometimes overused inside the Java community, that's true.

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

Sure, some design patterns work around language deficiencies or are that commonly used to justify including them into the language. Java sadly did not do this enough in the past, that's right. But if you look through the list of design patters only a minority fall into this category.

> someone merely came along and gave the crutches names.

That's basically the whole point of design patterns. It's assigning a name to things already widely used to improve communication between developers and to provide learners a point to look up a concept.

Java really felt refreshing versus what C++ world was doing before it came out.

Go dig out a book about Boochs, CORBA, DCOM/MTS,...

"Terrible" in comparison to what?