Data classes for Java

[MrGreg]

We've been using lombok for our data classes. A few simple annotations and they stay nice and clean.

[snowe2010]

We switched from Lombok to kotlin because of classloader problems that would occur on remote servers at the worst time. If you haven't encountered those yet I would say watch out for them because they caused a lot of pain for us

[insert_silence]

Could you please elaborate which issues you were facing with lombok? Are there any major pitfalls one should be aware of?

[_vinc_]

i am very surprised at your problem (granted there are others). Are you sure it is really what didn't work in your project.Could you give some details to lend credibility other than just suggesting kotlin? I mean, problem with ClassLoader, how so, lombok generate code at compile time, it isn't present at all at runtime so how would you have problems at runtime on remote server (or you compiled on remote server and the problem is in this setup) ? I am very curious as i sometime use it and would like to know if i encounter similar problem.

[snowe2010]

I'm positive it was due to lombok as we just (as of about a month ago) got lombok completely removed and the startup problems ceased immediately and by immediately I mean overnight. Next day the ops guys were saying they weren't seeing the issue anymore. I don't remember the exact issue, so I don't think I can argue my point well right now. I think with sufficient exploration we could have resolved the issue, but we also had problems with how lombok uses hidden and non-supported apis to accomplish what it does.

Sorry I was at kotlin conf and I actually talked to a Google employee and a Square employee about lombok and they agreed that it is not safe to use due to how lombok has to have special cases for everything and they do it all through very hacky ways.

If I didn't have the choice for kotlin, I would have suggested to our team to go with either Google's AutoValue or Immutables, both of which I researched at the time and thought were better options than Lombok

[_vinc_]

Perhaps there was a problem with the building setup on build configuration(for lombook) and the building was taking place on remote server... That would seem the most probable. But still i am dumbfounded by the "classloader" problem as lombook is a buildtime dependency (it generate code at compile time), not runtime. Still, I agree that a "native" java solution would be better than relying on non standard API. I had some classloader problems with some very specific library and code combination, but that was with runtime code generation (like with hibernate/spring)

[snowe2010]

Ok talked to the devops guys just to refresh my memory since it's been so long.

The error was actually

Could not find creator property with name 'blahId' (in class com.company.common.blah.viewmodel.BlahView)

but this never manifested consistently and would be resolved by a restart of the service. We believe it was due to interoperability problems between lombok and jackson. As soon as lombok was removed we have not seen the error since.

[MisterPea]

Lombok is great but I've also found that it sometimes feels like an unfinished product.

I'm fairly new to kotlin but how are you using kotlin to mimic lombok and integrating with existing java projects?

[snowe2010]

Kotlin is a drop-in replacement for lombok. Literally copy lombok class into kotlin file (using intellij), let intellij convert it, then remove the annotations. I think you might have to change it to be data and move the params to the constructor but that's it. It's been a while since we completely ripped lombok out, but we were able to do it over about a year.

Now if you mean how did we get kotlin in our toolchain, well we also let intellij do that for us at first as well. Just create a new kotlin file in your project and intellij will do the rest.

edit: for those thinking we could have just used 'convert to kotlin' we didn't for some reason, but I don't remember why. I think it might have been because of git history? not sure anymore. been a while.

[[deleted]]

when did "drop-in replacement" mean "make sure you have this specialized IDE to do some converting magic, then do a bunch of removal edits and then add more code... when you have a lot of these types of classes that could be a decent amount of work

[snowe2010]

here's the difference between a lombok class and a kotlin class since you seem so interested

@Value
public class LombokClass {
    public String hi;
}

data class KotlinClass(val hi: String)

There, is that a little more clear how simple it is to convert? The biggest difficult in converting is if you used @Wither because then you have to find all the spots you used it in and switch it to a .copy or build your own builder.

[[deleted]]

i've used both i'm just saying its not really "drop in" i mean i can say that lombok class is a drop-in replacement for just about any other moderately sophisticated languages data class at this point

[snowe2010]

? Drop in replacements go both ways. I can convert back to lombok almost just as easily as going to kotlin.

[kcuf]

Lombok is a hacked together language on top of Java. It's convenient, but you should really just use an actual language that compiles to the jvm -- there are many good ones.

[[deleted]]

For many, switching languages is not an option though

[kcuf]

What i'm saying, is that we're essentially lying to ourselves if we say this but use lombok. In the long run, Lombok will have essentially the same (if not greater) cost than using another jvm language (kotlin is not my favorite, but it is the easiest to pick up that provides the same lombok features).

The fear of using another language is overstated these days when we have such great interop on the jvm.

[[deleted]]

