You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/03/10 08:24:11 UTC
[jchevm] generic Harmony_Class_Lib/GNU_Classpath adapter is on JIRA Harmony-192
Archie,
Please take a look at bootstrap.c It would be great if we can do the
final integration in the next 2 days while this code is still fresh in
my mind.
Thanks
Weldon
--
Weldon Washburn
Intel Middleware Products Division
Re: [jchevm] generic Harmony_Class_Lib/GNU_Classpath adapter is on JIRA Harmony-192
Posted by "S. Meslin-Weber" <st...@tangency.co.uk>.
On Fri, Mar 10, 2006 at 11:41:11AM -0600, Archie Cobbs wrote:
> 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.
Or what about com.sun.* ? You'll have to for the doclets stuff.
Honestly, we need to credit lawyers with a little more sense than that.
> Can someone (Geir?) give us a quick answer on this so we can proceed??
Yes, please.
--
================================================================
Stephane Meslin-Weber Email: steph@tangency.co.uk
Senior Software Engineer Web: http://odonata.tangency.co.uk
================================================================
Re: [jchevm] generic Harmony_Class_Lib/GNU_Classpath adapter is on
JIRA Harmony-192
Posted by Archie Cobbs <ar...@dellroad.org>.
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
Re: [jchevm] generic Harmony_Class_Lib/GNU_Classpath adapter is on JIRA Harmony-192
Posted by Leo Simons <ma...@leosimons.com>.
On Fri, Mar 10, 2006 at 09:24:24AM -0800, Weldon Washburn wrote:
> On 3/10/06, Archie Cobbs <ar...@dellroad.org> wrote:
> > Weldon Washburn wrote:
> > > Please take a look at bootstrap.c It would be great if we can do the
> > > final integration in the next 2 days while this code is still fresh in
> > > my mind.
> >
> > Looks reasonable, you just commented out or changed the classes
> > and methods that would not load yet.
> >
> > What's the plan for dealing with the Pointer class? Here are some
> > possibilities that preserve Classpath compatibility:
> >
> > 1. Implement gnu.classpath.Pointer{32,64} in classlib
> > 2. Have jchevm autodetect whether gnu.classpath.Pointer or
> > java.lang.Pointer is to be used.
> >
> > 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.
We don't have to -- these things have something to do with one another,
namely, we have the files there in that way so we have code that is
compatible, which is a Cool Thing(tm).
> I vote for adding a few lines of code to avoid spending
> hours with an attorney. 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?
Then we'd move the "gnu" and "classpath" references into the algorithm.
We're still going to need them. My friend Cliff Schmidt tells me that
the verdict is still out on whether interfaces are copyrightable at all.
My friend Mark Wielaard tells me the GNU Classpath people like working
together with other people and love to see various kinds of
interoperability.
So while I have no idea what the fine-grained legal details are, I have
a strong hunch having some references to "gnu" and "classpath" every now
and then is ok.
LSD
Re: [jchevm] generic Harmony_Class_Lib/GNU_Classpath adapter is on JIRA Harmony-192
Posted by Weldon Washburn <we...@gmail.com>.
On 3/10/06, Archie Cobbs <ar...@dellroad.org> wrote:
> Weldon Washburn wrote:
> > Please take a look at bootstrap.c It would be great if we can do the
> > final integration in the next 2 days while this code is still fresh in
> > my mind.
>
> Looks reasonable, you just commented out or changed the classes
> and methods that would not load yet.
>
> What's the plan for dealing with the Pointer class? Here are some
> possibilities that preserve Classpath compatibility:
>
> 1. Implement gnu.classpath.Pointer{32,64} in classlib
> 2. Have jchevm autodetect whether gnu.classpath.Pointer or
> java.lang.Pointer is to be used.
>
> 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. 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?
>
> Eventually I'd like jchevm to have a command line flag that allows
> you to easily switch between Classpath and classlib at startup, for
> quick side-by-side behavior comparisions. This will greatlyl increase
> our ability to debug the classlib/jchevm interface.
This is an excellent idea! I really like it.
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [jchevm] generic Harmony_Class_Lib/GNU_Classpath adapter is on
JIRA Harmony-192
Posted by Archie Cobbs <ar...@dellroad.org>.
Weldon Washburn wrote:
> Please take a look at bootstrap.c It would be great if we can do the
> final integration in the next 2 days while this code is still fresh in
> my mind.
Looks reasonable, you just commented out or changed the classes
and methods that would not load yet.
What's the plan for dealing with the Pointer class? Here are some
possibilities that preserve Classpath compatibility:
1. Implement gnu.classpath.Pointer{32,64} in classlib
2. Have jchevm autodetect whether gnu.classpath.Pointer or
java.lang.Pointer is to be used.
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.
Eventually I'd like jchevm to have a command line flag that allows
you to easily switch between Classpath and classlib at startup, for
quick side-by-side behavior comparisions. This will greatlyl increase
our ability to debug the classlib/jchevm interface.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com