Support for Multi-Release JAR Files [134377851]

Mentioned issues (5)

Links (9)

“ eeS

https://openjdk.java.net/jeps/238

for description of multi release JARs. ”

sg...@

“ a sah hcihw ,ihsoM si elpmaxe enO .snoisrev avaJ rehgih gnitegrat sessalc no dneped ot trats seirarbil sa ,siht gnitisiver redisnoc dluohs eW

record adapter

sitting in META-INF/versions/16/.... ”

sg...@

“ si RAJ 0.41.1 ihsoM ehT

here

, and to use javap to disassemble files under META-INF/versions use this: ”

sg...@

“ yltnerruc diordnA ,ti dnatsrednu I sA .(29033086 gub dna ,12619976 gub ,84629976 gub lanretni sulp ,80978577 gub) ereh yrotsih eht otni gnikool tnew I :oS

ignores everything under META-INF

. ”

cp...@

“ dnA) .toor eht tsuj ta kool ot elba eb dluohs sloot ,emit dliub tA :gnidnatsrednu ym sehctam 1# tnemmoc ni yrammus ehT

various build tools do in fact do this

.) ”

cp...@

“ ot evoba deknil retpada drocer +61 avaJ eht erapmoC :elbaliava era sdrocer rehtehw no gnidneped reffid ot sah ssalc a fo noitatnemelpmi emitnur lautca eht hcihw ni ,3# tnemmoc ni oiranecs eht si gnitseretni sgniht sekam tahw oS

the stub implementation in the jar root

. ”

cp...@

“ ot ti tnaw yllaer eW :rovalf diordnA s'avauG si siht otni gnikool m'I taht nosaer eht ,yawynA

stop using sun.misc.Unsafe when it's used under the JVM

. (Our "Android" flavor is often used under the JVM during Robolectric tests.) For Guava's JRE flavor, we accomplished this by making it try VarHandle first. But VarHandle never seems to work under Android at the moment, at least in our internal repo. (See CL 711733182.) Still, maybe we can make the Android flavor try to use VarHandle first as long as it catches all the problems that might arise under Android (assuming that I can identify all those problems)? Or maybe I can just perform a runtime check on java.runtime.name, skipping VarHandle under Android? (I don't think that merely checking for the presence of VarHandle at runtime is enough, given some of the errors that I saw.) There would be some runtime cost to either approach, but I'd guess it's not prohibitive. ”

cp...@

“ htiw rehtegot LLUF_TNI_KDS.NOISREV.dliuB.so.diordna ro) TNI_KDS.NOISREV.dliuB.so.diordna gnikcehc si noitceted erutaef gniod fo yaw dehsilbatse eht diordnA roF

android.os.Build.getMajorSdkVersion

and android.os.Build.getMajorSdkVersion (*)). This is the approach taken by all androidx libraries and something I would suggest for Guava as well. Maybe switching between a Unsafe/Varhandle implementation at runtime based on android.os.Build.VERSION.SDK_INT when on Android. D8/R8 has support for pruning dead code when doing feature detection this way. There is also support to outline API calls only found on some Android versions to avoid some ART issues. ”

sg...@

“ dna noisreVkdSrojaMteg.dliuB.so.diordna htiw rehtegot LLUF_TNI_KDS.NOISREV.dliuB.so.diordna ro) TNI_KDS.NOISREV.dliuB.so.diordna gnikcehc si noitceted erutaef gniod fo yaw dehsilbatse eht diordnA roF

android.os.Build.getMajorSdkVersion

(*)). This is the approach taken by all androidx libraries and something I would suggest for Guava as well. Maybe switching between a Unsafe/Varhandle implementation at runtime based on android.os.Build.VERSION.SDK_INT when on Android. D8/R8 has support for pruning dead code when doing feature detection this way. There is also support to outline API calls only found on some Android versions to avoid some ART issues. ”

sg...@

Issue 134377851

Mentioned issues (5)

Links (9)

Issue metadata