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.
Regards,
Tim
--
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
|