About Question enthuware.oce-jpad.v6.2.559 :

[johnlong]

If a property based access is chosen for an entity class, the names of the fields do not have to correspond to the method names.

Could you please explain how names of the field will not correspond to method names (will not correspond to JavaBean conventions).

[admin]

Code: Select all

private int xxx;
public int getA(){
 return xxx;
}

Javabeans convention does not require field name to be same as the property name.

[johnlong]

field is "name"
setter and getter do not have to be "getName" and "setName"?
I think Javabeans would require exact naming as above, but JPA specifications are not required to be compliant. Correct?

[admin]

field is "name"
setter and getter do not have to be "getName" and "setName"?

Correct.

I think Javabeans would require exact naming as above, but JPA specifications are not required to be compliant. Correct?

Incorrect. Javabeans has no such rule on the naming of the field.

[johnlong]

You mean it is convention, but it is not recommendation?

[admin]

Javabeans conventions are conventions. And they don't impose any constraint on the name of the variable. So no, it is not an official convention. It is, however, considered a good programming practice (or recommendation, if you want to call it that:) ) to keep your variable name in line with the getter/setter names to avoid confusion.

Paul.

[johnlong]

JPA Specification 2.1 (Section 2.2) says :

It is required that the entity class follow the method signature conventions for JavaBeans read/write properties (as defined by the JavaBeans Introspector class) for persistent properties when property access is used.

In this case, for every persistent property property of type T of the entity, there is a getter method, getProperty, and setter method setProperty. For boolean properties, isProperty may be used as an alternative name for the getter method.
For single-valued persistent properties, these method signatures are:
• T getProperty()
• void setProperty(T t)

[admin]

Not sure what is your point but nowhere does it talk about the field/variable name.

[johnlong]

What about this sentence :

In this case, for every persistent property property of type T of the entity, there is a getter method, getProperty, and setter method setProperty.

[admin]

Yes, but property != variable/field.

As soon as a class gets a getX (and setX, if it is a mutable property), it is said to have a property named x. Irrespective of whether it has a variable/field named x or not.

[johnlong]

If property is not field, then what is it?

[admin]

See the first answer here: http://stackoverflow.com/questions/1011 ... ty-in-java

[johnlong]

Coming back to this discussion after almost 4 years

If a property based access is chosen for an entity class, the names of the fields do not have to correspond to the method names.

First of all, by definition the statement itself is contradictory - if you say property access it means that there are no fields in the Entity class, because "fields" are technically properties (promoted to properties from fields if you will by virtue of property accessor or/and mutator existense).

and again :
JPA Specification 2.1 (Section 2.2) says :

It is required that the entity class follow the method signature conventions for JavaBeans read/write properties (as defined by the JavaBeans Introspector class) for persistent properties when property access is used.

In this case, for every persistent property property of type T of the entity, there is a getter method, getProperty, and setter method setProperty. For boolean properties, isProperty may be used as an alternative name for the getter method.
For single-valued persistent properties, these method signatures are:
• T getProperty()
• void setProperty(T t)

And you are saying

property != variable/field.

and referring to Oracle glossary https://docs.oracle.com/javase/tutorial ... ary.html#P

property
Characteristics of an object that users can set, such as the color of a window.

Since you are referring to this definition, note it does not say here HOW 'characteristic of an object is set', i.e. as long as it is being set by user it is a property.

And you provided code example

Code: Select all

private int xxx;
public int getA(){
 return xxx;
}

Since Entity is not strictly (always) immutable object, and in that case the mutator (setYYY method) will be present, therefore xxx above is not (always) a field , it is a property.

Therefore, I believe the answer to this question is incorrect. Specifications clearly state that JavaBean conventions should be followed for property-based access.

[admin]

No, you are misintepreting.
>if you say property access it means that there are no fields in the Entity class
That's not what the explanation means. Property access simply means using the getter and setter methods. It does not mean there is no field. There may or may not be a field by the same name.

Yes, JavaBeans conventions for property are to be followed and they are being followed in this question and the explanation. Please go through it again.