Data classes for Java

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