harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Harmony Wiki] Trivial Update of "OSGi-Harmony Runtime" by galaxy
Date Tue, 18 Aug 2009 11:15:16 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Harmony Wiki" for change notification.

The following page has been changed by galaxy:
http://wiki.apache.org/harmony/OSGi-Harmony_Runtime

------------------------------------------------------------------------------
  
      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 .
  
+         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.
  
+         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 .
-     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 .
  
  
  
@@ -40, +34 @@

  
  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
-     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
+     B     Modify the classloading mechanism and booting of the jre to be able run normal
java applications
- 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 possible as I can , more contents
(classes ) will be included in the minimum environment other than splitting the modules apart
.The final jre include the following
-     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
@@ -83, +69 @@

  
  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 .
- 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
-     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
-     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
+     Third: Transfer the arguments to the “real “ main class ,invoke the main method
.
- 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 .
-     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 ;
-     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
+     Finally : we could not find the class and a ClassNotFoundException will be thrown .
- 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
.
- 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 .
  

Mime
View raw message