harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Kumpera <kump...@gmail.com>
Subject Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
Date Fri, 04 Nov 2005 19:53:14 GMT
I cannot see how adding package private classes can possibly be
classified as 'extend the defined namespaces'. This makes perfect
sense and allow implementation classes easier access the guts of spec
classes (eg, org.apache.harmony.ClassLoaderStuff will have some hard
time to mess with java.lang.ClassLoader insternals, but
java.lang.ClassLoaderStuff won't).

I see no point in been nicer than Sun on this matter, as there are
many package private classes around java.* - nice guys finish last ;-)

I see 2 options here:

-Allow for some implementation stuff to package private
-Have a org.apache.harmony, or something else, package tree where all
implementation stuff will reside.

In the first case, only trusted code will be allowed to access such
code by using reflection. Otherwise the SecurityManager will stop it.

In the second case, we will need some classloading hacks to forbid
application code to access public classes on the org.apache.harmony

Given a full j2se implementation, which one will require less effort
and code to be running ok?


On 11/4/05, Geir Magnusson Jr. <geirm@apache.org> wrote:
> My favorite subject...
> We have to address this.  We started a while ago and it didn't go
> well, but we now have two VMs to work with, bootVM and jcheVM, and we
> need to get going here in a serious way.  We're about to finish up
> the legal framework with the bulk contributuion rules, and as much as
> I am going to miss the process creation phase, it's time to get focused.
> 1) I didn't look at how jcheVM does it  - although I assume that it
> uses the canonical GNU Classpath approach - and I'm not sure that
> bootVM code is there yet for that.  I hope that Archie and Dan can
> chime in with a summary of where things are.
> 2) I'm really interested in interoperability with other projects, so
> however we do it, it should have this factor as one of the major
> design goals.
> 3) I'm really worried about the GNU Classpath interface that extends
> java.lang.  We do allow participants in this community to look at the
> spec license, and we won't extend the defined namespaces in the spec.
> So where does that leave us?  We'll, IMO it means we don't use the
> GNU Classpath interface as it is now (but I'd want to be sure that we
> do interoperate, so that means whatever we come up with we also
> contribute to GNU Classpath so people can plug that in....).  We have
> people around here, lurking and active, that have done this in anger,
> so speak up...
> geir
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org

View raw message