Concerning coding style of the example in the posting instructions

(This forum item was spawned from discussions in a private helpdesk ticket.)

I write with reference to the coding example in the posting instructions and many of your other examples posted in the forums. While I appreciate the recommended coding style as shown makes for convenient minimal examples and test cases, 
I contest that it breaks the rules for JPA2 entities on at least 2 counts.

Firstly, the posting instructions state: 

'Use a single Java file with one main class + static inner classes for entity / embeddable classes.'

The JPA2.0 final spect states:

'The entity class must be a top-level class.'

While it may be handy to have a single file using static inner classes for entities, compliant entity classes belong in separate files.

Secondly, in many forum posting examples, package private instance variables are used and then accessed by external clients without accessors. One example is in: Does ObjectDB support lazy loading?  which has initialisation of instance variables such as:

    A a = new A();
    a.list = new ArrayList<B>();  a.list.add(new B(1));     

    a.list.add(new B(2));    

The JPA2 spec explicitly forbids this:

'The persistent state of an entity is represented by instance variables, which may correspond to Java- Beans properties. An instance variable must be directly accessed only from within the methods of the entity by the entity instance itself. Instance variables must not be accessed by clients of the entity. The state of the entity is available to clients only through the entity’s methods—i.e., accessor methods (getter/ setter methods) or other business methods.'

While omitting accessors (getters and setters) may make for smaller test cases and examples, it is not a compliant coding style.

Webel

Your observation is correct and indeed the test case template uses some non standard JPA extensions (some of them are also supported by other JPA providers).

Unfortunately, a minimal runnable portable JPA program (which also requires an additional XML file) is less convenient in this context. The one class format is easier to read and more IDE portable.

However, regarding your second point, properties can be used and when using enhancement by a Java Agent even must be used, since ObjectDB may fail to handle direct access of such fields from other classes.