[gentoo-java] Java installation handling not acceptable

[gentoo-java] Java installation handling not acceptable

[Daniel]

Hi,
the installation of Java on Gentoo is the hell on earth!

- the installation is non transparent
- the java-"help"-utils (java-config, java-config-wrapper) are not acceptable,
because you don't really need them
- the whole solution of installing more than one jdk is bumptious - so not 
easy
handable

This meens that it takes long time to install java and that you need to do 
some
terrible thinks (e.g. unmasking some packages ... see
http://www.gentoo.org/proj/en/java/java-upgrade.xml).

This is not the way gentoo should go because this is to heavy for the user
(that mostly just wants to install a jdk :) )!

So I have collected some points _we_ should think about:
- why is jdk-1.5 still under development?
- is it really necessary to install an jdk-1.4 and jdk-1.5? - if yes, why you
don't need to install jdk-1.3?
- gentoo should never make a difference between jdk 1.4 and 1.5
- java-config should just generate some environment files to set a special vm
- if an ebuild requires a special vm (why ever, because the api of the jdk is
compatible in most points) it should gnerate a warning, that the vm should be
set to 1.x
- it is the problem of the user if there are two java applications which need
different vms (this problem is much easier to solve than installing java ;)).

I hope you will not understand this bug as an act of aggression - it should
just help Gentoo.

regards
Daniel aka Damage
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Java installation handling not acceptable

[Krzysiek Pawlik]

[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]

Daniel wrote:
> Hi,
> the installation of Java on Gentoo is the hell on earth!

It's a lot easier than it used to be.

> - the installation is non transparent

Could you elaborate on that one?

> - the java-"help"-utils (java-config, java-config-wrapper) are not acceptable,
> because you don't really need them

Just learn how to use them - that's all.

> - the whole solution of installing more than one jdk is bumptious - so not 
> easy
> handable

It is.

> This meens that it takes long time to install java and that you need to do 
> some
> terrible thinks (e.g. unmasking some packages ... see
> http://www.gentoo.org/proj/en/java/java-upgrade.xml).

The whole generation 2 is not considered stable, thus you have to unmask
some packages to get it - it's still in ~arch

> This is not the way gentoo should go because this is to heavy for the user
> (that mostly just wants to install a jdk :) )!

So do it.

> So I have collected some points _we_ should think about:
> - why is jdk-1.5 still under development?

Code built with 1.5 is not backwards compatible (JRE 1.4 can't run it).

> - is it really necessary to install an jdk-1.4 and jdk-1.5? - if yes, why you
> don't need to install jdk-1.3?

Yes - there's currently no code that compiles with 1.3 and doesn't with 1.4.

> - gentoo should never make a difference between jdk 1.4 and 1.5

It should.

> - java-config should just generate some environment files to set a special vm

NO! It was in generation 1 and that was hell, new stuff is a lot easier.

> - if an ebuild requires a special vm (why ever, because the api of the jdk is
> compatible in most points) it should gnerate a warning, that the vm should be
> set to 1.x

No, that would break the 'non-interactive' principle of portage.

> - it is the problem of the user if there are two java applications which need
> different vms (this problem is much easier to solve than installing java ;)).

Nope.

> I hope you will not understand this bug as an act of aggression - it should
> just help Gentoo.

A lot of FUD and misunderstanding, nothing more (yet).

-- 
Krzysiek Pawlik   <nelchael at gentoo.org>   key id: 0xBC555551
desktop-misc, desktop-dock, desktop-wm, x86, java, apache...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-java] Java installation handling not acceptable

[Daniel]

Hi,
thank you all for responding.

I notice that it is ugly to explain this problem. So I will ask a simple 
question and we will have a look at the answer(s).

How do I emerge JDK-1.5 if I also need to set the "java" useflag?

I'm really interested in your answers. But I think all possible answers are 
longer than two sentences, aren't they? And THAT is the problem.

