[Cooker] Java packages now built using icedtea by default

[Anssi Hannula-3]

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


--
Anssi Hannula

[guillomovitch]

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 ?

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.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: [phone]

[Nicolas JEUDY-2]

Le Monday 17 December 2007 10:28:32 Guillaume Rousse, vous avez écrit :

> 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 ?
>
> 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.

For me, the only use of sun jdk is for openoffice.org, lots of features are
missing or crashing without sun jdk ..

I don't know in cooker if it's the same, but openoffice.org is heavy dependant
of sun jdk.

Nicolas JEUDY

[Steve Morris-5]

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?

regards,
Steve


[samorris.vcf]

---

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

---

[Thierry Vignaud]

Anssi Hannula <anssi@...> writes:

> 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

you missed geogebra (was requiring jdk)

[Anssi Hannula-3]

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.

--
Anssi Hannula

[Steve Morris-5]

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. I
know that Netbeans 6 from Sun won't even install if iced-tea is the
running java, and eclipse 3.3 from the eclipse-foundation doesn't
function properly if iced-tea is the running java. Hence if iced-tea is
the default java how do we keep current in these packages?

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]

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.

 > I
> know that Netbeans 6 from Sun won't even install if iced-tea is the
> running java, and eclipse 3.3 from the eclipse-foundation doesn't
> function properly if iced-tea is the running java. Hence if iced-tea is
> the default java how do we keep current in these packages?
>


--
Anssi Hannula

[Steve Morris-5]

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.

regards,
Steve

> > I
>> know that Netbeans 6 from Sun won't even install if iced-tea is the
>> running java, and eclipse 3.3 from the eclipse-foundation doesn't
>> function properly if iced-tea is the running java. Hence if iced-tea is
>> the default java how do we keep current in these packages?
>>
>
>

[samorris.vcf]

---

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

---

[guillomovitch]

Steve Morris wrote:
> 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.
Rather because you can't expect mixing packages will work automagically.
Just because Sun distribute a rpm package doesn't make it a standard.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: [phone]

[Jaroslav Tulach-3]

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.
-jst

[Steve Morris-5]

Guillaume Rousse wrote:

> Steve Morris wrote:
>  
>> 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.
>>    
> Rather because you can't expect mixing packages will work automagically.
> Just because Sun distribute a rpm package doesn't make it a standard.
>  

I was suggesting that Sun distributing a rpm package makes them the

standard, I was implying that Sun is the java standard irrespective of
how it is distributed and Mandriva should use Sun's java. For Mandriva's
implementation to abort when used in conjunction with a Netbeans
feature, and the native Sun version works fine with the same Netbeans
process indicates to me that Mandriva's implementation has been
"tampered" with.

regards,
Steve


[samorris.vcf]

---

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

---

[Steve Morris-5]

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.
> -jst
>
>
>  

+1. One of Sun's prime directives, and all java developers, is never

compile java components with one jdk and attempt to run them with an
older jre, it is more often than not guaranteed to not work.

regards,
Steve


[samorris.vcf]

---

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

---

[Vincent Panel-3]

On Dec 20, 2007 12:26 PM, Steve Morris <samorris@...> wrote:

> Guillaume Rousse wrote:
> > Steve Morris wrote:
> >
> >> 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.
> >>
> > Rather because you can't expect mixing packages will work automagically.
> > Just because Sun distribute a rpm package doesn't make it a standard.
> >
> I was suggesting that Sun distributing a rpm package makes them the
> standard, I was implying that Sun is the java standard irrespective of
> how it is distributed and Mandriva should use Sun's java. For Mandriva's
> implementation to abort when used in conjunction with a Netbeans
> feature, and the native Sun version works fine with the same Netbeans
> process indicates to me that Mandriva's implementation has been
> "tampered" with.

... or that Sun's implementation contains bugs (and it implies some
workarounds in the program which won't work with a different
implementation) or the specifications are incomplete. Both are very
likely.

[Anssi Hannula-3]

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.

--
Anssi Hannula

[Steve Morris-5]

Vincent Panel wrote:

> On Dec 20, 2007 12:26 PM, Steve Morris <samorris@...> wrote:
>  
>> Guillaume Rousse wrote:
>>    
>>> Steve Morris wrote:
>>>
>>>      
>>>> 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.
>>>>
>>>>        
>>> Rather because you can't expect mixing packages will work automagically.
>>> Just because Sun distribute a rpm package doesn't make it a standard.
>>>
>>>      
>> I was suggesting that Sun distributing a rpm package makes them the
>> standard, I was implying that Sun is the java standard irrespective of
>> how it is distributed and Mandriva should use Sun's java. For Mandriva's
>> implementation to abort when used in conjunction with a Netbeans
>> feature, and the native Sun version works fine with the same Netbeans
>> process indicates to me that Mandriva's implementation has been
>> "tampered" with.
>>    
>
> ... or that Sun's implementation contains bugs (and it implies some
> workarounds in the program which won't work with a different
> implementation) or the specifications are incomplete. Both are very
> likely.
>
>  

Exactly my point, if Mandriva followed standards and used the standard

java there wouldn't be these issues.

regards,
Steve


[samorris.vcf]

---

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

---

[Adam Williamson-4]

On Fri, 2007-12-21 at 06:50 +1100, Steve Morris wrote:

> > ... or that Sun's implementation contains bugs (and it implies some
> > workarounds in the program which won't work with a different
> > implementation) or the specifications are incomplete. Both are very
> > likely.
> >
> >  
> Exactly my point, if Mandriva followed standards and used the standard
> java there wouldn't be these issues.

...but everything would be in non-free.
--
adamw

[Steve Morris-5]

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.

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]

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.

--
Anssi Hannula

[J.A. Magallón]

On Thu, 20 Dec 2007 23:01:53 +0200, Anssi Hannula <anssi@...> 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.
>

(just the first thing, correct me if I'm wrong, but this is what I
understand in all this mess...)

Ohhh, please, let's clarify some things, someone has not this clear, and
perhaps Mandriva people see it so bright that don't explain it...

- There is no 'Mandriva implementation', everything that is named
  'java-*-sun-*' are _Sun_ binaries (not even recompiled by Mandriva,
  as sources are not available), just packaged by Mandriva.
  This includes java 1.4, 1.5 and 1.6.
- The IceTea Java _is_ mainly sun java, mainly the 1.6 sources
  re-released as 1.7, built with gcc and without the Sun class library,
  due to copyright problems. It uses GNU Class library. It's neither
  Mandriva's implementation, just built by Mandriva...
  It is not the same as Kaffe or other java virtual machines, that have
  different implementations. This is just the Sun JVM made open source...

What dou you call 'the Mandriva implementation' ?
The problem is not Sun vs IcedTea. The problem is the same with sun 1.6
versus sun 1.4. The problem is the version of the runtime for which the
package was compiled. You will have the same problems if you build
with Sun JDK 1.6 and try to run on 1.4. Java is a programming language,
and as such it has clearly defined ABIs and protocols, that no compiler
even in 'damn crazy optimized' mode can break, and that every implementation
has to follow, _for a version_.
So the problem is not IcedTea vs Sun, but 1.7 vs 1.6 or 1.4.
If there was a new method added to a class (don't have the original
message handy just now), it was not IcedTea vs Sun, but 1.7 vs 1.6.
There is a standard...

Perhaps what should be done is define virtual packages such as java-1.6
or java-1.7, that would pull Sun's or IcedTea or GCJ or whatever and
set alternatives (such as gcc and gcc4.3), and let packages (eclipse?)
require the needed version.

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT