Rémi Forax's Blog

Java property (draft 3)

This is a new step in my quest (or curse) to provide properties to Java.
I've written a new version of the proposal (the third draft) of the property spec, available as a google doc
property draft (v3)

During the last month, i've written a new prototype from scratch that follows the specification. The prototype is not available yet, mostly because i change the spec too frequently, but i hope to post a blog about its availability in one or two weeks.

If you are concerned by the implementation details of the prototype, i will soon post messages that describe its implementation to Kitchen Sink Language mailing list.

I wait your comment about the spec.

Cheers,
Rémi

Comments

• Hello.

  I am concerned by your will to use dot '.' as a property accessor. I think it is real bad, as you will not be able to know juste by reading the code if you access a field or a property and thus cannot know the behavior of the operation without looking at docs or code, for even the slightest operation.

  bean.name3 = bean.name2; ought to look like you are trying to add a reference to an object, but it could do much harm like throw exceptions (nullpointer, arrayindexoutofbounds, ...) at any time, or worse, without notification if the implementor changes his code. Bad, bad bad.
  To me it just looks like a countermeasure to add operator overriding. (not that i intend it is your will, but the effect is the same..)
  I certainly do not want to go back at C/C++ when i spent more time wondering what the code was doing, swimming/drowning through various source files instead of simply coding.

  The dot problem is a blocker to me.

  Also, i wondered the reason for the no 'get set' declaration. It looks to me that not being able to set it will be a much common mistake from newcomers as it is not logical to "be able to say you want setters or getters, but not both, which is instead declared by declaring nothing".
  I hope you get the idea.

  Posted by: pepe on May 13, 2007 at 07:58 AM

• oh, and please pardon me for the line breaking. I always forget that....

  Posted by: pepe on May 13, 2007 at 08:15 AM

• '.' is perfect, because we are used to it and it's positon on most keyboard layouts..

  bean.value vs. bean.property is not more confusing as the method parameter hiding of class attributes, but a good editor (like nb 6) will highlight them in different colors and you'll see the difference instantly..

  Posted by: zero on May 13, 2007 at 08:23 AM

• Nice work! I wonder if there's opportunity here to had pure weakly referenced listeners without writing any boilerplate code? This would solve a ton of use cases that have to be byte-code enhanced.

  Posted by: jhook on May 13, 2007 at 09:05 AM

• Hello Rémi,
  It's a good start, or rather continuation I guess.

  I always start with a list of demands about what something needs in order to be successful and used. Use-cases so to say. For example will properties be picked up by tools and should there be possible to mix properties and normal getters and setters and they would look the same to the tool? Only when this is dealt with one should start to architecture the solution. Dot or hash matters less. If you can implement your own property types is more important and will affect the adoption. If you can't use this for JSF properties or get rid of common boiler plate, not just the MOST common boiler plate, why would anyone use it?

  I wrote a blurb on the Java Posse's mail list about what needs to be in properties to make them worth while. It's here: http://groups.google.com/group/javaposse/tree/browse_frm/thread/90f85b72b92f7c31/bcc097b519fe4a72?rnum=21&_done=%2Fgroup%2Fjavaposse%2Fbrowse_frm%2Fthread%2F90f85b72b92f7c31%3F#doc_bb82d287a1fefbbc

  Cheers,
  Mikael Grev

  Posted by: mikaelgrev on May 13, 2007 at 02:33 PM

• I propose the following (much shorter) syntax:
  a) for read-only properties:

  public String name {
  return fname;
  }

  private String fname;

  
  b) for read-write properties:

  public String name
  get fname;
  set(String newName) fname = newName;

  public String address
  get {
  return faddress;
  }
  set(String newAddress) {
  faddress = newAddress;
  notifyAddressChange();
  }

  private String faddress;

  
  I don't think write-only properties make any sense.

  Posted by: boris_kolar on May 14, 2007 at 03:30 AM

• I don't think writing setter getter is such a big problem. Eclipse or even any new IDE will generate it so why to change it? Adding new complexity will not make us more productive, It is always better to have lengthy readable code then shorter clumsy code.

  Posted by: amitpagrawal on May 14, 2007 at 07:34 AM

• Hi Remy,
  First, I'd like to congratulate to you for this nice work
  But I have question : In you doc about accessing Property object of an Class you introduce the keyword #
  Why ? In fact, you extend the class Class with the method getProperty().
  I do not understant this two ways to get the same object
  For me the # keyword is not very useful but maybe it's an compilation optimisation?

  Olivier PARNIERE
  

  Posted by: oparnier on May 14, 2007 at 08:14 AM

