Similarly to ACT-1562, JPAEntityScanner.getIdMethod() cannot cope with the case where the annotated @Id method overrides a generic method in the superclass.
In this case, Class.getMethods() will return both the declared method with the declared return type and a bridge method with a return type of the upper bounds from the generic class. The order these are returned in is undefined, although was fixed in Oracle's implementation until build 129 of JDK7 (see https://wikis.oracle.com/display/GlassFish/Method+Ordering+from+Class.getMethods).
If the bridge method is found first, then it will be returned with a wider return type (e.g. java.io.Serializable) rather than the specific return type of the entity (e.g. java.lang.Long). This will then cause JPAEntityMappings.createId() to throw an
This could all go away if we move to JPA 2.0 Entity Metamodels as suggested in ACT-802. Or we could fix it by adding a check with Method.isBridge():