Java SE 11 : Moving Java Forward – Part 2 : Properties accessor

This serie of article presents how, in my opinion, the java language should evolve to keep being a top choice language. It also presents some features, sometimes already existing in other language, that I love but that cannot (or should never) be part of Java, for some reasons that I will explain. I would really love to transform some of those ideas into JSRs one day.

Accessing fields of an object through a transparent accessor is definitely THE feature I miss in Java.

What is it?

In Java, we use to use getters and setters which allow to access a property of an object. I will not speak of the benefits of having getters and setters instead of having public fields, I assume that you are aware of that… In other languages (C#, AS3, …), you can declare explicitly the getter and setter of a property and use them as if you were using a public property. My favorite syntax is the one ActionScript3 :

//Object Declaration
public class MyObject {
       private var _myProperty:String;

       public function get myProperty():String {
                return _myProperty;

       public function set myProperty(value:String):void {
              _myProperty = value;

       public function get firstLetter():String {
               return _myProperty.substr(0,1);

var o:MyObject = new MyObject();
o.myProperty = "A value"; //Set the property using the setter
trace(o.myProperty); //Print the value return by the getter
trace(o.firstLetter); //Print 'A'

The Java syntax suggestion

Since I consider the ActionScript 3 syntax very convenient, I think that the Java syntax should be very similar. It would require to add new modifiers : get and set.

public class MyObject

    private String _name;

    public get String name() {
        return name;

    public set void name(String name) { = name;

MyObject o = new MyObject(); = "My name";
System.out.println("print entity : " +;


  • Using an accessor is transparent. The encapsulation is made implicit. The caller does not know if it is calling a public variable or an accessor.
  • Better OO style programming : From an external class point of vue, an object now really has public methods and properties, while before it was only public method.
  • Refactoring the code to change all direct accesses to the fields of the object is a peace of cake, you just have to change the class concerned, not all read/write calls.
  • No need anymore to have the JavaBean conventions on getter and setter. Some librairies relied on the fact that accessors of myProperty are called [get|is|set]MyProperty. Now the accesors are no more defined by convention but by contract. We can have a method on the class Class which retrieve the accessor (getGetters(), getSetters()). Once again, a big OOP enhancement.


  • It would require to change the naming convention of the object fields since the method and the property could have the same name. There’s no doubt that the JVM could allow that the property and the method have the same name, it is more a readability issue.

Implementation and Issues

Implementing this feature would require to add two new keywords (get and set) to the Java language. That is a bad things for the retro-compatibility but that is not a big problem. It would need to use the “-source”  command-line option as it has been done before when the assert keyword has been added in Java 1.4.

This change would also require to modify the JVM specification, and so the java compiler, to add the two new modifiers. Those two new modifiers are needed in the class file in order to identify, using the reflection, the getters and setters of a class.


I believe that this feature would be an awesome improvement of the Java language. As all major improvements, it requires a lot of work. If one day I feel ready enough to submit a JSR, that will definitely be this one!

This entry was posted in Uncategorized. Bookmark the permalink.

3 thoughts on “Java SE 11 : Moving Java Forward – Part 2 : Properties accessor

  1. Why not just do what groovy does and allow getters and setters to be used like fields. So .getName() and be accessed as .name and the compiler will work it out.

    I’m not sure this is such an improvement though since you still have the code bloat of actually declaring the setters. An annotation on fields to mark them as properties would be better as per Lombok.

  2. I don’t like the groovy solution since it relies on a naming convention. It is just a syntactic sugar. Actually Groovy does not have the choice since the JVM does not allow it…

    Lombok generates code based on the annotation. Again, that is just a syntactic sugar for those who are lazy to write getter and setter. Furthermore, I don’t think that generating code during the compilation is an option for the Java standard.

    The two solutions you exposed are nice work around, but, to me, it is not a long term solution. The properties of an object has to be declared by contract, in the class file. No more naming conventions! :D

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>