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."
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.
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.
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.
Yes we will try and improve the doc. I'll let look for the best approach.
Updated the Hibernate 5.1 User Guide to include a note about this particular Java Bean spec behavior.