Krzysiek Pawlik told me that one of my suggestions "would break 
the 'non-interactive' principle of portage". But the Java installation _is 
currently_ 'interactive'.

regards
Daniel
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Java installation handling not acceptable

[Wiktor Wandachowicz]

The transition period will end eventually. But you're right that the
new-style Java installation requires manual intervention Right Now (TM).
This is expected with many other packages that are in testing as well.
Problem is, Java is a requirement for many people and the (minor, IMHO)
hurdles just makes them unnecessarily angry. If one has to use testing
versions of packages, one also has to learn how to deal with them
correctly:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3

For the time being, one could write a script that could install testing
(~arch) Java on a stable profile - adding proper atoms to package.unmask
and package.keywords, checking the sanity, etc. But this work would
be outdated too some time in the future. It's just a matter of time when
these Java packages (and there are about 400 of them in portage!) will
become stabilized. The more time developers spend on this goal the
faster it becomes reality. And they don't get paid for it, remember.

Also, you don't expect to be able to use new-style Java (JRE, JDK)
only to find that some ebuilds you NEED for your work do not compile,
because they haven't been upgraded, right? I bet you'd pi***d off even
more in such situation. So, either the new Java goes in complete or it
stays in ~arch until ready. That's my understanding of this matter.

Another possibility is just to go full ~x86 for example (which is not such
a big deal, BTW). One of my systems (the one I'm writing this on) is on a
testing profile, and believe me, the new-style Java is GREAT here :) :) :)

There are problems, there are also solutions for them.
You have to decide for yourself what will you do with it.

Cheers,
Wiktor
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Java installation handling not acceptable

[Joshua Nichols]

Wiktor Wandachowicz wrote:

> > The transition period will end eventually. But you're right that the
> > new-style Java installation requires manual intervention Right Now (TM).
> > This is expected with many other packages that are in testing as well.
> > Problem is, Java is a requirement for many people and the (minor, IMHO)
> > hurdles just makes them unnecessarily angry. If one has to use testing
> > versions of packages, one also has to learn how to deal with them
> > correctly:
> > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3
> >
>   
If you're upgrading an existing install or using stable keywords on a
new install, yes, there's some manual intervention required... But for
the record, if you're using testing keywords on a new install... it Just
Works (TM). I just did a fresh install over the weekend and was pleased
to see how well it went  :-D 

> > For the time being, one could write a script that could install testing
> > (~arch) Java on a stable profile - adding proper atoms to package.unmask
> > and package.keywords, checking the sanity, etc. But this work would
> > be outdated too some time in the future. It's just a matter of time when
> > these Java packages (and there are about 400 of them in portage!) will
> > become stabilized. The more time developers spend on this goal the
> > faster it becomes reality. And they don't get paid for it, remember.
> >
>   
I was actually working on a script based on nelchael's find-unported.py
script, that would find all the packages using that have been migrated,
so it'd basically give you a list of things to put in
/etc/portage/package.keywords.

Also just had a revelation... could use that in combination with
find-unported.py to package.mask everything that was unported. This
would have the benefit of making it pretty obvious what stuff in a
dependency tree still needs to be migrated.

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Java installation handling not acceptable

[Daniel]

Hi,
sorry for late responding but I was in hollidays.

As I noticed, the main problem is that the jdk 1.5 is still marked as 
unstable. You have posted some reasons for that but it still makes no sense 
to me.
However, if the jdk 1.5 is marked stable the java installation handling would 
be much better because you don't need 2 or more jdks.

So I will wait and hope.

regards
Daniel
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Java installation handling not acceptable

[Joshua Nichols]

