[jmi-comments] 1) Structure factories 2) instances in values 3) CollectionType

This message is here only for your information. It repeats and extends
what I said on the thread about a JMI copy operation.


----- Forwarded message from Holger Krug <[email protected]> -----

Date: Thu, 8 Aug 2002 10:00:54 +0200
From: Holger Krug <[email protected]>
To: [email protected]

-snip-

Creating values of structure type
=================================

When I want to create a value of a structure type, the problem is: how
to find the factory for this type. Assume that I know from the
meta-model the meta-object (instance of StructureType). In such a case
I only can hope, that I find a factory for it. I think that is overly
complicated. Values of structure types are simply values, they must
not be managed by proxies to assure object identity etc., so why it's
made so complicated to create them ? It's even strange semantics to
make the creation of a pure value depend on something, which is
related to object identity.

Hence my proposal which should take into account possible technical
problems of JMI implementation vendors:

generated classes/interfaces for structure types
------------------------------------------------

For each instance A of StructureType two Java classes a generated:
- an interface A
- a class ADefault implementing the interface
The constructor(s) of ADefault are the factory methods.

Implementors should not have problems with this: Values returned by
getters have to implement A, hence implementors may use there own
inner representations to hold values of A. When receiving values of A
via setters, an implementor who internally can only use his specific
implementation AVendorImpl of A has to create an instance of
AVendorImpl base on the given instance of another class implementing
A.

The only problem with this might be, that when attributes have more
complicated type like:

Collection(Structure(Collection(Structure), Primitive, Class))

the implementation of the setter has to browse and copy the whole
data-structure to switch structure values to the form required by the
vendor.

values of structure types in reflective API
-------------------------------------------

In reflective getters I would allow users to give values of structure
type either as instances of java.util.Map or as instances of
Object[]. (I would prefer the second version out of performance
reasons.)

That solves the problem that users knowing the meta-description of the
structure type (instance of StructureType) otherwise are unable to
create values via the reflective API, because they do not know where
to find a factory.

My proposals solve even a second problem: Currently it's not clear
from the JMI spec what happens if I create a structure value in one
repository (probably from one vendor) and then put it into another
repository (probably from another vendor). Because the JMI does not
exclude it, it should work. On the other hand the existence of
specific factories for structures suggest that it won't work. With my
proposals it will work in every case and that would be clear from the
spec.

How values of CollectionType must be handled by implementors
============================================================

It's not mentioned in the JMI spec, but probably values of
CollectionType should be immutable, shouldn't they ? That requires
from the vendor to use his own Collection implementation not the one
provided by the user.

Example 1:
1) user creates a live collection c of something
2) user calls obj.refSetValue("att",c)
3) the underlying source of c changes
4) user calls d = obj.refGetValue("att")

Example 2:
1) user creates an ArrayList c
2) user calls obj.refSetValue("att",c)
3) user modifies c
4) user calls d = obj.refGetValue("att")

In both cases: should d reflect the old or the new state of c ?
Probably the old one. But the spec does not require this and e.g. MDR
implementation will, if I understand its code correctly, return the
old or the new state of c depending on when step 4) is executed.

Hence I think the JMI spec should be amended and explicitely state one
of:

a) collections provided by users must be dead and immutable
b) implementors must copy collections
c) the JMI APIs accept and return only specific Collection implementations

a) would not require any changes to existing implementations and would
be the best from a performance point of view but would pose problems
in multi-user applications. How can one user trust the other one ?

b) would be more safe, but even not fully, because the underlying
collection might even be changing will the implementors code iterates
it to actually perform the copy operation, which might make it
impossible to create the copy.

c) would be the safest thing and would almost enforce no changes for
implementors. Users would only be forced to wrap their collections
before providing them to JMI, which requires only slight code
changes, although may have a performance impact.

I would prefer c).

Similar remarks as given here apply also to multiplicity-related
collections.

Values containing instances
===========================

With "values containing instances" I mean values of data-types like:

StructureType(Class, ..) or
Collection(Class)

IMHO this in an ugly mixing of value and reference semantics. Is it
really used ? The problem it imposes is the need for user application
performing operations like copy extent content from one repository to
another to browse the whole structure of attribute values to replace
instances in the source by instances in the target. (That is even more
complicated, when there is no way to rebuild structure values later on
in the target, because there is no factory known, to perform this
task.) What is that for a repository, where I must pre-digest pure
values (as instances of data-types should be) to make them digestable
by a repository ?

If there is really a need to reference instances from within values, I
would recommend to introduce something like externalizable unique
references values, which may be copied as values from one repository
to another one, referencing an instance in e.g. a third repository.
The real mechanism of reference resolution initially might be vendor
or even repository specific, such that users may not be sure that an
implementation of vendor X might resolve references created in an
application of vendor Y. But the JMI spec would describe the external
format of references (e.g. String or Serializable), such that each
vendor could at least store references created by any JMI specific
repository. Later on (when JMI is amended by interfaces of JMI
repositories) one could use JNDI to make references resolvable by any
repository of any vendor.

-- 
Holger Krug
[email protected]

----- End forwarded message -----