harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [vmi] JNI spec interpretation?
Date Wed, 05 Apr 2006 16:34:21 GMT
Etienne Gagnon wrote:
> 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.

I agree.

> 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
> spec).

I agree -- and users will vote with their feet when choosing between VMs
that make different implementation decisions.  That's healthy.

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

Of course not, that's your prerogative.



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message