New Java feature

Does anyone know where to submit a language feature request? I have an idea for a feature, but don’t know where to submit it. Here is the feature. Let me know what you think.

Use annotations to declare private fields as properties. The compiler would detect this and:

  1. allow direct assignment to and reading of the field.
  2. or if a get/set is defined for the field it would automatically call the get/set.

To the developer using the class there would be no difference. You just use normal operations as if the field was public. Also the compiler would only call a get or set if one is defined, otherwise direct assignment would be used.

Advantages:

  1. Remove overhead of a method when it is not necessary while maintaining encapsulation
  2. Allow more natural use of fields in any type of equation
  3. No more arguments over public versus private :slight_smile:

public class Foo {
  //no set allowed, only get
  @readonlyproperty
  private int id;

  //can set or get
  @property
  private float cost;
}

public class Bar() {
  public void useFoo(Foo foo) {
    int id = foo.id;
    float tax = 0.10 * foo.cost;
    foo.cost = foo.cost + tax;
  }
}

Later you could change Foo with no need to change Bar.


public class Foo {
  //no set allowed, only get
  @readonlyproperty
  private int id;

  //can set or get
  @property
  private float cost;

  public float getCost() {
    float result = currencyConversionOut(cost);
    return result;
  }
  public void setCost(float cost) {
    this.cost = currencyConversionIn(cost);
  }
}

Post a bug/rfe here:

http://bugreport.sun.com/bugreport/

The description above makes it sounds like:

a) It wouldn’t be very different to just making the field public (and final for read only - though you could change it within the class) in the case of no gets/set.

b) Hard to read the client code when you’re not sure whats happening with the field access that looks like any other field access.

c) Could be implemented without a change to the language using one of the AOP frameworks.

Kev

Thanks.

That is what most people do. They don’t want to deal with making all those getters and setters, so they just make fields public. This would allow the fields to be made private and allow future changes that add a getter and/or setter without changes to client code. Now if you just make it public you break all client code if later you want to make it private because you thought of an operation that you need.

I would disagree with this. Client code would be easier to read since it would not be cluttered with tons of unnecessary method calls.

True, but then that would add a library dependency.

Thanks for the comments.

I do not think an OO language’s syntax should encourage the use of accessors and mutators. Despite its inflammatory title, this article provides an excellent overview of the problems that arise from indiscriminate use of accessors and mutators. http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html.

My experience aligns with the author’s observations: using accessors and mutators leads to “pull” models of programming, which are very difficult to maintain. Turning the design inside out, to a “push” model, yields clearer, more decentralized code, which is easier to maintain. This is especially true with wise use of design patterns. Of course, one could always throw OO design theory out the window and use getters and setters everywhere, but then shouldn’t we all just be using C++ or C# at that point? :wink:

Who are “most people”?

Having “properties” is identical to making the field public except for the getter/setter thing. Just make it private and have getters/setters. What if you want to synchronize that field later? Then you need to write getters/setters anyways.

C# has something sort of like this. It’s not a horrible feature, but I think it should at least use different syntax. Instead of “myClass.myVariable = 5”, it should be something like “myClass->myVariable = 5”. Why? So that you know you’re using a “property” instead of a variable. And you should automatically have to define getters/setters for them. It could be something like Java beans except actually useful.

These properties could then be public, private, or whatever. It would really just be a way of combining the variable with the getters/setters, which isn’t such a bad thing for alot of variables.

If you do post an rfe, please post a link to it so that people can vote for it or against it.

I am greatly opposed to your plan as it is stated, though I wouldn’t mind having something with the other syntax.

Getters/setters may be “bad” programming practice, but there are instances where they are perfectly reasonable. For instance, JComponents allow to get/set background color, opacity, etc. These are all fine because you’re just changing parameters of how a class is operating. It’s using getters/setters to send information around your code that causes a problem.

i think this feature is present in Actionscript and C#. is this possible?

No it is not identical to public fields. That is the point. This gives you the ability to have private fields without the code bloat of calling getters and setters. The compiler still handles various tasks behind the scenes. Since most get/set operations are simple return/assignment statements, this would allow you to skip this step. Then later if a getter or setter was required it could be added without affecting client code. That is the whole point behind encapsulation. Hide the details from the client. This will give you the best of both worlds. You can enable operations anytime as required, but you don’t need to impliment redundant code.

Yes this is what C# and I think VB does.

Some others have thought it’d be a good idea before:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6350740
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6347784
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4228585

The last one having the resolution. So far looks like it’s a maybe for Java 7?

Probably best not to post another duplicate. Seems to be quite a split opinion on the bugs too, still thinking about here. I’d be a bit worried about changing a direct member access into a method later on if the member could still be accessed directly by private access (or even protected/default). Seems like a recipe for spagehtti to me.

Kev

dont really like this idea too :-.

PS: One change I would like is to be able to add property/attribute to interfaces , so get/set wont be needed anymore when using interfaces and java will be a litttle nearer to multiple inheritance.

What I want is, to be able to declare variables in interfaces.

And then to specify public/protected/private read/write on them.

Preferably inside { } scope brackets.

But then, what I really want is structs and not-null and const declarations too.

Cas :slight_smile:

I’m still confused at the why of all this. ???

What I really want is all the power of Lisp but with Java. … then I remembered that we still have Lisp. Anyone want to get Sun to buy into LispGaming.org? :wink:

Jython. This language is going to explode at the end of the year when the Jython devs incorporate the same compiler optimizations Nutter did with JRuby and all of a sudden Jython is twice as fast as CPython.

Damn straight on that. The lack of those features is the main thing that commonly forces various trade-offs between being fast, OO, readable, and safe, and especially in games (though also in simulation), the choice that has to be made is to take fast code over good code.

Of course, none of it is never going to happen, it’s all been ruled against many times on the basis (IMO, at least) that we’re too likely to abuse any and all new language features to be given the privilege to do so. We can dream, though.

FWIW, I’d be for C# style getters and setters, it seems to me like a useful feature that considerably reduces the amount of useless boilerplate code we write (or in far too many cases, are too lazy to write, and merely make variables public instead).

Just so you guys know, Eclipse can create getters/setters for you. You have to right click on the variable declaration and pick some option from the menu (can’t remember which one). The only problem with it is that the comments never seem to be quite adequate.

Yea I create all my getters and setters with eclipse.
What I would like to see is a Jcanvas or a heavy internal frame.

Can’t you write a plugin for your ide that

  • hides getter and setter methods (from view)
  • processes @property(alike source->generate getters and setters) annotation before compilephase

public class Adress {

  @property
  private String number

  @property
  private Street street;

  @property
  private City city;

}

Offcourse if you add JPA, JAXB and some other annotations to it I’m not sure if you gained a hell of a lot.

//edit:
If nessesary you can add parameters to the annotation to make the setter protected, add comments or something.


@property(
 setterAccess=Protected,
 setterComment="Set's the supplied Sting as streetname for this Address",
 setterCommentParam="A non-null, non empty String"
)

You might want to nest annotations or do something else fancy.

//edit2:

To note that this doesn’t require a language change, doesn’t break backwards compatibility it only adds a useless annotation for the rest of the world to your classes.

All just looks like ugly kludges to me.

Why not just allow the definition of instance variables or whatever they’re called these days in interfaces, and reference them with a dot? etc. etc. Getters and setters are just sort of daft. They’re not really OOP anyway so it’s hardly a big deal if by not using them you might one day have to do a tiny bit of refactoring to reference your fields through an interface with getters and setters. Meh.

Cas :slight_smile: