Re[2]: Using OSG for Classpath

[Peter Kriens]

I know ... I have been there.

However, the problem is not so much in the API as well as it is in the
associated implementation code. But once I got time I will do some
experimenting. I found complete definitions of the standard Java
profiles somewhere on my harddisk.

Kind regards,

     Peter Kriens
DD> Peter Kriens wrote:
>> It may be easy to describe the modularization, it is much harder to
>> get a large number of companies to agree on this description. OSGi is
>> quickly becoming the defacto standard for this type of modularization.
>> 
>> The OSGi has so called execution environments which are machine
>> readable descriptions so I could use that to create the subsets for
>> these execution environments. I guess I can do this from the
>> monolithic JAR file without intruding on the normal development.
>> 
>> Lets see what comes out of that exercise.
>> 
DD> Here are a couple problems:

DD> * Figure out how to remove references to URLClassLoader from 
DD> java.lang.ClassLoader.  URLClassLoader then refers to the URL related
DD> classes, these in turn refer to all of the URL protocol handlers.  The
DD> HTTPS protocol handler then refers to things in ...

DD> * SecurityManager.  Need I say more?  The chain of classes needed by
DD> this class is unending.

DD> The result is that the simplest 'Hello World' program that only calls
DD> System.out.println() requires many hundreds of classes that at first
DD> glance one might not think were necessary.

DD> David Daney.


DD> _______________________________________________
DD> Classpath mailing list
DD> address@hidden
DD> http://lists.gnu.org/mailman/listinfo/classpath


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