Fernando Lozano's Blog

Community: linux.java.net Archives

Afraid of trying JPackage?

Most Linux developers and sysadmins I talk to think JPackage is great, once they are introduced to the advantages of not having tons of copies of every jakarta-commons-whatever and having each application automagically use the Java release (or even vendor release) it needs.

But mosf of them are scared of the bootstrapping procedure, except for the few lucy ones that already have a JPackage-compatible JVM as part of their (commercial) distros, or the few ones that are brave enough to try and find their applications already work with GCJ. Rebuilding a RPM package looks like mission impossible to them.

So I created the following shell script, that does everything you need to bootstrap your JPackage environment except for downloading Sun Java. Just save it on the same directory that has the Sun Java tarball and let it run. In the end, you'll have a few packages ready to copy and install on each Linux workstation or server in your network.

For the curious, this script (actually the JPackage RPM spec) generates the following packages:

• java-1.5.0-sun-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-alsa-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-demo-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-devel-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-fonts-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-jdbc-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-plugin-1.5.0.07-1jpp.i586.rpm
• java-1.5.0-sun-src-1.5.0.07-1jpp.i586.rpm

You may not be able to install the “sun-jdbc” package, but this does not means you won't be able to run JDBC applications. It just means you do not have installed unixODBC (and who does use the JDBC-ODBC bridge under Linux anyway?)

Likewise, you may not be able to install the “sun-alsa” package if you do not have the Alsa sound libraries installed. I personally don't think I need sound support to run my JavaEE application servers.

Finally, you do not need to install the “sun-fonts” package in every Linux workstation if you do use an X Font Server – you may need to install this only on the font server machine.

After installing the repackaged Sun Java, you can start downloading Java application packages from www.jpackage.org or, better yet, configure your yum repositories to point to the JPackage Project one.

Here's the script. It could be enhanced, for example not being hardwired to 1.5.0 update 7. But it does the work.

#!/bin/sh
# builds a JPackage-compatible Sun JDK RPM
# by Fernando Lozano 
#
# This script can be used, redistributed and changed in the terms
# of the Apache License 2.0 (http://www.apache.org/licenses/)
# provided these initial comments are not deleted nor modified.
# Of course you can add more comments if you like.

bin="jdk-1_5_0_07-linux-i586.bin"
srpm="java-1.5.0-sun-1.5.0.07-1jpp.nosrc.rpm"

base="build-sun-java-jpp-rpm"

if [ "$1" = "-h" -o "$1" = "-help" ]; then
    echo "This script builds JPackage compatible binary RPMS"
    echo "from Sun JDK 1.5.0_07 binary download for 32-bits Linux/Intel"
    echo "options:"
    echo "  -h: ths message"
    echo "  -q: really quiet"
    echo "  -v: verbose (shows rpmbuild messages)"
    exit -1
fi

if [ "$1" = "-q" ]; then
    output="/dev/null"
else
    output="/dev/stdout"
fi

if [ "$1" = "-v" ]; then
    rpmout="/dev/stdout"
else
    rpmout="/dev/null"
fi

echo "Checking prerequisites..." > $output

if [ -z "`which rpmbuild 2>/dev/null`" ]; then
    echo "rpmbuild not found. Either you need to adjust your PATH" 1>&2
    echo "or you need to install package rpm-devel as root" 1>&2
    exit 1
fi

if [ -z "`which wget 2>/dev/null`" ]; then
    echo "wget not found. Either you need to adjust your PATH or" 1>&2
    echo "you need to install package wget as root" 1>&2
    exit 1
fi

if [ ! -r $bin ]; then
    echo "$bin not found. " 1>&2
    echo "You need to download it from http://java.sun.com" 1>&2
    exit 1
fi

echo "Configuring RPM build environment..." > $output

d=`pwd`
mv ~/.rpmmacros ~/.rpmmacros.sav.$$ 2>/dev/null
echo "
%_topdir        %(echo ${d}/tmp-$base/rpm)
%_tmppath       %{_topdir}/tmp