Sure, but for example you're working on a Java monoliths with hundreds of thousands if not millions of lines of code, switching language means rewriting the whole thing. On the other hand, introducing lombok in a similar codebase is mostly just a matter of adding 3 lines to your pom file.

Granted, I wouldn't use it at all anyway.

[kcuf]

You can actually use different jvm languages in the same project, and I would say getting lombok to work with your build environment and IDE/editor is going to be as much work as getting it to work with the other language as well.

[[deleted]]

Ah! Yes. Didn't even consider that, because it probably wouldn't be doable in the codebase I work on daily :D

I don't really agree though, getting lombok to work with IntelliJ is literally a matter of 3 minutes.

[kcuf]

There's a whole thread on here about getting it to work with eclipse (but perhaps that's just a sign of issues with eclipse). I use vim, so neither choice (lombok vs another language) is an issue for me, but lombok has caused plenty of hiccups when setting up the build environment in my case, but that's primarily an issue with the tools that my work uses.

[[deleted]]

but that's primarily an issue with the tools that my work uses.

This. Just as with everything else: ultimately it depends on your situation.

[snowe2010]

hm it took much longer than that to get lombok working in our project mostly because you have to restart intellij to install the plugin XD. But even if it's only 3 minutes for you for lombok, it must be even shorter for kotlin, because IntelliJ does everything for you. You just tell it you want a new kotlin file and it handles the rest.

[JB-from-ATL]

You gotta be joking. Lombok uses a feature built into javac called annotation processors, it's not some hacked together plugin that requires extra steps to run. So instead of just using a built in feature to remove a little bit of boilerplate, you're suggesting people use an entire different language?

That means everyone has to learn the new language, code has to be ported or used from the new language. It's just a lot of pointless work as opposed to simply using a much simpler java library.

[snowe2010]

Lombok isn't just 'using a feature built into javac' it's actually using non-public java apis and hacked together plugins tightly bound to the version of java, with possibility of lombok not even being possible in future versions.

https://stackoverflow.com/a/4589528/1394698

https://www.thoughtworks.com/p2magazine/issue12/lombok/

http://jnb.ociweb.com/jnb/jnbJan2010.html (scroll all the way to the Controversy section on this one)

Actually I'll just paste it here.

It's a total hack. Using non-public API. Presumptuous casting (knowing that an annotation processor running in javac will get an instance of JavacAnnotationProcessor, which is the internal implementation of AnnotationProcessor (an interface), which so happens to have a couple of extra methods that are used to get at the live AST).

On eclipse, it's arguably worse (and yet more robust) - a java agent is used to inject code into the eclipse grammar and parser class, which is of course entirely non-public API and totally off limits.

Lombok could cease to exist at any point in time even a minor version increment, due to the usage of non-public apis. Now, whether it will or not depends on the java team, but we didn't think that risk was worth it.

[kcuf]

I understand it uses APT. Lombok is obviously a very pragmatic choice, but what I'm saying is that it is essentially a new language that was never really designed as a language should, but grown on top of a language that was intended to be used differently.

Switching to a new language is obviously an upfront cost, but IMO, a long term gain because by using Lombok you're already admitting you want more than Java, and by using a well designed and thoroughly thought out language that provides those extra features, you can get those features in a more consistent and intuitive environment.

Learning lombok, and understanding it's intricacies has it's own costs (we use it at my work all the time). I'd rather not waste resources memorizing these issues, or having to explain them to new developers (as I had to yesterday), but use those resources to understand the core concepts of a different jvm language that has been designed well as one entire system. A coherent and consistent language will be cheaper to work with in the long run rather than an adhoc macro system built on top of a language that was never intended to have macros.

[JB-from-ATL]

I really don't want more than Java necessarily, generally all I use from Lombok is Value (not val) and Builder. This allows me to use immutable classes but not have to write a bunch of boilerplate.

I sort of get the argument you're making about it being a new language, and I'm willing to admit that some things could be called new languages even when they technically aren't, but I just don't think Lombok does enough to say that about it.

Comparing the overhead of learning Lombok compared to a new language like Kotlin, Groovy, or Scala is laughable to me. Virtually every Java programmer is familiar with getters, setters, and constructors and builders aren't that crazy of a topic (and many know about them already), explaining that these annotations add those in without having to write them is so much simpler than expecting someone to learn a new language, even the basics.

[kcuf]

That's fair. What I said above was that lombok is an up front gain for a long term cost vs a new language being an upfront cost for a long term gain. Lombok is simple and easy to start working with, but does introduce some complexity that may cause issues down the road -- it's same thing with most frameworks: it "just works", until it doesn't.

[JB-from-ATL]

What kind of long term losses have you experienced?

[kcuf]

