Cay Horstmann's Blog

Properties Get No Respect

There has been another flurry of discussions about closures in Java and minor language enhancements, together with the usual flurry of “leave the language alone” lamentations.

Conspicuously absent from this discussion was my pet unappreciated language feature, native properties. Properties get no respect. Every few weeks, another blogger comes along and says “we need a property syntax”, proposes something, and moves on to greener pastures.

At best, properties are dull. Programmers who work with Swing, JPA, JSF components, XMLEncoder/Decoder, and other "beanish" technology cringe every time they have another class with a bunch of annoying trivial getters and setters. But it isn't the end of the world. They can cringe and keep on coding. How much gratification is there in making people cringe less? Apparently not enough to put together a proposal that deals with all the pesky details.

But it gets worse. While worrying about pesky details, the hapless property syntax designer needs to fend off a barrage of attacks from the inevitable naysayers (“What's the big deal...Eclipse writes the getters and setters for me”) and the OO purists (“Properties are the tool of the devil...they break encapsulation”).

As a result, most of the effort about properties has been half-hearted and scattered about in the blogosphere. There was never enough momentum to arrive at a consensus. Nikolay Botev, a computer science student at SJSU, has done something about that. In his independent study project, he collected every reference about properties he could find, in Java and other languages, and put all the information into a Wiki. He also added nifty voting buttons to the Wiki.

While everyone else is madly milling about at the mall, please take a few minutes to see check it out: http://oslo.cs.sjsu.edu:8080/xwiki/bin/view/JavaProperties. If you are a properties enthusiast (you know who you are), please make an account and add to the Wiki.

Happy holidays!

Comments

• The problem is that one can do properties in a million ways. The pros and cons with the different methods are pretty easy to understand, and all tend to agree on those, but which pros and cons are important is under debate. Every property advocate will stand by his way of doing properties since "it is not decided yet".

  The problem can only be solved by Sun, which is the only one capable of putting it in the platform. Sun must give some hints about what is important and what is not.

  For instance, should they be flexible or not. Should they be able to remove boiler plate or not. Is the memory consumption per instance important. Is the syntax important. And so on. Until this is decided no one of the proposal writes will give an inch.

  Posted by: mikaelgrev on December 21, 2007 at 12:44 AM

• sun should initiate a JSR to get the ball rolling, even if it's only slated for java9 ;) Personally, i'd be happy with a Netbeans plugin that artificially presented properties in the editor, while generating appropriate standard code in the actual java source files. But ultimately, properties must be introduced in the language, for toolability, refactorability, blah blah blah, not to mention binding, not to mention reducing boilerplate.

  Posted by: evanx on December 21, 2007 at 02:33 AM

• This is stunning work. Kudos.
  One thing to add, Remi Forax's property proposal is implemented at Kijaro

  Posted by: scolebourne on December 21, 2007 at 04:33 AM

• Nice stuff on the wiki. I've added this as a resource link on my Java 7 page.

  Posted by: alexdmiller on December 21, 2007 at 07:11 AM

• Most surprising was probably how Joshua Bloch and Neal Gafter replied to this issue at JavaPolis, to which I had to create a thread on the Java Posse discussion group: http://groups.google.com/group/javaposse/browse_thread/thread/2e4de260c64c956d

  Posted by: mrmorris on December 21, 2007 at 07:21 AM

• Joshua Bloch is really funny sometimes. So to him adding extension methods, with all the confusion that it might cause makes a lot of sense, but adding property support, which could save UI developers a lot of hassles is not worth it. I don't know, but I think language experts should stick to doing language design, and let UI design experts do what's best for UI development.

  Posted by: mikeazzi on December 21, 2007 at 08:00 AM

• Language change is no different to any other area of design - we all just solve the problems we experience. Since Josh and Neal haven't experienced the problems (based on my brief conversations with them), neither of them are overly inclined to fix it. (For the record, I've worked both on swing and web, so understand the pain of properties all too well)

  Posted by: scolebourne on December 21, 2007 at 11:16 AM

