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

Reply via email to