Java Beans support (was Re: Mike on Properties)

On 31 Mar 2004, at 23:54, Cedric Beust wrote:
>  Well, thanks Mike for finally delivering.
>
>  I posted a few comments on your analysis in my weblog, but at this 
> point, I think we should take the discussion on this list.  It looks 
> like the JSR EG has their work cut out for them 

:)

Agreed. Thanks to both of you for this - especially all the work that 
went into Mikes analysis.

There are various different issues that Mikes review covered. To ease 
the discussion I'm gonna try keep things in threads.

One was the newline sensitivity issue - which I think is now fixed in 
CVS and if it is not now fixed its a bug that we should fix. We can 
discuss that at length in another thread if need be. Another issue 
covered in passing was autoboxing support (that numbers are treated as 
objects) which again we can split off into another thread if need be.

But mostly the analysis covered beans & properties.
Its important to make the clear distinction between the Groovy support 
for working with existing Java Beans and having syntax sugar in Groovy 
to define new Java Beans.

For me quite a bit of of Mike's criticisms are actually criticisms of 
the Java Beans specification and the Java Beans support thats been in 
the JDK since about 1.1. IIRC.

Basically Groovy supports any Java Bean which implements the Java Beans 
specification. So given some Java Bean Foo you can do things like

y = foo.pizza
foo.cheese = "Edam"

which is equivalent to the Java code

y = foo.getPizza()
foo.setCheese("Edam")

So Groovy supports beans in the same way as most bean-centric 
frameworks and tools like JSP EL, Velocity, commons-beanutils, OGNL, 
jython, bsh along with languages like Ruby, Python, C# etc.

On the Java platform, Java Beans are defined by the JDK. This means 
that the java.beans.Introspector is used to introspect a type to figure 
out its read/write properties. This has nothing to do with fields or 
groovy - its the Java component model. Basically Java allows you to 
write a bad Java Bean if you don't know what you're doing.

e.g. if you use different types for the getter & setter, then the 
default introspector in the JDK gets confused. Ditto if you write 
multiple setter methods with the same name. If you want to give the 
Introspector a hint to exactly what properties you wish to expose, you 
can write a BeanInfo class.

So listings 16, 17, 18, 19 are really just demonstrating how to confuse 
Java's bean introspector. You could use Java code to demonstrate this 
issue.

To try keep the conversation manageable, I'm gonna try start a separate 
thread on 'getter/setter syntax sugar' where we just focus on if/how we 
should add some sugar to the Groovy language to allow standard Java 
Beans to be written more easily in Groovy.

James
-------
http://radio.weblogs.com/0112098/