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


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

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