Joe Nuxoll's Weblog
Tuesday November 22, 2005
Java Properties and Events Graham Hamilton recently posted an entry on his blog requesting suggestions for future Java language innovations. I work with Graham, and have had the opportunity to talk with him about a wide range of Java subjects. One place where we haven't seen exactly eye-to-eye is the area of language-level properties and events. I personally believe this is the #1 missing ease-of-development feature in the Java language (and platform, for that matter).
Adding properties and events to the Java language itself does more than eliminate common boiler-plate code, as is often used as the primary pro argument. The more important benefit of adding these concepts to the language itself is that it promotes the notion of "component library" instead of "class library" when designing new APIs and systems. Component-based development is what makes learning and developing with some "other" software platforms so much easier. The Java language is still very focused on the notion of "class library", which was long ago supplanted by "component libraries" in other platforms.
JavaBeans has been around for a long time. It was the *original* move toward component-based software for the Java platform. The notion of components promotes a plug-and-play method of software development where the common interfaces between components and an application are well defined. This makes it very easy for visual tools to aide in application design and building. It also makes it very easy for new concepts to be introduced to the end developer. A developer is handed a set of JavaBeans which they can study and poke-around with until they learn the new concepts implemented by the suite of JavaBeans. The only problem is... JavaBeans is just a conventional pattern, and not built into the language itself, and therefore completely ignored in most APIs. New technologies and APIs rarely use JavaBeans patterns, and the JavaBeans patterns themselves have gaping holes where tool vendors have had to fill in the gaps.
If these component-oriented concepts were in the language itself, they would be used across the board for new technologies. Any new API (or JSR, etc) would provide a set of components for a developer to use, as opposed to defining a set APIs to implement or leverage. Things would just be easier - both for tool vendors - and for end developers.
I have compiled my thoughts into a document that outlines how this might be accomplished. Please comment!
( Nov 22 2005, 08:18:30 PM PST ) Permalink Comments [4]
Nice thought!!
For properties I definitly like the idea! But I would personnaly not like the method body in the field declaration. While most of the time a simple "public Color bgColor get set;" would be enough, why not just extend the syntax to keep special case simple.
Exemples:
The property keyword indicates to the compiler a private field must be created. Also, the accessor for that field must have the same access as the method specified (if other then set and get specified, which are always public).
The above exemple would produce this bytecode - for an existing public void setBgColor(String newBgColor):
private Color $bgColor; public Color $bgColor$get() { return( this.$bgColor); } public void $bgColor$set(String value) { this.setBgColor(value); }But would produce the following for a private setBgColor method:
private Color $bgColor; public Color $bgColor$get() { return( this.$bgColor); } private void $bgColor$set(String value) { this.setBgColor(value); }And while being at brain storming... why not use that to create the appropriate code for adding listener functionality?
The property keyword indicates to generate a private field.
The get keyword indicates to create a public read accessor, unless a getterMethod is specifed. In which case, the accessor will have the same access as the specified method.
Same thing with the write accessor using the set keyword.
The bound and constrained keyword would make the compiler generate the appropriate code for property listener support.
Indexed properties could be automatically recognize when the type is an array, and then again appropriate code could be create for bounded and constrained properties.
But, I would keep as method call the property listeners manipulation methods - hum... - maybe forcing to use an interface (IJavaBean) - hum... looks ugly. Anyway.
Ok, maybe I gone a little bit too far....
Posted by Hugues Ferland on November 23, 2005 at 07:16 AM PST #
I *think* you had a typo in your prototype line: the "|" between the "set" and ":setterMethod". If you made that a "[" (like the "get" case), then I like it. I think I'd leave the event firing out of the picture for the language-level feature. I also don't think you actually need the property keyword to make this work. I do, however, like the inline get/set methods as options.
TYPE propName [get[:readMethod]|{...}] [set[:writeMethod]|{...}]Posted by Joe Nuxoll on November 23, 2005 at 09:53 AM PST #
Posted by fdasfdsa on October 12, 2006 at 07:19 PM PDT #
For the times when I want a simple "property", I just use a public member variable with no getter/setter methods.
For the times when I want added getter/setter logic, I use a private member variable and public getter/setter methods.
Most Java frameworks will use the getter/setter methods first if they are available and use the direct member variable if they are not.
No boilerplate code at all. Why are new language features needed?
Posted by javadev on October 07, 2007 at 10:14 AM PDT #