Daniel wrote:
> Hi,
> thank you all for responding.
>
> I notice that it is ugly to explain this problem. So I will ask a simple 
> question and we will have a look at the answer(s).
>
> How do I emerge JDK-1.5 if I also need to set the "java" useflag?
>
>   
I'm not sure what you're getting at with this question... You can just
emerge =jdk-1.5*... You'd have to set the java USE flag yourself in
make.conf as you normally would. However, not all packages with USE=java
have been migrated to the new Java system, so those would need to use a
1.4 JDK.
> I'm really interested in your answers. But I think all possible answers are 
> longer than two sentences, aren't they? And THAT is the problem.
>
>   
Well, it is a complicated issue. If we hadn't done anything, Java 1.5
would still be package.mask'd. If we had done the migration by dropping
it directly stable, there'd be even more problems than there are, since
stable users would be having issues too. The way it was done, with the
generations, was a compromise. It is certainly less than ideal, but it
was the sanest way we could come up with to support it.
> Krzysiek Pawlik told me that one of my suggestions "would break 
> the 'non-interactive' principle of portage". But the Java installation _is 
> currently_ 'interactive'.
>   
It's 'interactive' because it stops when a problem is detected... a good
thing, yes?
> regards
> Daniel
>   
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Java installation handling not acceptable

[Alistair Bush]

Daniel wrote:
> Hi,
> the installation of Java on Gentoo is the hell on earth!
>
> - the installation is non transparent
> - the java-"help"-utils (java-config, java-config-wrapper) are not acceptable,
> because you don't really need them
> - the whole solution of installing more than one jdk is bumptious - so not 
> easy
> handable
>
> This meens that it takes long time to install java and that you need to do 
> some
> terrible thinks (e.g. unmasking some packages ... see
> http://www.gentoo.org/proj/en/java/java-upgrade.xml).
>
> This is not the way gentoo should go because this is to heavy for the user
> (that mostly just wants to install a jdk :) )!
>
> So I have collected some points _we_ should think about:
> - why is jdk-1.5 still under development?
>   
Because not all packages (worthy of being in the tree)  compile with 
Java 1.5.
> - is it really necessary to install an jdk-1.4 and jdk-1.5? - if yes, why you
> don't need to install jdk-1.3?
>   
there are no packages that require jdk-1.3 to compile.  
> - gentoo should never make a difference between jdk 1.4 and 1.5
>   
Why?  I certainly make a difference between a amd x86 cpu and a intel 
x86 cpu.
> - java-config should just generate some environment files to set a special vm
> - if an ebuild requires a special vm (why ever, because the api of the jdk is
> compatible in most points) it should gnerate a warning, that the vm should be
> set to 1.x
> - it is the problem of the user if there are two java applications which need
> different vms (this problem is much easier to solve than installing java ;)).
>
>   

> I hope you will not understand this bug as an act of aggression - it should
> just help Gentoo.
>
> regards
> Daniel aka Damage
>   
Doesn't the java's project pages explain all this?
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Java installation handling not acceptable

[Joshua Nichols]

