harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Etienne Gagnon <egag...@sablevm.org>
Subject Re: [vmi] JNI spec interpretation?
Date Wed, 05 Apr 2006 16:17:52 GMT
Oliver Deakin wrote:
> What I mean to say is that the behaviour when the function is called
> without a pending exception is unspecified, and in that case I think it
> makes most sense to match the RI.

Let's say that I disagree to *impose* matching the RI's behavior for
undefined JNI code on Harmony VMs.  In many cases, matching the RI's
behavior on undefined JNI would require reverse engineering way beyond a
point I feel comfortable with.  I definitely think that Harmony's native
code should NEVER rely on undefined JNI behavior.  JIRA reports should
be raised for faulty JNI code.

On the other hand, I think that it would be a nice thing to keep an
explicit list of "expected" behavior for some widely used (by 3rd
parties) "undefined JNI", so that VM implementors are *encouraged* (not
*forced*) to provide such workarounds.  Some workarounds can be
expensive to implement; we had we had to implement a more expensive
approach for badly written JNI code that does not explicitly reserve
enough local native references (only 16 are guaranteed by default in the

So, I'll add a the ExceptionDecribe workaround to SableVM permanently,
but I do not wish feel obligated to do so. :-)


Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

View raw message