Hi there again, Am Freitag, den 03.02.2006, 14:36 +0100 schrieb Roman Kennke: > Hi Mark, > > Am Freitag, den 03.02.2006, 12:19 +0100 schrieb Mark Wielaard: > > Hi, > > > > This should get rid of the last regression that builder is complaining > > about (technically it isn't a regression, the test got changed to not > > expect a NullPointerException). It simply changes the Hashtable that > > doesn't allow null keys to a HashMap. The class wasn't thread-safe in > > the first place. > > Now that you say it, the point of the SwingProperyChangeSupport class is > to be not thread safe. It's even specified in the API docs. So we should > probably remove all the synchronization from this class. In Swing it is > ok to be not thread safe, since normally all operations should be > performed from the Event dispatch thread.
I just looked at the JDK1.5 API docs for that class and found that Sun seems to have completely removed the implementation except for the constructor which most likely only call super(bla) now. I guess the java.beans.PropertyChangeSupport is now made more efficient (and not thread safe) so that the SwingPropertyChangeSupport is not needed anymore. Should we follow this? /Roman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