Daniel wrote:
> Hi,
> the installation of Java on Gentoo is the hell on earth!
>   
I'm sure lots of people would disagree. In fact, I do hear fairly often
that our support of Java very good.
> - the installation is non transparent
>   
Care to elaborate? If you emerge java packages, things should just work,
ie the appropriate JDK will be pulled for building.
> - the java-"help"-utils (java-config, java-config-wrapper) are not acceptable,
> because you don't really need them
>   
How are they not acceptable? They are absolutely necessary actually, as
they are used for configuring and building Java on Gentoo
> - the whole solution of installing more than one jdk is bumptious - so not 
> easy
> handable
>   
I... really don't get what you saying. According to the handy
dictionary.reference.com site, bumptious means 'Crudely or loudly
assertive; pushy.' I don't really how supporting multiple JDKs is pushy
or supportive. It just offers a lot more flexibility. In particular, it 
gives a lot of power when it come time for a new Java release, such that
we can use the stable and widely used version, while all the issues with
various packages are being worked out with the new version.
> This meens that it takes long time to install java and that you need to do 
> some
> terrible thinks (e.g. unmasking some packages ... see
> http://www.gentoo.org/proj/en/java/java-upgrade.xml).
>   
Terrible thinks? It is a new system for handling Java.... so of course
it needs to be in testing keywords. Or perhaps would you prefer it were
marked stable and then have all sorts of fun breakages for our stable
packages? No one forces you to unmask anything. Most times people using
stable keywords run into the new Java system because they decided to
package.unmask Java 1.5. (And please note, there is a difference between
using testing keywords, ie ~x86, and using stuff in package.mask... the
latter are known to cause problems or are undergoing heavy testing)
> This is not the way gentoo should go because this is to heavy for the user
> (that mostly just wants to install a jdk :) )!
>   
If you don't have anything Java related installed, you can just emerge
the JDK. If you do have Java stuff installed, chances are you already
have one installed, and nothing is stopping you from emerging a
different one.
> So I have collected some points _we_ should think about:
> - why is jdk-1.5 still under development?
>   
http://www.gentoo.org/proj/en/java/tiger-faq.xml should spell out some
of it. And I'm not sure what you mean by under development. I presume
you mean testing keywords? If so, this is standard policy, because it
1.5 has only recently come out of package.mask.
> - is it really necessary to install an jdk-1.4 and jdk-1.5? - if yes, why you
> don't need to install jdk-1.3?
>   
Yes, it REALLY is necessary. First off, some packages are known to break
with Java 1.5. These will eventually can be patched. Second, every
package not using the new Java system needs to be built with Java 1.4 to
avoid the problems mentioned in the FAQ. It isn't necessary to install
1.3 because apparently, everything works with Java 1.4 that worked with
Java 1.3.
> - gentoo should never make a difference between jdk 1.4 and 1.5
>   
Um... no. There does need to be a difference. I'm going to assume that
you just aren't familar enough with the differences between the two.
Just a few points:

* There is a different version of bytecode between major revisions of
JDKs, ie from 1.3 to 1.4, 1.4 to 1.5. Bytecode is forward compatible (ie
use 1.4 bytecode in 1.5 JRE), but not backward compatible.
* There is a new keyword, enum. Therefore, code using enum as a variable
code fails to compile
* Java 1.5 has new APIs for XML at least. It introduces new abstract
methods on some abstract classes and interfaces. The result is that when
classes fail to compile which use these abstract classes and interfaces,
and haven't specifically update to support the new API
> - java-config should just generate some environment files to set a special vm
>   
What's a special VM?
> - if an ebuild requires a special vm (why ever, because the api of the jdk is
> compatible in most points) it should gnerate a warning, that the vm should be
> set to 1.x
>   
See my previous points about compatibility.
> - it is the problem of the user if there are two java applications which need
> different vms (this problem is much easier to solve than installing java ;)).
>
>   
The new Java system actually handles this. We basically create
'launchers' for this, which read information about the packages it
needs, and figures out if it can run in the current VM. If it doesn't,
it will switch to one.
> I hope you will not understand this bug as an act of aggression - it should
> just help Gentoo.
>   
I hope you understand that it is easy to misunderstand comments to the
effect of 'Java on Gentoo being hell on earth' as being aggressive.

-- 
Joshua Nichols
Gentoo/Java - Project Lead

-- 
gentoo-java@gentoo.org mailing list

[gentoo-java] unsubscribe

[Ezio Bernaudo]

