A modern programming language that makes developers happier.

kotlinlang

are there recommendations for moving from Java to Kotlin for hibernate? in particular, i'm trying to get the best null safety i can get... There is this <https://medium.com/swlh/defining-jpa-hibernate-entities-in-kotlin-1ff8ee470805> but...my issue is, if i set nullable=false...that should be a @nonnull object, because i know it's an impossibility for it to happen in my scenarios. How can I get that though? do I need to use lateinit here?

You can take a look at how i do it:
<https://github.com/linda-project/linda/blob/main/src/main/kotlin/dev/d1s/linda/entity/shortLink/ShortLink.kt>

I use constructors in most cases

I wouldn't recommend using `lateinit`  on JPA entities

The medium article you provided does not consider existing kotlin jpa plugin which in my opinion is the critical go-to when working with Kotlin and JPA (<http://start.spring.io|start.spring.io> includes it by default when you link Spring Data dependency) - with it you could write your classes as you would normally do it in Kotlin, preserving null-safety, immutability etc. and the plugin will take care of generating complaint bytecode.
Sample article about it:
<https://www.baeldung.com/kotlin/jpa>

<@U02Q05JJF7S> yep that sounds nice to me. So, they *have* to use the ctor init to do this, right? not exactly pretty if you've got a 20 column entity with annotations everywhere and mappings

<@U02D5CGFR0F> i'm surprised you don't just use lombok. Implementing your own hashcode/equals/string all the time is so much duplication versus @ToString @Equals

Simply because there are problems with it

seems that there is kapt or the lombok plugin. but i'm unfamiliar with what kinda problems there might be

<@U0JRS2YUB> I'm not sure if I understand you correctly, but you yourself don't have to write a no-arg constructor for entities, and the one generated by the plugin is only to be called via reflection.
You can read about it here:
<https://kotlinlang.org/docs/no-arg-plugin.html>
If you meant that having a single large constructor is a must (which can be ugly for entities with many fields) then it isn't - from the code perspective, you can work with entities as with other classes and use factory methods, secondary constructors, custom builders or whatever suits you.

And as a side note, I also don't use Lombok for Kotlin projects. For model classes I usually use data classes that provide equals, hashCode, and toString out of the box and for JPA entities I usually have a single MappedSuperclass having equals and hashCode implementation. I hardly ever need custom toString for JPA Entities. All in all, I couldn't work with Java without Lombok but don't need when working with Kotlin

A late notice: you may also check <http://bootify.io|bootify.io> for a Spring Boot app with database model, also not using dataclasses because it's creating problems