Class.getSimpleName not suitable for non-Java classes

[Daniel Armak]

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