[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