Not Found in GWT Release: svn trunk as of revision 861

Detailed description: This patch provides emulation for java.beans.PropertyChangeSupport and related classes. PCS is very useful when it comes to using an MVC idiom and generally writing objects that can be monitored via an observable pattern.

I know of at least one upcoming GWT book that makes use of PCS in it's examples and currently tells people to use my GWTx project to get an emulated PCS. As much as I like the fame and the glory that comes from my work getting noticed, that isn't the goal of GWTx.

Legal: The non-unit test files were based on Apache Harmony code. Each file contains a comment indicating where I grabbed it from before I started making changes. Harmony code is released under an ASL 2.0 license.

No code from the GWTx project was used in making this patch, though all GWTx code is ASL licensed too. I thought code derived from Harmony would be of better quality than what I wrote from scratch.

Changes to the Harmony sources: I generally tried to keep the sources formatted like Harmony does. That way tracking future updates to harmony's code base should be easier.

1. Removed any Serializable stuff.
2. Refactored any Java 1.5 stuff to be 1.4 compatible. In the case of generics I just commented them out. eg: List<PropertyChangeListener> became List/<PropertyChangeListener>/ to make it easier to add back in generics support later.
3. Some methods/classes that were introduced in Java 1.5 are currently commented out. There are TODO comments to aid in finding them when Java 1.5 support is added to GWT.
4. Discovered and fixed a bug in Harmony's version of fireProperyChange. (I've reported a bug report to them too.)
5. The doFirePropertyChange methods were reworked to be simpler and not require as much memory.
6. The getPropertyChangeListeners methods were reworked because they made use of methods not emulated by GWT.

Modified Files: A user/super/com/google/gwt/emul/java/util/EventListenerProxy.java A user/super/com/google/gwt/emul/java/beans A user/super/com/google/gwt/emul/java/beans/PropertyChangeSupport.java A user/super/com/google/gwt/emul/java/beans/PropertyChangeListener.java A user/super/com/google/gwt/emul/java/beans/PropertyChangeListenerProxy.java A user/super/com/google/gwt/emul/java/beans/PropertyChangeEvent.java A user/super/com/google/gwt/emul/java/beans/IndexedPropertyChangeEvent.java A user/super/com/google/gwt/emul/java/beans/VetoableChangeSupport.java A user/super/com/google/gwt/emul/java/beans/VetoableChangeListener.java A user/super/com/google/gwt/emul/java/beans/VetoableChangeListenerProxy.java A user/super/com/google/gwt/emul/java/beans/PropertyVetoException.java M user/test/com/google/gwt/emultest/EmulSuite.java A user/test/com/google/gwt/emultest/java/beans A user/test/com/google/gwt/emultest/java/beans/VetoableChangeSupportTest.java A user/test/com/google/gwt/emultest/java/beans/PropertyChangeSupportTest.java

Testing: The patch contains some unit tests for the PCS. The tests aren't exhaustive but they should at least indirectly cover the majority of the code.

Workaround if you have one: Use GWTx, hack up your own observer pattern system.

Links to the relevant GWT Developer Forum posts: http://groups.google.com/group/Google-Web-Toolkit/search?q=PropertyChangeSupport&start=0&scoring=d&amp;

As a new feature, this may be too late for 1.4; assigning to Bruce for review.

Thanks very much sandymac for the patch. As suspected, this is too much to bite off for 1.4 since there are inevitable design debates. One thing that could make this idea much easer to analyze would be some discussion on the contrib list regarding GWT-related use cases.

I vote for this as soon as it is possible.

PropertyChangeSupport is very handy in a GWT context. The use cases for GWT are basically the same as for standard desktop development with Swing/AWT - data bound properties - (http://java.sun.com/docs/books/tutorial/javabeans/properties/bound.html).

As to the design decisions, I really applaud the care and consideration you guys take in general design and in all of the implementation (quality, and it shows), and I know this is late, but this patch should be inconsequential to existing design. An initial include of PCS would not affect anything - it would simply make it possible for users to use PCS if they elect to do so? (For users that do not elect to use it, it stays completely out of the way.)

Is this going to be part of 1.5?

(Not committing to do it; just committing to seriously consider it.)

I hope it's not too late in the cycle to seriously consider this one. It's basically just improving compatibility; no one is forcing the core GWT widgets to use it necessarily.

Sorry to be fickle, but time pressure -- even if self-imposed -- has a very clarifying effect: we need to punt.

Shouldn't be harmful, though. It's pretty easy for anyone to use GWTx until we get around to putting more JRE support into GWT proper.

See http://code.google.com/p/gwtx/source/browse and so on.

Bruce,

GWTx is currently broken with respect to GWT 1.5RC1, and a message on the web site indicates that fixes won't be coming without new project volunteers:

"About GWT 1.5 support: GWTx targeted GWT 1.4 and as such doesn't not support any Java 5 features (eg: generics) and is unsupported when used with GWT 1.5. If you would like to help out with bring the GWTx code base forward, please contact sandymac at gmail.com"

My project currently won't build under GWT 1.5RC1 as a result. I only need GWTx for the PropertyChangeListener support.

I'll post if I find a workaround, but I thought you should know that the context of your comment #6, vis-a-vis the ease of just using GWTx, seems to only be relevant to GWT 1.4.x

I'm happy to amend my last comment. My project's module file had been importing what i thought was the minimal amount of GWTx to import for the PropertyChangeSupport stuff:

<inherits name="com.googlecode.gwtx.java.Beans"/>

But it turns out that the Beans module file immediately imports the io package, which is not necessary for what I needed. Replacing that statement with the following two did the trick, and now my project builds with 1.5RC1.

   <inherits name="com.googlecode.gwtx.java.util.emul.Emulation"/>
   <inherits name="com.googlecode.gwtx.java.beans.emul.Emulation"/>

Curiously, I have one project using GWT 1.5.0 RC1 that is managed by the standard GWT methods - projectCreator and applicationCreator to generate Eclipse launch profiles. I added the GWTx library jar into this project, made use of PCS, and compiled witht no problems.

A second project, on the other hand, uses gwt-maven to build and manage the lifecycle. I added GWtx as a dependency to that project and used the same PCS classes. This time, though, I ran into the problems described here.

I was able to resolve the issue using the suggestion in comment 8. But it begs the question: what was so different about the GWT-managed project compared to the gwt-maven project that it successfully built and compiled?

Attached is my successfully built project using 1.5.0-rc1 and (the complete) GWTx...

Oh - do note that the size of the download is due to the inclusion of some jar libraries for completeness. I also built the project on a Mac, so my toolkit was located at /Applications/gwt-mac-1.5.0-rc1/

Your mileage may vary if you try to run this app...

Hi Pohl,

I tried your suggestion posted on Comment 8 and got the following errors:

[ERROR] Errors in 'jar:file:/C:/gwt-windows-1.5.0/gwt-user.jar!/com/google/gwt/emul/java/util/Collections.java' [ERROR] Line 248: The type Enumeration is not generic; it cannot be parameterized with arguments [ERROR] Line 249: T cannot be resolved to a type [ERROR] Line 250: T cannot be resolved to a type [ERROR] Errors in 'jar:file:/C:/gwt-windows-1.5.0/gwt-user.jar!/com/google/gwt/emul/java/util/Vector.java' [ERROR] Line 113: The type Enumeration is not generic; it cannot be parameterized with arguments

I am using GWT 1.5 RC1 with GWTx-20070605.jar. Am I missing something? Please help.

Thanks -Ryan

rhfong,

I was using the same versions (GWT 1.5rc1 and GWTx-20070605) so maybe your errors have to do with something else. I noticed none of the errors seem to be about anything related to GWTx.

If you just changed from GWT 1.4, then I suspect that some GWT 1.4 jar is still lingering about in your build environment somewhere. Make sure you delete them completely. Then if your IDE is still looking for an old jar, it will give you a specific message about that instead.

Hope that helps...just my best guess.

Thank you so much for the fast reply. I am still figuring out to see what is causing the problem. Thanks for your suggestions as well. It would be really nice to have PropertyChangeSupport implemented in GWT 1.5.

Just to update on my findings with the problem I was having. It does seem to be somehow GWTx related issues. After I re-complied my project with following source code taken from the GWTx svn.

EventListenerProxy.java IndexedPropertyChangeEvent.java PropertyChangeEvent.java PropertyChangeListener.java PropertyChangeListenerProxy.java PropertyChangeSupport.java

After resolving package name issues and java.util dependencies, I was able to compile and use both PropertyChangeListener and PropertyChangeSupport in my GWT 1.5 RC01 project.

This bit me again when trying to upgrade to 1.6.4. But this time, instead of having dodged the bullet, I'm getting rhfong's symptoms in his Aug 28, 2008 comment.

Real support of these classes in GWT would decouple my project from GWTx and make these upgrades go easier.

I was able to work around this again. My original solution in comment #8 did not need to be altered at all. This time all I needed to do was replace the older GWTx-20070605.jar with the newer gwtx-1.5.2.jar

Their change in the naming scheme didn't make it obvious to me that the latter was newer, but I guess it is.

http://code.google.com/events/io/sessions/GoogleWebToolkitBestPractices.html

After seeing the above presentation, and putting its principles into practice, I have realized that I don't want property change support anymore. It's much better to treat models as ephemeral & disposable, and have an MVP Presenter who is responsible for changing a model publish that fact on an event bus.

Unstarring.

There's a lot of controversy about this, and it's far from clear this is really the right way to proceed, but it's presence will lure a lot of people in this direction. Consequently, I'd like to turn this on off until/unless consensus emerges that we really should have it (currently, the tide is strongly in the opposite direction).

Hello there, what is happening with this? I understand MVP and so on, still I find that native support for PropertyChange, as per GWTx, would be very useful to many and in any case would give developers a choice as to which pattern to use.

Please do add this functionality to GWT natively.

Thanks, Francesco