[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2268) JDK Bug 5062759 Breaks Hibernate Introspection

[Alex Pires de Camargo (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31855#action_31855 ] 

Alex Pires de Camargo commented on HHH-2268:
--------------------------------------------

Its possible to do something to deal with non-deterministic behavior of Class#getDeclaredMethods()? because error can appear or not depending on things like a method used after ou before another in any point of code.

See this code:

public class DeclaredMethodsTest {

	public static void main(String[] args) throws ParseException {

		Method[] methods = Calendar.class.getDeclaredMethods();
		for (int i = 0; i < methods.length; i++) {
			String name = methods[i].getName();
			if (name.matches(".*Lenient.*")) {
				System.out.println(name);
			}
		}		
		Calendar.getInstance().setLenient(false);
	}
}

The simple comment of setLenient line changes the order that method are returned by getDeclaredMethods and printed. On Hibernate this generates errors dificult to find.

> JDK Bug 5062759 Breaks Hibernate Introspection
> ----------------------------------------------
>
>                 Key: HHH-2268
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2268
>             Project: Hibernate Core
>          Issue Type: Patch
>          Components: core
>    Affects Versions: 3.2.0.ga
>         Environment: n/a
>            Reporter: James Olsen
>            Assignee: Steve Ebersole
>             Fix For: 4.x
>
>         Attachments: patch.txt
>
>
> Class#getDeclaredMethods() returns inherited methods - see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5062759
> This can result in Hibernate failing to determine the correct return type for a method that overrides an inherited method and further constrains the return type.  Behaviour is nondeterministic as it depends on the order of the returned array, e.g.
>  public volatile java.lang.Object com.xxx.impl.CPMImpl.getId() // from interface implemented by superclass
>  public volatile com.xxx.api.CPMId com.xxx.impl.CPMImpl.getId() // from superclass implementation
>  public com.xxx.impl.CPMIdImpl com.xxx.impl.CPMImpl.getId() // local
> The patch checks if the method is 'volatile' and ignores it if it is.

-- 
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