Upon examination the Linux Standard Base, in the currently released form, is missing one large camp of developers and applications—namely Java. That’s not to say you can’t run Java applications on essentially every Linux distribution. What it does say is there is no “LSB certified” offering for developers to target, giving them 100% confidence that their application will run as they intend it to.

From the LSB introduction page on the Linux Developer Network website comes the following statement:

“The Linux Foundation and the Linux Standard Base were created to enable ISVs to cost effectively target the Linux platform, reducing their porting, support, and testing costs while helping them address a global market for their applications.”

Supporting multiple platforms is one of the biggest cost factors for any software vendor. While it might not be a big deal for some in the FOSS world, it consumes large quantities of time and effort on the part of large project maintainers and contributors. Many get around the issue by requiring a particular library or Java runtime to be installed prior to their application. That works just fine until you need a locked-down OS with only “certified” drivers and libraries for a specific operating environment.

What’s the Big Deal?

At first blush it wouldn’t seem to be that big of a deal to just include the latest Java runtime from Sun and be done with it. But as the saying goes, nothing is ever as easy as it seems. One of the key tenets of the LSB is testing to ensure an application meets the minimal level of requirements. Once you bring testing into the picture you must use some sort of test suite. Take a look at the LSB Conference Call notes located on the public forum site to get an inside look at some of the issues at stake.

The solution to the problem is to use a category that the Linux Foundation calls “Trial Use”. By definition, Trial Use means there is no formal compliance process for the specification. In essence the application or library is included with the LSB distribution but doesn’t carry any of the benefits of certification—namely that an application written against the specified library is certified to run if the distribution is LSB version X.Y compliant.

Installing the latest version of Java can be an adventure in and of itself. For one user’s perspective take a look at this article on the Linux Developer’s Network (LDN). This highlights why it’s important to Java developers to have, at a minimum, a known version of the Java Runtime Environment (JRE) as a part of the LSB. It’s also helpful to have the JRE installed in a common location on the file system for reference purposes.

Java Versions

One of the biggest issues at stake is the standardization around a particular Java version. This can be problematic for any standards process especially if the item of interest has frequent releases or updates. Sun currently supports Java 1.5 and 1.6 with bug fixes and periodic releases. Version 1.5.0.01 was released back in February of 2005 while 1.6.0.0 was released in December of 2006. Java 2 Platform, Standard Edition (J2SE) Version 1.4.2 officially reached end of life on October 30, 2008. That means Sun will no longer issue bug fixes and patches for this version of the Java runtime.

With Sun updates coming at a regular pace it makes it difficult to pick a specific version number to standardize upon. The tendency is to pick an older version that has been released for a while to give some level of confidence that any bugs would have been discovered or at least identified by now. Most developers, however, like to use the latest and greatest releases to take advantage of the most up-to-date capabilities and features.

For the 4.0 release of the LSB the decision has been made to specify Java 6 Platform Standard Edition. The binary or a link to it must be installed in /usr/bin/java. Check out the LSB 4.0 beta Trial Use page for links to the standards related to Java.

Current Status

If you take a look at the LSB Roadmap you’ll see that each major release attempts to correspond to a major version or generation of the most popular Enterprise Linux distributions.  Version 4.0 of the LSB is scheduled to be released shortly. You can see a list of all the major components on the LSB 4.0 release site.

The application checker will not support Java applications for this release. Part of the rationale for putting Java into the Trial Use category is to work through some of the issues related to testing. Certifying the runtimes will be the first step and will help in the process of choosing which one(s) to include in the next release of the LSB. Once the runtime issue has been settled work can begin on developing the proper test suites to include in the application checker.

Current thinking for testing and associated licensing would involve the OpenJDK Community TCK license agreement, assuming the use of OpenJDK. For more information check out http://openjdk.java.net/legal/openjdk-tck-license.pdf for the license, http://www.sun.com/software/opensource/java/faq.jsp#k for the FAQ, and http://openjdk.java.net/groups/gb/2007-08-23.html for additional Q&A.

Bottom Line

For developers the bottom line is to use the Java 6 API standard for all applications targeted for LSB compliance. Sun provides a comprehensive set of documentation for all Java 6 APIs that should provide sufficient information to build your application. Sun does have a “100% Pure Java “cookbook available on their site, but it was published back in 2000.

Sticking to the standard APIs and the designated paths should be sufficient for testing with LSB 4.0 It will be important to track future releases of the LSB to make sure your application complies with any changes made and conforms to the final release version.