From Mandriva Community Wiki

This page discusses packaging Java applications for Mandriva Linux.

Contents 1 Java in Mandriva 2 GCJ and native code 3 Getting the environment 4 File layout 5 Compatibility with proprietary Java stacks 6 GUI Programming 7 Compatibility with the Sun Java stack 8 Running a jar in Linux as you would in Windows, etc. 9 Co-existence with JPackage 10 Problems with Current GCJ Packaging 11 Building a free Java stack from scratch 12 Major Java Programs 13 JVM's in Mandriva 14 TODO 15 Bugs 16 List of Mandriva Java Packagers

[edit] Java in Mandriva

The free Java stack in Mandriva is made up of three main components:

1. gij and libgcj, the GNU Java interpreter and runtime from the gcc package
2. ecj, the Eclipse Java compiler
3. java-gcj-compat and java-gcj-compat-devel, which effectively turn gij into java and ecj into javac, respectively

Note that gcj is not used at this time, except to transform bytecode into native code for use by gij. Any compilation to bytecode is instead done by ecj which has full support for Java 1.5.

There are also other components which provide features commonly found in a proprietary Java stack. Chief among these is probably gjdoc which provides javadoc support. As before, java-gcj-compat-devel will turn gjdoc into javadoc.

We also have jessie and gnu-crypto, for JSSE and JCE, respectively. For JCE, it is recommended that you use bouncycastle instead, as the current gnu-crypto is based on an older version of bouncycastle, anyway.

[edit] GCJ and native code

Unlike other Java virtual machines which feature just-in-time compilation of jar files, gij uses ahead-of-time compilation where every jar file has a corresponding jar.so native library.

Note that you do not need to compile to native code directly since there are helper scripts that will do the work for you. Inside an RPM spec file, use %{_bindir}/aot-compile-rpm with no arguments in the %install secion and include =%attr(-,root,root) %{_libdir}/gcj/%{name}= in the file list. This directory will contain any jar.so files that were produced.

Currently, we are including jar.so files directly into the rpm, thus turning a noarch package into an arch-specific package. I am of the opinion that it would be better to create another package such as %{name}-native which BuildRequires: %{name}, but we need a policy on this. One of the advantages is that it would keep the noarch packages and allow the use of JPackage packages directly.

[edit] Getting the environment

To install the equivalent of the jre, execute urpmi java-1.4.2-gcj-compat.

To install the equivalent of the jdk, execute urpmi java-1.4.2-gcj-compat-devel.

You may also try urpmi java and =urpmi java-devel=, respectively, but note that this may cause urpmi to suggest kaffe (or any number of proprietary environments if you have added binaries of the JPackage provided source rpms as a urpmi source).

[edit] File layout

Following JPackage standards, any JPackage compatible Java environment is installed under /usr/lib/jvm. For example, gcj is under =/usr/lib/jvm/java-gcj=. Jars are located under =/usr/share/java=. JVM extensions (such as bouncycastle) are located under =/usr/share/java-ext=.

The jpackage-utils package provides many useful scripts. The primary script is build-classpath. This script is used to set the CLASSPATH when building. For example, executing =export CLASSPATH=$(build-classpath junit)= at the shell sets =CLASSPATH=/usr/share/junit.jar= so that you do not need to hardcode the exact jar location. Note that in some cases, the names of JPackage jars may differ slightly from the upstream name. For example, the xerces jar is called =xerces-j2.jar=.

[edit] Compatibility with proprietary Java stacks

One of the main reasons that ecj is used over gcj is that it is a more complete (and bug-free) Java compiler than gcj. It supports all of the Java 1.5 language specification. However, here are some of the major drawbacks of the current free Java situation:

• No free JVM currently supports assertions, but code that uses them will compile fine.
• The java.nio package is broken. Currently, packages like azureus will not work.
• Swing is incomplete and not very well supported, particularly the HTML widget.
• Some tools are missing and javah support could be better. The future classpath tools package may remedy this.
• Applet support is very poor. The package mozilla-plugin-gcjwebplugin is included, but it does not support Java plugin 1.5 features, and it does not support Java and JavaScript communication. Its biggest flaw is that it is missing a security manager, so all code gets executed with full permissions. Therefore, it is considered a security risk to use the plugin at this time. Also, it is not clear how to enable it alongside the commercial Java plugin.
• Debugging is difficult. The standard GNU debugger can be used, with some success, but standard Java tools, such as eclipse, cannot be used.
• The classes java.beans.XMLEncoder and java.beans.XMLDecoder are not implemented ib libgcj-4.1.0.jar (they are in classpath 0.20+).

[edit] GUI Programming

Since Swing support is not yet complete, we provide (at least) two other options:

1. You can use SWT, which is part of eclipse but can be installed separately.
2. You can use the Java bindings provided for gconf, glib, gtk, gnome, and cairo.
3. The kdebindings package will hopefully provide Qt and KDE Java bindings in the future.

[edit] Compatibility with the Sun Java stack

