Proposal: Concise declaration of JavaBeans properties

[Joe Darcy]

Yes, this proposal is long overdue and will not be considered for JDK 7.

-Joe

Reinier Zwitserloot wrote:
> You're 2.5 months too late with a proposal. Also, I recall similar  
> proposals having been suggested during the official proposal period  
> (which was the month of march). They did not make the shortlist, for  
> some reason.
> 
>   --Reinier Zwitserloot
> 
> 
> 
> On 2009/25/06, at 12:36, Jan Kroken wrote:
> 
>>    PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0
>>
>>    AUTHOR(S): Jan Kroken
>>
>>    OVERVIEW
>>
>>    Add syntactic sugar to reduce the amount of boilerplate code needed
>>    to adhere to the JavaBeans specification.
>>
>>    FEATURE SUMMARY: Should be suitable as a summary in a language  
>> tutorial.
>>
>>    Add a new field modifier, that will generate the neccessary  
>> JavaBeans
>>    methods at compile time.
>>
>>    MAJOR ADVANTAGE:
>>
>>    Significantly reduce the amount of boilerplate code in Java  
>> source code.
>>
>>    MAJOR BENEFIT:
>>
>>    Reducing the amount of boilerplate code will:
>>    - increase readability
>>    - reduce the amount of possible programming errors
>>    - reduce implementation and maintenance cost
>>
>>    MAJOR DISADVANTAGE:
>>
>>    The proposal will increase the complexity of the language.  
>> Methods will
>>    exist without having an explicit declaration, which may confuse
>> programmers
>>    not familiar with the feature.
>>
>>    ALTERNATIVES:
>>
>>    The same feature can possibly be implemented using annotations and
>>    runtime code generation.
>>
>>    EXAMPLES
>>
>>    SIMPLE EXAMPLE:
>>
>>    A value class in the current java language:
>>
>>    public class MyValueObject {
>>      private Type1 field1;
>>      private Type2 field2;
>>
>>      public void setField1(Type1 field1) {
>>          this.field1 = field1;
>>      }
>>
>>      public Type1 getField1() {
>>          return field1;
>>      }
>>
>>      public Type2 getField2() {
>>          return field2;
>>      }
>>    }
>>
>>    The same value with the proposed language modification
>>
>>    public class MyValueObject {
>>      private :exposed(rw) Type1 field1;
>>      private :exposed(r) Type2 field2;
>>    }
>>
>>    Note that :exposed is not the suggested syntax modification.
>>    The exact notation should be decided upon by the working group.
>>
>>    In the above example, :exposed(rw) will expose the value both
>>    through a getter and setter, while :exposed(r) will expose the
>>    value only through a getter.
>>
>>    ADVANCED EXAMPLE:
>>
>>    Any explicit declarations of a JavaBeans method in the current  
>> class
>>    will ensure that the method is not generated based on the field
>>    declaration.
>>
>>    For instance, the class
>>
>>    public class MyValueObject {
>>      private :exposed(rw) Type1 field1;
>>      private :exposed(r) Type2 field2;
>>
>>      public void setField1(Type1 field1) {
>>          if(field1 == null) {
>>              throw new NullPointerException();
>>          }
>>          this.field1 = field1;
>>      }
>>    }
>>
>>    will be equivalent to
>>
>>    public class MyValueObject {
>>      private Type1 field1;
>>      private Type2 field2;
>>
>>      public void setField1(Type1 field1) {
>>          if(field1 == null) {
>>              throw new NullPointerException();
>>          }
>>          this.field1 = field1;
>>      }
>>
>>      public Type1 getField1() {
>>          return field1;
>>      }
>>
>>      public Type2 getField2() {
>>          return field2;
>>      }
>>    }
>>
>>    DETAILS
>>
>>    SPECIFICATION:
>>
>>    A modifier, currently represented by :exposed(specification),
>>    should be added to class fields.
>>
>>    The modifier has two optional arguments, r (read) and w (write).
>>    a read argument specifies that the compiler should generate
>>    public JavaBeans read methods for the field. The write argument
>>    specifies that the compiler should generate a public JavaBeans
>>    set method for the field.
>>
>>    If the field is a boolean field, both a getField and a isField
>>    method will be generated. If one of those are declared in the
>>    current class, none will be generated. This is to avoid a loophole
>>    where a transformation is added to one of those, while the field
>>    is accidentally made available through the other.
>>
>>    if no arguments are provided, both read and write methods will
>>    be generated.
>>
>>    Any explicit declarations of a JavaBeans method in the current  
>> class
>>    will ensure that the method is not generated based on the field
>>    declaration.
>>
>>    If a field is declared as an exposed, and there is a conflict with
>>    JavaBeans methods implemented in a superclass, the JavaBeans  
>> methods
>>    will be generated, and override the ones declared in the  
>> superclass.
>>
>>    The added field modifier should be chosen so it does not conflict
>>    with any existing Java source code.
>>
>>    The change would be implemented as desugaring at compile time. The
>>    class file format or type system will not be affected.
>>
>>    The effect this change will have on stack trace information and
>>    debugging information has not been analyzed.
>>
>>
>>    TESTING:
>>
>>    It will be possible to create test code with a full coverage of all
>>    variants.
>>
>>    LIBRARY SUPPORT:
>>
>>    There is no need for library support.
>>
>>    REFLECTIVE APIS:
>>
>>    This change will not require changes to the reflection apis.
>>
>>    OTHER CHANGES:
>>
>>    The only component that needs to be modified is the compiler.
>>
>>    MIGRATION: Sketch how a code base could be converted, manually or
>> automatically, to use the new feature.
>>
>>    A class could be modified through a series of transformations:
>>
>>    if there is a setter that matches the JavaBeans specification for a
>>    field, and the setter does not contain any other operations than
>> assigning
>>    the field to the passed arguemnt, then the setter can be removed,  
>> and
>>    the modifier :exposed(w) be added to the field declaration.
>>
>>    if there is a getter that matches the JavaBeans specification, the
>> getter
>>    only returns the field value without performing any other  
>> operations,
>> and
>>    there is not another getter not complying with these criteria, the
>>    getter(s) can be removed, and the modifier :exposed(r) be added  
>> to the
>>    field declaration.
>>
>>    redundant occurences of :exposed(r) or :exposed(w) in one field
>>    declaration should be removed.
>>
>>    If a field declaration has both an :exposed(r) and an :exposed(w)
>>    modifier, both should be removed and replaced with a modifier
>>    :exposed.
>>
>>
>>    COMPATIBILITY
>>
>>    BREAKING CHANGES:
>>
>>    No existing java programs will break. However, parsers, compilers  
>> and
>>    source analyzing applications for the java language will break,  
>> and have
>>    to be modified.
>>
>>    EXISTING PROGRAMS:
>>
>>    There will be no changes in behaviour for existing programs,  
>> neither
>>    class files nor programs compiled from source.
>>
>>    REFERENCES
>>
>>    EXISTING BUGS:
>>
>>    URL FOR PROTOTYPE (optional):
>>
>>    No prototype at this time.
>>
> 
>