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. <[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] >> >> >> > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
