Repetitive method name
napi
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
Or perhaps you have 2 Analyzer classes that are getting importes?
Mohd Hanafiah Abdullah
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
--
http://www.axiomsol.com
http://www.cs.indiana.edu/hyplan/napi.html
Roland
**************
How did you compile your source code? I find the source file name
"toplevel_JBC.c" rather suspicious.
--
Regards,
Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \
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
Ross Bamford
> In article <1116597325....@o13g2000cwo.googlegroups.com>,
> Rivky <rasa...@aol.com> wrote:
> >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?
>
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.
--
[Ross A. Bamford] [ross AT the.website.domain]
Roscopeco Open Tech ++ Open Source + Java + Apache + CMF
http://www.roscopec0.f9.co.uk/ + in...@the.website.domain
Daniel Sjöblom
> On Fri, 2005-05-20 at 14:09 +0000, Mohd Hanafiah Abdullah wrote:
>
>>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.
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.
--
Daniel Sjöblom
Remove _NOSPAM to reply by mail
Ross Bamford
> Ross Bamford wrote:
> > On Fri, 2005-05-20 at 14:09 +0000, Mohd Hanafiah Abdullah wrote:
> >
> >>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.
>
> 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.
> > 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.
>
Intriguing. I've never tried it... What happens when you load the
bytecode?
Daniel Sjöblom
> On Sat, 2005-05-21 at 16:46 +0300, Daniel Sjöblom wrote:
>>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.
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 :-)
>>>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.
>
> 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/String;)V
.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
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
> Ross Bamford wrote:
> > On Sat, 2005-05-21 at 16:46 +0300, Daniel Sjöblom wrote:
>
> >>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.
>
> 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)...
> >>>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.
> >
> > 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:
>
Like it. I'd never considered this. Looks like I'm spending a day
playing with bytecode (again) :)