You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Christophe Labouisse <ga...@tigris.org> on 2004/10/27 16:36:39 UTC
Javahl, alternative to jikes & Debian
I've been trying to create a patch for the current Debian package to
build the javahl bindings. In order to be compliant with Debian policy I
had to put aside using Sun's JDK and work with alternative compilers:
gcj & kaffe. Jikes is currently out because of a bug (issue 2057) but
also because compiling the javahl bindings requires both javac & javah.
Gcj is suggested in issue 2057 discussion and may be convenient as it
includes gcjh which is a replacement for Sun's javah. This last part is
currently not working because of a bug in gcjh which prevent it to
generate #defines for java constants as the other javah compilers do
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16843).
Kaffe is not bad however, I ran into 2 bugs. The first one is most
probably a Kaffe bug since in CommitMessage.cpp at line 106 uses
NewObjectArray which is declared as returning a jarray in Kaffe's jni.h
while CommitMessage.cpp wants to put it in a jobjectArray. The second
one is also probably a Kaffe bug although I'm not really sure. In
JNIByteArray.cpp, the getBytes method returns a signed char pointer
while m_data is declared as jbyte*. This does not cause any problem with
Sun's javah as jbyte is a typedef for signed char but Kaffe's definition
of jbyte is char. Hence a compilation error on JNIByteArray.cpp line 80.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Javahl, alternative to jikes & Debian
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Patrick" == Patrick Mayweg <ma...@qint.de> writes:
Patrick> I just need the constants in class/interface itself. In the 1.0.x
Patrick> branch, this may be internal classes.
I checked in a fix to gcj. It will appear in GCC 4.0.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Javahl, alternative to jikes & Debian
Posted by Patrick Mayweg <ma...@qint.de>.
Hi Tom,
I just need the constants in class/interface itself. In the 1.0.x
branch, this may be internal classes.
Patrick
Tom Tromey wrote:
>>>>>>"Christophe" == Christophe Labouisse <ga...@tigris.org> writes:
>>>>>>
>>>>>>
>
>I happened to see this message...
>
>Christophe> Gcj is suggested in issue 2057 discussion and may be
>Christophe> convenient as it includes gcjh which is a replacement for
>Christophe> Sun's javah. This last part is currently not working
>Christophe> because of a bug in gcjh which prevent it to generate
>Christophe> #defines for java constants as the other javah compilers
>Christophe> do (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16843).
>
>javah is not very well defined, so it isn't that clear exactly what
>constants we ought to be emitting. In particular I think the Sun
>javah emits constants inherited from superclasses, but not
>superinterfaces.
>
>What do the svn bindings need? If it is just constants defined in the
>current class, I can easily fix that. If it is constants from
>superclasses, that is somewhat harder (our javah replacement doesn't
>read superclasses at the moment).
>
>Tom
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Javahl, alternative to jikes & Debian
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Christophe" == Christophe Labouisse <ga...@tigris.org> writes:
I happened to see this message...
Christophe> Gcj is suggested in issue 2057 discussion and may be
Christophe> convenient as it includes gcjh which is a replacement for
Christophe> Sun's javah. This last part is currently not working
Christophe> because of a bug in gcjh which prevent it to generate
Christophe> #defines for java constants as the other javah compilers
Christophe> do (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16843).
javah is not very well defined, so it isn't that clear exactly what
constants we ought to be emitting. In particular I think the Sun
javah emits constants inherited from superclasses, but not
superinterfaces.
What do the svn bindings need? If it is just constants defined in the
current class, I can easily fix that. If it is constants from
superclasses, that is somewhat harder (our javah replacement doesn't
read superclasses at the moment).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Javahl, alternative to jikes & Debian
Posted by Patrick Mayweg <ma...@qint.de>.
Hi Christophe,
Christophe Labouisse wrote:
>I've been trying to create a patch for the current Debian package to
>build the javahl bindings. In order to be compliant with Debian policy I
>had to put aside using Sun's JDK and work with alternative compilers:
>gcj & kaffe. Jikes is currently out because of a bug (issue 2057) but
>also because compiling the javahl bindings requires both javac & javah.
>
>Gcj is suggested in issue 2057 discussion and may be convenient as it
>includes gcjh which is a replacement for Sun's javah. This last part is
>currently not working because of a bug in gcjh which prevent it to
>generate #defines for java constants as the other javah compilers do
>(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16843).
>
>Kaffe is not bad however, I ran into 2 bugs. The first one is most
>probably a Kaffe bug since in CommitMessage.cpp at line 106 uses
>NewObjectArray which is declared as returning a jarray in Kaffe's jni.h
>while CommitMessage.cpp wants to put it in a jobjectArray. The second
>one is also probably a Kaffe bug although I'm not really sure. In
>JNIByteArray.cpp, the getBytes method returns a signed char pointer
>while m_data is declared as jbyte*. This does not cause any problem with
>Sun's javah as jbyte is a typedef for signed char but Kaffe's definition
>of jbyte is char. Hence a compilation error on JNIByteArray.cpp line 80.
>
1. newObjectArray and all the other object array functions work with
jobjectArray in the sun include files, this is a bug in the include file.
2. jbyte should be a signed char, since the byte in java is also signed.
Since both error come from errors in the jni include files of Kaffe, I
would suggest that add the neccesary casts in your patch. I do not want
to add unneeded casts jast for buggy include files.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org