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

[殷啟聰]

Hi Markus,

I have set their Java version to either 1.6 or 1.7, except for
data-binding  as it sets the version explicitly.

As for JaCoCo, Lintian does not warn the Java version, I guess it
already sets the version? If not, we may use a
debian/maven.properties.

Cheers,
Kai-Chung Yan

2016-07-28 18:57 GMT+08:00 Markus Koschany <apo at debian.org>:
> 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
>
>



-- 
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: <https://linkedin.com/in/seamlik>
* Blog: <http://seamlik.logdown.com>
*/