why all fields are public in playframework?

Question

I'm still in a question why with playframework all fields in the classes should be public?

class A {
  public int a;
  public int b;
}

Some short explanation would be nice.

As I know if they are public then playframework uses generated invisible getters and setters for them? But if they are private then.. no getters and setters and then I should write them by myself ?

If it works such why then this is not Java anymore? Just too simple to understand I guess.

Versify

Please clarify what you mean by "why then this is not Java anymore?" – Lialiabilities

I believe that the OP might be referring to Java Coding Standards when he says "then it is not java anymore" – Congratulatory

I mean play changes the syntax of java simplifying it. Ok maybe be i was too loud to say such by it looks like tat. Acting as languages like Groovy for example, but groovy is not Java right?. I just believed that play use plain java. – Versify

Answer 1

The documentation provides an explanation for this. Play breaks a number of Java conventions with the idea of making the code more readable.

Basically, if you're just going to write:

class A {
    private int x;
    public int getX() { return x; }
    public void setX(int x) { this.x = x; }
}

why not have the framework generate the getters and setters for you (similar to C#)? Of course, since as noted in the documentation, the generated getters and setters are only available at runtime, the fields need to be declared public so the Java compiler won't raise an error if code outside the class accesses the variable.

Basically, this allows you to write:

class A {
    public int x;
}

class B {
     public void process() {
         A a = new A();
         a.x = 42;
     }
}

instead of:

class B {
     public void process() {
         A a = new A();
         a.setX(42);
     }
}

Better yet, if you need specific logic in the getter or setter you can add it in, e.g.:

class A {
    public int x;

    public void setX(int x) {
        if (x < 0) throw new IllegalArgumentException("x must be positive");
        this.x = x;
    } 
}

and still use this like so:

class B {
     public void process() {
         A a = new A();
         a.x = 42;
     }
 }

Whether or not this is the right way to handle things is, of course, a matter of opinion, but it's pretty common for Java developers to look for easier ways of writing all those boilerplate getters and setters (whatever it's relative merits, Groovy, Jython, JRuby, and Fantom all provide a mechanism for creating and accessing properties that results in syntax similar to what Play is achieving; Rhino at least provides a similar syntax for calling accessors and even Scala has a simpler mechanism to add accessors).

Leitao

Answer 2

The Play framework does lots of bytecode manipulation behind the scenes, to achieve a bit nicer syntax than would be possible with Java. So even though the code looks like Java, it has different semantics - using a field or calling a method does not always do what you think it does.

That's how Play has been designed. I haven't used it enough to give an opinion whether it's a good or bad thing, but it sure would be nice to have a list of all bytecode manipulation tricks that Play uses. I don't like using things which I don't understand (either I will learn them or avoid them). Would somebody know where they are listed (in addition to the source code)?

Mccaffrey

look for Enhancer. It pretty easy to understand. – Snyder

"..to achieve a bit nicer syntax than would be possible with Java." I don't understand what you are saying, are you implying that there is a "java code" that you can write for play which that code would not be "compiled" outside of the framework? – Chaucerian