transient field for PropertyChangeSupport and ListenerSupport

[fommil]

as the title says - could you please create an annotation for settings on the PropertyChangeSupport, such as whether an existing getPropertyChangeSupport() method should be called, or an existing variable, and if any newly created variables should be declared transient.

[fommil]

I suppose the workaround is to manually create the

private final transient PropertyChangeSupport propertyChangeSupport = new PropertyChangeSupport(this);

but I think there is an argument for @PropertyChangeSupport to come back since this and how to get the variable are essentially user options.

[fommil]

also, transient settings for @ListenerSupport would be good too. Or perhaps the better solution here is to write a custom serialiser or BeanInfo.

[peichhorn]

as the title says - could you please create an annotation for settings on the PropertyChangeSupport, such as whether an existing getPropertyChangeSupport() method should be called, or an existing variable, and if any newly created variables should be declared transient.

No need, both propertyChangeSupport and vetoableChangeSupport are already transient fields as you can see in the test-case BoundSetterVetoable. I still need to update the wiki though.

also, transient settings for @ListenerSupport would be good too.

Noted, but I need to think about this first.

[fommil]

When I do (in 0.11.4-SNAPSHOT)

Field field = Settings.class.getDeclaredField("$propertyChangeSupportLock");
log.info("modifiers = " + Modifier.toString(field.getModifiers()));

I'm getting "private final".

Same thing for $propertyChangeSupport and my classes that have @ListenerSupport.

BTW, why is the test case volatile transient instead of final transient? Can't you pass this from an initializer variable?

[peichhorn]

When I do (in 0.11.4-SNAPSHOT) [...] I'm getting "private final".

Have you tried a decompiler?

BTW, why is the test case volatile transient instead of final transient? Can't you pass this from an initializer variable?

@BoundSetter is supposed to work with serialization, therefore both propertyChangeSupport and vetoableChangeSupport are initialized lazily.

[fommil]

delombok isn't processing @BoundSetter at all. Can you recommend a decompiler?

Re: lazy init. Of course! I forgot that transient final fields aren't restored without readResolve.

Kind regards, Sam Halliday

Sent from my iPhone

On 15 Aug 2012, at 07:06, Philipp Eichhorn notifications@github.com wrote:

When I do (in 0.11.4-SNAPSHOT) [...] I'm getting "private final".

Have you tried a decompiler?

BTW, why is the test case volatile transient instead of final transient? Can't you pass this from an initializer variable?

@BoundSetter is supposed to work with serialization, therefore both propertyChangeSupport and vetoableChangeSupport are initialized lazily.

— Reply to this email directly or view it on GitHub.