IcedTea

[Jacek Konieczny]

Hello,

As some of you have already noticed (and complained) I have been
preparing IcedTea package for PLD, in 'icedtea6.spec'.

IcedTea (http://icedtea.classpath.org/) is a set of sources, patches
and build environment to build fully featured Java developement kit
and runtime environment from OpenJDK sources.

OpenJDK is the GPL  release of Sun's Jave JDK. Though, but itself, it is
not complete (still some third-party, non-GPL components are needed to
build it and for full functionality) and does not support every platform
we have. And it needs another JDK to build itself.

IcedTea can be built with GCJ/ECJ and can support more platforms (I
hope).

First IcedTea was started with the OpenJDK code which was Java 7
development code. Java 7 is still a future and world uses Java 6,
so a Java 6 OpenJDK has been released and IcedTea6 based on it. That is
why the package is named 'icedtea6' not 'icedtea'. 

When packaging IcedTea I wanted to solve some problem we have with our
current JDK packages:

1. Only single JDK could be installed. 

That was unacceptable for many. I need to use Java5 (java-sun-1.5.x) and
Java 6 (java-sun-1.6.x) to do my job… I had to use chroots. Then, PLD
packages expected the GCJ java stack (java-gcj-devel package). To
install it one would have to uninistall whatever other Java JDK or JRE
he is using.

Even to build the IcedTea6 I needed java-gcj-devel, which I couldn't
install as I need to have my java-sun working here. That is why
'java-gcj-devel' is the first package I have 'fixed'.

The fix was moving all /usr/lib/jvm/* stuff to a *-base subpackages,
which would provide all the needed JDK functionality, and could be
installed together with java-sun-* or other JDK. The base package would
contain links in %{_bindir} and other things that would conflict with
other JDK.

Then I did the same with IcedTea. One may install icedtea-jdk-base and
icedtea-jre-base and use it without un-installing sun-jdk or
java-gcj-devel.

2. I forgot ;)


Some decisions I made, may be controversial. I will list them for
discussion:

1. icedtea6.spec instead of, already existing, icedtea.spec -> already
   discussed.

2. 'icedtea6' instead of 'java-icedtea6'.

  This is a Java implementation, not a library. Let's keep java- prefix
for Java libraries. I don't like the 'java-gcj-compat' name either.

3. 'icedtea6' instead of 'openjdk'

  Yes, the thing built from IcedTea is OpenJDK… but OpenJDK could,
theoretically, be built from their own sources too. And we would get
something a bit different. So let's keep 'openjdk' name for that
'vanilla OpenJDK'

4. '-base' suffix for the 'base' packages…

  This is the first idea for the name I got. It could be 'jdk-icedtea6'
  package, it could be other suffix. It doesn't matter much as long it
  will be consistent with other JDK implementations.

  Currently only icedtea6.spec and latest java-gcj-compat.spec use this 
  'feature', so it can be still changed. Though, the more I think about
  it the more I like my '-base' idea :)

5. No '-tools' package.

  java-sun provides java-sun-tools subpackage providing 'java-jre-tools'
  virtual. It seems a very artificial separation and I think any
  dependencies on java-sun-tools or java-jre-tools should be dropped in
  favour on precise executable path dependency.

  I have created a 'icedtea6-jar' subpackage instead, for the one
  utility from java-jre-tools. This way alternative JAR implementations
  may be provided by PLD under /usr/bin/jar name.

6. Lots of 'obsoletes' in 'icedtea6' packages, sometimes duplicating
  those inherited by icedtea6-* dependencies.

  I think this is a best way to provide simple replacement for
  'java-sun' and 'java-sun-jre'. In many cases there will be no need to
  install 'icedtea6' package anyway, as 'icedtea6-jdk', 'icedtea6-jre'
  or even 'icedtea-jre-base' will be enough. But, if one wants simply 
  to replace existing Java implementation with IcedTea simple 'install
  icedtea6' in poldek should be enough.

7. 'jar' and 'appletviewer' in the -jdk-base, the 'jar' and 'appletviewer'
   packages provide only links and manual pages.

  This causes 'icedtea6-jar' to pull whole 'icedtea6-jdk-base', but 
  otherwise we would probably need to have icedtea6-jar-base subpackage
  too. 

  Current solution seems good enough for me as:
  a) usually when one really needs 'jar' (and ZIP is not enough), he
     probably needs a JDK anyway.
  b) we have other, smaller JAR implementations in PLD, like fastjar

Any more questions, comments, proposition?

And one 'little' request from me: could anyone review the existing and
write missing package descriptions (English and Polish) in icedtea.spec,
please?

Greets,
        Jacek