On 18:51 Tue 23 Sep , Andrew Haley wrote:
Andrew Haley wrote:
Matthias Klose wrote:
There are still some todo's; not sure which ones are required before the merge
to the trunk:
- Apply the Thread optimization change
This isn't important: gcj has its own implementation of ThreadLocal.
- Apply the nio change, backout out for the 2008-08-11 classpath import
- Tom Tromey had a comment that he wanted to add/fix something:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36762
- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36763
- * scripts/makemake.tcl: Switch gnu.java.math to BC compilation.
concerns by Andrew Haley.
This objection from me isn't very important either.
- Build a gjdoc binary.
I'll be offline for at least one week, starting tomorrow on Monday.
OK, thanks for all the work so far.
I'll now be out of the loop. I've added a couple of fixes, but the
nio and the gjdoc binary are still to do. Everything else seems OK.
Andrew.
Matthias added gjdoc binary support earlier. Here's the patch to
add the NIO change, which I just applied to the merge tree.
Note that this also regenerates some of the antlr generated files.
Unfortunately it seems it includes its version in the generated Java
files. There also seem to be some code changes, which I've left
because this is a later version than the one used previously. I also
reverted an unmarked local change to configure.ac made by Matthias before
the correct fix from Classpath was backported.
The issues with merging the NIO patch arose from the use of
gnu.classpath.Pointer in these classes and the pointer at which they
interact with GCJ local classes in libjava/java/nio, all of which use
gnu.gcj.RawData. For this patch, I've simply patched the Classpath
classes to use RawData (with appropriate comments). The Classpath
classes only use this to call a superclass constructor which ends up
at java.nio.Buffer, a GCJ local class. Ian's NIO change makes this
pointer final and in the process, sets it once in the Buffer
superclass instead of in those classes that use it.
Long term, should RawData be replaced with gnu.classpath.Pointer?
I've just been reading through the rather long thread when this was
introduced back in 2004:
http://osdir.com/ml/java.classpath.devel/2004-04/msg00019.html
There doesn't seem to be much mention of how this change would work
its way back to GCJ, if at all. From what I can see, technically the
two classes are identical but they have different semantics. RawData
is a pointer in itself used by CNI, whereas gnu.classpath.Pointer is
an abstraction which is used via Pointer32 and Pointer64 in the
reference JNI code.
What issues would there be with GCJ (and particularly CNI) using
gnu.classpath.Pointer in the same way as RawData is currently used?
The advantage is that we would have less maintenance issues with
respect to Classpath merges, but the disadvantage is we then possibly
confuse these two classes. Notably, gnu.classpath.Pointer WITH its
subclasses is used in the Gtk+ and GStreamer JNI peer code so GCJ
would have to use the class differently in the two contexts (CNI and
JNI).
Thoughts?
ChangeLog:
2008-09-25 Andrew John Hughes <gnu_andrew@member.fsf.org>
* classpath/configure,
* classpath/configure.ac:
Resynchronise with Classpath's configure.
* classpath/examples/Makefile.in:
Add equivalent support for building as in
tools/Makefile.in.
* classpath/java/nio/Buffer.java,
* classpath/java/nio/ByteBuffer.java,
* classpath/java/nio/ByteBufferImpl.java,
* classpath/java/nio/CharBuffer.java,
* classpath/java/nio/CharBufferImpl.java,
* classpath/java/nio/CharSequenceBuffer.java,
* classpath/java/nio/CharViewBufferImpl.java,
* classpath/java/nio/DirectByteBufferImpl.java,
* classpath/java/nio/DoubleBuffer.java,
* classpath/java/nio/DoubleBufferImpl.java,
* classpath/java/nio/DoubleViewBufferImpl.java,
* classpath/java/nio/FloatBuffer.java,
* classpath/java/nio/FloatBufferImpl.java,
* classpath/java/nio/FloatViewBufferImpl.java,
* classpath/java/nio/IntBuffer.java,
* classpath/java/nio/IntBufferImpl.java,
* classpath/java/nio/IntViewBufferImpl.java,
* classpath/java/nio/LongBuffer.java,
* classpath/java/nio/LongBufferImpl.java,
* classpath/java/nio/LongViewBufferImpl.java,
* classpath/java/nio/MappedByteBuffer.java,
* classpath/java/nio/MappedByteBufferImpl.java,
* classpath/java/nio/ShortBuffer.java,
* classpath/java/nio/ShortBufferImpl.java,
* classpath/java/nio/ShortViewBufferImpl.java:
Replace use of gnu.classpath.Pointer with gnu.gcj.RawData,
and fix some formatting issues.
* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaLexer.java,
* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaLexer.smap,
* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaRecognizer.java,
* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaRecognizer.smap,
* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaTokenTypes.java,
* classpath/tools/gnu/classpath/tools/gjdoc/expr/JavaTokenTypes.txt:
Regenerated (later version of antlr).
* java/nio/Buffer.h: Regenerated.
* java/nio/Buffer.java: Ported changes from Classpath.
* java/nio/ByteBuffer.h,
* java/nio/CharBuffer.h: Regenerated.
* java/nio/DirectByteBufferImpl.java: Ported changes from
Classpath.
* java/nio/DoubleBuffer.h,
* java/nio/FloatBuffer.h,
* java/nio/IntBuffer.h,
* java/nio/LongBuffer.h,
* java/nio/MappedByteBuffer.h,
* java/nio/MappedByteBufferImpl.h: Regenerated.
* java/nio/MappedByteBufferImpl.java: Ported changes from
Classpath.
* java/nio/ShortBuffer.h: Regenerated.