[Cooker] Java packages now built using icedtea by default

[Steve Morris-5]

Anssi Hannula wrote:

> Steve Morris wrote:
>> Anssi Hannula wrote:
>>> Steve Morris wrote:
>>>> Anssi Hannula wrote:
>>>>> Steve Morris wrote:
>>>>>> Anssi Hannula wrote:
>>>>>>> Steve Morris wrote:
>>>>>>>> Anssi Hannula wrote:
>>>>>>>>> Java packages are now built using icedtea by default on ix86 and
>>>>>>>>> x86_64, via new java-rpmbuild virtual jdk package.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> According to my earlier post, the next planned java build changes
>>>>>>>>> are:
>>>>>>>>>
>>>>>>>>>> - split eclipse-ecj out of eclipse (debian-style) to allow
>>>>>>>>>> main/contrib split
>>>>>>>>>> - move rest of eclipse to contrib
>>>>>>>>>> - move most of java stack to contrib, leaving only
>>>>>>>>>> jpackage-utils,
>>>>>>>>>> java-rpmbuild, gcc4.3, java-1.5.0-gcj, java-1.7.0-icedtea,
>>>>>>>>>> eclipse-ecj, and a handful of dependencies to main
>>>>>>>>>>
>>>>>>>>>> Possibly at some point later:
>>>>>>>>>> - removal of gcj aot compiling
>>>>>>>> What impact does this have on external packages that will not run
>>>>>>>> with
>>>>>>>> iced-tea?
>>>>>>> This should not have impact on those.
>>>>>>>
>>>>>> Sorry, I didn't explain myself properly. It appears from this post
>>>>>> that
>>>>>> there is a plan to make iced-tea the default java in the
>>>>>> distribution.
>>>>> Default java used for *building* packages. The run-time
>>>>> environment is
>>>>> discussed in a separate thread ("Java for 2008.1"), but I don't think
>>>>> we'll be switching the mandriva commercial distros from sun java for
>>>>> 2008.1.
>>>>>
>>>> Sure, but in the current environment all the packages that have been
>>>> compiled for a specific version of java have been set up in such a way
>>>> that they require the associated jre/jdk to be installed, and if one
>>>> tries to uninstall the jre then the package managers want to uninstall
>>>> all the packages that have been built for that java version. I know
>>>> this
>>>> because I have just been through that nonsense when I wanted to
>>>> uninstall jre/jdk 1.6 in favour of Sun's 1.6 versions (because the
>>>> Mandriva implementation is buggy and aborts under certain scenarios
>>>> whereas the Sun implementation functions correctly under the same
>>>> scenarios).
>>>> Also even though the Sun jre/jdk is rpm installed and hence registered
>>>> in the package database Mandriva refuses to recognise it as a
>>>> replacement for the Mandriva same version, hence all the packages that
>>>> have been built for that version of java refuse to acknowledge that
>>>> the
>>>> Sun version is a direct replacement the Mandriva implementation,
>>>> and the
>>>> whole process is a complete mess, IMHO brought on by the fact that
>>>> Mandriva is not adhering to the java standard: Sun.
>>> You must of course use Mandriva java packages here. If you want the
>>> sun implementation, use java-1.6.0-sun.
>>>
>> That is the buggy implementation I was trying to remove in favour of the
>> standard one directly from Sun that highlighted this mess.
>
> But java-1.6.0-sun *is* the Sun implementation, we are not building it
> ourselves, just providing the binaries built by Sun.
>
> If you have a problem with it, please file a bug report.
>

I mentioned this once in an earlier thread, and have sent an automatic

bug report to Sun, but I haven't heard anything from Sun. It will be a
while before I can uninstall the Sun environment an reinstall the mirror
environment, as I am undertaking Sun online java development courses on
my cooker machine and I need a working java environment.

regards,
Steve


