[hibernate-issues] [Hibernate-JIRA] Commented: (BVAL-41) Support BeanInfo implementation to receive property names

[ocpsoft (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/BVAL-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32716#action_32716 ] 

ocpsoft commented on BVAL-41:
-----------------------------

Java naming conventions prefer "isBoolean()" and "hasBoolean()"  ... it would be nice if hibernate also supported these.

org.hibernate.validation.util.ReflectionHelper.containsMember(Class<?>, String)
...
		try {
			clazz.getMethod( "has" + property.substring( 0, 1 ).toUpperCase() + property.substring( 1 ) );
			return true;
		}
		catch ( NoSuchMethodException e ) {
			// ignore
		}

		try {
			clazz.getMethod( "is" + property.substring( 0, 1 ).toUpperCase() + property.substring( 1 ) );
			return true;
		}
		catch ( NoSuchMethodException e ) {
			// ignore
		}
...

> Support BeanInfo implementation to receive property names
> ---------------------------------------------------------
>
>                 Key: BVAL-41
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-41
>             Project: Bean Validation
>          Issue Type: Improvement
>          Components: spec-general
>            Reporter: Emmanuel Bernard
>
> Michael
> - Why section 3.1.2 requires properties to follow the JavaBeans naming
> convention? In many non-English speaking countries (and projects with
> ridiculous managers/code standards), other prefixes are used and
> proper BeanInfo implementations are supplied. Although it is not
> pretty at all, since they are following the JavaBean spec, I don't
> think Bean Validation shouldn't work out-of-the-box for them;
> Emmanuel
> I reused the Java Persistence wording actually and I explicitly reference
> the Introspector class. Do people think we should be more cautious here?
> Speaking for France, I've never seen a project bothering about get/is/set
> and BeanInfo. People happily used frenglish: getCafeAuLait()
> Actually I've never seen anybody from the server side bothering about
> BeanInfos ;)
> Michael
> I've got an interesting case for that one: in some JVM languages,
> another standard is used to represent properties. Let's take, for
> instance, Scala.
> In Scala, one could write a bean like:
> @BeanInfo
> class Person(var id : Long, var name : String, var surname : String)
> Scala already maps vars as properties creating a private var, a public
> getter method named like the var and a setter like var_=. Something
> like:
> private var _id : Long
> def id = _id
> def id_=(newId: Long) = _id = newId
> that would translate to Java methods id and id_$eq (since = cannot be
> used in method names). So, when one use @BeanInfo, a proper BeanInfo
> subclass is generated by the compiler providing that mapping.
> Given how popular JVM languages are getting, not following a spec in
> another one and causing property support in those languages to fail to
> work doesn't seem nice.
> BTW, please let the JPA EG know about his as well.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira