Tom Tromey <[EMAIL PROTECTED]> writes:
> >>>>> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
>
> Mark> Would it not be simpler to add a VMClassLoader class to libgcj
> Mark> that implements the getPrimitiveClass() method?
>
> I'd prefer not to, simply because the current implementation is more
> efficient. It is just a single relocation. I'm just going to punt on
> the problem for now. Perhaps we can just maintain a 1-line divergence
> here. It turns out there's another gcj-specific hack we'd like in
> Integer. These sorts of details are what makes the merging go so slow
> -- I sometimes have time for a quick 1-class merge, but only if it
> doesn't involve solving a bigger problem.
I think that if the boolean.class special handling is specific to gcj
and not CNI then it probably should be separated out as a VM
dependency as others have suggested. Also as others have said, there
is little reason for bothering with efficiency in this case.
I think questions such as CNI/JNI differences like the loading of
libraries in static initializers can be done with the configure setup
we have now (already implemented).
Some other things, like multiple String implementations or similar
probably call for a mixture of things like selection through configure
causing a copy to the correct file to $builddir/proper_name to the
preprocessing suggested earlier as well.
So would it be okay to merge those classes on the basis that the
boolean.class issue is strictly a gcj thing as opposed to a CNI thing
and add this to the VM* layer?
Brian
--
Brian Jones <[EMAIL PROTECTED]>
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
