Tim Ellison wrote:
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.
Also agree. I think, as we agreed to do with the Java APIs, differences
with the RI should be examined on a case by case basis. To clarify, my
mail above wasnt intended as a blanket statement for all differences,
just for this particular one.
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).
Agreed - and recording where we have chosen to match or differ from the
RI would be useful also.
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
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
