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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
