Class.getSimpleName not suitable for non-Java classes

[Aleksey Shipilev]

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