I’m using compose BOM `2023.01.00` which brings in...

# compose

[Stylianos Gakis]

I’m using compose BOM 2023.01.00 which brings in androidx.compose.material:material:1.3.1. Some of my other deps, is bringing in 1.4.0-alpha04 apparently, which had some breaking change in rememberModalBottomSheetState.
Now I wonder, since gradle resolves 1.4.0-alpha04 instead at runtime, shouldn’t I also be getting that warning in my source code, so that the breaking change doesn’t let me compile in the first place?
Also jumping to sources when on that function brings me to 1.3.1. But running the app actually crashes at runtime since it’s using 1.4.0-alpha where it’s complaining that I am not passing a non-null parameter to the function.
Shouldn’t I be unable to compile in the first place instead in these cases?

[Yang]

Sounds like another precompiled library that depends on compose material is trying to consume the 1.3 bytecode at runtime which is no longer compatible since the actual compose material bytecode is 1.4

[Yang]

It’s both binary and source incompatible but I guess you’re not using the breaking APIs in your code so it compiles fine

[Stylianos Gakis]

Specifically I am using rememberModalBottomSheet, which in alpha is specified like this, where the confirmStateChange does not have a default paramater value anymore. In 1.3.1 it was confirmStateChange: (ModalBottomSheetValue) -> Boolean = { true }.
And in 1.4.0 there’s another function signature, where now the confirmValueChange does have the default parameter again.

But actually no, it is my own code which is trying to consume this API, not in the library. Specifically this line here.
So I really don’t quite understand how all these things interact with each other 😵‍💫

In the first place though, I’d have expected my IDE when doing Cmd + B on it to redirect me to the sources of 1.4.0-alpha, shouldn’t that be the case? Since gradle has resolved that as the chosen version? Because it doesn’t do that either.

[Yang]

I remember getting a compilation error with that api

[Yang]

The ide source navigation isn’t very reliable, sometimes it’s stuck in a particular version until the libraries are indexed again

[Stylianos Gakis]

Hmm yeah that’d make sense for the IDE. But shouldn’t gradle crash while building this? This passed even on our CI which was the surprising part. On CI it probably did not have the caches that I may have had in my local machine.

[Yang]

Then it has to be a binary compatibility issue with a 3rd player involved 😄

[Yang]

Can you check dependency insight?

[Stylianos Gakis]

Yes, I did find that I have one other library, which depends on accompanist 0.29-alpha, which in turn depends on something else which depends on material 1.4.0-alpha. So that’s where this one is brought in from.
But still, the code that crashes is on my source code, not from inside that library. I thought this is what you meant here right?

[Yang]

Yeah

[Stylianos Gakis]

Can you check dependency insight?

By this you mean doing like ./gradlew :app:dependencies > outputFile.txt right? And looking through it? Because that’s what I did

[Yang]

I’m not sure about how this kind of issues manifests in stacktrace but the code crashing on your code doesn’t sound right

[Yang]

You can use dependencyInsight and focus on the compose material library

[Stylianos Gakis]

The stacktrace is this from the minified build, at the start it points to exactly here.
I wonder if any of this is happening due to the fact that this module in particular does not depend on that 3rd party library which brings in the new material transitive dependency, but :app is the one that does that. And :app is the one which brings in the module which includes the linked code

Untitled

[Yang]

That sounds reasonable, as Gradle dependency resolution works in a project level, unless you set up resolution strategy in settings.gradle

[Stylianos Gakis]

Nope not doing anything in particular there.
Will try to see what dependencyInsight shows me, will do this as soon as I can find some time

[Yang]

You can run dependencyInsight on just that module to see what the resolved compose material version is

[Albert Chang]

When a library brings in a new version of compose, it only affects the module that depends on that library (and all the modules downstream). So maybe the line in question is in a module without that dependency.

[Stylianos Gakis]

If you happen to be part of the "Gradle Community" slack channel, I had a discussion in there about this exact problem and yes, the problem was exactly that :app was bringing the alpha version. The feature module was not (hence it was building just fine). But in the end, since :app also includes that feature module, it made it also use the alpha version, therefore crashing at runtime instead of at compile time.
A very interesting thing to learn about, I had no idea this could happen.

Solution is to either just bump everything to the latest version myself for now. But more generally I was suggested to consider using this Gradle feature https://docs.gradle.org/current/userguide/platforms.html to make sure all of my modules depend on the right version of that library by making them use this platform.
https://gradle-community.slack.com/archives/CAHSN3LDN/p1680088589320009?thread_ts=1680088589.320009&cid=CAHSN3LDN

[Colton Idle]

Going out on a limb, but do you use https://github.com/oleksandrbalan/modalsheet?

[Stylianos Gakis]

Nope, but I was using some alpha version of accompanist, 0.29.1-alpha in particular, which I think was the one bringing in the androidx.compose.material:material:1.4.0-alpha04 dependency.
I wish I could read the build scan I made to realize if this is in fact true, but I literally can’t understand reading through it 😂 That popup on the right side of the attached pic should probably be able to tell me, but I straight up don’t understand it 😵‍💫

The pic attached shows that :app was using the alpha dep, but :feature-businessmodel was seeing only 1.3.1, so the code in there did not know that it’d crash, but in the end, the app since it needs the alpha dep would make that module also use it, so the result is runtime crash.

So that was it, and til that this is possible to happen when you got a multi-module setup, I had no idea.

[Albert Chang]

You can also use ./gradlew -q :app:dependencies --configuration releaseRuntimeClasspath to get a text-based dependency graph so that you can find which dependency pulls in the alpha version by searching for androidx.compose.material:material:1.4.0-alpha04.

[Stylianos Gakis]

Before i try this, is there no way to figure this out from this website that the build scan shows me?

[Albert Chang]

I’m not familiar with this part of build scan but it’s the same info so you should be able to as well. However IMO it’s not straightforward and rather hard to search in this case.

[Colton Idle]

I can never understand build scan. i always end up printing out the dependency treat and cmd + f lol