How to find if androidx is building against java 8...

# random

[Colton Idle]

How to find if androidx is building against java 8 or java 11?

[Colton Idle]

im trying to find some canonical source saying its java 11. but if i set my android app to build against 8, then it still works fine.

also noticed this https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:buildSrc/private/src/main/kotlin/androidx/build/AndroidXImplPlugin.kt;l=1464;bpv=1

[Youssef Shoaib [MOD]]

I think there's some magic where newer Java features get desugared to support older platforms. Android technically doesn't run JVM bytecode even, it runs compiles DEX bytecode when the app first launches

[Colton Idle]

just weird because im trying to build an app that uses compose. and it uses java 8 and it works. meanwhile release notes say java 11

[Youssef Shoaib [MOD]]

That's the compiler, as in the compiler plugin I believe. So it's about the version you use to run your compilation with, not the version used at runtime

[Colton Idle]

yeah. im referring to this tho

compileOptions {
sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11
}
kotlinOptions {
jvmTarget = "11"
}

that comes by default in a new android app (file > new project)

it comes with compose by default. and somehow still compiles fine if i bump that down to java 1.8

[Youssef Shoaib [MOD]]

Basically, I don't think Compose actually has a minimum Java version. The compose plugin needs Java 11 on your system at compile time, but compose code at runtime doesn't seem to have a specific advertised minimum version. Also, Android does some funky stuff to let you use newer Jvm features on older SDK versions. According to apilevels.com:
> • Jetpack/AndroidX libraries require a minSdk of 21 or higher since April 2024.
> • Jetpack Compose requires a minSdk of 21 or higher.
Compose Desktop apparently supports JDK 11+
It's really hard to figure out what Android versions "map" to what Java versions (because Android technically isn't running a JVM). This docs page kind of suggests that SDK 26 supports all Java 8 bytecode features, with most bytecode features being supported with no minimum sdk.
This page suggests that Android 13+ supports Java 11, and Android 14+ supports Java 17.
Ultimately, what this means is that Compose is compatible with Android 21+, and so that's all you need to worry about.

[trevjones]

you might try downloading the gradle .module file and see if it has that info in it.

Otherwise unzip the aar and see what bytecode version the .class files are using

[trevjones]

yeah should be in the module metadata.

[Colton Idle]

oooh. ive tried this with other aars (even aars that i generated) and didn't see it in there. is the .module file the one thats shipped alongside the aar (i.e. i dont have to unzip, right?)

[trevjones]

yea. .module is like the gradle version of a .pom that gets published. its just a json file

[trevjones]

IIRC they started going up by default around gradle V4 or V5

[Colton Idle]

thanks. let me try to find em.

[Colton Idle]

cool cool. i see it here. matching their docs. woot

[trevjones]

nice

[Colton Idle]

funny enough. generating and publishing a new aar in latest AS, latest gradle, etc doesn't seem to add a org.gradle.jvm.version prop in the .module

[trevjones]

interesting. might be down to something with how AGP registers stuff with the publishing plugin?

[trevjones]

let me look at some of my AAR module files. one sec

[Colton Idle]

thanks. thatd be a nice sanity check.

Otherwise unzip the aar and see what bytecode version the .class files are using using javap did work though. i can confirm my jvm i ahve set that way. .module would be nicer though (mostly because the ide would block the build vs building successfully and crashing)

[trevjones]

yeah you are right. aar doesn't put the attr in the .module.

[trevjones]

I wonder if it they write it somewhere in the AAR. pretty sure I have seen AGP get angry about importing a library that targets a higher JVM than your current project does

[trevjones]

maybe in the manifest file

[trevjones]

no dice. probably just have to javap to get that info.

[trevjones]

IMO that might be worth an AOSP ticket to ask them to put it in the .module data

[trevjones]

if you feel so inclined link it back here and I'll star it

[Colton Idle]

last week lol https://issuetracker.google.com/issues/463409692

[Colton Idle]

as im digging into library dev for the first time im just like woah. this is a whole new world. and theres so many things that i thought would work, but dont. lol

[Colton Idle]

need to remember to write all of this up. lol

[trevjones]

It is way better now than 2019/2020 IMO. Biggest pain remains having a maven server that fits your needs

[Colton Idle]

i found the docs around jfrog and nexus pretty bad? i guess they just try to steer you towards their paid products. but once its up... it works well! also gcp hosts maven artifacts too. so that was a nice surprise. im kinda in this in tandem in two paths. 1 is for a public artifact. and the other is for an internal only library.

[trevjones]

yeah for me everything is private so I get to just ride the jfrog/artifactory wagon. But I refuse to use their gradle plugins. I don't trust them to do it right

[Colton Idle]

didn't even know they had plugins. i just use the built in maven publishing. seems to get the job done.

[trevjones]

I think its for doing sbom or some other security type stuff. probably links artifacts to builds in their UI. or so I assume

[trevjones]

but yeah just off the shelf maven publish feels right. no vendor lock in that way

[Colton Idle]

honestly the last thing i have to tackle is local maven and see how that works. for right now im just running an instance of nexus locally 😅

but i like it. it allows me to see what consumers ultimately see, generated aars, test how in-place artifact generation works. etc

[trevjones]

maven local should just work. Though I basically never touch it unless for testing my plugins