This page is a collection of notes on the creation of the lsb-java module.
One of the fundamental issues is whether or not Java is considered to be an application, or a part of the implementation. As an application, the JVM and all shared objects it may load must itself be LSB conforming. This may or may not turn out to be practical for Java interfaces beyond the core set of classes.
3rd party JVMs, which are currently in existence must be treated as an application. The JVM provided by a distribution however falls under the same rules as used for the other commands provided by the LSB. It does not have to be LSB conforming itself. It must however provide the interfaces specified by the LSB definition of the java command.
These notes take the position that java as provided by the lsb-java dependency will be a part of the distribution.
The lsb-java module will define the following commands:
The parameters that may be passed to these commands still needs to be defined.
The ClassPath project is creating the core class libraries used by the open source JVMs. Unfortunately, they do not yet have all of the classes defined by the Java specification implemented. Lsb-java will have to specify the subset that is implemented. There may be issues with using the term Java for an implementation that does not meet 100% of the specification.
The Java environment makes heavy use of 3rd party class libraries distributed as jars. This creates the same potential for DLL Hell we have seen for compiled programs. The JPackage project (www.jpackage.org) is attempting to solve this issue by creating conventions for packaging jars and providing a repository for finding them. While a good start, the docs are written using RPM specfile language, and there are further issues that they will likely hit later. These are the same sort of issues we have encountered with specifying package and package related problems.
JPackage specifies that an application shall use package dependencies to require these 3rd party jars. This then implies that the names of thepackages (or at least the provides) is well defined. Some of the outstanding issues with package naming are:
Without solving all of these issues, the problem of how an application can utilize 3rd party classes is just moved from one name space to another without actually providing the guarantees needed. One possible solution for part of this problem is the use of a name registry as is done for LSB packages.LSB packages are required to install their files under
/optaccording to the rules in the FHS and as supplemented by the LSB. A package containing a 3rd party jar must also follow these rules. Should we define a common directory under
/opt/lsb-java/jars?)? Can we count on the jar naming rules to ensure jars don't step on each other? Another option would be for jars to be installed under their own path under
/opt/lsb-java/<pkgname>/<pkg>.jar?) and then call a new command register-jar to cause the location of the jar to be added to the jvms classpath.
The JPackage project has identified the problem of the versioning of jars. The solution for this must be considered when developing the naming rules for jars and packages.
GJC can be used to convert classes & jars into shared objects. These shared objects must themselves be LSB conforming to ensure their portability. The LSB will need to add the gjc runtime that is needed to support these shared objects. Rules for the location of these shared object should mirror the rules used for the location of jars.
One of the features of JPackage is the use of the alternatives system to specify which jvm should be used. This has an impact on the distribution's support commitment that is part of the certification of the lsb-java module. A distro could inadvertently become liable for support for any 3rd party JVM that could be installed on a system.