United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6347784 RFE: Add a "property" keyword to avoid the need to invoke getters and setters
JDK-6347784 : RFE: Add a "property" keyword to avoid the need to invoke getters and setters

Details
Type:
Enhancement
Submit Date:
2005-11-09
Status:
Closed
Updated Date:
2010-04-04
Project Name:
JDK
Resolved Date:
2006-11-21
Component:
specification
OS:
solaris_2.5.1,linux,windows_xp
Sub-Component:
language
CPU:
x86
Priority:
P4
Resolution:
Duplicate
Affected Versions:
1.4.2,5.0
Fixed Versions:

Related Reports
Duplicate:
Duplicate:
Duplicate:

Sub Tasks

Description
A DESCRIPTION OF THE REQUEST :
I suggest that there be a keyword "property" in Java that, when applied to a class member field, has the following effect:

1.  A private field is created with the given name.

2.  If no getter and setter methods are defined for the property, then getter and setter methods with the access that was declared for the property are generated by the compiler.  If a getter and/or setter method is provided, then the access of those methods must match the access of the property, and no methods are generated by the compiler.

3.  Any reference to the property in an expression is compiled into an invocation of the getter method.

4.  Any use of the property as an lvalue is compiled into an invocation of the setter method.

Points 3 and 4 could be more general:  instead of checking for the presense of the "property" keyword, the compiler could simply compile references to an inaccessible member field as calls to an accessible getter method, if one exists, and compile assignments to an inaccessible member field as calls to an accessible setter method, if one exists.

I suggest that this feature not interact with the bean introspector, property editors, or other higher-level features of the Java Beans spec.

JUSTIFICATION :
The popularity of scripting languages such as EL suggests that people prefer to use property names to access properties rather than explicitly invoking getter and setter methods.  Certainly this:

aBean.foo = anotherBean.frob.something.random;

is a lot easier to read than this:

aBean.setFoo(anotherBean.getFrob().getSomething().getRandom());

I think that this suggestion, which would require changes to the compiler but not to the JVM, is consistent with the compiler-level changes introduced in Tiger.

                                    

Comments
EVALUATION

We may consider properties in Java SE 7.
                                     
2006-11-17



Hardware and Software, Engineered to Work Together