This was the tip that finally solved it! Here's the commit: https://salsa.debian.org/android-tools-team/android-framework-23/commit/a54bfa906afc9b139f1f6c1a99f76effec301a3e
.hc Michael Rogers: > Hi Hans-Christoph, > > As far as I can tell, "javac --patch-module" won't get you where you > need to go. You could create (perhaps using symlinks) the directory > structure it's expecting, where the root of the package namespace is > inside a directory named after the module (e.g. > src/main/java/java.base/java/lang), which contains a suitable > module-info.java. But even so, --patch-module would result in the code > being compiled as a module. You'd then need to modify the rest of the > toolchain to get every java call to consume that module. I don't know if > that would even be possible for d8, ProGuard, etc. > > I think what you probably want is for the code to be compiled as Java > 8-compatible class files. If I've understood the email thread correctly, > that should be possible, and it's encouraging that adding "--release 8" > to the compiler options has reduced the scope of the problem to just the > doclava call. In other words, it did solve the problem for the other > javac calls. > > This is just a random guess that you've probably already considered, but > is it possible that the "--release 8" argument that's passed to javac > isn't being passed to javadoc when running doclava? Perhaps the task > type for javadoc isn't JavaCompile, for example? (The same might apply > to -source and -target, I guess - I don't know if sourceCompatibility > and targetCompatibility set those arguments for javadoc as well as javac.) > > Cheers, > Michael > > On 31/01/2019 08:25, Hans-Christoph Steiner wrote: >> >> The Debian Android Team has been packaging the Android SDK with 100% >> free software and reproducible builds. The standard Android SDK >> binaries from Google have a non-free license and are built with ~13GB of >> mystery binaries they call "prebuilts". >> >> There are two key packages from the Debian Android Tools suite of >> packages that are currently not going to make it into the buster >> release. The core of the problem is that buster is using Java 11, and >> the Android AOSP code base still uses Java8 and, only in some cases, >> Java9. As far as I can tell, just rebuilding the current stretch >> package or updating will have more or less the same problems there. >> >> So far, apo of the Java Team, seamlik of Java/Android teams, and I have >> all tried quite a bit to get something working. Now we are banging our >> heads against details in Java builds that none of us have ever dealt >> with before. So we're putting out the call for help, to find someone >> with this knowledge. Right now, I think we need to figure out the new >> Java9 "modules", specifically using the --patch-module= flag to javac >> and java. >> >> Lots more details here: >> https://lists.debian.org/debian-java/2019/01/msg00052.html >> -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
