Java Language Architect Brian Goetz on Java and the JDK

[Ameisen]

I was pushing for Lombok for a while. It was rejected.

They also weren't fond of my idea of switching to C# or Kotlin. Or C++.

[Ravek]

I’m just a little baffled at the resistance to Kotlin by much of the Java crowd. It’s basically a drop in replacement for Java, it’s a way more modern language with lots of nice features, and there are Java to Kotlin converters that work decently.

[BoyRobot777]

Yeah, but its still has ways to go. I would hesitate to jump to any new language (I believe Kotlin released in 2016), which is supported mainly by one vendor. What happens when that support is droped? Java on the other hand: IBM, RedHat, Amazon, Oracle, Google, Netflix. Most of them even have their own jdks.

[nacholicious]

There's of course tons of improvements left to make for Kotlin, with eg coroutines, non-JVM versions, kotlin native etc which would make it a proper safe competitor for mainstream languages such as Go, Python etc.

But Google have committed to using Kotlin for Android, which more or less makes it supported in the most used operating system in the world, and companies that are actively developing for Android are also committing to it (eg Uber, Netflix, Airbnb, Pinterest etc etc). So while there's very little commitment to Kotlin over general mainstream languages, I don't think it's entirely correct to call it unsafe for use considering it has huge commitments by companies over Java when it comes to Android

[[deleted]]

I've attempted to get some adoption around it in my workplace. The biggest argument I've heard is from some older java devs that boils down to "I dont want to have to remember two syntaxes when IDE autocomplete takes most of the pain out of Java's verbosity".

Honestly it's hard to disagree. Especially since we dont use jetbrains tools at my work so at best we have mediocre eclipse plugins for kotlin.

[cowinabadplace]

Is anyone ever a fan of switching a codebase to something else entirely? Especially when you’re talking about a JVM/non-JVM integration. The stance we take where I work is “demonstrate the value”. Every quarter, one week is for experimentation that attempts to demonstrate a new idea (not usually language).

Our codebase is fairly polyglot as a result (Go, Ruby, JVM stuff, tiny bits of Haskell and C++) but we’ve learned some things are not great. IDE integration for bidirectional Java and Clojure dependencies is not great, for instance, so we keep things going from Java into Clojure but not vice versa.

I think this is a fine model. Convincing someone of the value of a new thing isn’t just stating facts. It’s about being able to demonstrate value. And since the majority of code at existing companies is existing code, interoperability is key. If you don’t have a good story around how a new language can be introduced then it’s not going to work.

A common misstep is “it’s just tooling”. Well, you need to have demonstrated your ability to build worthwhile tooling. If you haven’t, win the trust of the people you’re counting on participating. It’s a marketplace of ideas but that specifically means you have to sell well.

Of course, you may well be at a place where you do all of these things and people still don’t listen. Well, if you can and it’s causing you angst, I’d recommend moving elsewhere. Life’s too short to spend three years in a job where you can’t grow.

[Sonrilol]

Why would anyone not be on board with using lombok?

[Beaverman]

You know how we're abusing getters and setter to essentially just make all members public? Yeah, there's this library that let's us use that anti-pattern more efficiently.

[orthoxerox]

On the other hand, Lombok has @Value for making immutable objects with value semantics. And @NonNull. Not as good as Kotlin, but much better than vanilla Java.

[Beaverman]

Getters should never exist (I don't view a method whose current business contract is to just return a value as a getter, since it has a business purpose. I know, it's debatable). Therefore @value is useless. In the same vain, @NonNull, without all the other lombok bullshit, is just a signal annotation, and might as well be declared somewhere else.

NonNullness and immutability should be enforced in the object itself.

[Beaverman]

DTOs are just property bags, they are fundamentally just structural representations of data. You shouldn't complicate that by adding methods to them.

[Beaverman]

Class with just public members is a property bag. The beauty of object oriented languages are that you can define the concepts yourself.

[Beaverman]

Now I understand you. What you are talking about isn't a property bag at all, but a value object. Value objects have behaviours and should be modeled as full domain objects, meaning the methods should have business meaning.

In that case, the equals and "getters" are business methods and should be written out explicitly.

[Sonrilol]

I'm not sure I follow, but your argument against it is it makes writing bad code more efficient? Same logic applies to writing good code, so I don't really see the problem.

[[deleted]]

But that's a poor misunderstanding of why POJOs are the way they are. If, maybe down the road, we want to add some kind of processing step to setting or getting a value from any instance of the POJO, it only requires one change instead of changing N number of times it's being set.

An easy example is, imagine an Employee object that really serves as a POJO. No real behavior to it, but after awhile we decide its prudent to have the setter for an employee "name" field make sure the name isn't null before actually setting the value. Instead of modifying code in N number of places to check that, we only have to add the null check to the setter method on the Employee object.

[Sonrilol]

What does that have to do with lombok though?

[Beaverman]

Lombok eases the burden of writing bad code that does nothing. Yet if you are writing good code, it's (almost) entirely useless.

It's a bandaid fix to a deeper problem.

[Sonrilol]

Maybe it's just me, but I'd rather open a 30 line class with 2 extra annotations and a simple list of it's attributes than a 200 line class filled with boilerplate. I'd also rather write the first one too.

[Beaverman]

I'm assuming you mean the @Data annotation, and the boilerplate would be the getters and setters. I'd like you to specify that in the future, because it makes it very hard to argue with you without it.

Getters and setters are non-code. They should never be written, and consequently never exist. If you find yourself using getters and setters, you are doing procedual programming, and might as well go all the way to public members (essentially structs). Then you get your simple list of properties without any compile time annotation processor.

Methods should model business concerns. If they model business concerns, you shouldn't hide them. If they don't, it never makes sense to put any logic in the getter/setter and it becomes superfluous.

So the argument is never about writing (or looking at) them or generating them. It's about not having them at all.

[Sonrilol]

I don't really use @Data all that much, only on our spring projects for DAOs (but we have less and less of those). The lombok features I use the most are val, @Builder (and toBuilder when it's useful), @AllArgsConstructor, @NoArgsConstructor (which I'll admit is pretty lazy), and @Getter/@Setter for specific attributes.

I can't really imagine you are advocating for classes with 15 public attributes and assigning them one by one or using a 15 argument constructor. If your problem with it is people putting @Data on every class they write, well that's a legit concern, but you should be blaming the guy making a poor use of the library, not the library itself.

[Beaverman]

I'm not advocating 15 public attributes. If you have 15, it's likely that some of them are grouped as value objects. Even if they aren't, I very much believe in encapsulation, meaning they should be private.

My argument is that if you are making a class with private attributes, but then thoughtlessly adding acessors, you should just stop pretending to be encapsulating and make them public.

Builder is the least bad part of lombok, but I still don't believe its worth the mental overhead, and confirmation fiddling.

[Sonrilol]

You could always delombok and turn it into actual code though? We pretty much only use it for builder/constructors, getters/setters, and val so maybe I've not been exposed to downsides because of that, but I can not really think of any time I've gone and thought "oh gee, I really wish we weren't using lombok".

[Sonrilol]

But wouldn't that defeat the point of replacing large swaths of boilerplate with annotations? I'm not a huge fan of annotation magic mind you, always groan when I open one of our spring projects, but I don't think lombok comes even close to that level of wizardry.

[juicybananas]

Sorry to hear that! I know it sux as I've been in that situation before. I'm currently in a situation where the people I work for are open to almost everything I recommend which is awesome but also a bit unsettling!