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 spec). So, I'll add a the ExceptionDecribe workaround to SableVM permanently, but I do not wish feel obligated to do so. :-) Etienne -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