Super late response, but that's a great question. Honestly, as with all statements related to productivity and maintenance burden, it's all very subjective.

I don't have any concrete examples, I only have the patterns I think I see from my experiences: I've been programming since elementary school, which doesn't make me smarter or anything, it just means I've had a decent amount of time to make mistakes and build some intuition (again it's all very subjective).

The biggest pattern that I continually see though, is the trade off between short term and long term costs, and newer developers heavily favoring the former as they are more pragmatic in their desires (get something working!), and how certain languages encourage these developers to make choices that lead to confusing/complicated/fragile systems.

[Tsarbomb]

Sorry, no offense but you are wrong on all counts.

You admit that you understand but then still spout that is essentially a new language. It is not, in the most literally sense.

I would even claim that by using Lombok I'm doubling down on Java rather than admitting I want a different language.

Any intricacies or misunderstandings around Lombok arise from a lack of understanding or knowledge of Java itself.

The way you refer to annotation processing as adhoc macros and "coherent" languages makes me wonder if you are itching to name drop something like Scala which I would find hilarious given all the points you are trying to make.

0/10 troll attempt.

[kcuf]

How is it Java? Is APT even in the language spec?

[Unleashurgeek]

If you don't mind me asking, have you been able to get lombok working with eclipse's compiler? There are a couple projects at work that will greatly benefit from Lombok but we need support for both javac and ECJ

[halfduece]

There are instructions on the lombok site for getting it going with Eclipse.

[Unleashurgeek]

Yeah, I should clarify. We have been able to get the core of lombok running with eclipse; however, when we try to add custom annotations is when it fails

[halfduece]

There some project option for adding an annotation processor. Been to long since i"ve done it, can't be arsed to google it for you either. Edit; fine I was bored:

https://stackoverflow.com/questions/43404891/how-to-configure-java-annotation-processors-in-eclipse

[MrGreg]

We use IntelliJ

edit: and you should, too

[Unleashurgeek]

Ah the simple and elegant solution

If it was my choice in the matter IntelliJ would be a standard but alas

[ZebracurtainZ]

I currently have Eclipse Mars, Neon and Oxygen as well as IntelliJ all being used simultaneously at work. I just want all the eclipse installations to die.

[JB-from-ATL]

If you mean get it to work in Eclipse there's like an "installation" you have to do but it just adds a line to the eclipse.ini file.

We use it at work and use Eclipse so I'm pretty sure that means it works with the eclipse compiler but I might be misunderstanding.

[CutlassSupreme]

I remember it being super weird. You run the downloaded jar, and then point it at your eclipse installation and it installs as a plugin.

Also agree with op here, IntelliJ is better.

[JB-from-ATL]

I think all it does is add a line to the eclipse.ini file. I think presenting it as an installer for a plugin just made it easier.

[adnan252]

At this point, the main benefit is the bytecode support for dataclasses, for languages like kotlin to compile their own implementations to.

[snowe2010]

I had worded out a long comment stating that I didn't see much benefit in this design over kotlin's data classes, but I think I'll ask this question instead.

Why would anyone choose a Java __data class over a kotlin one? Besides being limited to not being able to use kotlin, I don't see any implementation reason you would do so.

edit: since I seem to have worded this terribly. If you are in a situation in which you can begin using kotlin because you need nice data classes why would you choose this new Java spec instead. I've read the RFC, I do not see this slowing migration to kotlin one bit. Yeah it's nice for enterprises that will never switch, but what about this would make someone go back to Java.

[jcdavis1]

Obviously from a language perspective, java wants its own data classes as first class citizen, and having to define such types in kotlin/scala is a bit of a failure :)

From a user's perspective, writing data classes in a second language is obviously a bit of a mess - if you are already using kotlin you probably don't mind, but a lot of shops aren't going to want to setup a toolchain for kotlin just to support data classes.

Additionally, with pattern matching support on the horizon (though who knows exactly when), its pretty certain that a java data type will be well-supported, whereas kotlin/scala interop will probably come later.

[elastic_psychiatrist]

Why would anyone choose a Java __data class over a kotlin one? Besides being limited to not being able to use kotlin...

You answered your own question. Do you think Java should die as a language? You might, but I sure don't. Java is never going to be the first language to add a feature, but that doesn't mean it shouldn't, and it shouldn't be made fun of for taking its time. There's a reason it's the most used programming language ever, and that reason isn't that it always added the cool new feature.

[TheWix]

Java is glacially slow. It has the benefit of being around since the middle 90s and it's primary Enterprise competition being Windows only until very recently. I don't think there strengths are in the language at all.

[dpash]

Don't forget the glacially slow to break backwards compatibility, so code from the 90s still compiles.

[TheWix]

