Re[2]: Using OSG for Classpath

[Peter Kriens]

Obviously, the first distinction is java, javax and the rest.

There are a number of well defined profiles in J2ME. There are issues
but it would be great if they could be supported. However, I think the
first step should be modularizing the low hanging fruit.

The OSGi modularization is based on Manifest headers that describe the
package and their dependencies. The simple headers are:

        Manifest-Version: 1.0
        Bundle-SymbolicName: ApacheTomcat
        Bundle-Version: 4.2.1
        Import-Package: javax.servlet; version=2.4,
          javax.servlet.http; version=2.4
        Export-Package: org.apache.tomcat.util.net; version=4.3

Bundles can import packages and export packages. Versions are
supported, as well as arbitrary attributes. When deployed on an OSGi
Framework, the bundles are wired together as defined by their
capabilities.

There are tools (I have one) that can create these headers depending
on a list of packages that need to be jarred. They analyze the
bytecodes and find out the dependencies.

Additionally, you can also include native code in the JARs. This is
described with the following headers;

        Bundle-NativeCode: /lib/java-io.DLL; osname = QNX;
           osversion = 3.1,
           /lib/java-io.so; osname=Linux; osversion=2.2.4


The trick is to define a good base set and then create additional JAR
files for the extensions.

Kind regards,

     Peter Kriens

        



AH> Peter Kriens writes:
 >> I am very impressed with the Classpath libraries. It is an impressive
 >> feat to get so much done.
 >> 
 >> I have, however, a request. The current classpath is becoming quite big
 >> and will contain too much for smaller environments. I am trying to get
 >> jamvm and classpath to work on an NSLU2 and it means I have to twiddle
 >> a lot. So I have some questions:
 >> 
 >> 1/ Could classpath be split up in multiple, independent projects? I.e.
 >>    every javax should have its own JAR.

AH> It would be a good idea to partition Classpath into subsets.  That
AH> said, the nature of the Java library makes this hard to do.

 >> 2/ Could you use the OSGi modularization headers for JAR files to
 >>    make these libraries deployable? These headers allow you to keep
 >>    implementation code protected from other JARs when running on an
 >>    OSGi system. These headers are ignored for other systems.
 >>    FYI, OSGi is used in Eclipse, Apache and in many commercial
 >>    projects. I would be more than willing to help to get these headers
 >>    in place.

AH> Please give us some idea about this.  How do OSGi modularization
AH> headers work?

 >> 3/ Cross dependencies should be absolutely minimized. I noticed
 >>    java.nio was used in several implementation packages.

AH> Here we must disagree.  Performance and completeness comes first.

AH> Andrew.


-- 
Peter Kriens                              Tel +33870447986
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599