333738 - Try to build JavaXPCOM with tree's jni.h (don't require JDK)

Status: RESOLVED WONTFIX

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[jhp (no longer active)]

The tree includes a jni.h at mozilla/stubs/include/jni.h.  Try to build against that, so XULRunner can be built without requiring a JDK.

Comment 1

[jhp (no longer active)]

The file mozilla/stubs/include/jni.h seems to be old.  It has no mention of either 'jweak' or 'ExceptionCheck', which are both used in JavaXPCOM.

The files in mozilla/stubs/include/ haven't been seriously updated since at least 2003, and most often longer than that.  I don't think anyone really maintains these files any more.

Comment 2

[jhp (no longer active)]

Attachment: jni.h update (1.8.1 branch)

Update sun-java/stubs/include/jni.h to the JNI 1.4 level.  Technically, for JavaXPCOM, we only need JNI 1.2 support, but might as well update to the latest level, in case we do need to use JNI 1.4 features in JavaXPCOM in the future.

Comment 3

[jhp (no longer active)]

Attachment: build patch

Build patch to go along with jni.h change.  This will just build the javaxpcom libraries with sun-java/include/jni.h, but won't build any jar files.

Comment 4

[Benjamin Smedberg]

Comment on attachment 224592 [details] [diff] [review]
build patch

I don't like having hidden side-effects (JDK not specified, so we don't build JARs)... we should have an explicit configure flag --disable-javaxpcom-jars

Comment 5

[jhp (no longer active)]

I thought the point of this bug was so a developer could build XULRunner and not worry about installing a JDK unless he/she specifically wanted to.  So requiring an explicit flag would go against that.

But if you want a flag, how about something like --with-mozilla-jni-h.  Actually, that's pretty lame.  But I think it should be something that says that it's using the jni.h in the sun-java directory, and doesn't require a JDK.

Comment 6

[Benjamin Smedberg]

I want the build system to be determinate (the presence or absence of tools should not affect the final output unless the user makes an informed choice).

--with-mozilla-jni sounds ok

Comment 7

[Mike Hommey [:glandium]]

If you can build with the internal jni.h why would you bother to build with an external one ?
Why not just build the libjavaxpcom with the internal includes, and build the jars with the provided jdk ?

Comment 8

[jhp (no longer active)]

Attachment: build patch v1.1

Didn't like --with-mozilla-jni, went with --disable-javaxpcom-jars, which is more descriptive.

(In reply to comment #7)
> If you can build with the internal jni.h why would you bother to build with an
> external one ?

The jni.h in Mozilla is only there as a fallback (for JavaXPCOM, anyway).  We should always use the jni.h provided by the JDK, since it will be more accurate for that platform and may include extra things not found in Mozilla's jni.h

Comment 9

[Benjamin Smedberg]

Comment on attachment 232915 [details] [diff] [review]
build patch v1.1

Hrm... I tend to think that we should default to building using the internal jni.h by default: we've seen issues where the jni.h that is provided by GCC has different typedefs that don't work with our code.

Comment 10

[jhp (no longer active)]

Then maybe we should have both "--with-mozilla-jni" and "--disable-javaxpcom-jars"?  Users can specify the former when building with GCJ, but all others could build without it (if fully building XR + JavaXPCOM).  For XR without JavaXPCOM, users could specify both, or "--disable-javaxpcom-jars" could automatically specify "--with-mozilla-jni"?

Comment 11

[jhp (no longer active)]

Attachment: jni.h update (trunk) (checked in)

Comment 12

[jhp (no longer active)]

Comment on attachment 233831 [details] [diff] [review]
jni.h update (trunk) (checked in)

Checked in jni.h update to trunk.

Comment 13

[Benjamin Smedberg]

I think we're going to WONTFIX this bug due to people not seeming to care, and our JNI headers hopefully going away once the OJI code for the Java plugin is removed.