How Scala several parameter lists get encoded in JVM bytecode

Question

In Scala, the following two functions are distinguished:

def paren(): Int = 42 def noparen: Int = 42 

The first has 1 parameter list with zero parameters, while the next has 0 parameter list.

However, their bytecode is identical when viewed with javap -v :

 public int paren(); Signature: ()I flags: ACC_PUBLIC Code: stack=1, locals=1, args_size=1 0: bipush 42 2: ireturn LocalVariableTable: Start Length Slot Name Signature 0 3 0 this LParentheses$; LineNumberTable: line 4: 0 public int noparen(); Signature: ()I flags: ACC_PUBLIC Code: stack=1, locals=1, args_size=1 0: bipush 42 2: ireturn LocalVariableTable: Start Length Slot Name Signature 0 3 0 this LParentheses$; LineNumberTable: line 5: 0 

Where does the Scala compiler store dimension parameter lists?

Answer 1

To test this, I used the following code and javap -v , just like you.

 @Deprecated //add an annotation for reference class Test { def test: Unit = ??? def test2(): Unit = ??? } 

at the very end, there is this conclusion:

 SourceFile: "Test.scala" RuntimeVisibleAnnotations: 0: #6() 1: #7(#8=s#9) Error: unknown attribute ScalaSig: length = 0x3 05 00 00 

Where #6 is @Deprecated and #7(#8=s#9) is @scala.reflect.ScalaSignature(bytes=...) . Thus, despite the fact that there are several methods, and the class has its own signature, there is only one ScalaSignature annotation, which encodes all the additional information of the signature in some binary format.

You already pointed to SID-10 in your answer, where it states that the signature is compressed (which is pretty obvious, given that there are no recognizable class names), and that the ScalaSig file ScalaSig was used for this before Scala 2.8. (The reason for the change is explained as the availability of reflection at runtime - (at least unknown) attributes are not saved by the JVM, annotations with proper preservation.)

Another thing to note is that while Scala signatures are a superset of Java signatures, Java signatures still need to be unique - the JVM does not care about Scala at runtime.

---

PS: this is also done in other JVM languages; one where I know that this is definitely the case of AspectJ. I think generics could be implemented in the same way, but it is not; they have their own encoding in the class file format.

Answer 2

Although he does not explicitly mention this,

SID-10 assumes that this information will be stored in ScalaSignature.