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. 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. <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > > >
