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
