Feature Request - make Library data class stable about aboutlibraries

[mikepenz]

While Library couldn't be marked as Stable, there's now a new extension function which wraps the Library into an value class marked as Immutable:

https://github.com/mikepenz/AboutLibraries/pull/906/files#diff-c6dbf278529759cc4388375a78a41da6646173cf61895a7117d6a75dda58f46fR9-R15

Overall the compose code was re-worked to be more efficient through the above too.

[mikepenz]

If only the official one was available for multiplatform projects 🙃 .

And unfortunately the awesome temporary one from Skydoves doesn't yet seem to support wasm: https://github.com/skydoves/compose-stable-marker

[mikepenz]

I have now added a stability config file to the core module which is applied to the m2 and m3 modules.
https://github.com/mikepenz/AboutLibraries/pull/947/files#diff-712ed77459cddd5330863385aafe9b2ac858c77264e835c5a72dec5d292692ec

https://github.com/mikepenz/AboutLibraries/pull/947/files#diff-b652902b5629ab239e12e0496a86224dfaaf82622c8bd7163cd329d5ae1a4df8R56

As described here:
https://developer.android.com/jetpack/compose/performance/stability/fix#configuration-file

for the m2/m3 modules the stability looks good now.

[mikepenz]

Thank you very much for the suggestion. I will have a closer look into that.

Most likely the @Stable will be the choice, until all required targets are supported

[mikepenz]

Upon further investigation, the @Stable nor the @Immutable annotations can be added to the Library class, as those are part of the compose-runtime, however the core module of AboutLibraries does not have dependencies on compose.

Looking for answers, I could not find a proper solution other than adding compose to core which is not anticipated.

Open for other solutions.

[Nailik]

I also recently found out that @Stable is compose only. But data classes should be recognized by compose as stable when they are stable.
So checking that all variables are val and all lists are ImmutableList it shoud work. Also as far as i know the immutable library https://github.com/Kotlin/kotlinx.collections.immutable requires only kotlin and not compose so i should work.

[mikepenz]

However as you noted the immutable project does not support all the architecture targets this project offers. Until this is the case, it cannot be fixed within the core library unfortunately.

[Nailik]

Nice thank you @mikepenz that's pretty much how i solved it currently.

BTW there seems to be an open PR from a guy at Jetbrains that would solve the issue by adding the remaining targets Kotlin/kotlinx.collections.immutable#148

[Nailik]

With kotlinx.collections.immutable 3.6.0 there is now finally support for all architectures and i think this could now be reopened and worked on

[mikepenz]

Thank you for the update here.

[mikepenz]

Started working on this. However something strange is happening, which I don't understand yet:

the Library class will not have a clear runtime stability even though as all of it is stable.

Resulting in the Libs class being unstable.

[Nailik]

Maybe you could use the @Stable annotation on the Library to tell the compiler that it has runtime stability?

[Nailik]

I opened a post in the kotlin slack maybe they can help https://kotlinlang.slack.com/archives/C3PQML5NU/p1704560437578069

[MV-GH]

Did you ran it from a clean build to generate the compose compiler metrics? There was a bug where in incremental compilation it would incorrectly infer stability. Can't seem to find the exact issue at hand though.

[mikepenz]

@MV-GH yes I tried it on clean builds too. Unfortunately, it still resulted in these strange results

./gradlew clean aboutlibraries-core:assembleRelease -PcomposeCompilerReports=true 

Using this branch (added compose compiler to the core module to run the report): https://github.com/mikepenz/AboutLibraries/tree/test/compose_compiler_core

It's worth noting that I observed inconsistencies between reports (when I was testing different things) - and yes I can confirm that incremental builds made things very inconsistent :D.

Thank you so much @MV-GH for also looking into it