What is the internal identification of a Java method?

Question

As we know, in Java, method name is not sufficient to distinguish different methods.

I think (may be wrong), to distinguish a method, it needs the following info:

(className, methodName, methodParameters)

Further,

how to identify a method more efficiently internally?
I heard of "method id". Does it mean there is a mapping between the above triple and an integer, so JVM use only method id after parsing?
If so, is it resided in symbol table?

Thanks!

Your question is too vague. Are you talking about identifying the method in the compiler? In the ".class" file? In the executing program? — Stephen C, Jun 16 '12 at 04:19

score 7 · Accepted Answer · answered Jun 16 '12 at 04:05

7

It's a CONSTANT_NameAndType_info Structure pointing at a method descriptor.

It pretty much consists of the method name, the parameter types, and (somewhat surprisingly) the return type.

answered Jun 16 '12 at 04:05

Laurence Gonsalves

137,896
35
246
299

score 0 · Answer 2 · edited Jun 16 '12 at 04:41

0

Java always differentiate its language elements by their fully qualified names.

Suppose you have a method myMethod(int a, int b) in class MyClass which lies in the package com.mypackage then java will identify the method with the name com.mypackage.MyClass.myMethod(int a , int b).

Just to give you some more insight, it also takes the Class Loader into consideration when there is a need to resolve two identical elements.

It does consider, which class loader was used to load the particular class containing the method to which you are referring. There are four types of class loaders in java. You can read the documention for java.lang.Thread class for this.

edited Jun 16 '12 at 04:41

Mike Samuel

118,113
30
216
245

answered Jun 16 '12 at 04:08

dharam

7,882
15
65
93

1

What do you mean by "There are four types of class loaders in java"? – Mike Samuel Jun 16 '12 at 04:41
A class which is loaded by the JVM can be loaded by any of the below four class loaders: 1) Bootstrap class loader 2) Extension class loader 3) System class loader 4) Application class loader Please see they have their own significance. For details please see the below link. http://javapapers.com/core-java/java-class-loader/ – dharam Jun 16 '12 at 05:06
Ah ok. (4) is not bounded the way the others are, and the first three are only distinguished by system property conventions for specifying search paths. What does this have to do with threads or method lookup? The method is based on the class, so depends on the classloader indirectly, but how does mentioning one taxonomy of classloaders address the original question? – Mike Samuel Jun 16 '12 at 05:31
For differentiating methods with similar signature, we need fully qualified class names , and the classes indirectly depends on the class loaders. This problem is widely seen on IBM Websphere 6.0.1 where if we put two jars common-collections.3.2.jar and commons.collections.2.0.jar then it cannot differentiate between few of the methods in the SetUtil class of both the jars. In that situation we need to define the loading policies of both the jars in general. – dharam Jun 16 '12 at 05:37

brandizzi · Answer 3 · 2012-06-16T04:29:43.053

I do not understand very well what you are trying to do but I think there are some possible answers nonetheless:

You may be interested in the JNI Method Descriptors, one of the various string formats used internally by the JVM (and by JNI libraries) for identifying Java elements.
It is difficult to know about what you are talking about. The "method id" can be a reference for a java.lang.reflect.Method object, or can be the method descriptor mentioned below, or any other thing. Where did you read about it?
I doubt there is such table inside the JVM. I mean, I doubt there is a global table, because almost always you retrieve a method from a class, even when dealing with it inside the JVM, so it is reasonable to believe the method is stored in the class. It is likewhen we use reflection to retrieve a method:
```
Class clazz = String.class;
Method method = clazz.getDeclaredMethod("charAt", Integer.TYPE);
System.out.println(method.getName());
```

Note that I ask the class String for the method, instead of asking some util class to give me the method charAt, which receives an int and is from the class String.

In other words, your identification tuple is almost correct - it just does not have a class:

(methodName, methodParameters)

and, instead of retrieving the method from the JVM passing the class and then the method name and then the parameter types, you retrieve the method directly from the class, giving the class the method name and the parameter types. A subtle difference, for sure, but I think it is what you are wondering about.

This is evident even in the JNI descriptors I mentioned below. For example, the method

long f(int i, Class c);

is represented by the following descriptor:

"(ILjava/lang/Class;)J"

Note that there is no reference to the class of the method.

The excellent documentation on the class file format (already pointed by @Lawence) may give you some insights. I recommend you to read it fully.

"I doubt there is such table inside the JVM." A JVM could define such a table for internal use, but doing so might complicate garbage collection of classloaders. — Mike Samuel, Jun 16 '12 at 04:42

score 0 · Answer 4 · answered Jun 16 '12 at 04:35

1) How to identify a method more efficiently internally?

Internally to what? There are many places where a method might need to be "identified" "internally". In the bytecode compiler, the JIT compiler, the classloader / linker, the classfile representation, reflection API, a debugger and so on. They each have different efficiency concerns.

2) I heard of "method id". Does it mean there is a mapping between the above triple and an integer, so JVM use only method id after parsing?

A method id is used in the classfile representation, and could be used by anything based on that, including the class loader / linker, the JIT compiler and the debugger.

The JVM doesn't parse Java code.

3) If so, is it resided in symbol table?

It might do. It depends on what you mean by "the symbol table". Bear in mind that there are lots of places where method identification is required, throughout the lifecycle of a class. For instance, the Java reflection APIs require method information to implement methods such as getDeclaredMethod(...) and various methods of Method.

What is the internal identification of a Java method?

4 Answers4