Hi everyone, I'm working on a Compose Desktop app...

# compose-desktop

[Ryan Smith]

Hi everyone,

I'm working on a Compose Desktop app that includes Retrofit and the need for XML {de,}serialization.

I started down the road using simple-xml, but found out later that Retrofit's Simple XML converter is deprecated in favor of their JAXB converter.

The interesting thing is that there appears to be two: jaxb and jaxb3. The former seems to be based on javax.xml.bind (which I think is the Oracle JAXB implementation), while the latter is based on the Jakarta JAXB implementation from The Eclipse Project.

Are there any license or other issues with using the jaxb converter (and, by extension, javax.xml.bind)? I'd prefer the Jakarta-based converter, but I can't find an artifact for it on Maven.

I suppose a more general question is "which is the recommended XML converter to use with Retrofit?"

[jw]

You can also use kotlinx.serialization

[jw]

With an XML text format

[Ryan Smith]

From what I've read kotlinx serialization doesn't support XML and has no plans to. There's [this](https://github.com/pdvrieze/xmlutil), though, which the developer has said is pretty stable. Is this what you mean?

[jw]

Yes

[Ryan Smith]

🙄 at embedded link formatting on mobile

[jw]

Someday they'll let us remove it like they do on desktop

[Ryan Smith]

🤞

[jw]

I don't have any examples of using it with Retrofit. I have an example with OkHttp

[Ryan Smith]

That would help, I might end up using OkHttp directly anyways. This is for an XML-RPC API, and while Retrofit is working I think I'm lightly misusing it

[jw]

https://github.com/JakeWharton/dependency-watch/blob/trunk/src/main/kotlin/watch/dependency/maven.kt

[Ryan Smith]

Thanks for sharing!

[jw]

Configuring Retrofit, if you wanted, is as easy as calling asConverterFactory on the TextFormat instance (which should be XML type) and then adding it as normal, and using the models in the body or return position of an interface function

[Ryan Smith]

Wow that's pretty convenient

[Ryan Smith]

asConverterFactory from this dependency?
"com.jakewharton.retrofit:retrofit2-kotlinx-serialization-converter:0.8.0"

[jw]

Yes. It's moving into Retrofit proper soon

[jw]

Hopefully for the next release

[Ryan Smith]

Ah, very cool

[Ryan Smith]

Getting a pretty hefty compile error while using kotlinx.serialization.

Here's the short version:

org.jetbrains.kotlin.backend.common.BackendException: Backend Internal error: Exception during IR lowering
File being compiled: /home/rsmit/repos/github/koji-buildroot-resolver/src/jvmMain/kotlin/data/net/xmlrpc/MethodCall.kt
The root cause java.lang.RuntimeException was thrown at: org.jetbrains.kotlin.backend.jvm.codegen.FunctionCodegen.generate(FunctionCodegen.kt:49)

[Ryan Smith]

I'm going through my dependencies right now, somehow I ended up with both kotlin 1.8.0 and kotlin 1.8.10 in the mix

[Ryan Smith]

Update: that did not help. Thought I was able to get everything up to 1.8.10, but I think Compose Multiplatform 1.3.1 needs 1.7.10

[jw]

There are versions for 1.8.0 and 1.8.10

[Ryan Smith]

I thought Desktop 1.4.0 was still in alpha?

[jw]

1.3.1 is for 1.8.10

[jw]

1.3.0 for 1.8.0

[Ryan Smith]

Dang, that's what I'm using so that's not the problem then

[Ryan Smith]

Side note: is there a compat matrix like this for desktop?

https://developer.android.com/jetpack/androidx/releases/compose-kotlin

[Ryan Smith]

This table is why I said "I think ... 1.3.1 needs 1.7.10"

[jw]

I look at the releases on the JB repo which each link to the corresponding AndroidX Compose compiler which then you can use that matrix with (or usually it will just say)

[Ryan Smith]

Oh yeah look at that! https://github.com/JetBrains/compose-multiplatform/blob/master/VERSIONING.md#kotlin-compatibility

[jw]

Even better

[Ryan Smith]

Even more confused about this code gen error now, but at least I learned something in the process

[Ryan Smith]

Figured it out. In XmlSerialName one must provide a value for namespace and prefix even if they're empty strings.

@XmlSerialName("methodCall", "", "") instead of @XmlSerialName("methodCall")

[Ryan Smith]

Buried deep in the stack trace was this, which lead me there:

ERROR_EXPR 'Stub expression for default value of namespace' type=kotlin.String

[Kirill Grouchnikov]

JAXB still around? I had a session on it at javaone back in 2005 👀

[jw]

It, like too many, were forced to migrate package names in the javax debacle. Otherwise still very much useful since not much has changed since 2005

[Kirill Grouchnikov]

Back then there were around 20 competing xml serialization libraries. I had a benchmarking project on java.net to try and compare them

[Kirill Grouchnikov]

Courtesy of web archive

[Ryan Smith]

I've tried out 3 just today, but I'd still wager there are far fewer than 20 stand-out XML libraries now that JSON, protobuf, et al are a lot more popular

[Kirill Grouchnikov]

XStream is still around. Impressive run.

[jw]

Jackson/Woodstox also a good choice today

[Ryan Smith]

Jackson was next on my list to try before kotlinx.serialization came up

[Konstantin Tskhovrebov]

https://github.com/Kotlin/kmm-production-sample/blob/compose-app/shared/src/common[…]ithub/jetbrains/rssreader/core/datasource/network/FeedParser.kt

you can find another sample here 😉

[Ryan Smith]

@Konstantin Tskhovrebov - I noticed some nullable types in your data classes e.g. link: Stirng? but don't see any corresponding configuration for handling nulls. Are fields like link only null if they are omitted? If something like <link>null</link> appears in the XML?

[Ryan Smith]

I'm asking because in this XML-RPC APi I'm working with nil is a possible value, and I'm not seeing a way to configure my XmlFormat to handle that as null

[Ryan Smith]

Looks like I got lucky and it's actually represented as <nil/> , which I can represent with an object.