LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Visual Java


By Allen Holub
July 15, 2005 — 
I recently stumbled across JSR 273, “Design-Time API for JavaBeans,” on the jcp.org site. This is a new Java Specification Request that was originally contemplated for Mustang (J2SE 6), but which will probably be released after Mustang ships next year. The point of this JSR is to extend the JavaBeans 1.01 spec to make it easier to integrate a JavaBean-compliant component that you write into a design-time container. (I’m talking primarily about visual components that appear in a user interface and are manipulated by a design-time Visual Basic-like layout tool; these sorts of beans have nothing to do with EJBs, for example.)

The main reason I find this JSR interesting is that the original JavaBeans specification was responsible for introducing the getter/setter idiom to Java, an idiom that’s fundamentally at odds with the object-oriented principle of implementation hiding. The result is that there are a lot of procedural programs written in Java by people who think that they’re programming in an object-oriented way. Overuse of getter/setter functions causes serious maintenance problems, and can obviate most of the advantages of OO systems.

Interestingly, the original JavaBeans spec didn’t mandate that you use a getter/setter idiom. The point of the idiom was to tag certain attributes of an object for inclusion in a tool-generated property sheet. That is, if you provided getFoo() and setFoo() methods, then a design-time tool would include a Foo property in the property sheet for that component. The spec provides for a much more object-oriented way of doing the same thing: A BeanCustomizer could create an arbitrary property sheet for a component, thereby rendering the getter/setter functions unnecessary.

The problem was that nobody understood how to build a customizer. The specification itself was responsible for this problem. The section on customizers was both sketchy and much harder to understand than the rest of the document. More to the point, the spec included no discussion of why you might want to use a customizer. The net result is that nobody did use them, and as a consequence a lot of bad code has been written.

One solution to this problem would have been to introduce a new keyword to Java (such as @property), which could be used syntactically like an access privilege such as private. This way you could declare a private field that was marked as a property so that the design-time tool could do its thing and construct the property sheet for you. At the time, Sun was adamantly opposed to the notion of introducing new keywords to Java, though the new metadata feature of Java 5 effectively does exactly that.

With JSR 273, we now have the opportunity to replace a troublesome idiom that never should have been introduced with a more maintainable (and object-oriented) alternative. To do that, however, the JSR development process needs to be completely transparent (in the sense of the programmer community being able to monitor the expert group’s work). That is, the new specification (and the expert group that’s producing it) has to educate the community as to why a new way of doing things is better than public get/set functions, and the best way to do this is to publish the discussion that results in the final API set.

I’m also not convinced that the expert group will know enough about OO principals to fix the problem of a procedural idiom corrupting otherwise object-oriented code. Certainly, other expert groups have compounded the problem by using the same getter/setter idiom as JavaBeans, and I have to believe that the experts wouldn’t have done so if they understood the underlying issues.

Finally, I’m worried that the spec will be written as opaquely as the original, and that the IDE companies will use the new mechanisms for their own components, but nobody else will. If the spec is poorly written, and at the same time allows the use of getter/setter methods, people will do the latter.

Unfortunately, JSR 273 shows all the signs of being completely opaque. The JSR Web page (jcp.org/en/jsr/detail?id=273) lists no Web site or mailing list for this project. You can nominate yourself for the expert group from a link on the JSR Web page, but that’s the only obvious way to get involved at present. Nonetheless, if you feel strongly about these issues, I recommend that you get involved. You can write the project lead (Sun’s Joe Nuxoll) at joe.nuxoll@sun.com.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


Share this link: http://www.sdtimes.com/link/28727
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading