Serialization - future direction and support for other serialization protocols, via a public Serialization API and JERI Serialization Layer.

[pfirmstone]

No description provided.

[pfirmstone]

https://cr.openjdk.java.net/~briangoetz/amber/serialization.html

[pfirmstone]

 [java] WARNING: An illegal reflective access operation has occurred
 [java] WARNING: Illegal reflective access by org.apache.river.api.io.ObjectStreamClassContainer$3 (file:/C:/Users/HD.Design/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar) to method java.lang.Enum.readObjectNoData()
 [java] WARNING: Please consider reporting this to the maintainers of org.apache.river.api.io.ObjectStreamClassContainer$3
 [java] WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
 [java] WARNING: All illegal access operations will be denied in a future release

[pfirmstone]

Serializable classes annotated with @AtomicSerial can be serialized using AtomicMarshalOutputStream and deserialized using AtomicMarshalInputStream.

AtomicMarshalInputStream is a complete re-implementation of deserialization.

@AtoimcSerial is serial form compatible with Java Serialization, with the exception of circular object graphs.

[pfirmstone]

AtomicMarshalInputStream requires @AtomicSerial deserialization constructors, it doesn't call readObject(), although it does check whether it exists. AtomicMarshalInputStream allows deserialization of Serializable Objects that have ONLY primitive fields and do not have a readObject() method.

We probably aren't going to have access to these private deserialization methods in future, so will need to work without them. It probably also means that we will need all classes to have deserialization constructors.

[pfirmstone]

According to the Project Amber link above, java will likely have a new keyword "open" to allow legal reflective access to private methods and constructors.

It is unlikely that fields will be accessible in future.

Currently AtomicMarshalInputStream allows deserialization of simple Object's that contain only primitive fields and has no readObject method. Since it is unlikely that we will have reflective access to readObject and other standard java serialization methods, we will probably need to remove support for this functionality, probably sooner the better and require all serializable objects to implement @AtomicSerial and its required constructor.

AtomicMarshalOutputStream will need to be modified to support an annotated deconstructor, this can be defined by an interface, with a caller sensitive parameter, so that each class in the object heirarchy with state, implements as well as calls the superclass method implementation.

[pfirmstone]

Anyone interested in this topic, feel free to post ideas or thoughts on this issue.

I have been considering other Serialization protocols, most Object protocols represent Object data as fields with name value tuples.

So far in developing the @AtomicSerial public API, I have been duplicating the capabilities of Java Serialization, I first re- implemented Java de-serialization and now I have re-implemented serialization (I haven't yet uploaded it). However one of my concerns is that it is unnecessarily overly complex and could only be partially supported by other serialization protocols.

The name tuple pairs allow for flexibility in evolution of serial form, in my current implementation of deserialization, it is possible to change the serial form in a backward compatible manner. Access to the underlying stream, from object classes, which Java Serialization permits, creates extraneous artifacts that are not part of an object's declared serial from, the order of these artifacts, whether objects, or primitives, when written to the stream is of critical importance and cannot be changed, without breaking compatibility.

As @AtomicSerial uses a completely different API, and wouldn't yet have a significant user base, it would be better to make a breaking change now, rather than leave it until later.

This would also mean deprecation and removal of the @AtomicExternal API's, Objects would be limited to defining a set of parameter tuple name value pairs that represents the serial form of the class in an object's inheritance hierarchy, within a tree graph of objects.

To date I have maintained a serial form identical to that of Java serialization, however it's possible for a class to support both @atomic and Serializable, with different serial forms for each.

The benefit would be support of a wider range of cross platform serialization protocols.

It would seem better not to repeat the mistakes of Java Serialization.

Thoughts?