Home » Language IDEs » Objectteams » Is serialization of roles/teams supported?
| |
| Re: Is serialization of roles/teams supported? [message #569478 is a reply to message #568929] |
Thu, 04 March 2010 15:15   |
 Abdullah O.
Messages: 4
Registered: March 2010 |
Junior Member |
|
|
Hi all,,
Serialization in OT/J should be attached, as a concept, to inner classes. According to Java language definition, serializing inner classes "is strongly discouraged " :? , and a set of reasons have been mentioned; the most important one is that: implementing the names and synthetic fields of inner classes is a compiler dependent issue. This may come out with different serial-IDs, for example.
Because OT/J realizes the roles by the means of inner-classes, then its a must to serialize the outer team class in order to allow roles to be serialized (since role classes are non-static) as well.
Also, we should make sure that roles (and teams) don't implement any transient fields! to make sure of a complete serialization process.
Finally, there is nothing prevents OT/J to support serialization (as a default choice), but the above.
Regards
Abdullah
|
|
|
| Re: Is serialization of roles/teams supported? [message #569522 is a reply to message #569478] |
Thu, 04 March 2010 16:31 |
Stephan Herrmann
Messages: 1843
Registered: July 2009 |
Senior Member |
|
|
Abdullah O. wrote on Thu, 04 March 2010 10:15
> Hi all,,
>
> Serialization in OT/J should be attached, as a concept, to inner classes. According to Java language definition, serializing inner classes "is strongly discouraged " :? ,
That's interesting. Do you have a reference for this?
Quote:
> and a set of reasons have been mentioned; the most important one is that: implementing the names and synthetic fields of inner classes is a compiler dependent issue. This may come out with different serial-IDs, for example.
That shouldn't disturb us, because there's only one OT/J compiler (currently).
Which reminds me, that support for a third party OT/J compiler would require
diligent specification of several aspects of the byte code we produce.
Quote:
> Because OT/J realizes the roles by the means of inner-classes, then its a must to serialize the outer team class in order to allow roles to be serialized (since role classes are non-static) as well.
That's true. Let's see, we have several implicit references that should be
considered, some of which must be included in serialization to preserve
the semantics, others are optional:
- role -> team: MUST be included
- role -> base: MUST be included
- team -> role: OPTIONAL
- team -> base: no direct dependence (only via role)
- base -> team: no direct dependence
- base -> role: OPTIONAL (implicit, invisible reverse of role->base).
Do you agree on this table?
Quote:
> Also, we should make sure that roles (and teams) don't implement any transient fields! to make sure of a complete serialization process.
Well, isn't it the purpose of transient fields to actually provide for incomplete
serialization (i.e., after deserialization those fields are simply set to defaults)?
Quote:
> Finally, there is nothing prevents OT/J to support serialization (as a default choice), but the above.
thanks,
Stephan
|
|
|
| Re: Is serialization of roles/teams supported? [message #569549 is a reply to message #568929] |
Thu, 04 March 2010 17:23 |
Olaf Otto
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Very triky one.
The thing with serialization is that it is essentially persistence, and should thus be explicit to avoid unwanted serialization. Can we gurantee the consistency of the object teams application's runtime state, for instance in the context of role migration and team activation / deactivation? How do we deal with Thread-related state?
Basically, we might need to take care of all generated fields and must make them either transient or clearly define their effect on serialization.
In OT-JPA, for instance, I declared all generated fields of a base as transient to the persistence context, since it is unclear whether a user intends to serialize these. This is also important to prevent the (not unlikely) case of an explosion of serializations due to the potentially large transitive hull of a team.
Probably, marking references to the DoublyWeakHashMap transient and adding a role state restauration to a Roles readObject method might be more suitable? This way, role instances would only be serialized iff 1) The role or team is serialized and, in the latter case, the team contained a non-transitive user-defined field referencing the corresponding role instance(s). (See OTClassDescriptor in ObjectTeamsSemanticsAdapter for my approach to this problem for the JPA).
Looking at this, I think we might have to consider a reasonable amount of constraints. This will be a little more triky.
Best,
Olaf
|
|
|
| Re: Is serialization of roles/teams supported? [message #569611 is a reply to message #569522] |
Fri, 05 March 2010 17:02 |
Abdullah O.
Messages: 4
Registered: March 2010 |
Junior Member |
|
|
Serialization in OT/J should be attached, as a concept, to inner classes. According to Java language definition, serializing inner classes "is strongly discouraged " :?
Quote:
> That's interesting. Do you have a reference for this?
Yes .. http://java.sun.com/javase/6/docs/platform/serialization/spe c/serial-arch.html
read the note in section 1.10
Quote:
> - role -> team: MUST be included
> - role -> base: MUST be included
> - team -> role: OPTIONAL
> - team -> base: no direct dependence (only via role)
> - base -> team: no direct dependence
> - base -> role: OPTIONAL (implicit, invisible reverse of role->base).
>
> Do you agree on this table?
Yes. Also we should keep in mind the cases of nesting and stacking, as well as teams as roles. But I think all the cases could be mapped into the table.
Quote:
> Well, isn't it the purpose of transient fields to actually provide for incomplete
> serialization (i.e., after deserialization those fields are simply set to defaults)?
You are right. In fact I mean the logical completeness, e.g. a deformation to the object (e.g. in its state) may result after de-serialization.
Quote:
> thanks,
> Stephan
You are welcome ..
Abdullah
|
|
| |
Goto Forum:
Current Time: Mon Jan 17 17:11:21 GMT 2022
Powered by FUDForum. Page generated in 0.01976 seconds |
] 
Search
Help
Register
Login
Home
