From The Linux Foundation
lsb-java mailing list created. See also archive.
The new home for this exploratory project is [1]
This is also a LsbInterpretedLanguage, so general problems introduced there may apply to Java as well.
NEWS: Sun announces J2SE to be released under GPL.
Contents |
Problem Statement
The question that is addressed in this paper is Why should we include Java in the LSB specification?
Scope
In general, this paper refers to the Java Runtime Environment (JRE) which is made up of the Java Virtual Machine Library. the Java 2 Platform, Standard Edition (J2SE) APIs and some deployment layers.
This paper will refer to JRE, which is meant to include the JVM and J2SE. It is not clear at this point in time if the deployment technologies are required or are relevant.
The arguments in this paper, both for and against, are for the most part applicable to the server component (J2EE) of Java and the Micro Edition (J2ME). Additional work will be needed to identify the components that should be included in any Java Spec for J2EE and J2ME.
History
The issue of Java was raised at the LSB working group meeting in December 2004. There was a discussion about whether is was appropriate to include the JRE in the specification.
One school of thought held that it was appropriate because it is a defacto standard, is very stable and passes the best practices test.
Another school of thought held that licensing restrictions prevented its inclusion in the specification.
Data
It is the intent of the following data points to show that Java is a very important technology in todays servers, and desktops that interact with those servers.
"There's only two stacks now, .Net and Java," Greg Papadopoulos, Sun's chief technology officer, said in an interview with CNET News.Com. "The world should have two, for competitive reasons."
Hot Jobs on Yahoo shows thousands of openings for Java developers.
The battle for supremacy in the enterprise database development world has come down to two players: Java and .NET. - link
Argument for Inclusion
It is felt by some that the JRE is very relevant to any desktop based Linux implementation as is the J2EE to the server environment. It is clear that many web services exist today that are based on either Java or Microsofts .NET products. This does not imply there is an either / or scenario. It may well be true that a complete Linux desktop must be able to handle both Java and .NET based activity as well and other related technologies. However, the argument for including .NET as a part of the LSB standard is beyond the scope of this document.
According to http://www.linuxbase.org , The mission statement of the Linux Standard Base is as follows
To develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system.
http://www.linuxbase.org/test/registered.html
Current versions of the specification targets binary compatibility of libraries on Linux Distributions and certification of those distributions and the applications.
It seems intuitive that a similar approach can be made for the JRE. The usage of Java is widespread, especially in Web based applications. There are several similar, but slightly different implementations of the JVM. And finally developers of Java based applications would likely embrace the usage of a standard if that standard provided assurance that the Java application would run seamlessly on a compliant system.
Argument against Inclusion
The primary argument against inclusion in the LSB specification is the licensing issue. It is hoped that discussions can be held that address this concern.
Conclusion
It is the position of this paper that it is beneficial to the Linux community to recognize and/or establish a minimum set of Java methods, classes and resources that would exist on a compliant system.
Licensing concerns should be discussed and resolved if possible.
The intent of including Java in LSB will be to reference Sun defined Java specification. It seems likely that a minamum set of APIs, classes and methods will be defined.
Fundamental Issue
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.
Project Scope
The lsb-java module needs to define what is needed to execute an application. This includes the command use to invoke the JVM, the architecture of the JVM as defined by the byte codes which may be used, and the class library and its interfaces. It should not unnecessarily exclude alternative approaches (e.g. gcj). Note that the Java language itself need not be defined for the runtime environment.
Command definition
The lsb-java module will define the following commands:
- java
- javac - this is a development thing, so maybe it doesn't need to be dealt with now
- ???
The parameters that may be passed to these commands still needs to be defined.
Machine Architecture
For Java this is convered by the definition of the JVM and the byte codes. If there are multiple versions of these specs, we need need to identify which one is being used by the LSB.
Class Library Definition
The GNU 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 (see project page for comparisons). Note that the stated objective is GNU Classpath 1.0 will be fully compatible with the 1.1 and largely compliant with the 1.2 API specification, while many commercial developers consider 1.1 obsolete and are mostly interested in 1.3/1.4 compatibility. 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.
Testing
We will need to build a set of existence-testing tools that parallels the LSB testing tools (appchk, libchk, etc). Behavioral ("runtime") tests should be derived from the existing Java Test projects.
Other Related issues
There are other related issues that may be out of scope for the initial spec, but thought should be but into how to make sure all of these different solutions play well together.
Third Party Class libraries
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 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 the packages (or at least the provides) is well defined. Some of the outstanding issues with package naming are:
- Class->Jar mapping. : Jars tend to be TLA of a class name or purpose (class com.foo.bar -> cfb.jar). Unfortunately, this can result in name conflicts (com.far.boo also -> cfb.jar). Some rules needs to be put in place to ensure a unique mapping from class names to jar names.
- Jar->Package mapping. : Same as above, the rules for naming a package based on the jar it contains must be clear with no ambiguity. Also, what about packages that contain multiple jars?
- Package availability. : How can packages for 3rd party jars be located and installed? and who is going to provide support for these packages?
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 /opt according 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, for example /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, for example /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 jvm's 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.
GCJ classes
GCJ 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 gcj 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.
3rd party JVMs
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.
Interim Strategies
Since the process of getting Java into the LSB will likely take some time, we may need to explore some alternative short-term strategies.
LSB-compliant JRE/JDK
One alternative is to build a Java runtime package which is itself compliant with the LSB.
Platform Issues
One potential problem is that different architectures may require different JREs, which means we may have to port several JREs to the LSB. Sun's JRE is probably the best choice for ia32 and x86_64; IBM's is probably the best for the s390 family (and maybe the ppc family as well). This needs some investigation.
IBM has done some preliminary investigation; the major missing dependency seems to be ALSA. The LSB Navigator has data for IBM's Java and Sun's Java.
Java Certification
We'd want our binaries certified so we can call them Java. This might involve some licensing issues, etc.
Red Hat's IcedTea Project
Red Hat has a project called IcedTea, which aims to fill in the gaps in Sun OpenJDK with parts of GNU Classpath. The project seems to be good enough that there is talk of making IcedTea the default Java compiler in Fedora 8.
This might be a good base for our package.
IcedTea isn't complete yet; at this writing (October 2007), their page claims that sound, JavaScript support, and SNMP are not yet supported.
Interface Chart
Here are interfaces needed by the IBM JDK, compiled by George Kraft.
| Library | API | x86 | x86_64 | ppc32 | s390 | s390x | Comment |
|---|---|---|---|---|---|---|---|
| libc | backtrace | Y | Y | Y | Y | Y | |
| libc | backtrace_symbols | Y | Y | Y | Y | Y | |
| libc | \__deregister_frame_info | Y | Y | Use lsbcc to eliminate. | |||
| libc | \__divdi3 | Y | Use lsbcc to eliminate. | ||||
| libc | dl_iterate_phdr | Y | Y | Y | Y | Y | Use lsbcc to eliminate. |
| libc | \__fixdfdi | Y | Use lsbcc to eliminate. | ||||
| libc | \__fixsfdi | Y | Use lsbcc to eliminate. | ||||
| libc | \__floatdidf | Y | Use lsbcc to eliminate. | ||||
| libc | \__floatdisf | Y | Use lsbcc to eliminate. | ||||
| libc | \__getdelim | Y | Use lsbcc to eliminate. | ||||
| libc | getspnam_r | Y | Y | Y | Y | Y | This ia a Shadow Password API. Should use PAM instead. |
| libc | madvise | Y | Y | Y | Y | Y | Should use posix_madvise instead. |
| libc | memalign | Y | Y | Y | Y | Y | Should use posix_memalign instead. |
| libc | mincore | Y | Y | Y | Y | Y | Not specified, but documented for Linux. |
| libc | \__moddi3 | Y | Use lsbcc to eliminate. | ||||
| libc | \__overflow | Y | Use lsbcc to eliminate. | ||||
| libc | \__register_frame_info | Y | Y | Use lsbcc to eliminate. | |||
| libc | sendfile | Y | Y | Y | Y | Y | LSB candidate sendfile |
| libc | syscall | Y | Y | Y | Y | Y | Not portable. |
| libc | \__ucmpdi2 | Y | Use lsbcc to eliminate. | ||||
| libc | \__udivdi3 | Y | Use lsbcc to eliminate. | ||||
| libc | \__uflow | Y | Use lsbcc to eliminate. | ||||
| libc | \__umoddi3 | Y | Use lsbcc to eliminate. | ||||
| libc | \_Unwind_Find_FDE | Y | Use lsbcc to eliminate. | ||||
| libX11 | \_Xdebug | Y | Y | Y | Y | Y | Use lsbcc to eliminate. |
| libX11 | \_XEatData | Y | Use lsbcc to eliminate. | ||||
| libX11 | \_XFlush | Y | Y | Y | Y | Y | Use lsbcc to eliminate. |
| libX11 | XMissingExtension | Y | Use lsbcc to eliminate. | ||||
| libX11 | \_XRead | Y | Y | Y | Y | Y | Use lsbcc to eliminate. |
| libX11 | \_XReply | Y | Y | Y | Y | Y | Use lsbcc to eliminate. |
| libXext | XextAddDisplay | Y | Y | Y | Y | Y | Proposed. |
| libXext | XextCreateExtension | Y | Y | Y | Y | Y | Proposed. |
| libXext | XextFindDisplay | Y | Y | Y | Y | Y | Proposed. |
| libXext | XextRemoveDisplay | Y | Y | Y | Y | Y | Proposed. |
| libXp | XpEndJob | Y | Use GtkPrintUnixDialog instead. | ||||
| libXp | XpEndPage | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXp | XpGetContext | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXp | XpGetDocumentData | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXp | XpGetOneAttribute | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXp | XpGetPageDimensions | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXp | XpGetPdmStartParams | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXp | XpGetScreenOfContext | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXp | XpQueryExtension | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXp | XpSelectInput | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXp | XpSetImageResolution | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXp | XpStartPage | Y | Y | Y | Y | Y | Use GtkPrintUnixDialog instead. |
| libXt | applicationShellClassRec | Y | Y | Y | Is Motif application using? | ||
| libXt | colorConvertArgs | Y | Y | Y | Is Motif application using? | ||
| libXtst | XTestFakeButtonEvent | Y | Proposed. | ||||
| libXtst | XTestFakeKeyEvent | Y | Y | Y | Y | Y | Proposed. |
| libXtst | XTestGrabControl | Y | Y | Y | Y | Y | Proposed |
| libXtst | XTestQueryExtension | Y | Y | Y | Y | Y | Proposed |