Community
Participate
Working Groups
final IObservableList currentGroupTradeObList = BeansObservables.observeDetailList(Realm.getDefault(), modelObValue, "trades", Order.class); results in an UnsupportedOperation exception.
*** Bug 180386 has been marked as a duplicate of this bug. ***
Boris, do you have time to look at this for 3.3M7? The reason I ask is that this is unexpected. I would think that the default behavior when observing a list is for it to be mutable, not immutable.
Boris, are you going to be able to get to this for M7?
I can try...
(In reply to comment #4) > I can try... > If you can't get to it let me know and I'll try to find the time.
Implementation released >20070428. Tests would be good... Brad?
(continuation from IM about the patch...) I raised the question to Boris on IM that when an item is added a new list is constructed and the bean will fire a change event for the property. This is not conveying to the consumer that a value has changed at an index, it's saying that the entire list changed. This comes from section 7.2 of the bean spec[1]... "In order to change the size of the array you must use the array setter method to set a new (or updated) array. " As a result it would throw a property change event. My opinion is that we shouldn't try to mimic this when an item is added. If wanting to fire a change event from the bean the consumer could set a new list as they would an array. If the consumer wants the array behavior they could also just expose an array rather than a collection. I'm not comfortable guessing at this and it could have performance issues as we'd be constructing new lists any time an item is added or removed. We also have to make assumptions on the type of List that the consumer is exposing when we set a new list. Thoughts? [1] http://java.sun.com/products/javabeans/docs/spec.html
Created attachment 65354 [details] tests patch This is a patch with tests that I've written for the mutable aspects. Half of these tests fail. The reason being that the bean list is not be mutated on change of the observable list. This is occurring because I removed the code to set a new list on every change. I'd attempt to fix this but I don't have anymore time today to do so.
(In reply to comment #7) > (continuation from IM about the patch...) > > I raised the question to Boris on IM that when an item is added a new list is > constructed and the bean will fire a change event for the property. This is > not conveying to the consumer that a value has changed at an index, it's saying > that the entire list changed. This comes from section 7.2 of the bean > spec[1]... > > "In order to change the size of the array you must use the array setter method > to set a new (or > updated) array. " > > As a result it would throw a property change event. My opinion is that we > shouldn't try to mimic this when an item is added. If wanting to fire a change > event from the bean the consumer could set a new list as they would an array. > If the consumer wants the array behavior they could also just expose an array > rather than a collection. > > I'm not comfortable guessing at this and it could have performance issues as > we'd be constructing new lists any time an item is added or removed. We also > have to make assumptions on the type of List that the consumer is exposing when > we set a new list. > > Thoughts? > > [1] http://java.sun.com/products/javabeans/docs/spec.html > Also if this was the approach a setter would have to exist for the list to be mutable.
Joe, you have experience with the Java Bean spec; what do you think we should do with comment #7? Thanks in advance
(In reply to comment #10) > Joe, you have experience with the Java Bean spec; what do you think we should > do with comment #7? Yes, this is a real problem with the JavaBeans spec right now which doesn't treat list properties at all well, probably because at the time of the spec collections didn't exist. However, JSR 273 (Design time API for JavaBeans) does address this and provide really good support for list properties. The spec isn't finalized yet but it is close to having a reference implementation. It won't make the language till Java7 though. What it does is allow you to tie together things like a getCollection() method, the add, and the remove, as well have property change events that are signalled with the index of the item(s) being added or removed. It also supports generics, arrays (for people who want to use arrays). Joe
Thanks for the input Joe. So we need to make a decision on this if we want to get this into 3.3M7. My vote is if a getCollection() method exists then we can adapt it to an IObservableList and it should be mutable. In our applications we will expose a getter and not a setter. We want to be able to mutate the list but we don't want someone to be able to set a new instance so we don't expose a setter. I vote for this to be an adpater to an existing instance and it does not change that instance.
(In reply to comment #12) > I vote for this to be an adpater to an existing instance and it does not change > that instance. > That is confusing. Make that... I vote for this to be an adapter to an existing instance and it does not replace the instance on change.
Since I haven't heard anything either way I'm just going to go with the way it was previous implemented as I think it's important to get this in.
Created attachment 65447 [details] tests patch along with bug fixes Patch working as initially designed.
Brad, we should get this in for RC1.
+1 for the patch (I added another test class for the "standard" case where the property is an array type). Released >20070515.
Btw, the only real changes in the code were two places where a variable was not incremented properly.
Verified by checking the test results for I20070517-1700.
