harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [arch] VM/Classlibrary interface
Date Tue, 31 May 2005 19:50:01 GMT

On May 29, 2005, at 6:35 PM, Peter Edworthy wrote:


>
> Sadly I've left my copy of the Java 2 security model book at work, but
> basically my understanding is ClassLoaders restricting access is the
> correct solution. It provides the interface independence we are  
> looking
> for, i.e. changes to the VM interface and changes to the Java(x).*
> interface are entirely independent. Yes it can be circumvented, but  
> only
> with access to the security settings and then anything could be done.
>
> This does require support from 'ClassPath' type projects though,  
> but any
> solution requires an agreement of the interface between the JVM and  
> the
> java(x).* class libraries.

Yes - that would be one of the goals here at Apache Harmony - to  
drive to consensus on what that interface should indeed be, and all  
work to make that so.

>
> The implementation would be whenever a 'VM implementation' class is  
> used
> in 'ClassPath' or similar projects the 'VM implementation ClassLoader'
> would have to be used. When a Java(x).* class was used the default  
> loader
> would be used, this explicitly seperates the namespace for JVM  
> classes and
> java(x).* classes. The obvious way to get this loader would be through
> Object.getClassLoader() and ensuring the 'VM implementation  
> ClassLoader'
> was on the tree below the java(x).* ClassLoader.
>
> I'm open to suggestions of how best to mark the ClassLoader as the 'VM
> implementation ClassLoader' as of cause an interface marking it  
> would have
> to be at the ClassPath( java(x).*) level. I don't like relying on  
> it being
> the bootstrap ClassLoader as this may be being used in a separate
> ClassLoader space within another JVM.

Not that I want to punt the question, but it is an implementation  
question for the VM, right?  I mean, we can decide on the interface,  
declare that our VMs and class library implementations will support  
said interface, and then the VM impls can innovate on how they deal  
with it.  Clearly they deal with it in a few ways - Classpath has  
their scheme of language protection via package private, but there  
must be other solution from other VMs.

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message