[Android-tools-devel] RFS: android-platform-libcore/6.0.1+r55-1

[Markus Koschany]

On 28.07.2016 12:18, 殷啟聰 wrote:
> Hi Markus,
> 
> I pushed all the changes that you advised, except for the Java version part.
> 
> According to the Lintian tag's page [1], this warning is supposed to
> warn that one is compiling Java codes to a Java version that is
> incompatible with the default JVM in Debian. However the default JVM
> version in Debian Stretch is already Java 8, I don't think it's
> incompatible. Since the build script doesn't specify any Java version,
> it automatically choose one, which is seemingly the latest one. If we
> backport these packages to Jessie, they will be compiled in Java 7
> which is also compatible with the default in Jessie. We only assure
> the compiled Java libraries can be run inside Debian, does we not?
> 
> I also noticed a bug [2] reported on this issue, though no one is replying.
> 
> [1]: https://lintian.debian.org/tags/incompatible-java-bytecode-format.html
> [2]: https://bugs.debian.org/829592

Yes, I know the bug report. There are at least two aspects in this case.
Most recently I fixed

https://bugs.debian.org/cgi-bin/832568

If you compile libraries against the latest JRE version but an
application that depends on those libraries also supports older JDKs,
you will get a runtime error. So you could say that the app should
enforce the dependency on the most recent JDK but I think it is the
other way around.

Debian is a binary distribution, so it is not totally uncommon that
people will install packages from a newer Debian release but still use
an older JRE. Whether this is a release critical issue is debatable in
my opinion because we actually don't support mixing different releases.
On the other hand we also ensure that our packages use versioned
dependencies if required and it is better to define a lowest common
denominator for maximum compatibility in Java anyway.

It is also better to control byte code compilation instead of simply
relying on the current default-jdk and date of compilation.

I think it shouldn't be too hard to use the sourceCompatibility and
targetCompatibility options in Gradle.

Regards,

Markus


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20160728/8917dcbd/attachment-0001.sig>