Issue 133: TCK : Map tests

[Craig L Russell <Cr...@Sun.COM>]

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
>

Re: Issue 133: TCK : Map tests

[Craig L Russell <Cr...@Sun.COM>]

Javadogs,

I agree with Erik that the spec should more closely follow Java  
semantics.

Here's the proposed spec change:

<spec 18.14.1>
The element-type attribute specifies the type of the elements. The  
type name uses Java language 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 exactly as in the Java language: they are  
first checked to see if they are in the package in which they are  
used, and if not, assumed to be in the java.lang package.
</spec>

Craig

On Oct 26, 2005, at 5:20 AM, erik@jpox.org wrote:

> Quoting Craig L Russell <Cr...@Sun.COM>:
>
>
>> 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.
>>
>>
>
> I like better this
>

Re: Issue 133: TCK : Map tests

[er...@jpox.org]

Quoting Craig L Russell <Cr...@Sun.COM>:

> 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.
>

I like better this