Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7
On 2015-05-27 08:09, tony mancill wrote:
> On Tue, 26 May 2015 17:54:17 +0200 Niels Thykier <niels@thykier.net> wrote:
>> On 2015-05-26 17:25, Thorsten Glaser wrote:
>>> On Tue, 26 May 2015, Niels Thykier wrote:
>>>
>>>> I agree that the is a good idea to clarify this. My personal
>>>> recommendation is to declare that:
>>>>
>>>> * gcj-jdk is not considered a suitable Java implementation for our end
>>>> users nor for implementing the default-java.
>>>
>>> Please do not do that. Way too much software, even *really* deep
>>> down in the cycle, things like gettext, depend on default-jdk and
>>> build java versions of their libraries. Even if they don’t work
>>> as well as the OpenJDK versions, or don’t work at all, they still
>>> prevent the source packages FTBFSing and provide Build-Depends for
>>> lots of other packages.
>>>
>>
>> While a valid concern, I personally disagree that this is sufficient
>> reason to keep the "silently broken" behaviour, which is our status quo.
>> That said, as I am not going to implement the change, I am not the one
>> you need to convince.
>>
>>> If you really want to go this route, please ensure that Debian can
>>> still work on OpenJDK-less architectures first, by removing the
>>> java packages from all those source packages.
>>>
>>> Thanks.
>>>
>>> bye,
>>> //mirabilos
>>>
>>
>> This is certainly a possible solution. Another would be to make them
>> build-depend on gcj-jdk, if they are truly java5 compatible. I believe
>> gettext is mostly in the latter category - my guess is that they have
>> not touched those bindings considerably in many years.
>>
>> My concern with gcj-jdk implementing default-java is that it leads to
>> silent breakage because gcj-jdk is stuck in ("almost") Java5 support
>> while Debian is moving to OpenJDK-8 with lambda functions, tons of new
>> classes etc. This breakage is /not/ discovered by us, but by our end
>> users that consumes ports without OpenJDK support and I think that is
>> the wrong signal to send to our users.
>
> This is primarily a +1 regarding the points that Niels has made...
>
> Requiring gcj-jdk/Java5 compatibility in any broad sense ignores the
> evolution and current state of the language and applications as they are
> used by the large majority of our users. (It also turns the "busy" knob
> up to 11.)
>
> So it seems like life would be easier if default-jdk were equivalent to
> openjdk-7. This still covers a large number of architectures [1], and
> comparing these to the ports supported by default-jdk [2], the only
> architectures left out are: hppa, hurd-i386, and m68k. (I believe that
> sparc *is* sparc64, if I'm not mistaken.)
I suspect mips and mipsel are soon to be added to the "left out"
architectures. Also, sparc is sparc 32bit userspace, there is sparc64
port in Debian.
> For those packages that are
> deep in the dependency graph and are still java5-compatible, it seems
> like it would be sufficient to build depend on default-jdk | gcj-jdk.
>
... and the sufficient logic to find the correct JAVA_HOME.
> However, couldn't we use versioned build-deps on default-jdk + the
> virtual runtime dependency for the binary package to accomplish the same
> effect? For any software that requires Java7, we would build-dep on
> default-jdk (>=2:1.7~) and require java7-runtime for the resulting
> binary package. (The versioned build-dep has already been used in some
> cases to excluce gcj-jdks.)
>
STOP! Versioned dependencies on default-java for pulling a particular
Java version IS A BAD IDEA!
We have twice now added an epoch to default-jdk et al, because we had to
revert the default java on several architectures. So far it has always
been openjdk -> gcj, but it could just as well be openjdk-8 to openjdk-7
next time.
As soon as the epoch is bumped, you get the old java version while the
dependency is still satisfied!
To be honest, I mostly of the belief that using the java major version
as a part of the version for default-jdk et al. is a misfeature. It
appears to trick people into believing it is useful method to ensure a
minimum java version, only to be surprised by an "oops, we have to
revert to gcj and have to bump the epoch".
> For Java8, the pattern would be the same, and it won't be long before
> we'll have to accommodate sources that *require* Java8. The versioned
> dependency would allow us to differentiate between source packages that
> require 8 (or 9) and those that will still build with Java 7, etc.
>
No, I am not convinced it will (as per above). Perhaps we should have a
look at versioned provides as an alternative.
> [...]
>
> Thanks for the discussion,
> tony
>
> [1] https://packages.debian.org/unstable/openjdk-7-jdk
> [2] https://packages.debian.org/unstable/default-jdk
>
>
Thanks,
~Niels
Reply to: