Class.getSimpleName not suitable for non-Java classes

Daniel Armak danarmak at gmail.com
Fri Mar 10 19:40:04 UTC 2017


Hi,

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)

println(ClassLayout.parseClass(classOf[Foo2]).toPrintable)

Foo object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0    12        (object header)                           N/A
     12     1   byte Foo.x                                    N/A
     13     3        (alignment/padding gap)
     16     1   byte Foo.y                                    N/A
     17     7        (loss due to the next object alignment)
Instance size: 24 bytes
Space losses: 3 bytes internal + 7 bytes external = 10 bytes total

While this simply crashes:

class long
case class Foo(x: long, y: long)

println(ClassLayout.parseClass(classOf[Foo]).toPrintable)

Exception in thread "main" java.lang.IllegalStateException: Field
Foo.x @12 (long, 8b) is not aligned
    at org.openjdk.jol.info.ClassLayout.checkInvariants(ClassLayout.java:131)
    at org.openjdk.jol.info.ClassLayout.<init>(ClassLayout.java:123)
    at org.openjdk.jol.layouters.CurrentLayouter.layout(CurrentLayouter.java:78)
    at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:70)
    at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:54)

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

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.

Thanks,
​
-- 
Daniel Armak


More information about the jol-dev mailing list