Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via or IRC
Bug 154 - blackdown-jdk
Summary: blackdown-jdk
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Karl Trygve Kalleberg (RETIRED)
Depends on:
Blocks: 155
  Show dependency tree
Reported: 2002-01-13 23:35 UTC by Chris Arndt
Modified: 2003-02-04 19:42 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Chris Arndt 2002-01-13 23:35:44 UTC
the blackdown-jdk installs to /opt/blackdown,
shouldn't it have a link to /opt/java?

it appears to cause problems with the php install
Comment 1 Karl Trygve Kalleberg (RETIRED) gentoo-dev 2002-01-14 04:06:51 UTC
I discussed this with chouser last year and we decided that the /opt/java
symlink is a bad idea for the following reasons:
1) The contents of the /opt/java directory is different, depending on the actual
JDK or JRE you install.
2) There is a big difference in layout even between a JRE and JDK from the same
3) When one installs a Free JVM, such as kissme, japhar or kaffe (we don't have
finished ebuilds for this yet), the /opt/java would link to /usr which seems a
bit silly.

My proposed remedy is as follows:
1) All JDK and JREs set CLASSPATH and JAVA_HOME in /etc/env.d/20java
2) All JDK and JREs provide /usr/bin/java-config that can be used to query
  - VM version
  - location of java, javac, jar or any other executable of interest, and
necessary parameters
  - preferred CLASSPATH and JAVA_HOME
  - other necessary environmental settings
  - knowledge about optional java libraries (jaxp, java-gnome, etc...)

This is preferrable since it would be trivially possible to default to Jikes as
the compiler without having to put shitloads of logic into the ebuilds, as we do
now. java-config can compose a complete and working CLASSPATH for a set of
jarballs, and even take care of proper versioning.

The alternative to this would be to enforce a common layout in /opt/java that
all ebuilds can rely on, but this proved troublesome as some applications'
configuration scripts got confused when I tried to "clean" the directory
structure in /opt/java too much.
Comment 2 Chris Arndt 2002-01-14 23:11:12 UTC
Thanks for the explination.
I'll agree that this sounds like a much better approach.