Question

In Play Framework 1.x, the convention is to use public fields on Java classes. The justification for this is because of how the Play Properties Enhancers work as described here: http://www.playframework.org/documentation/1.2.4/model

In a nutshell, public fields are ‘ok’ because Play auto-generates setters and getters at runtime. That makes sense to me and there are other questions that cover that.

Play Framework 2.0 works very differently. There is no “Properties Simulation” capability. Maybe they are looking at adding this later but I could not find anything to suggest this. Without the properties simulation, the original justification for using all public fields is gone. The Play Framework 2.0 samples still use public fields though:
http://www.playframework.org/documentation/2.0/JavaEbean

Why are public fields still recommended for playframework 2.0? Is this just a habit of developers on the old version of play who created the samples or is there another reason why the use of public fields is still recommended in Play 2.0?

Answer 1

Looking in the documentation: https://github.com/playframework/Play20/wiki/JavaEbean, Play will generate missing accessors for us.

However they are caveats with this technique, the most will be that the ebean instrumentation won’t work on generate get/setter… and so problem might happen (transaction, …)

Here is the related quote:

Play has been designed to generate getter/setter automatically, to ensure compatibility with libraries that expect them to be available at runtime (ORM, Databinder, JSON Binder, etc). If Play detects any user-written getter/setter in the Model, it will not generate getter/setter in order to avoid any conflict.

Caveats:

(1) Because Ebean class enhancement occurs after compilation, do not expect Ebean-generated getter/setters to be available at compilation time. If you’d prefer to code with them directly, either add the getter/setters explicitly yourself, or ensure that your model classes are compiled before the remainder of your project, eg. by putting them in a separate subproject.

(2) Enhancement of direct Ebean field access (enabling lazy loading) is only applied to Java classes, not to Scala. Thus, direct field access from Scala source files (including standard Play 2 templates) does not invoke lazy loading, often resulting in empty (unpopulated) entity fields. To ensure the fields get populated, either (a) manually create getter/setters and call them instead, or (b) ensure the entity is fully populated before accessing the fields.

HTH