What's New in SDO Java M2 1. `java.io.Serializable` support for `DataObject`s including objects not in a `DataGraph` (TUSCANY-22) 2. Java code generator improvements 3. XML Schema generation (TUSCANY-535) 4. StAX-based Load load and save support (TUSCANY-118) 5. new SDOUtil methods 6. CrossScopeCopyHelper (TUSCANY-627) 7. open content creation API (SDO 2.1 enhancement early implementation - see draft 2.1 spec) 8. sample programs 9. More than 12 new bugfixes Details are described below. SDO Java M2 is a superset of previous SDO Java M1 release. Anything in M1 is also in M2, but M2 contains features and bugfixes not present in M1 release. Downloading http://incubator.apache.org/tuscany/downloads.html#Apache%20Tuscany%20Java%20Downloads Compatibility Concerns M2 is still on SDO Java specification 2.01 same as M1. SDO Java M2 maintains API/SPI compatibility with M1 release, by only adding new functions. A program written to the M1 API/SPI can both compile and run using M2 libraries. However, a program written for M2 cannot necessarily compile or run against M1 libraries. Command Line Output Changes Although the SDO Java developers try hard to keep output from the command line programs compatible between releases, new information sometimes has to be added. This might break scripts that rely on the exact format of the output. In M2, for example, SDO static code generator help information is updated as new options available. New Features 1. `java.io.Serializable` support for `DataObject`s including objects not in a `DataGraph` (TUSCANY-22) DataObject used to be required to put into DataGraph before being Java serialized; from M2 on, DataObject can be Java serialized standalone. And the data object serialization format conforms to SDO Java specification 2.01. At the same time, DataGraph serialization is also working now although whose format is still not compliant yet. 2. Java code generator improvements A new option (-interfaceDataObject) is available to generate interfaces that extend commonj.sdo.DataObject (TUSCANY-254). The existed option (-noEMF) pattern has been improved, e.g., inheritance and bidirectional references are now working (sca-core.xsd can be generated). On the other hand, generated interfaces now extend java.io.Serializable by default convenient to remote invocation. 3. XML Schema generation (TUSCANY-535) XSDHelper used to go only one way that #define methods import models from XML Schema, SDO Java M2 has implemented `XSDHelper.generate()` methods to export models as XML Schema. 4. StAX-based Load load and save support (TUSCANY-118) A new helper XMLStreamHelper has been added, it's based on Stream API for XML which makes SDO convenient to use in StAX environment. On the other hand, StAX load/save is a better-performance alternative sometimes. 5. new SDOUtil methods * SDOUtil.getSubstitutionValues() SDO user used to assume the SDO implementation is based on EMF and use EMF API/SPI to access substitutable Property since no such API/SPI available in SDO Java M1. M2 has provided such non-EMF way to get the Sequence corresponding to a substitutable Property (TUSCANY-502/503) * SDOUtil.isRequired() Determine if a property is required, that is, minOccurs > 0 (TUSCANY-504) * SDOUtil.setRootObject() SDO user used to be only able to get the root object of a DataGraph in SDO Java M1, M2 has enabled setting the root object of a DataGraph (TUSCANY-512) * SDOUtil.getTypes() Gets all of the types associated with a uri (TUSCANY-583) * SDOUtil.registerDataGraphTypes DataObject/DataGraph serialization used to be instances only; models are expected on the other endpoint otherwise either anyType will be used to deserialize DataObject/DataGraph or ClassNotFoundException will be thrown. Even if no ClassNotFoundException, anyType isn't always satisfying. SDO Java M2 has enabled models seriallization by registering Types to be serialized along with a DataGraph (TUSCANY-670) 6. CrossScopeCopyHelper (TUSCANY-627) Types are registered within certain scopes (TypeHelpers). Two Types from different scopes (TypeHelper) are two different types even if imported from very same source such as XML Schema. Some scenario such as local invocation prefers copying to serialization which requires copying to use Types from (invocation) destination endpoint instead of the source/original one. SDO Java M2 has enabled copying DataObject instances from one TypeHelper to another scope. 7. open content creation API (SDO 2.1 enhancement early implementation - see draft 2.1 spec) * TypeHelper.createOpenContentProperty() * TypeHelper.getOpenContentProperty()