Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 217.158.94.220 is neither permitted nor
 denied by domain of t.p.ellison@gmail.com)
Message-ID: <436BEFB5.2080801@gmail.com>
Date: Fri, 04 Nov 2005 23:33:09 +0000
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
References: <89DB404C-2E97-49E8-92B6-05113E8FF0DB@apache.org>
 <8cca42d80511041153k2c3dbf9h400df8aa8ec8f545@mail.gmail.com>
In-Reply-To: <8cca42d80511041153k2c3dbf9h400df8aa8ec8f545@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Rodrigo Kumpera wrote:
> 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
> tree.

We'll just talk to the guys in Felix :-)


Regards,
Tim

> Given a full j2se implementation, which one will require less effort
> and code to be running ok?
> 
> Rodrigo
> 
> 
> 
> 
> 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
>>
>>
>>
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.