Since no acknowledgement is forthcoming from [EMAIL PROTECTED], I will repost here what I sent to them.
======================================================================== == This message may get a little long. The gist is that I argue against the use of the idiom "value == Boolean.TRUE" to check for Boolean arguments to the get/canSet/setParameter calls to DOMConfiguration implementations in DOM3, or anywhere else, for that matter. Outline: 1) Why this message is here 2) Original bug report 3) Background of bug discovery 4) User-side arguments against passing Boolean.TRUE 5) Implementation-side arguments against testing == Boolean.TRUE 1) Yesterday, I submitted a couple of bug reports to [EMAIL PROTECTED] regarding problems I was having with the Xerces2-J DOM3 experimental implementation. The bugs are: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20429 and http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20431 Among other responses, I received the following: ======================================================================== ============== The DOM Level 3 specification wants to rely on the fact that Boolean.TRUE is passed to the setParameter/getParameter method to allow people using '==' operator to compare values. Therefore, I am not sure if this is indeed a bug that needs to be fixed. I would like to get clarification from the DOM WG ([EMAIL PROTECTED]). Christopher would you like to post your question there? Thank you, -- Elena Litani / IBM Toronto ======================================================================== ============== Hence, this note. 2) For reference, here is the text of the first bug that I posted: ======================================================================== ============== Regarding the DOM3 Level experimental implementation in Xerces2-J: There is a coding error in org.apache.xerces.dom.DOMConfigurationImpl.setParameter(String name, Object value). The error is in the first two lines: if (value == Boolean.TRUE || value == Boolean.FALSE) { boolean state = (value == Boolean.TRUE) ? true : false; . . . Since the value argument is a Boolean _Object_ and not a primitive, the == operator compares identity of objects, not equivalence of Boolean values. Since I pass a Boolean Object that is freshly allocated (actually, I don't but the Jython runtime does), the == is not satisfied and the code drops through to the default, FEATURE_NOT_FOUND. The check should be done the same way the name check is done, viz. if (value.equals(Boolean.TRUE) || value.equals(Boolean.FALSE) { boolean state = (value.equals(Boolean.TRUE) ? true : false; . . . or, more succinctly, if (value instanceof Boolean) { boolean state = value.booleanValue() [Ed. This last line should be boolean state = ((Boolean) value).booleanValue()] ======================================================================== ============== After some more exploration, I realized that the idiom using "== Boolean.TRUE" as a test for a Boolean parameter was widely used in all the implementations of DOMConfiguration that I could find. The other bug report and my additional comments point this out. 3) What I was _really_ trying to do was use the DOM3 interface from Jython, the Java implementation of the Python scripting language. For those who may not know it, here are a few relevant characteristics of Jython. a) Since Jython is Java running in a JVM, it in principle gives interactive access to any Java class/object in the same JVM. b) For its own logical operations, Jython treats 0 as false and 1 as true. c) To assist calling Java methods, Jython uses reflection to do automatic type conversion of arguments based on the signature of the method. d) Jython variables are dynamically typed, so it is not possible to declare a variable to be of a specific type. I wanted to evaluate in Jython an expression like documentConfig.setParameter("validate", 1) to turn on validation. This threw a FEATURE_NOT_FOUND exception - not surprising, since I had forgotten that the second argument was an Object, not a Boolean, so Jython converted the 1 to a java.lang.Integer. When I tried documentConfig.setParameter("validate", java.lang.Boolean.TRUE) I still got a FEATURE_NOT_FOUND exception. The clue to this behavior was to try truth = java.lang.Boolean.TRUE documentConfig.setParameter("validate", truth) which still gives a FEATURE_NOT_FOUND exception, only here it is possible to check the value of truth and find that it is Jython's version of truth, namely 1. So the java.lang.Boolean.TRUE as a direct argument is presumably converted first to Jython's 1 and then to a java.lang.Integer. When I tried documentConfig.setParameter("validate", java.lang.Boolean(1)) as recommended by my Jython book to get a java.lang.Boolean on the Java side, I still got a FEATURE_NOT_FOUND exception. What Jython did in this case, apparently, was allocate a new java.lang.Boolean object and set its value to true. Unfortunately, this object is then not the identical object as java.lang.Boolean.TRUE, so that the value == Boolean.TRUE check on the Java side fails. When I modified the setParameter() implementation as described in my bug submission, then the last expression form above worked fine. My conclusion was that Jython could not satisfy the original setParameter() signature. 4) Let's look at this from the outside in, i.e., from the perspective of a user of the setParameter() interface. * From Elena's note, the reason for requiring that a user pass one of only two allowed instances of java.lang.Boolean is to allow the implementers to use the value == Boolean.TRUE idiom to test for a Boolean actual argument. But this is twisting a user interface to fit a particular implementation of that interface, which is a violation of interface abstraction. * The fact that the actual interface of setParameter() is limited to particular instances of java.lang.Boolean, rather than any true or false instance of same is counterintuitive and can only be expressed in comments about the interface. While this can set up an "I told you so" for human users of the interface, mechanical users like Jython get the interface through reflection where comments don't appear and couldn't be interpreted anyway. * There are at least two implementations, described in my bug report, that allow any true or false instances of java.lang.Boolean to be passed with no problem. 5) Now let's look at this from the inside, i.e., as an implementer. * Unfortunately for this case, Java has overloaded the == operator with two different meanings. For boolean primitive values, it means an equality of truth value of which there are only two, true or false. For java.lang.Boolean Objects, it is a test of Object identity with no reference to the values of the Objects concerned. For java.lang.Boolean Objects, there is no limit to the number of Objects that can be created, although they can only hold the values true or false. Trying to use the second form of the == operator as a replacement for the first is a recipe for trouble; that is why the equals() method exists on every object - so that Object equivalence is always distinguishable from Object identity. * Use of the value == Boolean.TRUE idiom sets a bad example for other implementers. It _looks_ a lot like value == true, but its meaning is quite different. That difference in meaning may be twisted into being equivalent here, but that has no guarantee to work in other applications. Given how often implementers borrow from one another, one should be careful to program as cleanly as possible. In summary, I suggest that the "value == Boolean.TRUE" idiom is an invalid implementation of a test for Boolean objects and that it be replaced by a valid "value.equals(Boolean.TRUE)" or some equivalent representation throughout DOM3. Thanks for your time. Christopher T. Day Staff Scientist Berkeley Lab NERSC/HENPCG [EMAIL PROTECTED] ======================================================================== == -----Original Message----- From: Elena Litani [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 8:43 AM To: Christopher T. Day; [EMAIL PROTECTED] Subject: Bugs 20429 and 20431 The DOM Level 3 specification wants to rely on the fact that Boolean.TRUE is passed to the setParameter/getParameter method to allow people using '==' operator to compare values. Therefore, I am not sure if this is indeed a bug that needs to be fixed. I would like to get clarification from the DOM WG ([EMAIL PROTECTED]). Christopher would you like to post your question there? Thank you, -- Elena Litani / IBM Toronto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
