Re: Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7
On 05/27/2015 03:41 PM, Jan Henke wrote:
> Am 27.05.2015 um 15:04 schrieb Thorsten Glaser:
>> On Wed, 27 May 2015, Rene Engelhard wrote:
>>
>>> I know, there at least we need to kill gcj support. But until then. Or
>>> we decide we don't care ab out 1.5/gcj now. Explicitely.
>>
>> On Wed, 27 May 2015, Markus Koschany wrote:
>>
>>> Niels and Emmanuel have already pointed out the most important facts why
>>> we can't support GCJ forever. My Java baseline is:
>>
>> OK, let me rephrase my intent again.
>>
>> I think it’s fair to drop GCJ support. But please do not so for
>> as long as doing that breaks GCJ architectures. That means, for
>> all affected packages, do maintainer uploads or NMUs *first*
>> that:
>>
>> - change the B-D to require default-jdk only on an architecture
>> whitelist (do not use a blacklist, that makes bootstrapping
>> new architectures impossible_)
>>
>> - change d/rules, d/control to only build the *-java packages
>> on those architectures
>>
>> - ensure these changes are in sid *first*
>>
>> Thanks!
>>
>> bye,
>> //mirabilos
> Hi,
>
> even with just being someone lurking on the ML for some time I still
> would like to voice my opinion on this matter.
>
> I think gcj serves one single purpose only at this point in time:
> Bootstrapping during the OpenJDK build.
No.
It's a direct build dependency for pdftk (but doesn't affect jdk-default).
It is used to provide a natively compiled ecj (and I think still ant) to speed
up builds on OpenJDK architectures.
It is used for bootstrapping, however the replacement to build openjdk on a new
architecture without having gcj on that architecture isn't yet implemented:
cross-building of openjdk-8 (help would be welcome, it's a packaging task and
supposed to be supported upstream).
> I concur with the voiced
> opinion, that gcj is from a piratical perspective not a working JVM any
> more. As unfortunate it is for the architectures without OpenJDK, I also
> think gcj does not work as default-jdk either on those architectures.
>
> As much as it is sad to write this, I fully agree at this point Java
> should be dropped from those architectures without an OpenJDK build. It
> is better to have no installable default-jdk, than a silently broken JVM
> that is not really usable with current Java applications.
sure, then please let's drop the mips and mipsel binaries too. These are
currently not built anymore for openjdk-8, and I don't see any feedback to
improve the situation.
The next question is how to define "OpenJDK build". There are the Hotspot VM's,
the Zero VM and JamVM. The Hotspot VM's and Zero are upstream, however being
upstream doesn't mean that these are always buildable (e.g. sparc HotSpot became
unbuildable in 7, looks buildable in 8 now; e.g. mips/mipsel based on Zero
doesn't build/work).
Learning from the attempt to keep a Hotspot port in the packaging (KFreeBSD),
it's required to have this maintained upstream. Things rot too fast in the
packaging.
Other release architectures based on the Zero port are armel, armhf, powerpc, s390x.
So the bigger question is, which Zero ports should be removed. From my point of
view these are mips and mipsel, and probably others. In any case we will end up
with release architectures having no java support -- which is fine, other
languages don't provide this either).
I didn't look at JamVM for a long time, so maybe somebody else could figure out
if this is an option for the current Zero ports.
Matthias
Reply to: