Weldon Washburn wrote:
>> Either solution is OK with me, but I'd much prefer #1 because it's
>> cleaner code and I'd rather not start adding hacks at this point that
>> move us away from the current common API.
> 
> I agree that #1 is the cleanest, easiest technical approach.  The
> difficulty is convincing an attorney that a file in Harmony Class Lib
> called "blah blah GNU blah blah CLASSPATH" has nothing to do with gnu
> or classpath.  I vote for adding a few lines of code to avoid spending
> hours with an attorney.

Hmm.. honestly I'm starting to lose patience with all this legal nonsense.
Not your fault of course Weldon.

Rhetorically I ask how is using "gnu.classpath" in a class name any worse
than using "java.lang"? Sun has a trademark on the work "java" you know.

Can someone (Geir?) give us a quick answer on this so we can proceed??

> How about an algorithm that first checks for
> gnu.classpath.PointerXX and if its not found then looks for
> xxx.yyy.zzz.Pointer class?   I am not happy with putting Pointer
> classes in the java.lang package.  Maybe create a new package called
> kernel_path.  Thoughts?

Putting it in java.lang is fine -- as long as the class is package
private, which makes it invisible to user code. This is what's done
with all the other VM related classes like java.lang.VMThread, etc.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com