RE: Classpath build process and VM-specific issues

[Jeroen Frijters]

Etienne Gagnon wrote:
> Jeroen Frijters wrote:
> > Indeed. The goal is to find the optimal solution that would be spec
> > compliant, portable and efficient. Since I obviously believe that my
> > proposal is better than the byte[] proposal, I would like to convice
> > Etienne (and you) of this. I fail to see how you can take issue with
> > that.
> 
> Fair.
> 
> > I don't feel like writing real JNI code, but here is the 
> general idea:
> 
> So, you don't have a real proposal...  We need to compare *real* JNI
> code to real JNI code, otherwise, we'll be arguing about 
> misconceptions.
> 
> I still think that my proposal is better than the one you 
> sketched below.
> 
> > jobject WrapPointer(JNIEnv* env, void* p)
> > {
> > #if PLATFORM_HAS_32_BIT_NATIVE_POINTER
> 
> For one thing, my proposal does not need any specific #ifdef 
> per pointer size.

Absolutely, that is a big advantage of the byte[] approach, but IMHO it
optimizes for the wrong scenario. I (and I suspect most others) don't
care about pointer sizes other than 32/64 bit.

> >   jclass pclass = env->FindClass("RawData32");
> >   jmethodID mid = env->GetMethodID(pclass, "<init>", "(I)V");
> 
> That's supposed to be faster than my proposal????

This is only done once. But you are missing my point about efficiency.
The JNI approach isn't about performance, it is going to be slow, no
matter what. I just want the option the make my implementation fast. The
byte[] approach doesn't give me this option. It forces me into
suboptimal implementation.

> >   return env->NewObject(pclass, mid, p);
> 
> ** Bzzzt *** Please try again...
> 
> Now that my proposal has been criticised to death on the smallest
> nitpicks of pure ISO C portability, let me comment on the portability
> ]of your code.

I'm not the one nitpicking about pure ISO C portability (I don't use
JNI, so I couldn't care less), but we could use the exact same trick you
used in your JBYTE_IS_NOT_SIGNED_CHAR versions of wrap/unwrap. So this
is a non-issue.

> So, no, your proposal is NOT portable,

It is portable (can be made portable by someone who cares, i.e. not me).

> and is of thus ranks lower than my proposal on 2 counts:
> 1- Efficiency:

For a JNI based implementation, maybe, but I'd argue that anyone using
JNI doesn't care about performance anyway.

Regards,
Jeroen