openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-251) org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined behavior, leading to VM-dependent crashes
Date Sun, 10 Jun 2007 01:15:25 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503137
] 

Patrick Linskey commented on OPENJPA-251:
-----------------------------------------

It was significant, due to the additional exceptions that were raised by getDeclaredMethod(),
which throws when it fails.

We should aim to have a solution that is both correct and fast, IMO. It shouldn't be that
hard to implement such a solution with appropriate use of a bit of caching. As ever, it's
unfortunate to need to add a cache, since that's one more memory resource to manage and synchronization
area to care about.

In fact, IIRC, a caching solution was marginally faster than the non-caching solution that
we ended up using.

> org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined behavior, leading
to VM-dependent crashes
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-251
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-251
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jpa
>    Affects Versions: 0.9.7
>         Environment: Sun JDK 6.01
>            Reporter: Jonathan Feinberg
>             Fix For: 1.0.0
>
>         Attachments: weirdness.zip
>
>
> Given 
> public interface A { Object getId(); }
> @Entity
> public class B implements A { 
>     @Id
>     public String getId() { return "foo"; } 
> }
> B.class.getDeclaredMethods() will include both "public java.lang.String B.getId()" and
"public java.lang.Object B.getId()". The order in which these two methods appear is NOT DEFINED!
Because org.apache.openjpa.enhance.Reflection.getDeclaredMethod()  returns the first matching
method, and because that method might well be the abstract one retuning Object, OpenJPA will
complain that it cannot persist an ID with a non-explicit strategy, and throw up.
> Class.getDeclaredMethod() (note singular, not plural) is defined to return the method
with the most specific return type under these circumstances, and should therefore be used.
Here's my implementation of Reflection.getDeclaredMethod:
> 	private static Method getDeclaredMethod(Class cls, String name, Class param)
> 	{
> 		Class[] params = param == null ? new Class[0] : new Class[] { param };
> 		try
> 		{
> 			return cls.getDeclaredMethod(name, params);
> 		}
> 		catch (Exception e)
> 		{
> 			return null;
> 		}
> 	}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message