Properties in Java

Hans writes an excellent post on the use of bound properties, and how a simple property keyword that simulates getX/setX methods wouldn't buy him much.

Properties also have a difficult interaction with access control. Declaring a property to be publically readable but only package/protected/privately writeable would either be impossible or need some hacky syntax for the read v. write access level. This is not an improvement over getX/setX.

Now, since no-one is talking about VM support, properties would be implemented through translation to methods and fields. Obviously this makes them less amenable to reflection, but my main concern is this. We have an increasing list of language constructs implemented through translation: instance initializers, bridge methods, inner classes (and the calling convention for their constructors), enums. Specifying such translations in the JLS is rare because they are implementation details. (Notable exceptions: 15.9.3 implies the calling convention for anonymous classes and 8.9 has some info about enums.) We don't want to restrict the classes emitted by compilers except when it's essential for source and binary compatibility. (The binary representation of a class in 13.1 is rather loosely specified for this reason.) Clearly, a cross-compiler convention for representing properties would be necessary in the JLS, so no-one would ever be able to implement properties in a more lightweight fashion.

I must admit I do like the increased safety available in Stephen Colebourne's property proposal, though maybe you could get that with method references: (borrowing from the Javapolis whiteboards)
binder.bind(user, User.getFirstName.method);
binder.onChange(user, User.setFirstName.method, closure);

But overall, like Peter von der Ahé, I am moving away from properties.

Comments:

This is probably the best idea. Stop this crazy wave before the javabeans enthusiast take over command and we get into property hell. I really would love having properties in Java, but it is just not trivially doable with all the requirements in the javabeans field.

Posted by Fatih Coskun on January 10, 2007 at 02:00 AM PST #

How about annotations? private @Getter @Setter(AccessLevel.PROTECTED) int whatever; Where there are the 4 obvious access levels, and the default (for both annotations) is AccessLevel.PUBLIC The annotations cause getter/setters to be created as you'd expect them.

Posted by Reinier Zwitserloot on January 10, 2007 at 05:00 AM PST #

Pity the blog categorized my previous comment as spam, if you find it somewhere in the bin and think it's of any use ... In short, I do agree with "moving away from properties" and method referencing. The property stuff I'd rather see in IDEs.

Posted by Stefan Schulz on January 13, 2007 at 11:25 PM PST #

I quite like the idea of having some mechanism to access methods directly for complementing reflections (which also always needs textual reference to a methods name and signature) as a compile-time feature. One can access classes by .class, why not access a method by stating its signature followed by .method? E.g.:
String.valueOf(Object.class).method
Maybe somehow extendable for accessing fields, too, such as:
String.value.field
would return the field object. Only, the notation might be ambiguous though.
I would not wonder, if accessing method objects could not go hand in hand with the closure stuff somehow. Imagine using a method reference as parameter type defining the closure's signature.

When reading Stephen's proposal, the only thing I can see is providing a shortcut for saving to write OO code. Quite a big chunk of code, but still. This should not be the task of a new compiler construct and could be solved easily by any good IDE (even including maintenance aspects). But maybe I am missing something important here.

Posted by Stefan Schulz on February 01, 2007 at 07:11 AM PST #

I quite like the idea of having some mechanism to access methods directly for complementing reflections (which also always needs textual reference to a methods name and signature) as a compile-time feature. One can access classes by .class, why not access a method by stating its signature followed by .method? E.g.:
String.valueOf(Object.class).method
Maybe somehow extendable for accessing fields, too, such as:
String.value.field
would return the field object. Only, the notation might be ambiguous though.
I would not wonder, if accessing method objects could not go hand in hand with the closure stuff somehow. Imagine using a method reference as parameter type defining the closure's signature.

When reading Stephen's proposal, the only thing I can see is providing a shortcut for saving to write OO code. Quite a big chunk of code, but still. This should not be the task of a new compiler construct and could be solved easily by any good IDE (even including maintenance aspects). But maybe I am missing something important here.

Posted by Stefan Schulz on February 01, 2007 at 07:11 AM PST #

Post a Comment:
Comments are closed for this entry.
About

Alex Buckley is the Specification Lead for the Java language and JVM at Oracle.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds