Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » Is serialization of roles/teams supported?
Is serialization of roles/teams supported? [message #568929] Mon, 22 February 2010 06:29 Go to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
A simple example fails with java.io.NotSerializableException: org.objectteams.DoublyWeakHashMap
Re: Is serialization of roles/teams supported? [message #569396 is a reply to message #568929] Wed, 03 March 2010 04:06 Go to previous messageGo to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
Hi Stephan
May you please describe what is your take on team/role serialization?
Serialization is very important use case for implementing distributed applications and stateful web applications.

Regards,

Eugene
Re: Is serialization of roles/teams supported? [message #569478 is a reply to message #568929] Thu, 04 March 2010 10:15 Go to previous messageGo to next message
Abdullah O. is currently offline 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 11:31 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 924
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 12:23 Go to previous messageGo to next message
Olaf Otto is currently offline Olaf Otto
Messages: 10
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 12:02 Go to previous messageGo to next message
Abdullah O. is currently offline 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
Re: Is serialization of roles/teams supported? [message #569627 is a reply to message #569611] Wed, 10 March 2010 10:06 Go to previous message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 924
Registered: July 2009
Senior Member
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
Previous Topic:What makes a class a role?
Next Topic:UML models for OT/J?
Goto Forum:
  


Current Time: Thu Apr 17 11:31:04 EDT 2014

Powered by FUDForum. Page generated in 0.01871 seconds