Why was the decision made to support proguard work...

# compose-desktop

[spierce7]

Why was the decision made to support proguard workflows, instead of an r8 workflow? R8 has many more compose optimizations, right?

[eygraber]

I think R8 is more closely related to dex. Not sure which parts operate on jvm bytecode and which are dex but that's probably got something to do with it.

[spierce7]

R8 operates on bytecode

[eygraber]

From https://r8.googlesource.com/r8

R8 is a java program shrinking and minification tool that converts java byte code to optimized dex code.

[spierce7]

I realize it says that, but I’ve seen others use r8 for optimizing jars for non-dex / non-android uses, and I’ve also personally done it.

It, just like proguard, works on bytecode.

[jw]

R8 can produce either dex or java bytecode, as Scott said

[eygraber]

So it could be used (in theory), or there's another reason why it can't?

[jw]

It could be used. No theory about it!

[Thomas]

Can confirm, I am already using R8 for months in production for my app Hue Essentials for Windows and macOS

[spierce7]

I was never able to get r8 to compile correctly / consistently with compose. I can’t remember why. I know you and at least one other have gotten R8 working though.

[alexey.tsvetkov]

Why was the decision made to support proguard workflows, instead of an r8 workflow? R8 has many more compose optimizations, right?

Well, we have not intended to introduce ProGuard primarily for optimizing bytecode. The primary reason behind introducing ProGuard/R8 is to simplify shrinking and/or obfuscation for our users. It was requested multiple times in this channel and in our issue tracker. Both tools should be similar in this regard.

Despite the fact that it can output bytecode, R8 seems to be positioned primarily for Android development. For example, there are no non-Android specific docs. At the same time it does not guarantee 100% compatibility with ProGuard. It feels weird to tell users: “Hey, we added support for R8. It’s like ProGuard, but might be a little different. It also does not have own docs, but since it more or less like ProGuard, so look at the ProGuard docs. Good luck!”

Just to clarify, I don’t mean to strictly prefer one tool for another. We can support both, probably. But we had to start with something, and I don’t see the vague “more compose optimizations” as a very compelling argument for starting with R8.

[jw]

Are there even Android docs for R8? The tool is pretty opaque. That being said, the usage is exactly the same with just a flag toggling between the backends.

[jw]

And if you need confidence, part of the release process of R8 is R8 running over the R8 jar.

[hfhbd]

docs no, but the help command shows the jar option

[mikehearn]

I've used R8 with desktop JARs, it worked OK. I agree it's weird to point people to ProGuard docs for R8 though. These tools should probably become implementation details that power a higher level abstraction over what you want

[mikehearn]

The Compose optimizations seem pretty specific and powerful, looking into them. Lambda grouping, for example. There are articles exploring this and saying they're so effective you should never test performance in debug mode at all, you should only use a fully R8 optimized binary for testing. JITC is apparently not enough to properly optimize compose generated bytecode.

[jw]

That claim is for Android's interpreter and JIT, not the JVM

[mikehearn]

Yeah but a lot of the optimizations wouldn't be done by HotSpot either. Possibly you'd get some with graalvm native images, because that can do a whole program analysis

[jw]

Whole program analysis tends to offer immediate access to constant performance but not optimal performance. I'm not ready to make any claims about what Hotspot would or wouldn't do in comparison to ART. It will certainly do a lot more in quantity of optimizations and has the ability to re-JIT at will whereas ART will be much more conservative given the battery-powered nature of its usage (generally, at least)