%packager       build-sun-java-jpp-rpm by Fernando Lozano 
" > ~/.rpmmacros

echo "Creating build directories..." > $output

rm -rf tmp-$base
mkdir tmp-$base
cd tmp-$base
mkdir rpm
mkdir rpm/SOURCES
mkdir rpm/SPECS
mkdir rpm/SRPMS
mkdir rpm/RPMS
mkdir rpm/RPMS/i386
mkdir rpm/RPMS/i586
mkdir rpm/RPMS/noarch
mkdir rpm/tmp
mkdir rpm/BUILD

echo "Downloading SRPM from JPackage.org..." > $output

wget -qc http://mirrors.dotsrc.org/jpackage/1.6/generic/non-free/SRPMS/java-1.5.0-sun-1.5.0.07-1jpp.nosrc.rpm

echo "Moving required files to build dirs..." > $output

cp ../jdk-1_5_0_07-linux-i586.bin rpm/SOURCES
rpm2cpio java-1.5.0-sun-1.5.0.07-1jpp.nosrc.rpm | cpio -imud --quiet
mv java-1.5.0-sun-*fonts.xsl rpm/SOURCES
mv java-1.5.0-sun.spec rpm/SPECS

echo "Building JPackage compatible binary RPMS..." > $output

rpmbuild -ba rpm/SPECS/java-1.5.0-sun.spec > $rpmout 2>&1

echo "Finished." > $output

echo > $output
echo "Sun JDK Packages are in $d/rpm/RPMS/i586" > $output

echo "You may need to mannualy create the Java plug-in symlink for Mozilla / Firefox:" > $output
echo "# cd /usr/lib/firefox*/plugins" > $output
echo "# ln -s /usr/lib/jvm/java-sun/jre/plugin/i386/ns7/libjavaplugin_oji.so . > $output

Java One mini-talks for Linux users

The Java.Net Community Corner in the Java One Pavillion will feature a few talks of special interest for Linux developers, ranging from on Sun proprietary JVM and new JCP standards to F/OSS JVMs.

If you are around, please come and join us!

Linux distributions packagers will have a special interest in the May 17, 2:30pm presentation. I can't tell the details, but it'll be about things you weren't legally able to do before. You probably heard about a new license Sun will announce during JavaOne, so stay tunned.

The full schedule of Java.Net mini-talks during JavaOne can ne seen on the Community Corner Wiki page.

Echoing the Java Compatibility Call to Arms

Sun David Dagastine in his blog http://blogs.sun.com/roller/page/dagastine?entry=java_compatibility_call_to_arms asks developers to test their applications on all available JREs, citing Sun, IBM and BEA.

I agree with them that no matter how big are vendors and JCP efforts to promote compatibility and interoperability, the ability to run apps is the real measure of compatibility, and you will only get that if most developers test their code with as many JREs as they can, and report back any unexpected behavior.

But I have to add that it's not enough to test the biggest proprietary JREs, which are all of them Sun licensees. Java compatibility will only be real when there's also an independent JRE implementation that is able to run most if not any Java app and you are free to port this JRE to the platform of your choice. That's the true meaning of IT standards: not having to rely on a single vendor to run your apps. David's request is about relying on just Sun as the direct or indirect supplier of JREs.