Alle 21:52, lunedì 31 luglio 2006, Joshua Nichols ha scritto:
> Daniel wrote:
> > Hi,
> > the installation of Java on Gentoo is the hell on earth!
>
> I'm sure lots of people would disagree. In fact, I do hear fairly often
> that our support of Java very good.
>
> > - the installation is non transparent
>
> Care to elaborate? If you emerge java packages, things should just work,
> ie the appropriate JDK will be pulled for building.
>
> > - the java-"help"-utils (java-config, java-config-wrapper) are not
> > acceptable, because you don't really need them
>
> How are they not acceptable? They are absolutely necessary actually, as
> they are used for configuring and building Java on Gentoo
>
> > - the whole solution of installing more than one jdk is bumptious - so
> > not easy
> > handable
>
> I... really don't get what you saying. According to the handy
> dictionary.reference.com site, bumptious means 'Crudely or loudly
> assertive; pushy.' I don't really how supporting multiple JDKs is pushy
> or supportive. It just offers a lot more flexibility. In particular, it
> gives a lot of power when it come time for a new Java release, such that
> we can use the stable and widely used version, while all the issues with
> various packages are being worked out with the new version.
>
> > This meens that it takes long time to install java and that you need to
> > do some
> > terrible thinks (e.g. unmasking some packages ... see
> > http://www.gentoo.org/proj/en/java/java-upgrade.xml).
>
> Terrible thinks? It is a new system for handling Java.... so of course
> it needs to be in testing keywords. Or perhaps would you prefer it were
> marked stable and then have all sorts of fun breakages for our stable
> packages? No one forces you to unmask anything. Most times people using
> stable keywords run into the new Java system because they decided to
> package.unmask Java 1.5. (And please note, there is a difference between
> using testing keywords, ie ~x86, and using stuff in package.mask... the
> latter are known to cause problems or are undergoing heavy testing)
>
> > This is not the way gentoo should go because this is to heavy for the
> > user (that mostly just wants to install a jdk :) )!
>
> If you don't have anything Java related installed, you can just emerge
> the JDK. If you do have Java stuff installed, chances are you already
> have one installed, and nothing is stopping you from emerging a
> different one.
>
> > So I have collected some points _we_ should think about:
> > - why is jdk-1.5 still under development?
>
> http://www.gentoo.org/proj/en/java/tiger-faq.xml should spell out some
> of it. And I'm not sure what you mean by under development. I presume
> you mean testing keywords? If so, this is standard policy, because it
> 1.5 has only recently come out of package.mask.
>
> > - is it really necessary to install an jdk-1.4 and jdk-1.5? - if yes, why
> > you don't need to install jdk-1.3?
>
> Yes, it REALLY is necessary. First off, some packages are known to break
> with Java 1.5. These will eventually can be patched. Second, every
> package not using the new Java system needs to be built with Java 1.4 to
> avoid the problems mentioned in the FAQ. It isn't necessary to install
> 1.3 because apparently, everything works with Java 1.4 that worked with
> Java 1.3.
>
> > - gentoo should never make a difference between jdk 1.4 and 1.5
>
> Um... no. There does need to be a difference. I'm going to assume that
> you just aren't familar enough with the differences between the two.
> Just a few points:
>
> * There is a different version of bytecode between major revisions of
> JDKs, ie from 1.3 to 1.4, 1.4 to 1.5. Bytecode is forward compatible (ie
> use 1.4 bytecode in 1.5 JRE), but not backward compatible.
> * There is a new keyword, enum. Therefore, code using enum as a variable
> code fails to compile
> * Java 1.5 has new APIs for XML at least. It introduces new abstract
> methods on some abstract classes and interfaces. The result is that when
> classes fail to compile which use these abstract classes and interfaces,
> and haven't specifically update to support the new API
>
> > - java-config should just generate some environment files to set a
> > special vm
>
> What's a special VM?
>
> > - if an ebuild requires a special vm (why ever, because the api of the
> > jdk is compatible in most points) it should gnerate a warning, that the
> > vm should be set to 1.x
>
> See my previous points about compatibility.
>
> > - it is the problem of the user if there are two java applications which
> > need different vms (this problem is much easier to solve than installing
> > java ;)).
>
> The new Java system actually handles this. We basically create
> 'launchers' for this, which read information about the packages it
> needs, and figures out if it can run in the current VM. If it doesn't,
> it will switch to one.
>
> > I hope you will not understand this bug as an act of aggression - it
> > should just help Gentoo.
>
> I hope you understand that it is easy to misunderstand comments to the
> effect of 'Java on Gentoo being hell on earth' as being aggressive.
>
> --
> Joshua Nichols
> Gentoo/Java - Project Lead

-- 
gentoo-java@gentoo.org mailing list