Greg, I actually end up implementing the BXML to Java converter. It is now working for basic BXML feature(excluing Javascript, listener). The code is available from:
https://github.com/calathus/BXML-to-Java-converter/blob/master/README This tools was implemented with AOP like idea to intercept the actual Pivot object instantiation/modification and generate corresponding Java source code. I modified the BMXLSerializer so that it will call back code emitter interface.(So the change is minimal for the BMXLSerializer). In order to map objects to variable names used for Java source code, I needed to use Map. Normally the objects are ordinary Pivot class's instances. But some internal objects are ArrayList. So I avoided to use java.util.HashMap, and created custom environment class using List. For this application, since it will not create big table, this will be sufficient. The comment/feed back for this tool is welcome. On Thu, Dec 23, 2010 at 5:24 AM, Greg Brown <[email protected]> wrote: > I'd expect that you would run into the same issue using the JDK > collections. From the Javadoc for java.util.Map: > > "Note: great care must be exercised if mutable objects are used as map > keys. The behavior of a map is not specified if the value of an object is > changed in a manner that affects equals comparisons while the object is a > key in the map." > > Certainly adding or removing an item from a list should affect the value of > the equals() method, and probably hashCode() as well. > > What is the use case for using a list as a key? > > On Dec 22, 2010, at 10:27 PM, calathus wrote: > > > Hi, > > org.apache.pivot.collections.ArrayList, HashMap, HashSet are overriding > equals and hashCode. > > When a new element is added(or removed), the value of hashCode will be > changed. > > This is problematic for using the instance(ArrayList) in a dictionary > like java.util.HashMap as the key value. > > Essentially we cannot use it for key value. > > > > I wonder this is intentional or bug. > > If you need to compare the value based comparison, it might be better not > to override equal but introduce another method(e.g, equivalent). > > > > I had some bug related to this. It will create some surprise for the user > and it will not be easy to find the cause of the problem. > > I think if the collection is immutable, the current code would make sense > though. > > > > -- > > Cheers, > > calathus > > > > > > > > -- Cheers, calathus
