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 10:15   |
Eclipse User |
|
|
|
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 11:31 |
| Eclipse User |
|
|
|
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 12:23 |
| Eclipse User |
|
|
|
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 12:02 |
| Eclipse User |
|
|
|
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
|
|
|
| Re: Is serialization of roles/teams supported? [message #569627 is a reply to message #569611] |
Wed, 10 March 2010 10:06 |
| Eclipse User |
|
|
|
Abdullah O. wrote on Fri, 05 March 2010 12:02
> Yes .. http://java.sun.com/javase/6/docs/platform/serialization/spe c/serial-arch.html
> read the note in section 1.10
Wow, Java documentation officially telling us we should not use (certain features of) Java :)
Luckily, from scanning their reasons, I only see two restriction that also
apply to roles in OT/J:
we (currently) cannot use serialPersistentFields in roles. Actually, we could even try to remove the underlying restriction (no static fields in non-static inner classes) ...
roles cannot implement Externalizable.
More specifically:
we don't have to worry about different compilers, there is only one OT/J compiler and if eventually we will support different ones, we'd first specify all necessary byte code details to ensure compatibility.
roles are not local classes (for which naming is insufficiently specified)
serialization of the enclosing team is not an accident but an intended necessity.
It seems we needn't worry about those recommendations too much.
cheers,
Stephan
|
|
|
Goto Forum:
Current Time: Tue Jul 01 05:40:47 EDT 2025
Powered by FUDForum. Page generated in 0.05230 seconds |
Home