Hi Andy,
On Oct 23, 2005, at 2:25 AM, Andy Jefferson wrote:
Hi Michelle,
I've been through the issues with the various TCK Map tests, and
have the
following comments :-
1. The key-type, value-type are currently being defined as things
like Object,
String, SimpleClass whereas the Collection tests use fully-
qualified names.
While this may be intentional to check the qualification of namings
it does
raise the issue of what an implementation is supposed to do wrt
class namings
when not fully-qualified. I refer to spec section 18.14.1
<spec>
The element-type attribute specifies the type of the elements. The
type name
uses Java rules for naming: if no package is included in the name, the
package name is assumed to be the same package as the persistence-
capable
class. Inner classes are identified by the "$" marker.
</spec>
Java has a slightly more complicated way of dealing with type names
in the java.lang name space, and the JDO spec doesn't go into that
level of detail.
As I understand it, the java compiler allows you to have classes
named String, Integer, etc. in user-defined packages; but if you
don't, then the compiler assumes that these classes are in java.lang.
There is support for importing these classes from other packages but
you cannot import them from the un-named package.
In practice, using your.own.package.String is really "not best
practice"; in fact, I don't know of any practical use-case for it. So
for JDO, I would be happy to require that String, Object, Integer,
and the like are assumed to be in the java.lang package.
In any case, I don't want to require users to qualify String,
Integer, etc. when Java does not require it.
Here's the proposed spec change:
<spec>
The element-type attribute specifies the type of the elements. The
type name uses Java rules for naming: if no package is included in
the name, the package name is assumed to be the same package as the
persistence-capable class. Inner classes are identified by the "$"
marker. Classes Boolean, Byte, Character, Double, Float, Integer,
Long, Number, Object, Short, String, and StringBuffer are treated
specially: they are assumed to be in the java.lang package and cannot
be in user-defined packages.
</spec>
The only other interpretation that I would support is to literally do
what Java does: for these specific type names (String, Integer, etc.
list of 10 names), look first in the named package for the type, and
if not found, go to java.lang to resolve them.
If anyone feels strongly that JDO should allow these 12 java.lang
class names to be defined in user-defined packages, please say so.
so in the case of the TCK tests, since there's no package name we
prepend the
package of the class being persisted. This means that the String,
Object
fully-qualified names get messed up since they aren't in the same
package as
the class. I suggest that these be fully-qualified in the MetaData as
"java.lang." so that a JDO implementation can find the correct
class. You can
leave the "SimpleClass" as they are currently since those will be
correctly
identified.
With the proposal above, JDO implementations would have to treat
String, Integer, etc. specially.
Craig
--
Andy
