classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re[2]: Using OSG for Classpath


From: Tim Ellison
Subject: Re: Re[2]: Using OSG for Classpath
Date: Mon, 5 Dec 2005 22:23:01 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Peter Kriens <Peter.Kriens <at> aQute.se> writes:

> 
> 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> Classpath <at> gnu.org
> DD> http://lists.gnu.org/mailman/listinfo/classpath
> 


Peter,

Take a look at the core Harmony classlib code that was accepted into the project
on Dec 1.  It is split into bundles with manifests.  Is this what you were
thinking about?  It enables a finer level of library interop (see [1]).

It would be great if Classpath adopted the same componentization framework to
enable this degree of interaction.

[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200512.mbox/ajax/
address@hidden

Regards,
Tim

-- 

Tim Ellison (address@hidden)
IBM Java technology centre, UK.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]