A DESCRIPTION OF THE REQUEST :
A new keyword to the Java language that marks variables to have Getter/Setter to be automatically generated by the compiler.

JUSTIFICATION :
IDEs like eclipse have capability to autmatically generate getters and setters. But they bloat the code and make it harder to read. I wonder why this isn't
something the compiler could do at compile-time. Why not simply invent a
new keyword, e.g. "bean". Every bean is known to the compiler to have a
public Getter/Setter which can be overridden:

public Test
{
  // will generate:
  // String getBlah();
  // void setBlah(String s) { this.blah = s; }
  public bean String blah;

  // and can be overridden:

 public void setBlah(String s)
 {
    whatever();
    super.setBlah(s);
  }
}
(Incident Review ID: 232174) 
======================================================================

N/A

This is really a request for properties, and 6347784 expresses it better.
Posted Date : 2006-11-17 00:47:40.0

I agree this is a needed feature, we're using Javabeans every day and we have to write trivial getter/setter methods again and again. It's true that many IDEs generate getter/setter methods automatically, but the result is a code cluttering of getter/setter methods and when you change the type or class of a field you must change its getter/setter methods by hand.

 But I would suggest using metadata instead of a new keyword (this RFE would be present in JDK > 1.5, so we may use metadata to implement it). A Javabean could be written this way:

public class MyJavabean
{
  @property(Property.RW) private String propOne; // Read/Write Property
  @property(Property.R) private String propTwo;  // Read Property
  @property(Property.W) private String propThree;  // Write Property
}

 The compiler would generate automatically the methods:

getPropOne(),setPropOne(),getPropTwo,setPropThree.

  If you want to make a non-trivial getter o setter method, you can write your own and the compiler would not create it (the compiler only should generate a getter/setter method if it's not yet written).

 I think this solution:

 1) Would save time to programmers that build Javabeans

 2) Would avoid code clutter with getter/setter methods (the code would become cleaner)

 3) Would make easier the maintenance of the code, because the getter/setter methods would be better synchronized with their properties (if you write them and some time later you modify the property type, you needn't change getter/setter methods by hand).

 4) Would not have a big impact on the JVM or the libraries, because there wouldn't be changes at the bytecode level.

 5) Would not have a big impact on pre-1.6 source code, because there wouldn't be new keywords that break compilation of old code.

Your example is a little bit  bad, because Test does not have a super-class with a method setBlah(String). If something like this is done, then it should be done better.

public class Test {
  property  String value {
    get {
      return this.value;
    }
    set {
      assert value != null;
      this.value = value;
    }
  }
}
public class TestTest {
  public void blah() {
     Test test = new Test();
      test.value = "hello world";
      System.out.println(test.value);
  }
}

Then you also could create read-only/write-only properties.

Actually, if  properties were accessed using normal syntax, and you could change a field like "public String blah" to be a property without breaking binary compatibility, you would have even less stuff in your code.

You could just declare your class variables public, and then change them to be "properties" just like they always had a getter and setter.

For example, when you write you class, you could just write:

public class Test {
   public String blah;
   public int someInt;
}

Then you can add behavior/checking lazily, AS-NEEDED.  You decide you need value to be ranged checked after all, it could be done something like this:

public class Test {
   public String blah;
   @property public int someInt {
      set {
         if(value < 0) {
            value = 0;
         }
          someInt = 0;
      }
   }
}

I suppose it would break with the customary way to do things, so it probably won't be accepted. But it would:
1. Not be confusing - there aren't methods that are "magically showing up" even though they aren't in the sourcecode.
2. Eliminate the clutter for properties that don't actually do anything other than return or set their value (most of the properties that I write).
3. Has elegant, easy to read syntax for accessing the property, and for declaring the property when special code isn't needed (again, the majority of the properties that I write).

Some people will undoubtedly say that it's "confusing" to actually be calling a method using dot notation, but it's just different. No one uses dot notation for public properties anymore anyways - they use get/set.. And if I call getBlah(), and it does something other than return a value, well, that's pretty confusing anyways.

I like the "normal" syntax of C# (and Visual Basic) better - where you can say  test.bla and test.bla = "hello". This syntax also makes it easy to always access the getter/setter when using the variable inside the same class - right now you have to remember to use setBla("h") when accessing bla inside the Test class.

 Good Idea,,,,will improve efficeincy,,,,,,,,,,,,

(forgot)  With the property keyword, it would auto-generate unless an actual get/set method exists in the class.  This is (if I remember) how Delphi did it.

Why not a property modifier.  (e.g. property String blah;) that auto creates get/set and keeps the actual property private?

Let's also include the optional calling of propertyChange and vetoableChange.

I

I would vote for this feature as well (thought it's already can be implemented either with XDoclet or metadata, but seems like there is not default support yet). Paul Rivers idea seems to be most appealing one. Shouldn't break any backward compatibility whatsoever and compromise security...

It would be very useful!!!

This is much needed