Re: Inconsistency between ClassDesc::packageName and Class::getPackageName

2022-08-22 Thread Joseph D. Darcy

On 8/22/2022 11:57 AM, Alan Bateman wrote:

On 22/08/2022 18:13, Kasper Nielsen wrote:

Hi,

I understand that the methods are behaving as specified.
However, I still think that

int.class.getPackageName() = "java.lang"
int.class.describeConstable().get().packageName() = ""

is surprising behavior. And should probably as a minimum be
documented on ClassDesc::packageName.

A named module is a set of named packages and it just wouldn't work 
for a class in a named module to say that it's in the unnamed package. 
As I recall, the original proposal for getPackageName was that it 
return null when the class is for an array or primitive class but that 
turned out to be a usability issue. The proposal was refined to what 
is specified now.


ClassDesc is a nominal descriptor so it's more like parsing a string 
to get the package name. I don't disagree that the packageName method 
could link to isArray and componentType when the descriptor is for an 
array type, or isPrimitive to test if the descriptor is for a 
primitive type.



I agree it would be fine to add apiNote/@see/@link tags, etc. , but 
don't think any behavior change is justified.


-Joe



Re: Inconsistency between ClassDesc::packageName and Class::getPackageName

2022-08-22 Thread Alan Bateman

On 22/08/2022 18:13, Kasper Nielsen wrote:

Hi,

I understand that the methods are behaving as specified.
However, I still think that

int.class.getPackageName() = "java.lang"
int.class.describeConstable().get().packageName() = ""

is surprising behavior. And should probably as a minimum be
documented on ClassDesc::packageName.

A named module is a set of named packages and it just wouldn't work for 
a class in a named module to say that it's in the unnamed package. As I 
recall, the original proposal for getPackageName was that it return null 
when the class is for an array or primitive class but that turned out to 
be a usability issue. The proposal was refined to what is specified now.


ClassDesc is a nominal descriptor so it's more like parsing a string to 
get the package name. I don't disagree that the packageName method could 
link to isArray and componentType when the descriptor is for an array 
type, or isPrimitive to test if the descriptor is for a primitive type.


-Alan.


Re: Inconsistency between ClassDesc::packageName and Class::getPackageName

2022-08-22 Thread Kasper Nielsen
Hi,

I understand that the methods are behaving as specified.
However, I still think that

int.class.getPackageName() = "java.lang"
int.class.describeConstable().get().packageName() = ""

is surprising behavior. And should probably as a minimum be
documented on ClassDesc::packageName.

/Kasper

On Mon, 22 Aug 2022 at 17:46, Joe Darcy  wrote:
>
> Hello,
>
> The method Class.getPackage is behaving as specified:
>
> public Package getPackage()
> Gets the package of this class.
>
> If this class represents an array type, a primitive type or void, this method 
> returns null.
>
> as is Class.getPackageName():
>
> If this class represents an array type then this method returns the package 
> name of the element type. If this class represents a primitive type or void 
> then the package name "java.lang" is returned.
>
> and ClassDesc.packageName is as well.
>
> Class.getPackage has been doing what it been doing since about JDK 1.2 so due 
> to behavioral compatibility, there would have to be a much stronger case for 
> altering its behavior at this point.
>
> -Joe
>
> On 8/22/2022 2:17 AM, Kasper Nielsen wrote:
>
> Hi,
>
> I was playing around with java.lang.constant and found an inconsistency 
> between
> ClassDesc::packageName and Class::getPackageName as outlined in the table 
> below.
> Specifically dealing with primitive and array types.
>
> Class   ClassDesc::packageName Class::getPackage Class::getPackageName
>  -- -- - -
>   int"" null  "java.lang"
>   int[]  "" null  "java.lang"
>   Integer"java.lang"java.lang "java.lang"
>   Integer[]  "" null  "java.lang"
>
> I was originally going to submit a patch for ClassDesc. But I now think
> Class::getPackageName is the one that I need to patch. Thoughts?
>
> Thanks,
>   Kasper


Re: Inconsistency between ClassDesc::packageName and Class::getPackageName

2022-08-22 Thread Joe Darcy

Hello,

The method Class.getPackage is behaving as specified:


public Package getPackage()
Gets the package of this class.

If this class represents an array type, a primitive type or void, this 
method returns null.


as is Class.getPackageName():

If this class represents an array type then this method returns the 
package name of the element type. If this class represents a primitive 
type or void then the package name "|java.lang|" is returned.


and ClassDesc.packageName is as well.

Class.getPackage has been doing what it been doing since about JDK 1.2 
so due to behavioral compatibility, there would have to be a much 
stronger case for altering its behavior at this point.


-Joe

On 8/22/2022 2:17 AM, Kasper Nielsen wrote:

Hi,

I was playing around with java.lang.constant and found an inconsistency between
ClassDesc::packageName and Class::getPackageName as outlined in the table below.
Specifically dealing with primitive and array types.

Class   ClassDesc::packageName Class::getPackage Class::getPackageName
  -- -- - -
   int"" null  "java.lang"
   int[]  "" null  "java.lang"
   Integer"java.lang"java.lang "java.lang"
   Integer[]  "" null  "java.lang"

I was originally going to submit a patch for ClassDesc. But I now think
Class::getPackageName is the one that I need to patch. Thoughts?

Thanks,
   Kasper