[lsb-discuss] LSb Java

Pavel Shved pavel.shved at gmail.com
Wed Jun 16 13:36:24 PDT 2010


Hi.

A couple of words from the guy who was doing the project.

On Monday 07 June 2010 18:14:34 Robert Schweikert wrote:
> The goal of the GSoC project was in my mind to make openJDK LSB
> compliant and NOT, add a mode in which I can build openJDK in an LSB
> compliant way. These are quite different goals and the GSoC produced a
> way in which one can build openJDK in an LSB compliant way.
You're right.  But we also aimed another goal: keep all the functionality 
that presents in OpenJDK.  Could these goals be achieved simultaneously?  
We didn't know before we started the scrutiny of OpenJDK during the 
summer.

First, OpenJDK contains a virtual machine with its own memory and thread 
management.  It's a very low-level code.  To implement it, such functions 
as alloca(), ucontext(), syscall() to get thread id, mincore(), and 
special kind of mmap() are used.  Let alone that a part of it is 
implemented in assembler!  Could this undergo a major rewrite to rely on 
LSB?  Even this being done, would it then be accepted by the upstream?..

Second, some features (such as SO_PEERCRED for sockets) were introduced 
in Linux to make existing functionality more accessible.  "Downgrading" 
them to implementations, which are less convenient but included into LSB, 
would be suitable for a special LSB build.  But for the upstream?

Another reason to create an "LSB build of OpenJDK" was that, 
surprisingly, OpenJDK happened to use bootstrapping.  We had agreed 
before that we need only compliant JRE, and a java compiler tools might 
be out of LSB coverage.  After I started patching, it appeared to be 
true: compiler tools rely on non-LSB interfaces (such as ptrace and 
thread debugging library that was ported from Solaris).  Thus, to build 
OpenJDK with LSB SDK, compiler part should have either be done with "LSB 
mode" or just become crippled.  The latter would be OK, if the goal was 
to build JRE and ship it, but it wouldn't be OK, if we wanted to make 
upstream patches.

Therefore, after the aforementioned scrutiny, I realized, that before 
OpenJDK and LSB come to an agreement of sorts, or before LSB evolves, 
upstream OpenJDK wouldn't become LSB-compliant.  So I aimed creating an 
LSB build, that could live apart from trunk of OpenJDK.

The build created can be easily be maintained to monitor the state of 
discrepancy between interfaces OpenJDK uses and those LSB provides, it 
also has infrastructure to support building OpenJDK for a specific LSB 
version.  This build keeps all Java features, fails gracefully if an 
optional feature (such as availability of all required ALSA interfaces) 
is absent, and fails early if a required feature is not presented (with 
an informative message).  You can check what was replaced with LSB 
wrappers in the web interface to repository with GSoC results [1] -- it's 
the most complete list.

The results, unfortunately didn't meet all the expectations.  However, a 
proper investigation of OpenJDK was performed, and, at least, we got an 
LSB build.

References:

[1]:  GitWeb interface to LSB wrappers folder
http://git.coldattic.info/cgi-
bin/gitweb/?p=openjdk7.git;a=tree;f=hotspot/lsb;hb=c29b600ec850f122b81ea4d50d5f039780b12552

--
Pavel Shved


More information about the lsb-discuss mailing list