Page 1 of 1
About Question enthuware.oce-jpad.v6.2.559 :
Posted: Sat Dec 24, 2016 1:52 pm
by 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).
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Sun Dec 25, 2016 1:00 pm
by 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.
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Sun Dec 25, 2016 6:29 pm
by 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?
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Mon Dec 26, 2016 12:47 am
by admin
johnlong wrote: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.
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Wed Dec 28, 2016 7:50 am
by johnlong
You mean it is convention, but it is not recommendation?
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Thu Dec 29, 2016 2:06 am
by 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.
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Thu Dec 29, 2016 11:41 am
by 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)
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Thu Dec 29, 2016 12:42 pm
by admin
Not sure what is your point but nowhere does it talk about the field/variable name.
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Thu Dec 29, 2016 2:54 pm
by 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.
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Thu Dec 29, 2016 10:15 pm
by 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.
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Wed Jan 04, 2017 11:04 am
by johnlong
If property is not field, then what is it?
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Wed Jan 04, 2017 11:25 am
by admin
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Sun Nov 29, 2020 12:22 pm
by 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.
Re: About Question enthuware.oce-jpad.v6.2.559 :
Posted: Mon Nov 30, 2020 2:56 am
by 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.