[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

[Anssi Hannula-3]

Jaroslav Tulach wrote:

> Dne Wednesday 19 December 2007 15:21:25 Anssi Hannula napsal(a):
>>>>> What impact does this have on external packages that will not run with
>>>>> iced-tea?
>>>> This should not have impact on those.
>>> Sorry, I didn't explain myself properly. It appears from this post that
>>> there is a plan to make iced-tea the default java in the distribution.
>> Default java used for *building* packages. The run-time environment is
>> discussed in a separate thread ("Java for 2008.1"), but I don't think
>> we'll be switching the mandriva commercial distros from sun java for
>> 2008.1.
>
> I am afraid you are asking for troubles. icedtea (based on openjdk) is Java 7,
> while commercial alternative is Java 6. I am not sure if the APIs in Open JDK
> already differ from Java 6, but I am pretty sure they will one day. At that
> time you may compile fine, but not execute on Java 6 then. And this may
> happen even if your source code is compilable on Java 6. This is what
> happened to NetBeans few years ago:
>
> StringBuffer s1 = new StringBuffer();
> StringBuffer s2 = new StringBuffer();
> s2.append(s1);
>
> compiles fine on JDK 1.3 as well as JDK 1.4, but if you compile on JDK 1.4, it
> does not run on JDK 1.3. Why? Because new method append(StringBuffer sb) was
> added to that class in JDK1.4.
>
> The sad thing is that you do not find out unless you execute that line of
> code. That is why I do not recommend compiling against rt.jar from newer
> version and running the result on older one for production use.

The bytecode version number is specified in the .class header. An older
JRE fails to load a class with a too new bytecode version.

Icedtea builds bytecode version 50 (6.0) by default (when target is not
specified explicitely).
However, indeed our current gij4.3 does not support loading classes of
that version yet, David and I are working on updating gcc4.3 with a new
snapshot that does.

--
Anssi Hannula

[Anssi Hannula-3]

Guillaume Rousse wrote:
> Anssi Hannula wrote:
>> Java packages are now built using icedtea by default on ix86 and
>> x86_64, via new java-rpmbuild virtual jdk package.
> If we can build all java packages through icedtead, do we really need to
> keep 3 different jdk in the distribution, especially proprietary ones ?

The proprietary jres are needed for java plugin and java web start.

> And even if we keep them, can we drop this ugly and fragile system of
> alternative-setup based setup, and adopt the standard setup of all other
> languages in the distribution, where we have a default version, and
> eventually non-default ones if really needed (such as python vs
> python2.4) ? I know you guys don't want to deviate from one single inch
> from jpackage practices, but it may be time to realize those practices
> date back from old times, and doesn't match current needs ? This one, in
> particular, was made to be able to build some packages with the only
> free jdk available at this moment, instead of hardcoding the use of
> proprietary sun jdk. This is just not true anymore.
>
> I'd like to have a java packaging in the distribution suiting the needs
> of average users (the one needing to run java applications), not suiting
> the needs of java developpers needing to test their own applications
> against all different flavours of available jvms. Current situation is
> just overkill.

I agree quite a bit. If a java app is defined to use/require a single
predefined jre, it would make the app less fragile, i.e. the stability
of the app does not depend on the installed jre rpm set.

Same for all the dozens of java related alternatives setups.

However, most of the java packaging is done by David and Alexander, and
I don't think they'd agree. In addition of breaking compatibility with
jpackage, which is valued by some, it would make syncing with
fc/jpackage (our java packages are mostly slightly modified copies of
those) more difficult.

--
Anssi Hannula

[guillomovitch]

Anssi Hannula a écrit :
> Guillaume Rousse wrote:
>> Anssi Hannula wrote:
>>> Java packages are now built using icedtea by default on ix86 and
>>> x86_64, via new java-rpmbuild virtual jdk package.
>> If we can build all java packages through icedtead, do we really need
>> to keep 3 different jdk in the distribution, especially proprietary
>> ones ?
>
> The proprietary jres are needed for java plugin and java web start.
And do we really need 2 different version of them ?

[..]
> However, most of the java packaging is done by David and Alexander, and
> I don't think they'd agree. In addition of breaking compatibility with
> jpackage, which is valued by some, it would make syncing with
> fc/jpackage (our java packages are mostly slightly modified copies of
> those) more difficult.
I'm ready to help maintaining a parallel java packaging effort, limited
to jre, if we can't agree on goals.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: [phone]

[Anssi Hannula-3]

Guillaume Rousse wrote:

> Anssi Hannula a écrit :
>> Guillaume Rousse wrote:
>>> Anssi Hannula wrote:
>>>> Java packages are now built using icedtea by default on ix86 and
>>>> x86_64, via new java-rpmbuild virtual jdk package.
>>> If we can build all java packages through icedtead, do we really need
>>> to keep 3 different jdk in the distribution, especially proprietary
>>> ones ?
>> The proprietary jres are needed for java plugin and java web start.
> And do we really need 2 different version of them ?

I don't know. I guess there must be some reason they exist, better ask
someone else.

> [..]
>> However, most of the java packaging is done by David and Alexander, and
>> I don't think they'd agree. In addition of breaking compatibility with
>> jpackage, which is valued by some, it would make syncing with
>> fc/jpackage (our java packages are mostly slightly modified copies of
>> those) more difficult.
> I'm ready to help maintaining a parallel java packaging effort, limited
> to jre, if we can't agree on goals.

I'm afraid I don't really have time for that :/

--
Anssi Hannula

[Steve Morris-5]

Anssi Hannula wrote:

> Jaroslav Tulach wrote:
>> Dne Wednesday 19 December 2007 15:21:25 Anssi Hannula napsal(a):
>>>>>> What impact does this have on external packages that will not run
>>>>>> with
>>>>>> iced-tea?
>>>>> This should not have impact on those.
>>>> Sorry, I didn't explain myself properly. It appears from this post
>>>> that
>>>> there is a plan to make iced-tea the default java in the distribution.
>>> Default java used for *building* packages. The run-time environment is
>>> discussed in a separate thread ("Java for 2008.1"), but I don't think
>>> we'll be switching the mandriva commercial distros from sun java for
>>> 2008.1.
>>
>> I am afraid you are asking for troubles. icedtea (based on openjdk)
>> is Java 7, while commercial alternative is Java 6. I am not sure if
>> the APIs in Open JDK already differ from Java 6, but I am pretty sure
>> they will one day. At that time you may compile fine, but not execute
>> on Java 6 then. And this may happen even if your source code is
>> compilable on Java 6. This is what happened to NetBeans few years ago:
>>
>> StringBuffer s1 = new StringBuffer();
>> StringBuffer s2 = new StringBuffer();
>> s2.append(s1);
>>
>> compiles fine on JDK 1.3 as well as JDK 1.4, but if you compile on
>> JDK 1.4, it does not run on JDK 1.3. Why? Because new method
>> append(StringBuffer sb) was added to that class in JDK1.4.
>> The sad thing is that you do not find out unless you execute that
>> line of code. That is why I do not recommend compiling against rt.jar
>> from newer version and running the result on older one for production
>> use.
>
> The bytecode version number is specified in the .class header. An
> older JRE fails to load a class with a too new bytecode version.
>
> Icedtea builds bytecode version 50 (6.0) by default (when target is
> not specified explicitely).

Anssi,

    There is more involved in this than purely bytecode version numbers.
Different versions of Java add/remove classes and methods within
classes, and even go as far as overloading methods. Hence compilers and
jres cannot necessarily be mixed. I am in the situation where I am
running Netbeans 6 from Sun, which won't even install if java 7 is
active, and Eclipse 3.3 from the Eclipse foundation which produces
rubbish syntax errors if java 7 is active, not to mention developing
java applications for external use means having to stuff around
switching java versions all the time. Also last time I looked at the
java 7 jre it appeared to me to be a cutdown version compared to
Mandrivas Sun jre 6 package.
    IMHO what would be the ideal scenario would be for the Mandriva java
applications to save the current java environment, switch to java 7 if
that is what you really want to compile all the java applications with,
and then restore the java environment when finished.

regards,
Steve

> However, indeed our current gij4.3 does not support loading classes of
> that version yet, David and I are working on updating gcc4.3 with a
> new snapshot that does.
>

[samorris.vcf]

---

begin:vcard
fn:Steve Morris
n:Morris;Steve
email;internet:samorris@...
x-mozilla-html:TRUE
version:2.1
end:vcard

---

Hi, Guillaume,

I don't know what do you mean by "parallel Java packaging effort".
But I want to explain why I value fc/jpackage compatibility. It is only a
practical reason - they've got a lot of packages I'm using daily, which are
still not available in Mandriva. I wouldn't like breaking compatibility for
no real reason (e.g. renaming packages), but there are a lot of things that
are harder then they should be and breaking it in such cases can be a good
thing. But this should be decided on a case by case base until we get feature
parity. I will join  to any effort that will make it easier to get more of
the packages I need in Mandriva.

For e.g. the latest geronimo-specs from jpackage provides several versions for
almost every J2EE spec and I agree that there shouldn't be packages for all
of them (and alternatives) when most of them have excellent backward
compatibility.

I hope that it is possible everyone interested in the Java to work together.

On Friday 21 December 2007 23:40:38 Guillaume Rousse wrote:

> Anssi Hannula a йcrit :
> > Guillaume Rousse wrote:
> >> Anssi Hannula wrote:
> >>> Java packages are now built using icedtea by default on ix86 and
> >>> x86_64, via new java-rpmbuild virtual jdk package.
> >>
> >> If we can build all java packages through icedtead, do we really need
> >> to keep 3 different jdk in the distribution, especially proprietary
> >> ones ?
> >
> > The proprietary jres are needed for java plugin and java web start.
>
> And do we really need 2 different version of them ?
>
> [..]
>
> > However, most of the java packaging is done by David and Alexander, and
> > I don't think they'd agree. In addition of breaking compatibility with
> > jpackage, which is valued by some, it would make syncing with
> > fc/jpackage (our java packages are mostly slightly modified copies of
> > those) more difficult.
>
> I'm ready to help maintaining a parallel java packaging effort, limited
> to jre, if we can't agree on goals.

[guillomovitch]

Alexander Kurtakov a écrit :

> Hi, Guillaume,
>
> I don't know what do you mean by "parallel Java packaging effort".
> But I want to explain why I value fc/jpackage compatibility. It is only a
> practical reason - they've got a lot of packages I'm using daily, which are
> still not available in Mandriva. I wouldn't like breaking compatibility for
> no real reason (e.g. renaming packages), but there are a lot of things that
> are harder then they should be and breaking it in such cases can be a good
> thing. But this should be decided on a case by case base until we get feature
> parity. I will join  to any effort that will make it easier to get more of
> the packages I need in Mandriva.

I was only speaking of java runtime here,  as they are distributed
together), the only piece of interest for people just using java, by
opposition to java developers. That's the package most suffering from
the general "we can't decide of a reasonable effort scope, so let's
assign ourselves the maximum constraints at once" attitude from the
jpackage project. I'm fed up with silly fonts alternatives setup, insane
package names, or forced dependencies on jdbc because "otherwise sun
lawyers may comes after us".

Now we have a real open-source alternative to proprietary java runtimes,
I see no reason to keep the ugly, complex, undocumented, and fragile
packaging from jpackage project, instead of trying to achieve the same
level of integration we have for all other languages in the distribution
(perl, python, etc...). For 90% of them, there is only version of the
runtime in the distribution, because this is enough to satisfy all
needs. In case of exception, such as python 2.4 needed to run zope, an
additional package is provided, is installable in parallel (no file
conflict), but it is not intended as a full-blown main python package
replacement. And all python modules are built against the main python
package only.

And as the java runtime is actually a subset of the java development
kit, just consider how much this simplification effort would help you
maintaining java packages. No one cares than ant being buildable against
gcj, sun legacy jdk or icedtea, as long as you provide a working ant
package in the distribution, but ensuring it just gives you more
troubles. And it is even worst for non-java specialist (think of
openoffice maintainer, for instance).

So yes, I think it's worth breaking compatibility with jpackage for
jdk/jre packages now.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: [phone]