The Mandriva Club currently provides packages of the Sun jre and Sun jdk. JPackage provides a java-1.4.2-sun-compat and java-1.4.2-sun-compat-devel package, respectively, which make the Sun Java stack behave like any other JPackage stack (i.e., you may change it by setting JAVA_HOME=/usr/lib/jvm/java-1.4.2-sun or by using =update-alternatives jre_1.4.2= and =update-alternatives java_sdk_1.4.2=, respectively.

Currently, developers employed by Mandriva are using the proprietary Sun JVM to build some of your favorite applications which you may have previously thought were free. Mandriva should state a policy on whether software built with a non-free Java SDK is allowed into the distro. For example, OpenOffice contains Java code and is in the distro even though a free compiler has not been used to build these binaries.

We can make their job easier by providing java-1.4.2-sun-compat in Mandriva Club and by encouraging them to switch to java-1.4.2-gcj-compat for all packages in main, and to use java-1.4.2-sun-compat for packages in Mandriva Club only. So far, though, Mandriva has not agreed to any such policy.

[edit] Running a jar in Linux as you would in Windows, etc.

Ideally, we would like to be able to execute jar files by default in KDE and GNOME, or even at the shell. This is so even though JPackage doesn't support jar manifests. The java_binfmt package may be useful here, and could even be required by default.

[edit] Co-existence with JPackage

JPackage provides a cross-distribution Java Packaging standard. To really benefit from JPackage and be compatible several things needs to be addressed and fixed upstream. Info regarding this has been moved to a separate JPackage section.

[edit] Problems with Current GCJ Packaging

As of gcc-4.0.1-5mdk, Java support is working relatively well.

A few bugs remain:

1. The file /usr/bin/addr2name.awk is missing Bug #17412.
2. Some manpages and infopages are missing Bug #18157.
3. The file libgcj.pc installed to incorrect location Bug #18859.
4. Missing %ghost/FakeAlternatives for gcj Bug #18158.
5. /usr/include/ffi.h includes ffitarget.h incorrectly Bug #19564.
6. libtool.m4 and ltmain.sh have a version mismatch Bug #19739.
7. .la and .a should be removed Bug #20462.
8. tomcat5 doesn't build Bug #18166.
9. Other gcc packaging bugs Bug #18151, Bug #18152, Bug #18153, Bug #18154, Bug #18155, Bug #8156, Bug #18159, Bug #18160, Bug #18357.

Also related is the fact that rpmupload does not seem to handle arch changes. This will become a problem as noarch packages are converted to (i586, x86_64, etc.) binary packages and uploaded into the distro, unless binary packages are kept separate from the core noarch packages.

[edit] Building a free Java stack from scratch

The packages to build are listed in order. A nested list element means that the child package is required by the build/install of the parent package. Some packages may require bootstrapping in order to build for the first time. Use rpm --define 'bootstrap 1' (FIXME: we should create %{name}-bootstrap packages, where %{name} BuildRequires: %{name}-bootstrap) when building. After bootstrapping is complete, you will need to rebuild the packages.

Packages marked with a (*) have already been packaged in Mandriva. Packages with a (b) still have to be rebuilt in Mandriva after bootstrapping has been completed.

• Core: jpackage-utils (*)
• Core: java-1.4.2-gcj-compat (*)
  • Requires: eclipse-ecj (*)
  • Requires: gjdoc (*)
    • BuildRequires: antlr (*)
      • BuildRequires: ant (*)
      • BuildRequires: bcel (*)
        • BuildRequires: regexp (*)
      • BuildRequires: bsf (*)
        • BuildRequires: jython
        • BuildRequires: servlet (*)
      • BuildRequires: javamail (classpathx-mail) (*)
      • BuildRequires: jaf (classpathx-jaf) (*)
      • BuildRequires: jakarta-commons-logging (*)
        • BuildRequires: avalon-logkit (*)
        • BuildRequires: avalon-framework (*)
      • BuildRequires: jakarta-commons-net (*)
      • BuildRequires: jdepend (*)
      • BuildRequires: jsch (*)
        • BuildRequires: jzlib (*)
      • BuildRequires: junit (*)
      • BuildRequires: log4j (*)
        • BuildRequires: xml-commons-apis (*)
      • BuildRequires: oro (*)
      • BuildRequires: xml-commons-resolver (*)

[edit] Major Java Programs

1. ant.
2. eclipse.
3. tomcat.

[edit] JVM's in Mandriva

1. CACAO (JRE).
2. GCJ (JDK).
3. JamVM (JRE).
4. Kaffe (JDK).
5. Sun Java 1.5 & 1.6 (JRE & JDK, non-free)

[edit] TODO

1. java_binfmt: better integration
2. jonas: semi-packaged, get building and remove binary jars (no longer in FC5?).
3. kdebindings: build with java support (Ubuntu has a patch for this).
4. openoffice2: build using a free jdk.
5. subversion: build the java bindings.

[edit] Bugs

1. Come up with a Native Java Packaging policy.
2. Look at packaging xwiki, which is used by the club.
3. Make the club rpms work with JPackage. I think this is as simple as making this change: %define upstreamdir %{_libdir}/jdk-%{javaver}_%{buildver} (with the correct %{version} and %{buildver} of course).

[edit] List of Mandriva Java Packagers

• David Walluck
• Christiaan Welvaart
• Per Øyvind Karlsen