On Wed, Aug 5, 2009 at 5:17 PM, Mark Evensonevenson@panix.com wrote:
Unfortunately Alessio's (and Tobias?) work on [adding richness to inspection of Java objects][1] contains a bug that manifests itself in stopping [JSS][2] from working.
The attached patch gets JSS to run again, but I am not sure the right way to fix the problem in the trunk, mainly as I don't understand all of our conversion rules, and how they interact with Java's autoboxing.
The problem with JSS occurs when JavaObject.javaInstance(Class c) is invoked with a Class from a primitive boolean on an JavaObject that wraps a java.lang.Boolean. The call to java.lang.Class.isAssignableFrom() has an oddly (to me) specific contract that "[i]if [the] Class object represents a primitive type, this method returns true if the specified Class parameter is exactly this Class object; otherwise it returns false." This makes JavaObject<java.lang.Boolean>.javaInstance(boolean) fail, when everything seems to work fine if we simply return the wrapped object.
Right, that's an oversight on my part. Unfortunately Java's reflection does not know about automatic boxing/unboxing, you have to do it by yourself.
What I don't understand mainly is if boolean/java.lang.Boolean objects are somehow special in our treatment of them, or should we do this for all of the other primitive types?
The latter. I believe there's already code written for this somewhere (in jmethod perhaps?), so maybe we could generalize & reuse that code.
Also, I have a question about your patch: do you have a specific reason to handle null by always signaling an error? In principle, null is assignable to any non-primitive type, so the type error ought to be signaled only for primitive types, imho.
Bye, Alessio
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel