... Hmm, or perhaps not a bug. Check out the Javadoc of
ConstructorProperties:
http://docs.oracle.com/javase/8/docs/api/java/beans/ConstructorProperties.html
An annotation on a constructor that shows how the parameters of that
constructor correspond to the constructed object's getter methods. For
example:
public class Point {
@ConstructorProperties({"x", "y"})
public Point(int x, int y) {
this.x = x;
this.y = y;
}
public int getX() {
return x;
}
public int getY() {
return y;
}
private final int x, y;
}
The annotation shows that the first parameter of the constructor can be
retrieved with the getX() method and the second with the getY() method.
Since parameter names are not in general available at runtime, without the
annotation there would be no way to know whether the parameters correspond
to getX() and getY() or the other way around.
Clearly, the intent of this annotation is to document a correlation between
constructor arguments and properties that *do have* getters.
I still agree that from a usability perspective, jOOQ shouldn't care too
much about the presence of such getters, but it's interesting to know the
contract of the actual annotation.
Cheers
Lukas
2015-01-09 8:10 GMT+01:00 Lukas Eder <[email protected]>:
> Thanks for reporting. This is a bug:
> https://github.com/jOOQ/jOOQ/issues/3911
>
> Best Regards,
> Lukas
>
> 2015-01-08 23:50 GMT+01:00 Robert DiFalco <[email protected]>:
>
>> I'm having a problem with Immutable POJOs. Well, not Immutable but with a
>> constructor annotated with @ConstuctorProperties. As I'm typing this I'm
>> wonder if getters can overwrite constructor names. But here's the issue I'm
>> having:
>>
>> I have a query returning one Numeric identity field and three Timestamp
>> fields. I have a POJO with a constructor like this:
>>
>> @ConstructorProperties({"id", "lastCalled", "lastAnswered",
>> "lastConnected"})
>> public FriendCallInfo(final Long id, final Timestamp lastCalled, final
>> Timestamp lastAnswered, final Timestamp lastConnected) {...}
>>
>> But this constructor only ever gets called with "id". What's interesting
>> is that I only have one getter on this class and it is for #getId. The
>> others don't have proper getters. That makes me wonder if the JOOQ
>> implementation is trying to be clever, so instead of just using my
>> ConstructorProperties it is also looking for fields and getters. Since it
>> finds one for #getId it ignores the other properties in my Constructor.
>>
>> Yes it looks like that is the case. If I rename #getId to something like
>> #getThisId then even the ID doesn't get sent to the constructor. It appears
>> as if the contract requires not only a properly annotated constructor but
>> also either a field or member with the same name as the constructor
>> property.
>>
>> Would you consider this a bug and if so should I create an issue for it?
>> It seems like I should be able to create a java object that has a well
>> defined constructor that may take a different form than the getters and
>> setters of the bean. I currently do it this way in JPA. But maybe that
>> breaks some contract.
>>
>> Thanks!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "jOOQ User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
