Lombok makes Java cool again

Tend to agree. But if you work in a team, there will be someone who just loves implicits and overloading and you won't be able to change his mind. Strong code style policies help, but they are really rare in real processes.

So, like Spring?

ba dum tish

I've used lombok in the past but only in projects where somebody insisted on using it before I joined. It can be nice having it around if you are stuck in a project where you have to use Java and it's just not negotiable to use something else and you have to use frameworks that expect a lot of model classes, DTO's and so on that comply with the java beans convention.

This is a convention that emerged in the late nineties where people used a naming convention for setters and getters to expose properties. Lots of frameworks (hibernate, jackson, gson, etc.) rely on discovering such properties via reflection. Unfortunately this results in a lot of boiler plate and code that does nothing interesting. Worse, a lot of these frameworks expect mutable classes, which should rightfully make you feel dirty every time you write one.

Lombok helps with that and you can sort of fake having quasi immutable classes. There's a price to pay unfortunately: it depends on generating code at compile time. This makes it necessary to use plugins for your favorite IDE to not get confused about all the non existent methods you are calling to access these getters, setters, builders and all the other boiler plate Lombok generates. Unfortunately these plugins make intellij more likely to get confused, which is something that can only be fixed with lengthy rebuilds, cache clearing, and the occasional restart. I've wasted no small amounts of time in trying to convince Intellij to get rid of phantom compile errors.

For this reason, I'd never introduce it in any project I'm in charge off. It's just not worth the pain and I'd rather solve the problem of not having to have stupid code like that to begin with by using something that does not require it. IMHO code generation is a bit of an anti pattern. It's kludge for having flawed languages and broken frameworks. There usually is a better solution than generating a lot of source code.

These days, Kotlin is a vastly superior way (and I say that with close to 25 years of Java experience) of avoiding that type of code and modern frameworks like spring boot work fine with it. Also worth pointing out that Java is slowly absorbing new features. Type inference is there now and they are working on data classes and a few other features. It might eventually catch up with less than half of what Kotlin does today in a decade or so. But why wait? IMHO Java is no longer a defensible choice on most new projects.

Converting Java to Kotlin with the built in conversion tool in intellij is not flawless but it gets you quite far and you can go class by class. I actually have one project where I've been gradually moving to Kotlin for over a year now. Every time I touch some old code, the first thing I do is convert it to Kotlin. Only takes a few minutes once you get the hang of it and it's a great way to explore the language. Mostly you spend this cleaning up the things it got wrong regarding nullability, funky generics, or just using a bit more idiomatic constructs (e.g. using sequences instead of streams), etc .

Can you provide a linke to Google's paper? I'm really interested in it.

Spring boot with Lombok has been my go to framework for a few years now. Annotation-based programming seems to get a lot of negative attention here on HN, and it definitely is not perfect but there is just no other framework that (in my opinion) comes close in terms of productivity and workflow.

Currently I'm building my SaaS + Selfhosted software licensing product with this Spring Boot + Lombok + Postgresql combo and Annotations are helping me out for :

* @Bean, @Autowired, @Profile,... for configuring dependency injection with multiple profiles (saas vs selfhosted)

* @Entity, @Table, @Repository, @Enumerated, @Embedded for mapping my classes to Database tables

* @Api, @ApiOperation, @ApiParam,... for generating Swagger documentation for my endpoints

* @GetMapping, @PostMapping, @PreAuthorize for configuring and authorizing my endpoints

* Lombok @Data, @Value, @Builder for tedious boilerplate generation

* @NotNull, @NotBlank, @Email, @PhoneNumber, @Pattern(regex), @Length(max=12),... for validation of form input, api params and database models.

* @JsonProperty, @JsonSerialize, @JsonIgnore for configuring json deserializing for my DTO's

* @Value("${my.config.key}") for decoupling configuration from my code and injecting values at runtime

I probably forgot a few more use cases. All of these are pretty straightforward, are defined alongside the code they are modifying or interacting with and would lead me to a lot of lost time and a lot more code if I were to implement them myself, or configure them by hand "in real java code".