You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Jonathan Feinberg (JIRA)" <ji...@apache.org> on 2007/06/06 18:29:25 UTC
[jira] Created: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
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: 1.0.0
Environment: Sun JDK 6.01
Reporter: Jonathan Feinberg
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.
[jira] Updated: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
Posted by "Marc Prud'hommeaux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marc Prud'hommeaux updated OPENJPA-251:
---------------------------------------
Fix Version/s: (was: 1.0.0)
1.0.1
Bumping to release 1.0.1 since 1.0.0 is being released.
> 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.1
>
> 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.
[jira] Resolved: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey resolved OPENJPA-251.
-------------------------------------
Resolution: Fixed
I was unable to reproduce this on my machine (presumably my VM uses the "expected" ordering), but I believe that I resolved the issue with changes to getDeclaredMethod().
> 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.2
>
> 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.
[jira] Commented: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501994 ]
Patrick Linskey commented on OPENJPA-251:
-----------------------------------------
>From a fix standpoint, it'd be nice to come up with a helper method that replaces the functionality of getDeclaredMethods(), but only lists the most-specific of duplicate covariant signatures (getMostSpecificDeclaredMethods() or something) so that we can use it throughout the codebase without duplication of the looping logic.
> 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.
[jira] Updated: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey updated OPENJPA-251:
------------------------------------
Fix Version/s: 1.1.0
> 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.2, 1.1.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.
[jira] Updated: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated OPENJPA-251:
----------------------------------
Affects Version/s: (was: 1.0.0)
0.9.7
Fix Version/s: 1.0.0
Thanks for the info, Jonathan. Seems like a good analysis and an easy fix.
Would you be able to provide a patch, and run the build script to verify it doesn't break anything?
> 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.
[jira] Updated: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
Posted by "Jonathan Feinberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Feinberg updated OPENJPA-251:
--------------------------------------
Attachment: weirdness.zip
The enclosed demonstration program gives the output
public java.lang.String weirdness.TheImplementation.getIt()
public java.lang.Object weirdness.TheImplementation.getIt()
on my machine, but gives the output
public java.lang.String weirdness.TheImplementation.getIt()
public java.lang.String weirdness.TheImplementation.getIt()
on a seemingly identical machine belonging to my colleague.
> 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: 1.0.0
> Environment: Sun JDK 6.01
> Reporter: Jonathan Feinberg
> 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.
[jira] Commented: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
Posted by "Abe White (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502016 ]
Abe White commented on OPENJPA-251:
-----------------------------------
The original implementation used Class.getDeclaredMethod. It was changed because this is significantly slower than using getDeclaredMethods() and searching through them, and this method is used a lot during deployment.
> 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.
[jira] Updated: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
Posted by "Albert Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Albert Lee updated OPENJPA-251:
-------------------------------
Fix Version/s: (was: 1.0.1)
1.0.2
Defer to next release.
> 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.2
>
> 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.
[jira] Commented: (OPENJPA-251)
org.apache.openjpa.enhance.Reflection.getDeclaredMethod() has undefined
behavior, leading to VM-dependent crashes
Posted by "Jonathan Feinberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503101 ]
Jonathan Feinberg commented on OPENJPA-251:
-------------------------------------------
Abe, I'd rather have the right answer slowly. :)
Out of curiosity, how much time does it add to deployment?
> 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.