Even if you argue that free software / open source software JRE implementations are not yet certified and may lack important parts of the JavaSE APIs, there's a good chance they already have enough to run your app, and the problems you may find when they don't run your app are actually your fault, not JRE flaws, as in the case of OpenOffice.org (see http://people.redhat.com/green/linuxworldfreej.pdf).

Hey, they already run Eclipse and Tomcat! Red Hat guys are even running JonAS under GCJ! Why then wouldn't your app run under a free software / open source JRE?

Here's a few good candidates you can try. Please add at least one of them to your standard testing practices:

• Kaffe - http://www.kaffe.org
• GCJ - http://gcc.gnu.org/gcj (this already comes bundled with most Linux distros
• JamVM - http://jamvm.sf.net (good for embebed devices, small RAM footprint)
• SableVM - http://www.sablevm.org

The developers of these free software / open source software JREs found that the single bigger headache, which prevents them from running even some open source Java applications, is the use of vendor-specific, non-standard classes by the applications. Most of the time they are com.sun.* classes bundled with Sun JRE.

So I add to David's request: please treat any use of non-standard JRE classes as a programming error. This will help a lot achieving true standard, compatible and ubiquitous Java.

When Applets are not WORA

During the end of 2005 I had a customer who could not run a Java Applet on his desktops, despite having the latest update from Sun. And the desktops ran the fastest-growing OS and browser in the market today

This customer ran Fedora Linux 4 and Firefox 1.5. We tried other Firefox and Mozilla releases (but could not try old Netscape 4 because the portal uses recent CSS standards and they were planning to start using AJAX). We also tried other releases of Sun Java as far as 1.4.0, besides IBM and BEA JREs for Linux. None of them worked for that particular application.

And what the application did to break compatibility? Nothing so uncommon: it used JSObject to direct the browser window load another page. The applet was a virtual keyboard for user login and we tested it worked flawlessly under Windows with both Firefox, Mozilla and the virus / worms farm (IE). Applets that didn't use JSObject worked fine in both Linux and Windows.

The applet used only standard Java SE / Java Plugin classes, no com.sun.* stuff, no JNI calls and no third party libraries. It is a very basic Swing application.

Digging deeper into the problem, we found the cause was that Fedora 4 packages were compiled using GCC 4.0 while Sun, IBM and BEA Java for Linux were compiled using GCC 3.3 (and older releases with GCC 2.9). So memory layout differences between the code compiled with each GCC release made the interaction between the JVM and the browser lock both, but without generating a SIGSEGV.

We confirmed the problem running the applet under Fedora Core 3 (that uses GCC 3.4) and all went fine. So the customer was left with the option of re-engineering the web app to not use Applets at all, or downgrade the Linux desktop to an earlier Fedora release, that is about to have no support anymore. Unfortunately, free software JVMs like GCJ, Kaffe and JamVM do not yet support reliable applet execution inside the browser.

We would not have had this problem (and the stress it caused) if Sun had a more liberal license that allowed Sun Java to be bundled and distributed with community-supported Linux (like old proprietary but freeware Netscape 4 did) and recompiled / repackaged and redistributed by those distribution mantainers. I hope Harmony or some of the other free software JVM matures quickly enough to give me a real choice over Sun Java.

If you use Linux, you should use JPackage

JPackage (www.jpackage.org) is an Open Source Software project that aims to provide popular Java applications and libraries in a manner that is compatible with Linux standards like the FHS and administrative best practices for the platform. But it goes well beyond simply packaging Java software as RPM packages used by most popular Linux distributions, it also provides ways to deal with conflicting Java VM and third-party library releases. It allows you to have at the same time one app that requires Java 5.0 and other that was certified to run only with 1.4.2 or even 1.3.1. It also allows you to have apps that require for example Hibernate 3.0 and other that works only with Hibernate 2.1 without requiring each app to have its own private copy of Hibernate libraries and their dependencies like Jakarta-commons and C3P0.

Major Linux distributions are already commited to JPackage, like Red Hat and Mandriva, and even Debian is using JPackage conventions and scripts for including F/OSS Java applications like RSSOwl and Eclipse in it's official download feeds.

In order to get a completely managed Java environment, JPackage even tells you how to repackage popular proprietary software like Sun JDK their way. Unfortunately they can't redistribute those packages because of license restrictions.

I manage a few Red Hat Enterprise Linux servers who already comes with JPackage RPMs for IBM JRE. It was very nice to be able to use their dependency information to deploy applications to our internal network and let yum take care of updates. It was also very nice to be able to use the alternatives system (from Debian) to switch the default Java from IBM JRE to GCJ when I was mantaining one app that made use of GCJ CNI. And I had no trouble deploying this update alongside others that required IBM JRE (or Sun JRE). JPackage makes sure each app runs on the JVM it needs.

Bottom line, the fact RHEL4 already uses JPackage made deploying and updating Java apps (both desktop and server-side) to a wide array of users and needs much easier than when I had to manually install, configure and customize Sun JRE and many vendors apps.

But now I need Java 5.0 for a new app and but I do not have it JPackage-enabled. Of course I could follow JPackage web site instructions on how to repackage Sun JRE 5.0 (or the new IBM Java Runtime 1.5.0) but it would be much better if they already provided JPackage-compatible RPMs. After all, I could use this time to do more important things for my employee.

Nothing prevents them to do so. The JPackage guys have already done all the hard work for Sun, IBM, BEA, Apache, JBoss and other Java vendors. Their work was already tested and validated by a number of users and corporations. And all major Java vendors already uses many F/OSS software as part of their products, so a few JPackage scripts should present no problem.

So, please, Java Vendors, make JPackage a standard part of your Linux packaging and support. You'll make your customers very glad.

How to Make Java Suited For Desktop Apps

Why don't open source developers help make open source java real?

In spite of all the rants about the need of open source Java, the open source / free software community itself is doing very little to make it real.

Not to disregard the efforts of the kaffe, gcj, classpath teams and other involved with F/OSS Java VMs, but what are big open source java projects from Apache Jakarta and Eclipse, small projects like HSQLDB and JUnit, and even individual open source developers, doing to help them?

I remember a few months ago someone posted at an Apache mailing list a complain about the huge help the foundation provided to identify and fix bugs on Sun Java, receiving almost nothing in return. He asked, why weren't some of these efforts spent trying to identify where and how to improve kaffe and etc so they become reliable platforms for running apache software?

Now I ask the same question for open source developers in general: Why don't you spend a little time testing your apps under kaffe and/or gcj? If only to provide them useful bug reports. But most things that prevent current applications to run under these free JVMs are just a few lines of code away, if some more developers decide to contribute patches.

After all, if the community itself don't think F/OSS Java is worth their time and efforts, why should Sun think different?

The Linux Java community

Before entering the subject of this post, let me introduce myself as the newest member of the group of Java.Net community leaders. I'm not here to replace Kevin in the Linux community, but to work with him in making linux.java.net the main source of information for Java developers who work on the Linux OS.

Talking a little about myself, I was a free software developer long before Linux became a mainstream OS and "Open Source Software" turned into a buzzword, but I'm also a corporate consultant, working with large Brazillian corporations and government agencies, so hopefully I can provide fresh views on many matters that are today distension points between Java and OSS developers in general.

The Linux community is a very heterogeneous bunch. Many do not view themselves as Linux users or developers, although their J2EE applications are hosted by Linux-powered servers and their embedded devices are based on the Linux kernel. Others may even say they don't care about Open Source Java at all. But their daily work is centered on Open Source tools like Ant, JUnit, Eclipse, Struts or JBoss.

Indeed, Java and Linux were the greatest changes on the IT industry during the latest decades, competing only with the Internet. Today, innovations on IT do not come mostly from big corporations anymore. They come mainly from community efforts,from the collaborative efforts of the best minds, whether they are at corporations, academia or not-for-profit organizations.

Java and Linux represent different views on how to advance the state-of-the-art in IT by bringing in the end-user. Both communities have much to learn from each other. Java and Linux have a lot more in common than recent arguments about open sourcing Java have shown; both pursue vendor-neutral standards-based software and open evolution instead of closed design groups.

In spite of Java platform independence, many important things about Java are very platform-specific: efficient JVMs and application servers, device compatibility, end-user support and desktop application deployment are some of these.

The Linux Community at Java.Net is the place where you Java developer that works on or targets Linux and other Open Source platforms like OpenBSD can find a forum to express your views about how Java could be improved. So what improvements do you think Java could have when running on Linux? And how do you think F/OSS developers and the JCP could work better together?

This work is licensed under a Creative Commons License.