On Sun, May 8, 2011 at 10:08 AM, Patrick Julien <[email protected]> wrote: > Here is what I am planning to do to fix issue 6068 > > http://code.google.com/p/google-web-toolkit/issues/detail?id=6068 > > 1. Add to BeanMethod.java (package > com.google.web.bindery.autobean.vm.impl;) an TO_ARRAY value > > 2. Add to JBeanMethod.java > (com.google.web.bindery.autobean.gwt.rebind.model;) an TO_ARRAY value > > 3. in AutoBeanFactoryGenerator#writeShim (package > com.google.web.bindery.autobean.gwt.rebind;) handle the TO_ARRAY case > by checking the: > > a. if the type is assignable to Collection<?> > b. Determine if toArray has one of two supported method signatures in > Collection<?> > c. Generate code that assigns each element of the newly created array > by wrapping it first
This sounds reasonable to me. > 4. Add a unit test to check for unfrozen beans. > > a. Get a collection of AutoBeans > b. assert they are frozen > c. Initialize an ArrayList using this other collection > d. Assert the objects stored the second ArrayList are unfrozen The objects stored in the second ArrayList would still be frozen. It's the AbstractRequestContext and BaseProxyCategory that produces the frozen/unfrozen behavior by cloning the AutoBeans as they're being read though the external methods facades. I think the test that you want here is to ensure that Nth element of a wrapped collection's toArray() is the same as the Nth element of the collection. That is, list.get(0) and list.toArray()[0] are both wrappers. > Open Questions: > > 1. Should I try to handle immutable collections, i.e., > Collections.unmodifiable* or guava's Immutable*? The mutability of the collection shouldn't matter here, since toArray() either returns a newly-allocated array or fills in the array passed to toArray(T[]). -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