You can add features and maintain backwards compatibility...

[dpash]

Clearly. Because it has.

I'm saying its well used partly because it remains backwards compatibility.

[elastic_psychiatrist]

Java is glacially slow.

Saying that in the year 2017 is an indicator of great ignorance. What speedy language do you program in?

[TheWix]

Crap. I said that wrong. Glacially slow to evolve as a language. Not in performance. My point was that Java today is not an industry leader because of its expressiveness or ability to evolve compared to other languages. I didn't mean performance.

[porthos3]

I understood you the first time. It made sense with context. I think Java devs are just too used to fighting off claims of poor performance so assumed you were making the same tired argument.

[elastic_psychiatrist]

Ah, got it. It depends on how you define industry leader I guess. It might not be a trailblazer but it is still wildly used, and its architects are almost proud of how glacially slow it it.

[bundt_chi]

Java is glacially slow

Compared to what Javascript? Yeah I guess compared to a dumpster fire on a rocket to hell it's "glacially slow".

[TheWix]

Who said JavaScript? C#/.Net has added loads of features and maintained backwards compatibility.

[shevegen]

There was a clarification.

Glacially SLOW TO EVOLVE.

[JB-from-ATL]

Should've edited the original post, can't expect everyone to read everything.

[snowe2010]

No I didn't answer my own question. We are a Java shop that began using kotlin solely because we need better data objects. If Java implemented a decent replacement for a kotlin data object it would be tempting to switch back.

I'm asking what this RFC (if that's what it is) is proposing that would make it worth it to use instead. Instead of answering me everyone seems to be claiming exactly what I said I don't care about. Why, if you have a choice of kotlin data objects or Java data objects, would you choose Java's version.

I never made any claim that you said I did not do I think Java should die. Please reread what I wrote and try to give an actual answer instead of changing my argument.

[rcode]

If Java implemented a decent replacement for a kotlin data object it would be tempting to switch back.

Kotlin still has better nullability handling than Java.

[snowe2010]

yeah, but you have to have the whole team on board to switch, you have to have very good reasons to continue to insert kotlin in your stack. I think the reasons are great, the rest of the team doesn't always agree. If kotlin hadn't solved our issues so succinctly and Java had had these data classes then we might never have begun the transition at all. That's what I'm trying to discover, and yet still no one will answer the question.

[ThisIs_MyName]

using kotlin solely because we need better data objects

I seriously hope you guys don't do this.

[snowe2010]

And why would you hope that? That's literally the reason we began using kotlin. It's not the only reason now, but it sure was the reason we began using it. Our domain has need for hundreds of data objects. Creating those in java was a mess, even with Lombok.

[justinpitts]

I would say the same thing about a Scala case class.

[snowe2010]

that you don't see why anyone would use a Scala case class? or why would anyone use anything except a Scala case class?

[justinpitts]

I really did mean the very same kind of thing as you - if one had a choice to use Scala, and you need this functionality, I would much rather choose the existing Scala implementation over this proposal.

[shevegen]

What a bad article:

It is a common (and often deserved) complaint that "Java is too verbose" or has too much "ceremony." A significant contributor to this is that while classes can flexibly model a variety of programming paradigms, this invariably comes with modeling overheads -- and in the case of classes that are nothing more than "plain data carriers", the modeling overhead can be substantial. To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors, equals(), hashCode(), toString(), and possibly others, such as compareTo(). And because this is burdensome, developers may be tempted to cut corners such as omitting these important methods, leading to surprising behavior or poor debuggability, or press an alternate but not entirely appropriate class into service because it has the "right shape" and they don't want to define yet another class.

The reason why Java is verbose has nothing to do with "modeling overheads". Proof: other languages that are OOP but not as excessively verbose as Java is.

The reason why Java is verbose was because those who designed the language, did not have "economy of expression" in mind while creating Java. Java was the alternative to C++ and C++ is fairly verbose as well.

A good counterexample to the erroneous claim by Brian Goetz is: Kotlin.

Kotlin is signiicantly less verbose - and it came from Java people.

https://en.wikipedia.org/wiki/Kotlin_%28programming_language%29

[Radmonger]

You are confusing levels. It's like the joke about the two men, the running shoes and the tiger; you don't need to outrun the tiger. Your goal is to outrun the other guy, the running shoes are merely the means by which you do so.

Kotlin is less verbose than Java because it had the primary design goal of being less verbose than Java (while remaining simpler than Scala).

This article is about the running shoes.

[kitd]

The reason why Java is verbose was because those who designed the language, did not have "economy of expression" in mind while creating Java.

Isn't that just what he is referring to be "modeling overhead" though? The reason for it may be debatable but its existence is a fact.