harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From galaxy <tian.gal...@gmail.com>
Subject Re: The OSGi-Harmony Runtime
Date Sun, 16 Aug 2009 10:29:47 GMT
A little more than 10M if we only count the jar files in lib/boot
right now.Haven't
been fully tested though , maybe more than this in the end
2009/8/16 Xiao-Feng Li <xiaofeng.li@gmail.com>

> Good work! How much is the size of the minimum OSGi-ed JRE?
>
> Thanks,
> xiaofeng
>
> On Sun, Aug 16, 2009 at 3:22 PM, galaxy<tian.galaxy@gmail.com> wrote:
> > Hi  all
> >    Now the code for OSGi-ed Runtime of Harmony is almost complete , I'd
> > like to give a review of
> > the work so far.The code and usage will be uploaded together soon
> >
> > Introduction To OSGi-ed JRE
> >
> >
> >
> > 1 : The main purpose
> >
> > OSGi has become one of the best ways to govern the jar files in a number
> of
> > applications Such as the power it exhibits in eclipse .And as we all know
> > ,the Harmony runtime is a modularized one and each module , with its
> > manifest file , is just like one bundle in the OSGi framework .So we are
> > think of governing the modules in Harmony runtime in a OSGi-ed way.
> >
> >
> >
> > 2 : Ways to meet the main purpose
> >
> >       Naturally, there are two ways to meet this purpose:
> >
> > A  Implementing the OSGi framework in VM in C/C++ to govern all the java
> > modules
> >
> > B  Using one of the OSGi-ed framework implemented in java to implemented
> a
> > half OSGi-ed JRE.
> >
> >       Finally I picked the plan B with the well known OSGi framework
> :Felix
> > .And the reasons are as follows
> >
> > First : Implementing a OSGi-ed framework from scratch in c/c++ in the vm
> is
> > difficult and time-consuming .
> >
> > Second : Plan A suffers from the facts that implementations differs huge
> > from VM to VM .Plan B won’t have this kind of problem as long as the
> modules
> > comply with the OSGi specifications and we have a adapted java.exe , the
> > rest is nearly the same.
> >
> > Third : Beside the framework ,each OSGi implementation has a lot of
> add-ons
> > .This will facilitate future development of new features and utilities
> .For
> > example : the could use the bundle fileinstall to install all the jar
> files
> > lies in a folder ,very helpful in certain circumstances.This could be
> done
> > rapidly if we choose plan B .
> >
> >
> >
> > 3 : Problems and fixes
> >
> > The difficulties ,or the main tasks ,of this project are as follows
> >
> > A     Find the minimum working environment of OSGi-framework and modify
> the
> > rest modules in Harmony ,mainly the manifest file ,to resolve the
> coupling
> >
> > B     Modify the classloading mechanism and booting of the jre to be able
> > run normal java applications
> >
> > And the fixes are
> >
> > For A:
> >
> > Harmony is a modularized runtime .So determine the minimum working
> > environment is no more than choose the right module to stay with the VM
> > .However ,although the coupling is little , it does exist . So a
> > modification of the module is necessary ,mainly the manifest file .And as
> I
> > want  to remain the original structure of Harmony as largely as possible
> > ,more contents (classes ) will be included in the minimum environment
> other
> > than splitting the modules apart .The final jre include the following
> > component :
> >
> >
> >
> > luni.jar
> >
> > annotation.jar
> >
> > security.jar
> >
> > math.jar
> >
> > text.jar
> >
> > regex.jar
> >
> > noi_char.jar
> >
> > nio.jar
> >
> > logging.jar
> >
> > concurrent.jar
> >
> > archive.jar
> >
> > the ICU4J folder.
> >
> >
> >
> > The remaining jars are governed by the OSGi framework to handle. One more
> > thing to mention is the two classes
> > ,”java.beans.PropertyChangelinstener”,”java.beans.PropertyChangeEvent”
> has
> > to be moved out of beans.jar .This is because of the coupling of
> beans.jar
> > with other modules in the minimum runtime .Well the good thing is these
> two
> > classes havn’t imports any other classes in the modules governed by the
> OSGi
> > framework .I think we could include them in any modules lie in the
> minimum
> > runtime as long as the VM could find them .
> >
> >
> >
> > For B:
> >
> > I added one extra sphere between the VM and the main class to run
> > .org.apache.osgi.FelixStarter. , the following is done in this class
> >
> > First: Loading the configurations and Start Felix ,the OSGi framework we
> use
> >
> > Second: Initializing the class org.apache.osgi.OsgiClassLoader ,this
> class
> > will load the main class and subsequently all the classes used in the
> main
> > class
> >
> > Third: Transfer the arguments to the “real “ main class ,invoke the main
> > method .
> >
> >
> >
> > The sequence of class loading is as follows :
> >
> >
> >
> > First : Check the class name to determine whether it should be loaded by
> the
> > parent class loader .This work is done by specifying the
> > “org.osgi.framework.bootdelegation” property to include all the package
> > names in the modules stays in the VM .
> >
> > Second : load the classes in the bundle governed by the framework .I will
> > examine each bundle's export and import property to search for the class
> > name ;
> >
> > Third : the classes in the application’s class path .
> >
> > Finally : we could not find the class and a ClassNotFoundException will
> be
> > thrown .
> >
> >
> >
> > Both the OSGi framework and the Harmony do not allow the define , imports
> or
> > exports of java.* classes and packages ,so a lot of examines has been
> > removed to facilitate our purpose .
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > regards
> > Tian
> >
>
>
>
> --
> http://people.apache.org/~xli
>



-- 
regards
Tian

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message