-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
the setter method got letter case error... #504
Comments
👤 awanabe 🕗 Nov 24, 2012 at 09:07 UTC What steps will reproduce the problem?
What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below. |
👤 reinierz 🕗 Mar 11, 2013 at 19:55 UTC According to the bean spec, spring is in error, so you should probably file this with them. Actually, the bean spec says that, to maintain all-caps properties, the rule is: If both the first and second letter of the camelcased (i.e. from setter/getter method name) property name are uppercase, then DO NOT lowercase the first letter to arrive at the property name. If you take that to its logical conclusion with capitalizing, which the beanspec never actually talks about, and for which there is no method in Introspector, then in your example: capitalize("aBoo") would seemingly have to become getABoo(), but then if you were to decapitalize this, then according to the very same beanspec, you end up with 'ABoo' as property name. That means the beanspec's own rules aren't idempotent; taking any property name, capitalizing it, and decapitalizing it does not necessary result in the original string. I'm guessing spring figured out this screwup in the spec and 'fixed it' by basically not changing the casing of anything if the second letter is a capital. However, we are of the opinion that this alternate rule ("If the second letter is a capital, then, whether capitalizing or decapitalizing, don't change anything") is just crazy and not at all logical. It's also a spring invention (I can see why they did it, but, still, an invention). Basically, the bean spec is broken in this regard and lombok and spring have chosen different tactics to solve the discrepancy. We could try and be more compatible with spring, but then we'd be breaking backwards compatibility. Not to mention we're joining this train into crazytown. If you can find anything from official oracle spec that shows this silly behaviour is in fact what you are supposed to do we'll re-open this issue. Also, if there are other major tools that work the same way and lombok is really the only exception, that too would be reason to re-open this issue. |
End of migration |
… @ToString.Exclude/Include projectlombok#504
added new test classes from lombok make code generation for equals and hashCode more lombok like
Duplicate of #2693 |
Migrated from Google Code (issue 431)
The text was updated successfully, but these errors were encountered: