This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: New GCJ manual
- From: Tom Tromey <tromey at redhat dot com>
- To: Nic Ferrier <nferrier at tapsellferrier dot co dot uk>
- Cc: java-patches at gcc dot gnu dot org
- Date: 28 Jan 2002 22:56:55 -0700
- Subject: Re: New GCJ manual
- References: <87r8oapslu.fsf@tf1.tapsellferrier.co.uk>
- Reply-to: tromey at redhat dot com
>>>>> "Nic" == Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
Nic> I've attached the source of of the GCJ manual with my hacked in
Nic> CNI details. Note this is not a patch, it's easier to ditribute
Nic> the whole source!
This is great stuff.
You'll have to send this to gcc-patches too. The gcc doc people will
probably want to look at it (and nit-pick your texinfo, be prepared).
I think the subsection "Nested classes as a substitute for namespaces"
could simply be removed. It is ancient history.
Nic> "Accessing a static field also requires the class of the
Nic> field to be initialized. The Java compiler will generate code
Nic> to call @code{_Jv_InitClass} ..."
Nic> should this be: Jv_InitClass ?
gcj generates a reference to _Jv_InitClass.
The CNI user should use JvInitClass.
We shouldn't tell the user about _Jv_InitClass, since it is
internal-only.
Nic> "Note that currently you cannot mix C++ catches and Java catches in
Nic> a single C++ translation unit. We do intend to fix this eventually."
Nic> Is this true? Have we already fixed it?
We haven't, and in fact my current understanding is that it is
unfixable.
Nic> section reflection:
Nic> Is pretty skimpy. I imagine we've done all these things. If someone
Nic> who worked on reflection wants to drop me a line about how things work
Nic> I'll info-ize the email.
Unfortunately there's quite a bit there, and bits are missing.
For instance the stuff in gcj/method.h isn't really useful yet.
The functions in gcj/field.h are a bit more useful.
Nic> Alternately I'll get information from a Sun JNI manual.
Care is required here because we don't want our manual to be a derived
work of Sun's.
There's a couple things we ought to document but currently don't.
Don't feel obligated to do this; we can always refine the initial
manual once it is in.
* We should document naming shared libraries so that Class.forName()
will automatically load them
* We should document gnu.gcj.RawData as a special non-scanned pointer
field.
Tom