[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549726#comment-14549726 ]
Andy Jefferson edited comment on JDO-709 at 5/19/15 11:14 AM: -------------------------------------------------------------- As said above, you cannot do "default null" (my comment "crapness of Java annotation defaulting"). Maybe get those Java language spec people at Oracle to allow it? As also said above, an option is just to have the "converter" attribute as type Class and throw away generics, and you can then have "default void.class". Regarding "disableConversion" and "converter", yes it is not perfect how they interact. We have the following ways of handling a member (or key/value/element) : * default JDO implementation (internal) handling (what people get with JDO 3.1 or earlier) * PMF default converter for the type * optional class-level default converter for the type * optional member/element/key/value converter for the type One way we could interpret it all 1. converter not specified, disableConversion = false -> use class-level converter if available, else use PMF converter if available, otherwise fallback to default implementation handling. 2. converter not specified, disableConversion = true -> use default implementation handling 3. converter specified, disableConversion = false -> use converter 4. converter specified, disableConversion = true -> use default implementation handling Better ideas? was (Author: andy): As said above, you cannot do "default null" (my comment "crapness of Java annotation defaulting"). Maybe get those Java language spec people at Oracle to allow it? Regarding "disableConversion" and "converter", yes it is not perfect how they interact. We have the following ways of handling a member (or key/value/element) : * default JDO implementation (internal) handling (what people get with JDO 3.1 or earlier) * PMF default converter for the type * optional class-level default converter for the type * optional member/element/key/value converter for the type One way we could interpret it all 1. converter not specified, disableConversion = false -> use class-level converter if available, else use PMF converter if available, otherwise fallback to default implementation handling. 2. converter not specified, disableConversion = true -> use default implementation handling 3. converter specified, disableConversion = false -> use converter 4. converter specified, disableConversion = true -> use default implementation handling Better ideas? > Standardize field/property converters > ------------------------------------- > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api > Reporter: Matthew T. Adams > Assignee: Matthew T. Adams > Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)