AW: [sdo] ISSUE 22: Java Annotations and SDO Metadata

["Barack, Ron" <ron.barack@sap.com>]

Title: ISSUE 22: Java Annotations and SDO Metadata

Hi Radu,

 

Not sure what you mean by point 2.  The SDO hierarchy would exactly reflect the hierarchy/inheritence structure in Java.  In our implementation, we introspect all base classes, and use them to determine the base SDO types.  The properties declared in a base type reflect the annotations in the base class, and they all inherit according to the normal rules (of SDO and of Java).

 

Regarding point 3, we definitely would like to see POJO classes (e.g., JPA Persistent Objects) used as sources for metadata.  Eg, a JPA POJO could be annotated with both JPA and SDO annotations and fed to TypeHelper.define(Class).  The more complex question is the use of POJO classes as static SDOs, i.e., as something that provides a type safe interface but is "castable" to DataObject.  Static SDOs in the SDO 2.1 sense would require bytecode enhancement, or some code generation step.  Such an approach is in keeping with our philosophy, and I guess fits in well with EclipseLink, but may be problematic for other vendors.  Issue 133 and 134 could be a compromise here.  For the current discussion, however, I think the point is that we want to allow SDO annotations on both interfaces and classes.

 

Ron

 

---

Von: Radu Preotiuc-Pietro [mailto:radu.preotiuc-pietro@oracle.com]
Gesendet: Dienstag, 11. November 2008 04:43
An: Buennig, Stefan; sdo@lists.oasis-open.org
Betreff: RE: [sdo] ISSUE 22: Java Annotations and SDO Metadata

I have a few more comments related to this proposal.

 

1. I know that we have talked about JAXB annotations and that it would be desireable to re-use them as much as possible, but there are too many JAXB annotations to provide mandatory support for all of them in SDO. What if we include mandatory support for just a few of the more often used ones, such as whether a property to be rendered as element/attribute or the name of types/properties?

 

2. What do we do about inheritance? It would seem that the annotations of a property are inherited along with that property, but in Java I seem to remember that this is not the case. I think we should say a few words on this topic.

 

3. I think we may have covered this, but how are Java classes (as opposed to interfaces) handled? I guess, more generally, are Java objects not created by SDO factory methods supposed to have SDO behavior?

 

Thank you,

Radu

---

From: Buennig, Stefan [mailto:stefan.buennig@sap.com]
Sent: Wednesday, October 29, 2008 11:27 AM
To: sdo@lists.oasis-open.org
Subject: [sdo] ISSUE 22: Java Annotations and SDO Metadata

Hi all,

On this week's call we had an interesting discussion about ISSUE 22: Java Annotations and SDO Metadata.
The discussion was based on Ron's proposal:
http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200809/doc00000.doc

I will try to summarize this discussion:

There was an agreement that it is an useful feature to create SDO types by introspecting Java interfaces or classes. The API to use this feature will be JavaHelper.define(Class).

In cases where the information in the Java interfaces/classes are not rich enough to create the SDO type information, Java  5 annotations can be used to add these missing information.

SDO's Java code generator should be able to generate these annotations.
Radu mentioned that it still must be possible to generate plain interfaces/classes without SDO in the imports.

The chapters 1.1.1 @SdoTypeMetaData and 1.1.3 @SdoPropertyMetaData describe structured annotation classes to add information to types and properties.

The discussion was less about the content of these annotations but rather if the annotations should be structured or with a single value.

Pros for structured annotations:
+ annotations are bundled
+ developer has to learn fewer annotations and can use syntax completion in it's IDE
Cons:
- developers could be more familiar with single valued annotations as used in JPA or JAXB

The chapter 1.1.2 @SchemaInfo raised a big discussion if this annotation is useful.
The idea of this annotation is to provide a link from the Java interface/class to the XML schema. This link is similar to the package-annotation in schemas, just the other way round. With the @SchemaInfo annotation the JavaHelper could receive the missing type information from the XSD and so further annotations wouldn't be needed.

The advantage of this link to XSD is that the definition of types could be done in one step. The enrichment of already defined types to merge Java-based and XSD-based metadata is not necessary.

The concerns about this annotation are that the mapping between the types defined by analyzing Java and the types defined by XSD is not clear.

Also resolving the schema could be difficult.
This annotation would be a simple way to connect Java interfaces/classes with very XML specific metadata.
May be, we need an API to connect interfaces or classes with SDO types or whole schemas.

The chapter 1.1.5 Code generation template for DataType types describes in the current proposal a way to define simple types by dummy interfaces.

The most attendees in the call agreed that this way is some kind of ugly because the interfaces will never be used in the real coding. That could confuse the users.

The advantage of this approach is that the dummy interfaces are an easy way to represent hierarchies in the simple types similar to complex types.

There was a comment that user defined simple types are very uncommon in Java-driven data models, so these dummy-interfaces would be needed in very few cases.

As an alternative to these dummy-interfaces the usage of package annotations should be considered.

Stefan.

Stefan Bünnig
Senior Developer
NetWeaver C Tools

SAP AG
Rosenthaler Straße 30
10178 Berlin
T   +49 30 41092-608
F   +49 6227 78-42807
M  +49 172 3088-367
mailto:stefan.buennig@sap.com
www.sap.com

Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO), Léo Apotheker (stellv. Sprecher/Deputy CEO), Werner Brandt, Claus Heinrich, Gerhard Oswald, John Schwarz, Peter Zencke

Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board: Hasso Plattner, Registergericht/Commercial Register Mannheim No HRB 350269

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.