Class.getSimpleName not suitable for non-Java classes

[Daniel Armak]

Here's a simpler proposal: what exactly doesn't work if you just change the
three calls to Class.getSimpleName with getName?

As far as I can see, the only thing that's affected is that printed layout
contains longer, less readable names. This is actually useful sometimes if
you have classes with the same name in different packages. Regardless, a
simple algorithm could be used here (e.g. discard everything until the last
'.').

Also, Class.getName is already used to represent array component types
(ClassData.java line 93). What's the difference?

Daniel Armak

On Sat, Mar 11, 2017 at 12:19 AM, Daniel Armak <danarmak at gmail.com> wrote:

> Hi,
>
> For the first issue: my classes don't have an FQDN of "int". They just
> have a name of "int" inside some package, so an FQDN of e.g. "com.bar.int".
> There's no reason to confuse them with the primitive int type. (Although
> even a class with an FQDN of "int" in the default package would still be
> distinct from the primitive int type.)
>
> And, since jol is using Class.getSimpleName, not Class.getName, it's not
> using FQDNs anyway. So it can't use these 'simple names' to identify
> classes anyway, since two similarly named classes in two different packages
> would be confused. (Not to mention two similarly named classes from
> different classloaders...)
>
> I think jol can and should fix the first issue, e.g. by storing whether a
> field's type is primitive whereever it needs to later compare the field
> type's name to a primitive type.
>
> As for the second issue, which was fixed in JDK9, given that 'simple
> names' are not used to identify classes (since they're not FQDNs anyway),
> they're only used when printing output for the user. If that is indeed
> their only purpose, then one possible workaround is, when getSimpleName
> throws, to fallback to some other string - such as the name of the class
> (as given by getName) minus the package prefix.
>
> These fixes would be good enough for me; do you think they would be
> appropriate for jol?
>
>
> Daniel Armak
>
> On Sat, Mar 11, 2017 at 12:07 AM, Aleksey Shipilev <shade at redhat.com>
> wrote:
>
>> Hi,
>>
>> On 03/10/2017 08:40 PM, Daniel Armak wrote:
>> > There are two issues that I’ve encountered.
>> >
>> > First, jol assumes any class whose simple name is “int” is the primitive
>> > int type, etc. But languages other than Java can create classes with
>> such a
>> > simple name, and it’s a valid JVM class name. So this Scala code
>> produces:
>> >
>> > class byte
>> > case class Foo(x: byte, y: byte)
>>
>> Um. The problem for JOL is that it's internals are using stringy FQDN for
>> class
>> names to avoid retaining/loading them. This allows, e.g. to reason about
>> heap
>> dumps without having class definitions around. If your generated class
>> has the
>> same FQDN as the regular Java "byte", you are going to have a bad time.
>> Unsure
>> how should this one be fixed.
>>
>>
>> > The other issue I encountered is JDK-8057919
>> > <https://bugs.openjdk.java.net/browse/JDK-8057919>, which was fixed in
>> JDK9
>> > but is present before that. Class.getSimpleName throws an exception for
>> > some classes generated by non-Java compilers, notably by scalac (SI-2034
>> > <https://issues.scala-lang.org/browse/SI-2034>), whose names are valid
>> JVM
>> > class names but not valid Java class names.
>>
>> Again, not sure how this should be worked around in JOL. It seems to me
>> JDK 9
>> should be able to handle this correctly anyhow.
>>
>>
>> > How do you think these issues should / will be fixed? I want to use jol
>> (as
>> > a library), so I’ll probably make a locally modified copy to work around
>> > these issues, but these changes likely wouldn’t be the right/general
>> ones
>> > to make to the upstream source.
>>
>> So, both things you have are interesting and complicated interop issues.
>> If you
>> have simple solutions for them, please can contribute them! See:
>> http://openjdk.java.net/contribute/
>>
>>
>> Thanks,
>> -Aleksey
>>
>>
>