Date: Tue, 9 Aug 2005 01:53:36 -0400 (EDT) From: Mikhail Teterin <mi@corbulon.video-collage.com> To: glewis@eyesbeyond.com (Greg Lewis) Cc: gnome@FreeBSD.org, java@FreeBSD.org, kyle.yuan@sun.com Subject: Re: should not jint be as wide as void* ? Message-ID: <200508090553.j795rblk014729@corbulon.video-collage.com> In-Reply-To: <20050809052027.GA43606@misty.eyesbeyond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508090553.j795rblk014729>