The issue is minor, but we need to decide whether it is an error to have an interface with a non-property method or an abstract class with an abstract non-property method.
My vote would be that it's an early error, not an error that is only thrown if you try to use one of the non-property methods. This is possibly but not probably a backward compatibility issue, if any users are depending on the behavior in JDO 2.0 section 18.3.
Please comment if you believe that we should allow non-property abstract methods to be declared in parameters to newInstance.
Craig In 12.6.6,an abstract class that is declared in the metadata as persistence- capable, in which all abstract methods are persistent properties, or an interface that is declared in the metadata as persistence-capable, in which all methods are persistent properties, or... If the parameter does not satisfy the above requirements, JDOUserException is thrown.
But in 18.3,Persistent properties declared in the interface are defined as those that have both a get and a set method or both an is and a set method, named according to the JavaBeans naming conventions, and of a type supported as a persistent type. The implementing class will provide a suitable implementation for all property access methods and will throw JDOUserException for all other methods of the interface.
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
