I have already added

"io.ktor:ktor-client-jackson:$ktor_version"

We use Gson, and include “io.ktorktor gson1.0.0” in our gradle without issue and without specifying serialization. Might want to try asking in #ktor

I added Kotlinx maven to repositories and it was solved. It would be nice if someone explained why json-jvm needs Kotlinx.Serialization #ktor

I think ktor is moving towards a multiplatform implementation. It would be a smart move to use the kotlinx.serialization way to make json as that would be applicable to all platforms, and less code would have to be duplicated.

I'm already using Jackson with Kmongo in my persistence layer.

when I run my ktor API from the intellij play button thing it works but when I use gradle run it fails to find kotlin serialization at runtime after I make a request

any ideas?

probably a subtlety in how your classpath is set up. IntelliJ doesn’t quite do it the same as gradle

In my experience gradle’s dependency management has been more accurate. That doesn’t mean it’s helpful in your case. 😉

the different serialization version seem like a culprit but I'm unsure how to debug classpaths exactly

Ah. Just specify a dependency on serialization with a version explicitly; then both should have the same opinion of what jars to use

Hi all, I'm working on a kotlin/spring-boot project that needs to connect to 2 different databases. While testing, I need to execute 2 different sql files for each database data initialisation like this:

@Sql(executionPhase = Sql.ExecutionPhase.BEFORE_TEST_METHOD, scripts = ["classpath:script2.sql"], config = SqlConfig(dataSource = "dataSource1")) @Sql(executionPhase = Sql.ExecutionPhase.BEFORE_TEST_METHOD, scripts = ["classpath:script1.sql"], config = SqlConfig(dataSource = "dataSource2")) @Test

But I'm having this compilation error: "Repeatable annotations with non-SOURCE retention are not yet supported"

Is Kotlin with JEE a good idea? As in, are there any drawbacks, or things that make Kotlin not compatible/not adequate?

you might run into a need to open up a bunch of classes

or use all-open plugin

Other than that, there's no particular problem?

shouldn’t be

For a webservice, we generate Java class from a xsd file, using XJC. But I would be better if we can get Kotlin data class instead. My first approach would be to generate Java class then run annotations processor to generate Kotlin data class version using KotlinPoete. Did you get this kind of issue too? How did you solved it? What do you think of my approach?

Depends on how much you stand to gain by having a data class. What sort of bugs would such a tool help you avoid? In my usage for generated code it hasn’t proven to be much of a problem to have the classes be Java since “populate the object that’s an instance of a generated class” is generally pretty self contained and only used immediately before serialization or whatever, but YMMV

We wants to enforce the use of immutable objects using data class + val + named parameters.

ok, but why? Are you shuttling these DTOs throughout the codebase? if so, that might not be a great idea, but again it’s situational. If not, then you’re probably not buying much.

I’m not saying it’s bad just that maybe the engineering hours it would take to build and maintain your own custom code gen may have higher ROI elsewhere

You got a point. Currently, the process is creation Java object using XJC then converting it in Kotlin using IntelliJ, change it to data class, updating annotations, …. As you noticed everything is done manually. Which is a bad process. That’s why I was thinking to help the team to automate it. But I didn’t questionned enought the needs of Kotlin. But, there is one case where the use of Kotlin is valuable. I didn’t check the generated Java class, but with our DTOs in Kotlin, we can’t create an object without all required/mandatory fields (thank’s to the constructor with named parameters). But I’m afraid that with the Java class, the code will compile without all mandatory setted (no thanks to the no-args constructor).

@dwursteisen there’s a dedicated plugin for the kotlin compiler named no-args it’s used for jpa it creates a synthetic no-args constructor for classes annotated with

@Entity

so that your cannot access it directly but jpa can using reflection quite handy 🙂

This is what we’re using (because JAXB needs it too.). My concern is more about creating an object from Java generated class without settings all mandatory fields. (Because I think ; I didn’t check ; that XJC generate class with no-args constructor). While with Kotlin (and even with no-args plugin), you/a developper can’t create an object without setting all mandatory fields in the constructor.

as @mp hinted, it’s a cost/benefit ratio decision i’m afraid only you can decide

since you would presumably know when the schema changes, it means that the times when you would introduce a bug by not setting a newly added field are at least limited

so while I’m all in favor of compile time where possible, this is at least a more constrained problem than “populating an obj via setters” is typically