Re: Inconsistency between ClassDesc::packageName and Class::getPackageName
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
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
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
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