Property name beginning with at least two uppercase characters has odd functionality in HQL

Description

When using annotated beans I found an instance where if you have a field name which then has a method name where that method name has 2 uppercase characters in a row, the Introspector.decapitalize() method will leave that property alone. This then causes HQL to fail when you try to reference the actual field name (as we try to keep with the bean property format). Example:

When referencing "Foo.bAr = " in HQL it will fail saying that "bAr" doesn't exist. In the logs, the field is actually referenced (by the AnnotationBinder) as "Foo.BAr"

I'm not sure if this is intended, and I understand why (given the concept behind the Introspector.decapitalize() functionality) it works this way. But if this is correct, then maybe there should be some documentation to at least indicate that this is how it works since it is not as simple as "capitalize/decapitalize the first letter."

Environment

None

Activity

Show:
Nikita Metzger
March 3, 2016, 1:00 PM
Edited

From the javadoc: Utility method to take a string and convert it to normal Java variable name capitalization.
In your case you apply this function to string constructed from the getter function, which is already modified(first letter of the property is capitalized) -> and Character.isUpperCase(name.charAt(1)) && Character.isUpperCase(name.charAt(0)) check will return true for aB and AB. So it is improper use of decapitalize function.
Using it in hibernate leads to the problem, that using Field access aB property and AB property are different, but for property access aB and AB are the same and only AB will be used. So I cannot use f.e. as in my case hClassCode property, I should use HClassCode which is bad practice for naming properties or hclassCode which is bad too for me.

It would be kind of you to re-open this issue.

Emmanuel Bernard
March 3, 2016, 1:32 PM

Can you give a full example of what you think we should do ? Some arbitrary annotation to differentiate them ?
If that's the case, it is one of those cases where the benefit / cost is too low to complexity the code just for this.

Nikita Metzger
March 3, 2016, 2:20 PM

I have currently no idea how to implement this, while there is modified value on the input, but annotation will be a solution.
If it is complex to you then at least it should be documented. I spent several hours trying to get the reason of exception Class has no such property although the class has this property. I think it will be correct assumption, that switching from field to property access shouldn't be broken due to field name.

Emmanuel Bernard
March 3, 2016, 3:17 PM

Yes we will try and improve the doc. I'll let look for the best approach.

Vlad Mihalcea
March 7, 2016, 12:50 PM

Updated the Hibernate 5.1 User Guide to include a note about this particular Java Bean spec behavior.

Assignee

Emmanuel Bernard

Reporter

Joshua Backfield

Labels

None

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

None

Pull Request

None

backportDecision

None

backportReEvaluate

None

Priority

Major
Configure