I have been continuing my work on integrating Beans Binding (JSR 295) and the Swing Application Framework (JSR 296) with the work I have been doing on providing a JPA enabled HMVC framework for Swing developers. I must already say that getting to the information on how to exactly use these two apis isn’t straight forward. JavaDoc is probably not what it should be. I can’t really blame them on this, as I am probably the worst candidate for this exercise. Document, as in RTFM, is completely nonexistent.
As I was coding on some UI parts of the demo application for this, I got mail about the issue I mentioned earlier with the NetBeans example code. It seems either the Beans Binding stuff (more specifically its ObservableList implementation) has issues dealing with the same elements being removed and added back again to the Collection.
Indeed, I was executing a Query on the EntityManager returning the same Set of instances (as the EntityManager will take care of Object Identity for you), but this seems to break some bindings (NPE). I could figure out why yet though! I didn’t got it first, as the mail stated that this behavior was not reproducible with the initial transaction management, as generated by NetBeans. But then it came clear, as I was reverting the changes, that the RefreshTask was rollbacking the transaction, causing managed instances to become detached and the Query hence returning new object instances for every row from the table.
I fixed this for now by calling a EntityManager.clear() while doing the refresh. I think this is pretty ugly, as I would expect object identity to be something I want to be able to rely on, especially in such long living applications as Swing rich client apps.
Bad news is that I found about a downside of my approach. But I guess this is probably more related to me trying to fix a inherently broken example…