Consider switching to Skiko

[kirill-grouchnikov]

The original dependency on Skija was recently updated to a fork of Skija. I would suggest looking into switching to Skiko instead - which is Jetbrains' replacement for Skija, and is being used as the graphics foundation of Compose for Desktop.

Upsides:

• if the goal is to enable usage of chart libraries in Compose for Desktop, then Skiko is the right dependency to have
• continued, ongoing investment from Jetbrains into the library
• can remove a bunch of null assertions and tests as nulllability is built into Kotlin

Downsides

• requires switching to Kotlin instead of Java, as Skiko is Kotlin bindings to Skia
• bigger dependency footprint, as Skiko contains more than just Skia bindings

I have kirill-grouchnikov@aa8eab2 as proof of concept. What it has:

• switching to use Kotlin. Note that the translation is automatic, and there's a lot of cleanup to be done to make the code look Kotlin native
• switching to use Skiko 0.6.6. Note that the latest is 0.7.2, but I didn't want to look too deeply into the specific dependencies that are needed. Right now I'm just hardcoding skiko-jvm and skiko-jvm-runtime-macos-x64 in there
• some tests still fail. I started "fixing" the tests, but it's just tedious, as most of those still failing are around nullability checks and are not relevant in the world of Kotlin

Note that this is a proof of concept for your consideration. If you decide to go down that road, I can help with questions, but I'm not going to own the full switch to Skiko.

[jfree]

Thanks Kirill! It's a good suggestion, I'll take a look at what you've done. I think it would make sense to leave SkijaGraphics2D as is and start a new project SkikoGraphics2D - let's see if I find time for that. 😄

[hakanai]

I got tricked! LOL

The front readme suggested that this would work for Compose Desktop and that's my exact use case. It took me a while to notice that there were two different Skia bindings on the classpath.