Re: GCJ manual changed

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On 30 Jan 2002, Nic Ferrier wrote:

> > > @code{gcj} uses the same compiler technology as @code{g++} (the GNU 
> >  
> > Use @command to mark up command names. 
> 
> I have not changed these. This is what was already in the file. I'll
> send a diff next time so you can see that's true.

This particular use wasn't.  Just because some part of the file use @code
instead of @command isn't a reason not to use @command in new text.

> > > @deftypefun jstring JvNewStringUTF (const char* @var{bytes}) 
> > > Returns a @code{String} which is made up of the UTF encoded characters 
> >  
> > You say "UTF", which UTF (there are several, e.g., UTF-8, UTF-16,
> > UTF-32)? 
> 
> It should be obvious to a Java programmer. This is the same text as
> the old CNI manual.

You're using a term from another field.  When doing so, you should do it
in a way that is correct in the context of that other field rather than
making an incorrect usage that will be understood by those Java
programmers who aren't also too experienced in Unicode for the incorrect
usage to grate on them.  Elsewhere you've explicitly named UTF-8.

> +@code{gcj} uses the same compiler technology as G++ (the GNU

This is the first place I quoted before where you've added use of @code
for commands - consistent with elsewhere in the manual but not correct
Texinfo 4 style as should be used for new documentation (and which old
docs should be fixed to use).

> +@example
> +JvPrimClass(void) => java.lang.Void.TYPE

You should use @result{} (see the Texinfo manual) here.  (I think that, 
though this is a macro, @result{} is more appropriate than @expansion{}, 
@expansion{} being more appropriate for Lisp macros.)

> +@deftypefun void* _Jv_AllocBytes (jsize @var{size})
> +Allocates @code{size} bytes from the heap.  The memory is not scanned

Should be @var.

> +While C++ and Java share a common exception handling framework,
> +things are not yet perfectly integrated.  The main issue is that the
> +run-time type information> facilities of the two
                            ^ stray >

> +Note that the lock has to be released even the block is abnormally
> +terminated by an exception, which means there is an implicit
> +@code{try finally} surrounding synchronization nlocks.

Is "nlocks" a specialised term here, or should it be "locks" or "blocks"?

-- 
Joseph S. Myers
jsm28@cam.ac.uk