I agree that would be very desirable. May I ask you for some more details about the conflicts you've got? Perhaps, there's some easy solution to the problems you were having...

@eiswind Oh interesting, thanks for elaborating. Yes, I've added my 2¢ to that Kotlin issue.

A workaround for the time being would be to generate data classes that do not implement the generated interfaces, or generate Kotlin data classes that contain delegate getters and setters...

Unfortunately, I don't think we can make a thorough fix in jOOQ 3.10 anymore. We'll definitely look into Kotlin code generation improvements in jOOQ 3.11, though.

@eiswind Hey Thomas! Were you able to move this forward a bit? In general, how are you doing Kotlin code generation? I want to give it a shot.

Currently we have a few big issues that hold us back from using jooq:

• The code generator does not generate immutable data classes in kotlin
• Nullability information for columns is not provided by the code generator ( How about generating jsr-305 annotations derived from not-null-db-constraints? Or generate kotlin with nullable-/not-nullable types).
• Java 8 Time API: We would like to use "Instant", rather than LocalDateTime to represent SQL DateTime / Timestamp. Since "Instant" is the perfect match for UTC epochmillis.

Is there any chance to get these features implemented one day? I would love to get rid of hibernate.

Thanks a lot. Jooq is great and might become awesome ;)

Thanks for your feedback, @bastman. Let me show you how none of these issues will hold you back:

The code generator does not generate immutable data classes in kotlin

Create your own for the time being! It's really simple, just extend the JavaGenerator in jooq-codegen and you're done!

That said, let me increase the priority of this particular feature request (out of the box kotlin data class generation)

Nullability information for columns is not provided by the code generator ( How about generating jsr-305 annotations derived from not-null-db-constraints? Or generate kotlin with nullable-/not-nullable types).

While I appreciate that people used to the convenience of Kotlin (or Scala, Ceylon, etc.) nullability guarantees would like to see this functionality also in Java, it is unreasonable to expect this from a SQL API. This is explained here:
https://blog.jooq.org/2017/07/25/5-things-you-may-not-have-known-about-jooq/#thing1

Anyway, this discussion has been had before many times, e.g. #4748 and #6244. JSR-305 is currently not an option for jOOQ's core, and if you like to have those annotations on your kotlin data classes, then see my previous answer, it'll be easy to generate them yourself.

Java 8 Time API: We would like to use "Instant",

Easy. Just write your converter: https://www.jooq.org/doc/latest/manual/code-generation/custom-data-types/

rather than LocalDateTime to represent SQL DateTime / Timestamp. Since "Instant" is the perfect match for UTC epochmillis.

Be careful though. Instant is not the perfect match for TIMESTAMP (without time zone!), although it might be the perfect match for TIMESTAMP WITH TIME ZONE, e.g. in PostgreSQL

Is there any chance to get these features implemented one day?

Sure. "One day" is a very broad specification, so I can certainly say yes to this question

I would love to get rid of hibernate.

None of the issues you've mentioned should keep you from doing that. The overall gain is still magnificent if you're sure that jOOQ is a better fit than Hibernate - because these design decision are much more higher level than individual data types.

Besides, from the way you phrased this, I'm sure you've already decided anyway.

Hope this helps :-)

We're definitely (finally) going to implement a new way generating DTO types in jOOQ's code generator, perhaps even replacing the term POJO (whose J means Java) by DTO in generated package names and API. The main issue here is #3821, in whose context Kotlin data classes will also be supported.

No existing logic will be removed, it will just be reorganised to better allow for further extensions, like this one.

@lukaseder - any update on the Kotlin data class for pojos? Is that a part of the 3.13 release?

Haha, promises... Every. Single. Time. Why do I keep making them? No, this is not part of any release yet.

I recognise a lot of people want this.

In the meantime, I've invested some time in a new jOOQ-kotlin module: #6256. Its purpose is to offer a better out of the box experience by providing a few extension methods for useful things.

Any feedback in that area that you folks may have is very welcome!

I will address this now for jOOQ 3.14 via #6248. I don't think that generating data classes in isolation makes sense. I'd like to offer the same feature set as for Scala, a complete KotlinGenerator that generates kotlin code for all objects.

Implemented via #6248 (push to github pending)

A nice feature when implementing an entire KotlinGenerator rather than "just" data class support is that we can use Kotlin properties also in interfaces and records. This will lead to a more consistent, complete experience, rather than having to wrestle with interop things like https://youtrack.jetbrains.com/issue/KT-6653

I mean, why not:

ctx.batchStore(
  BookRecord(id = 1, title = "Effective jOOQ")
  BookRecord(id = 2, title = "Just use SQL")
)

When generating Kotlin data classes with optional parameters, such as:

data class T(
      val i: Int? = null
    , val j: String? = null
)

Then, the existing RecordMapper implementation is wrong and no longer works. This is independent of adding better code generation support for Kotlin and can happen with manually written data classes as well. I've created an issue for this: #10194

There will be a flag to opt out of this in the KotlinGenerator: #10288