Repetitive method name

[napi]

I got the following error when running a Java program. What could be
the
problem? Thanks for any tips.

Napi

----------------------Cut here---------------------

java toplevel_JBC
Exception in thread "main" java.lang.ClassFormatError: Repetitive
method name/signature in class file Analyzer
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at _touch_files._touch_files(_touch_files.c)
at toplevel_JBC.#C_main(toplevel_JBC.c)
at toplevel_JBC.main(toplevel_JBC.c)

 

[Rivky]

Do you have 2 methods with the same name and parameters defined?

Or perhaps you have 2 Analyzer classes that are getting importes?

 

[Mohd Hanafiah Abdullah]

Do you have 2 methods with the same name and parameters defined?
No

Or perhaps you have 2 Analyzer classes that are getting importes?

No

Is there a limit to the number of characters in a method's name?

Thanks.

Napi

 

[Chris Uppal]

Exception in thread "main" java.lang.ClassFormatError: Repetitive
method name/signature in class file Analyzer

It means that the classfile for class Analyzer is probably corrupt, or that it
has been modified in a way that a Java compiler would not do. It has (at
least) two methods with the same declared name, argument types, and return
types -- and that isn't legal in a classfile, so the JVM is refusing to load
it.

Perhaps the result of a buggy bytecode obfuscator ?

-- chris

 

[Roland]

I got the following error when running a Java program. What could be
the
problem? Thanks for any tips.

Napi

----------------------Cut here---------------------

java toplevel_JBC
Exception in thread "main" java.lang.ClassFormatError: Repetitive
method name/signature in class file Analyzer
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at _touch_files._touch_files(_touch_files.c)
at toplevel_JBC.#C_main(toplevel_JBC.c)
at toplevel_JBC.main(toplevel_JBC.c)

**************
How did you compile your source code? I find the source file name
"toplevel_JBC.c" rather suspicious.
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[Ross Bamford]

No

Is there a limit to the number of characters in a method's name?

No.

There is a limit (of 255 characters) on the canonical representations of
the parameters in the signature, but not the name. The name is a UTF-8
string from the constant pool.

I've seen this error before with CGLIB, and obfuscators make it happen
too if you run them wrong. Generally it's a symptom of bytecode
problems, almost always in code not generated by javac (it catches this
at compile time). You have two methods in your bytecode with the same
signature as defined by:

http://java.sun.com/docs/books/vmspec/2nd-
edition/html/ClassFile.doc.html#7035

Remember you can't overload on return type alone.

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

No.

There is a limit (of 255 characters) on the canonical representations of
the parameters in the signature, but not the name. The name is a UTF-8
string from the constant pool.

Nitpick. This is not true. The limit of 255 is on number of parameters
(calculated in a specific way, long and double parameters are counted
twice), not on the length of the UTF-8 string. The UTF-8 string cannot
contain more than 2^16 - 1 characters.

Remember you can't overload on return type alone.

It is very much possible to do so in bytecode. It is however not
possible to have a static method and an instance method with the same
name and same descriptor.

 

[Ross Bamford]

Nitpick. This is not true. The limit of 255 is on number of parameters
(calculated in a specific way, long and double parameters are counted
twice), not on the length of the UTF-8 string. The UTF-8 string cannot
contain more than 2^16 - 1 characters.

Right, it was that bit that threw me. I originally thought it was 255
params, but then looked it up and the double-contributions of double and
long made me doubt myself. I read it as 255 characters after the type id
resolutions.

It is very much possible to do so in bytecode. It is however not
possible to have a static method and an instance method with the same
name and same descriptor.

Intriguing. I've never tried it... What happens when you load the
bytecode?

 

[Guest]

Right, it was that bit that threw me. I originally thought it was 255
params, but then looked it up and the double-contributions of double and
long made me doubt myself. I read it as 255 characters after the type id
resolutions.

The part about counting doubles and longs twice is derived from the fact
that doubles and longs take up two stack slots on the VM stack. I'm not
sure what difference that makes in this context, so you are right about
it being rather weird. But then again, this isn't the only wart in the
JVM spec

Intriguing. I've never tried it... What happens when you load the
bytecode?

Nothing out of the ordinary, it works as expected. If you want to test
it, you can compile this snippet with jasmin to see for yourself:

..class public BCTest
..super java/lang/Object

; Default constructor

..method public <init>()V
.limit locals 1
.limit stack 1
aload_0
invokespecial java/lang/Object/<init>()V
return
..end method

; Main, print result of the two methods with
; signature differing only in return type.

..method public static main([Ljava/lang/StringV
.limit locals 1
.limit stack 2

getstatic java/lang/System/out Ljava/io/PrintStream;
invokestatic BCTest/test()F
invokevirtual java/io/PrintStream/println(F)V
getstatic java/lang/System/out Ljava/io/PrintStream;
invokestatic BCTest/test()I
invokevirtual java/io/PrintStream/println(I)V
return
..end method

; Method that looks like this in java:
; public static float test()
;
..method public static test()F
.limit locals 0
.limit stack 1

ldc 3.14
freturn
..end method

; Method that looks like this in java:
; public static int test()
;
..method public static test()I
.limit locals 0
.limit stack 1

bipush 42
ireturn
..end method

 

[napi]

**************
How did you compile your source code? I find the source file name
"toplevel_JBC.c" rather suspicious.

I've found the problem. It has more than one method declarations
without
method names. A bug in the compiler. And after grep-ping the
assembly code
I found many of the following code:

..method public static ([Ljava/lang/String;[I)V
..method public static ([Ljava/lang/String;[I)V
....

It was generated by a C to Java Bytecode (AMPC) compiler I wrote, and
the problem has been resolved.

Thanks for all the feedback.

Napi

 

[Ross Bamford]

The part about counting doubles and longs twice is derived from the fact
that doubles and longs take up two stack slots on the VM stack. I'm not
sure what difference that makes in this context, so you are right about
it being rather weird. But then again, this isn't the only wart in the
JVM spec

No, that's certainly true .. it seemed wierd, but your description has
just made it click for me. It *is* stack slots isn't it? So it's just
their strategy for handling 64-bit parameters (i.e. split them into two
32-bits)...

Nothing out of the ordinary, it works as expected. If you want to test
it, you can compile this snippet with jasmin to see for yourself:

Like it. I'd never considered this. Looks like I'm spending a day
playing with bytecode (again)