• This looks really cool, I think the language you are using needs work.
  I think this syntax would be much easier on a developer...
  public property [options] name Type();
  so...
  public class MyBean {
  public property String name1; // read-write
  public property get set String name5; // same as above
  public property get String name2; // read-only
  public property set String name3; // write-only
  public property bound String name4; // bound

  public property get String name6{ return "hello"; }; // read-only
  public property set String name7(String name) { }; // write-only
  }

  I would also enforce an implied annotation (Property??? ick, your job to name it, and possibly many: IE- BoundProperty, ImmutableProperty, etc...)...
  so, your "real" property, would be old style with an annotation.
  That would be much cleaner, and provide the same thing.
  OR
  I would much rather see...
  public class MyBean {
  @Property
  public String name1; // read-write
  @Property( Property.READ_WRITE )
  public String name5; // same as above
  @Property( Property.READ_ONLY )
  public property get String name2; // read-only
  @Property( Property.WRITE_ONLY )
  public property set String name3; // write-only
  @Property( Property.BOUND )
  public property bound String name4; // bound

  @Property( Property.READ_ONLY )
  public property get String name6{ return "hello"; }; // read-only
  @Property( Property.WRITE_ONLY )
  public property set String name7(String name) { }; // write-only
  }
  and let the compiler do the rest for us... but that means allowing the compiler to change classes based on the annotations they have on them.

  Todd_Musheno@yahoo.com

  Posted by: musheno on May 14, 2007 at 12:46 PM

• Rémi,

  Very nice work I like the spec, and I don't even mind the #. It's very clear and there is little room for abuse. Does this kind of change effect Serialization? Are property objects themselves serialisable? And well, the "Property Class" has properties. Wouldn't that lead to infinite recursion if you tried to serialize it?

  Also is it a syntax error to declare a method String getName() if there is a property name? Auto generated methods would look like get$name() right?

  I'm defiantly going to try this out when it gets put in KSL.

  Posted by: aberrant on May 14, 2007 at 01:50 PM

• "
  - Don't aim people with a weapon, it's bad and can lead to disastrous results
  - It is perfect. We all know how to handle a weapon. Moreover, next generation weapons will display if they are loaded or not. No risk of confusion.
  "

  I am talking about a long time coding horror experience and you are arguing about typing habits and key position. They should not have a greater weight over what can hurt us until the end.
  Having an IDE showing the status does not change anything to my points. Referencing an instance will lead to unpredictable results in time, illogical errors at runtime, ... Did you ever suffered autoboxing runtime errors? This would lead to the same, or even worse if we combinate this with autoboxing. I certainly do not want anything of this nightmare.

  What is meant to be different should be different.
  Not only it is easier to teach, but it also removes confusion and helps in maintaining legacy code. Confusion as non-identifiable code is our enemy.

  Remi: i did not see any reference to vetoable setter. How would you handle them?
  

  Posted by: pepe on May 14, 2007 at 02:02 PM

• What is the great benefit of adding a property keyword to Java? The only reason I can grasp from the proposal (besides saving keystrokes) is to gain assignment overloading (which seems to be even worse than common operator overloading) and type-safe property access to overcome the bad design called Bean-style programming. I'd favor an object-oriented approach. I'm sure, it would be possible to find a way to make it work for old and new style until applications also are refactored to the new style. For example, as proposed in the Bean Properties Project.

  Posted by: stefan_schulz on May 16, 2007 at 02:48 AM

• Stefan,
  Bean-properties is exactly the kind of functionality we need. That isn't all that is needed for properties to be adopted on a wide base though. We need some syntactic sugar and keyword to make this both popular and used/supported. The syntax is for the popularity and the property keyword is so that this will be supported by tools. Without these two things there is no need to have properties at all IMO.

  Cheers,
  Mikael Grev

  Posted by: mikaelgrev on May 16, 2007 at 05:23 AM

• So you want Java to support properties to make applications change to a better design? Interesting. Still, not very convincing.
  Especially overloading assignment smells. Why not using methods instead, dropping the get/set prefixes (as I don't think they are necessary for properties). E.g.:

  author.forename("John F.");
  String forename = author.forename();

  Which would leave author.forename for accessing the property.

  Posted by: stefan_schulz on May 16, 2007 at 11:19 AM

• Stefan,
  Yes, that will work for me. I'm not too picky when it comes to syntax. I'll learn and adapt. I have been bitten by autoboxing a few times so the simple "." notation that look like an assignment but can throw exceptions is not that good. "#", "->" or "()" is fine with me. I'm use-case driven and just want this to solve all the problems. See my latest post at Javalobby for the long version of what I think is important.

  Cheers,
  Mikael

  Posted by: mikaelgrev on May 16, 2007 at 12:48 PM

• Will new property have compatibility with old setXxx and getXxx type property?
  Judging from the draft 3, it seems that it will not be able to use new property syntax for a framework that expect setXxx and getXxx like Struts.

  Posted by: naoki_kishida on May 18, 2007 at 07:04 AM

• The proposed syntax is inconsistent with existing Java, where modifiers are in front, not at the end. Write-only properties are misused in C# (used instead of methods) and I would recommend not to support them.
  One other issue I had with C# properties is that if an interface declares only a getter, the implementation class could not add a setter cleanly, i.e. you have to declare the getter as a part of the interface and the setter separately, which is ugly as hell.
  My proposal would be:

  public readonly property name { return name; };

  or:

  public readonly property name get { return name; };

  and for read/write properties there won't be a readonly modifier:

  public property email
  get { return name; }
  set(String value) { name = value; };
  

  Posted by: kolev on May 27, 2007 at 09:03 PM

This work is licensed under a Creative Commons License.