• The Wiki page is a bit misleading at first glance. Why is not it possible to program: button.text = "String"? One could always do it that way but as we can see that approach is not very popular. And it is not because of Java language limitations. I am sure you understand it very well. If you do not respect OO (at least encapsulation) then go ahead and rely on your class member variables. I personally treat Java as a language which allows me to program in OO way, at least I have no problems with what you call properties. I do understand why I need to key in those set/get methods. To me "properties problem" looks a bit "artificial".

  Posted by: imichtch on December 21, 2007 at 11:54 AM

• I want properties. Actually what I really want is the "property object" like what Remi is proposing. If I want that kind of functionality now I have to use reflection and that can be really slow and not type safe. I'd like to be able to write code that can instantly transform any array or collection of beans into a list or table model.
  Example:

  List beans = ....
  PropertyTableModel model = new PropertyTableModel(beans);
  model.addColumn(PersonBean#Name);
  model.addColumn(PersonBean#SSN);
  model.addColumn(PersonBean#Birthdate);
  model.addColumn(PersonBean#Address);

  
  and *POOF* you have a table model that wraps your collection of beans. This model can be used to back a JTable or JFreeReport or anything that deals with TableModels.

  
  

  Posted by: aberrant on December 21, 2007 at 01:12 PM

• Bah .. the generics in my decelerations got messed up. That should be :

  
  List<PersonBean> = ...

  
  

  Posted by: aberrant on December 21, 2007 at 01:15 PM

• I just ran into the comments Mr. Botev made about my project (bean-properties) which is surprising because you would assume he would bother verifying his mistakes with the mailing list or myself. I'm surprised you would paste such misinformation into the wiki without asking for comments.
  Another point that annoys me is the fact that someone blatantly copied and pasted content from the website (which is outdated by a far better explanation today) without permission and without giving me the minimal decency of a response...
  These are my replies to the comments made here.
  Regarding point 1: Saying "native properties can do X better" is no proof and no argument. Furthermore it is technically wrong! You cannot properly use declarative programming with non-object properties that compile to getters setters for several different reasons:

  You don't have a "point" in which you parse such an annotation in order to assign it to meta-data or access strategies.
  You have no way to customize annotations externally (context object mutability) which makes declarative programming into hardcoding (sort of EJB3 without deployment descriptor option).
  If a user defines an annotation only the user can parse and handle it the code cannot globally apply the effect of the annotation. E.g. @SSN would mean social security number, which would imply validation. In bean-properties it is trivial to do all the coding in one place and use the annotation as more than just a marker.

  
  Point 2: Since property get/set hacks compile to getters/setters the question is whether they will be compatible. Under the hood a String will be passed, not a literal which is "faked" by the compiler. Sure a compiler can try to enforce things but such issues with backwards compatibility tend to "leak" which is not technically possible in bean-properties where the value is real and not a "fake" element.
  Furthermore, when these elements are passed bean-properties requires no internal reflection (as language changes would require) and uses simple virtual invocations.

  Point 3: This is incorrect and shows that Mr Botev has read too much BS rather than tried to implement such a thing...
  Current "practical" suggestions expect a hardcoded "magic" method for bound properties that would need to fire the event to the right listeners. Listener management is not a practical feature for a language level change according to any practical (non-object) property suggestion.

  Point 4: This point was obviously misunderstood by Mr Botev who apparently doesn't understand the meta-data needs of ORM systems. I suggest he takes a look at the ORM implementation of bean-properties and compares it to a POJO based ORM before discussing literals.
  The point was made in regards to introspection and user customizable meta-data which won't be possible in getter/setter based properties.

  Point 5: Again no understanding of meta-data and a stupid response of "X is possible with Y" without any informed argument... No UI Factories are not possible since there is no guarantee to order of properties and no ability to define property meta-data from localization to validation etc...

  Point 6: A custom bean info is indeed possible which is an interesting approach which I have yet to see a single person taking. Obviously a custom bean info is useless for server side code or for that matter, useless for everyone since practically every bean using code I ever saw (including code from Sun) uses the get/set method even when working with the bean-info. The alternative is just too buggy to use and too much of a pain to understand.

  Point 7: No its not. Getters setters have no modifiable managed meta-data.

  Point 8: Thats not true. Centralized management of beans is done on the server side constantly where it works great. You can control how centralized you would like management to be by overriding the bean container and building your own policy. Since the number of bean classes is limited the memory leak claim is BS and I suggest you read enough about bean-properties to understand that the container doesn't hold object instances before badmouthing the entire project.

  Point 9: Delegation is no substitute for objects, lets remove all inheritance and only use composites for everything.... The AOP suggestion besides being unpractical in many deployment scenarios is just plain ridiculous. I don't even want to start a discussion on the complexities of debugging and maintaining AOP.

  Point 10: I don't understand his point here...

  
  Clearly Mr Botev has had something to say about every point I've made but didn't have the balls to say it to me or to our list...

  Posted by: vprise on December 21, 2007 at 01:38 PM

• BTW the wiki also contains very outdated syntax information about bean-properties and lists it as a suggestion rather than a working implementation that people are already using...

  Posted by: vprise on December 21, 2007 at 01:40 PM

• Someone vandalized the Wiki earlier today. I managed to get the missing content back, but the voting buttons are gone right now. Sorry about that. I'll try to get them back later.

  Posted by: cayhorstmann on December 21, 2007 at 06:11 PM

• vprise,

  Regarding my bean-properties project analysis document:

  I have updated all quoted text to be in proper citation format and put a note up alerting visitors as to the outdatedness of the information.

  After your emotions have cooled off, I would encourage you to post comments with your constructive arguments (without the ad hominem attacks please) directly to the analysis page on the Oslo XWiki. Or even better, you can register and edit the page, inserting your response to each point directly into the document.
  

  Posted by: nikolaybotev on December 24, 2007 at 10:17 PM

• I'm upset because a great deal of work myself and others have put forward, has been slandered inappropriately. You shouldn't be surprised that I'm upset about this, otherwise you would have bothered to actually ask for feedback.

  Posted by: vprise on December 25, 2007 at 04:29 AM

• I recall the passage in "Through the Looking Glass" where there is a forest in which nothing has any name and Alice and a deer walk alongside each other until they are out of the forest and the deer is startled, realizes it is a deer and that Alice is a little girl, and springs away.

  The simple fact is that properties are an existing pattern which is implicitly emulated by getter setter syntax, and is explictly used in extra-Javic contexts such mapping JavaBeans in JSTL.

  My suggestion is to take a deep breath and look at other languages such as C# that implement properties. (This is not to say that I endorse C#, just that I was impressed by this feature.) Declaring a property gives it a default implicit getter and setter block. The default getter and setter block does just about what the standard JavaBean syntax does. It does not break encapsulation because you can override the default behavior if you wish. The block is attached to the property, instead of being split out into getXxx(), setXxx().

  One of the rules of good engineering is to make simple things easy, and to require you to coordinate as few things as possible. Another is that for efficiency, work should be directed toward satisfying business rules not programming conventions.

  I suspect that some folks who are doing POJO programming, are worried that their lines-per-day productivity will be adversely impacted. ;)

  Posted by: esmiley on June 09, 2008 at 09:46 AM

• Thanks so much for this! This is exactly what I was looking for.
  ///////////////////////////
  phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex mootzie
  and other video to SWF, FLV ecoded by Java.
  May it Gadgets helpful To your lifestyle... Enjoy！！

  Posted by: cgspender on June 19, 2008 at 04:53 PM

• excellent work

  Posted by: cgspender on June 19, 2008 at 04:53 PM

• Thanks so much for this! This is exactly what I was looking for.
  ///////////////////////////
  phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex phone sex mootzie
  and other video to SWF, FLV ecoded by Java.
  May it Gadgets helpful To your lifestyle... Enjoy！！

  Posted by: cgspender on June 19, 2008 at 04:53 PM

• well done

  Posted by: cgspender on June 19, 2008 at 04:54 PM

This work is licensed under a Creative Commons License.