Scala Programming Language
  1. Scala Programming Language
  2. SI-2034

getClass fails for doubly nested inner-class

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Misc Compiler
    • Labels:
      None

      Description

      The following code fails with java.lang.ClassNotFoundException: TestScalaBug$$foo

      workaround is to add a class foo

      may be related to bug 1572

      object TestScalaBug {
      
        def main(args: Array[String]) {
          val fooz = new foo.foo2
          println(fooz)
        }
      
        object foo {
          class foo2 {
            override def toString = getClass.getSimpleName
          }
        }
          
      }
      

        Issue Links

          Activity

          Hide
          Sarah Gerweck added a comment -

          This is a really nasty issue that prevents Scala from being used with a great many modern frameworks that rely on reflection and annotation scanning for service detection. This issue is a showstopper for anybody who wants to use Scala in a Java EE environment (like me).

          (I apologize that this is a bit of a "me too," but I think this issue is serious enough that it warrants the bump. This, along with the related SI-6546, are in danger of killing the Scala pilot at my company. I can't even load our code into the same container without breaking the whole deployment.)

          If binary compatibility is the concern, maybe we can have a compiler flag or something? If a new compiler could support both versions, I could happily throw the switch and not worry about old compilers being able to use my libraries. I might even be willing to write some code here, but I'm not sure that it would actually save any time by the time someone finished pointing me in the right direction as I don't really know the Scala compiler.

          Show
          Sarah Gerweck added a comment - This is a really nasty issue that prevents Scala from being used with a great many modern frameworks that rely on reflection and annotation scanning for service detection. This issue is a showstopper for anybody who wants to use Scala in a Java EE environment (like me). (I apologize that this is a bit of a "me too," but I think this issue is serious enough that it warrants the bump. This, along with the related SI-6546 , are in danger of killing the Scala pilot at my company. I can't even load our code into the same container without breaking the whole deployment.) If binary compatibility is the concern, maybe we can have a compiler flag or something? If a new compiler could support both versions, I could happily throw the switch and not worry about old compilers being able to use my libraries. I might even be willing to write some code here, but I'm not sure that it would actually save any time by the time someone finished pointing me in the right direction as I don't really know the Scala compiler.
          Hide
          Paul Phillips added a comment -

          It isn't compiler knowledge that is necessary so much as a great deal
          of time and patience. The algorithm by which names are derived requires
          comprehensive modification. A single character, $, is used to encode dozens
          of different pieces of information. That character is also used by java.
          There is no way to correctly handle all competing uses while still only
          using $, especially given the hardcoded assumptions in java.lang.Class
          which cause the getSimpleName issue. The workable answer in my opinion is
          to reserve characters from a larger set and start using meaningfully: see
          http://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm . There is much
          which would have to be kept working and little documentation about what it is.
          That however is the task.

          Show
          Paul Phillips added a comment - It isn't compiler knowledge that is necessary so much as a great deal of time and patience. The algorithm by which names are derived requires comprehensive modification. A single character, $, is used to encode dozens of different pieces of information. That character is also used by java. There is no way to correctly handle all competing uses while still only using $, especially given the hardcoded assumptions in java.lang.Class which cause the getSimpleName issue. The workable answer in my opinion is to reserve characters from a larger set and start using meaningfully: see http://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm . There is much which would have to be kept working and little documentation about what it is. That however is the task.
          Hide
          Charles Oliver Nutter added a comment -

          We (JRuby) have had this issue brought to our attention due to an issue caused when attempting to bind one of these classes in JRuby. We use the reflection APIs in question, including getSimpleName...and as a result, the class fails to bind.

          I do not have a solution for you, but I will mention that JRuby has been using the techniques in John Rose's "symbolic freedom" post for many of our internal classes. It works pretty well...but there are some JVMs that are more strict (than they are supposed to be) that have had issues with some of our method names (J9 that I recall offhand).

          In any case, we'll probably have to work around this in JRuby as well. I'm not sure I agree that it's a Scala issue, since getSimpleName really shouldn't blow up like this. But the way things are is the way things are. I hope Scala will find an alternative that works with current getSimpleName, and I hope the JDK gets patched to not blow up on unusually-named classes.

          Show
          Charles Oliver Nutter added a comment - We (JRuby) have had this issue brought to our attention due to an issue caused when attempting to bind one of these classes in JRuby. We use the reflection APIs in question, including getSimpleName...and as a result, the class fails to bind. I do not have a solution for you, but I will mention that JRuby has been using the techniques in John Rose's "symbolic freedom" post for many of our internal classes. It works pretty well...but there are some JVMs that are more strict (than they are supposed to be) that have had issues with some of our method names (J9 that I recall offhand). In any case, we'll probably have to work around this in JRuby as well. I'm not sure I agree that it's a Scala issue, since getSimpleName really shouldn't blow up like this. But the way things are is the way things are. I hope Scala will find an alternative that works with current getSimpleName, and I hope the JDK gets patched to not blow up on unusually-named classes.
          Hide
          Paul Phillips added a comment -

          I fixed this but pushing the fix through exceeds my abilities, so I am attaching it here in case it is of interest to others.

          Show
          Paul Phillips added a comment - I fixed this but pushing the fix through exceeds my abilities, so I am attaching it here in case it is of interest to others.
          Hide
          Olivier Toupin added a comment -

          Double nested class fail: with java.lang.InternalError: Malformed class name

          object A {
          object B {
          class C {

          }
          }
          }

          val c = new A.B.C()
          c.getClass.getSimpleName() // Throws: java.lang.InternalError: Malformed class name

          Show
          Olivier Toupin added a comment - Double nested class fail: with java.lang.InternalError: Malformed class name object A { object B { class C { } } } val c = new A.B.C() c.getClass.getSimpleName() // Throws: java.lang.InternalError: Malformed class name

            People

            • Assignee:
              Iulian Dragos
              Reporter:
              Hassan Chafi
              TracCC:
              Alan, Barry Kaplan, Eric Willigers, Erik Engbrecht, Miles Sabin, Paul Phillips, Seth Tisue
            • Votes:
              15 Vote for this issue
              Watchers:
              17 Start watching this issue

              Dates

              • Created:
                Updated:

                Development