classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: jni.h


From: Mark Wielaard
Subject: Re: Patch: jni.h
Date: Wed, 28 Apr 2004 20:51:24 +0200

Hi,

On Wed, 2004-04-28 at 18:02, Dalibor Topic wrote:
> David Holmes wrote:
> >>GetStringUTFChars returns "const char *" which is much
> >>more logical and seems to be the right thing. JNI 1.1 spec says it
> >>should return "const jbyte *". I search a little bit with google and
> >>jni.h in other open source projects use "const char *" too. Now I
> >>really wonder what we should do ? Should we leave it like it is and
> >>cast to "const char *" in all instances we use GetStringUTFChars in out
> >>own code or should we just apply the attached patch to change our
> >>jni.h.
> > 
> > Sun's own jni.h uses "const char*"

[Little intermezzo because I think this is important. Although in this
case it isn't such a big deal of course.]

Please don't refer to proprietary source code when working on GNU
Classpath! An outsider that looks at something that is indeed basically
a public interface and then tells us is not that harmful. And you didn't
do it with the intention to copy any implementation detail. But we
really don't want to refer to proprietary source code whenever we can
avoid it because it would put us in an awkward position if we are ever
in front of a judge about whether or not GNU Classpath was developed in
a clean room way. If there are many instances were people say "yes, of
course I studied that proprietary implementation first before writing
our version" that would make us look bad. And in this case there are
enough publicly available sources that looking at the proprietary
version can be avoided.

Summary: Working from publicly available documentation/books to make
something compatible -> good. Referring to proprietary implementation to
learn implementation details -> bad. See also the Hackers Guide:
http://www.gnu.org/software/classpath/docs/hacking.html#SEC2

Sorry for being so pedantic about this. I do not mean to scare people
that just looking at something is bad. It shouldn't, but in practice it
can work against us so please avoid it when possible. [... insert rant
about proprietary software developers trying to make sharing ideas and
software a crime ... mutter something about Caldera, SCO, Sun ...]

> > This may be a typo in the JNI 1.1 spec as the corresponding
> > ReleaseStringUTFChars takes a "const char*" too.

I was wondering earlier this week why the JNI method GetStringUTFChars()
returns const jbyte* while ReleaseStringUTFChars() takes a const char *.
That definitely indicates that either of these two is wrong.

The Java Native Interface Programmer's Guide and Specification
> uses jbyte* in $3.2.1 example 
> http://java.sun.com/docs/books/jni/html/objtypes.html . The latest JNI 
> docs from 1.4.2 also use jbyte :
> http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/functions.html#wp17265
> The JNI tutorial uses a const char * in its example here
> http://java.sun.com/docs/books/tutorial/native1.1/implementing/string.html

Found the following old discussion thread between Brian and Tom about it
from 2001:
http://mail.gnu.org/archive/html/classpath/2001-10/msg00119.html
Don't have a copy of the paper JNI book here to check what it says.

Strangely enough contrary to the 1.4 docs, the older 1.3 docs (1.2 isn't
publicly available anymore) say it is const char *:
http://java.sun.com/j2se/1.3/docs/guide/jni/spec/functions.doc.html#17265

Since we seem to agree that const char * is best and we found one more
or less "official" reference that confirms this I think we should change
the classpath jni.h to be similar to what libgcj has.

Tom said that you should also change the C++ declaration which should
indeed match the C prototype. But lets postpone completely merging jni.h
with libgcj till after 0.09 is released (Friday).

This will fix a whole bunch of warnings in the gtk+ peers.

Thanks,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]