should not jint be as wide as void* ?

[Mikhail Teterin]

> On Sat, Aug 06, 2005 at 01:05:41AM -0400, Mikhail T. wrote:
> > Looking deep into Mozilla's LiveConnect sources (under
> > mozilla/sun-java/stubs/include/) I gather, jint really
> > wants to be intptr_t -- not a mere int as, for example,
> > jdk1.5.0/include/freebsd/jni_md.h makes it out to be.
> > 
> > Can anyone comment? Thanks!
> 
> I'm doing a build of the current CVS on FreeBSD 5.4/amd64 at the moment.
> It hasn't gotten to the plugin build yet, but I'll be interested to see
> (a) if there are warnings about pointer widths and (b) if it works :).

I'm, actually, thinking, the jint should be left alone and just the
GetJavaWrapper() and its friends be changed to accept intptr_t (or some
j-prefixed equivalent) instead of jint.

You will not get warnings (in Java) because actual callers of
GetJavaWrapper come (I think) from the LiveConnect part of the browsers,
which are compiled separately.

The HEAD of the spidermonkey (js) tree currently, sort of, expects
GetJavaWrapper to take a jlong, when a regular long is 8 bytes (their
own strange way of _not_ using intptr_t). But this means, the real
GetJavaWrapper and the UnwrapJavaWrapper() need to accept a (pointer to
a) truly intptr_t-wide value. Per cscope:

Global definition: UnwrapJavaWrapper

  File                             Line
0 CNSAdapter_JavaPluginFactory.cpp 389 NS_IMETHODIMP CNSAdapter_JavaPluginFactory::UnwrapJavaWrapper(JNIEnv* jenv, jobject jobj, jint* obj)
1 CFactory_IJVMPlugin.cpp           42 NS_IMETHODIMP CFactory::UnwrapJavaWrapper(JNIEnv* jenv,
2 JSObject.cpp                     223 JDresult UnwrapJavaWrapper(RemoteJNIEnv* env, jobject jobj, jint* obj)
3 JavaPluginFactory5.cpp           476 JavaPluginFactory5::UnwrapJavaWrapper(JNIEnv* jenv, jobject jobj, jint* obj) {

and:

Global definition: GetJavaWrapper

  File                             Line
0 CNSAdapter_JavaPluginFactory.cpp 367 NS_IMETHODIMP CNSAdapter_JavaPluginFactory::GetJavaWrapper(JNIEnv* jenv, jint obj, jobject *jobj)
1 CFactory_IJVMPlugin.cpp           19 NS_IMETHODIMP CFactory::GetJavaWrapper(JNIEnv* jenv, jint obj, jobject *jobj) {
2 JavaPluginFactory5.cpp           447 JavaPluginFactory5::GetJavaWrapper(JNIEnv* proxy_env,

All of those "jint obj" need to change together with whatever functions
these guys themselves call.

For you to test it from inside a browser, you'll have to patch Firefox'
js/src/liveconnect...

It may be easier to just build (and test) the lang/spidermonkey -- I
asked portmgr to allow me to unbreak it on amd64.

> Until then, its worth noting that the Linux amd64 release from Sun
> (1.5.0_04) still has jint defined as int. It appears that Solaris
> in 64 bit mode also still has jint defined as an int. This raises
> some questions in terms of compatibility for us to change it to be
> something other than an int.

It is, actually, even better. Sun's jni_md.h defineds jint as int, but
jri_md.h (deploy/src/plugin/share/npapi/jri_md.h) has the following
code:

	[...]
	#ifdef IS_64 /* XXX ok for alpha, but not right on all 64-bit architectures */
	typedef unsigned int    juint;
	typedef int                             jint;
	#else
	typedef unsigned long   juint;
	typedef long                    jint;
	#endif
	[...]

A bloody mess, that we need to straighten out :-(

	-mi