Is it possible, given a java.lang.Class
object, to get the source file name and the line number at which the class was declared?
The data should be available in the .class
file's debug info. The only place I know of, where the JDK returns such debug info is in java.lang.StackTraceElement
but I'm not sure if it's possible to force Java to create a java.lang.StackTraceElement
instance for an arbitrary class, b开发者_开发百科ecause we are not executing a method in the class.
My exact use case is an anonymous inner class which has a compiler generated name. I want to know the file name and the line number for the class declaration.
I prefer not to use a byte-code manipulation framework, but I can fall back to it if I have to.
The answer to this comes down to how much control you have over the code that is implementing the Listener. You are right that it is not possible to create a stacktrace without being in a method.
The general technique is to create an Exception(), in the constructor, but don't throw it. This contains the stacktrace information, which you can use how you want. This will give you the line number of the constructor, but not of the class. Please note that this method is not particularly performant either, because creating a stacktrace is expensive.
You will need to either:
- force some code to be executed in the constructor (relatively easy if your Listener is an abstract class which you control)
- Instrument the code somehow (the cure seems worse than the disease here).
- Make some assumptions about the way classes are named.
- Read the jar (do the same thing as javac -p)
For 1), you'd simply put the Exception creation in the abstract class, and the constructor gets called by the subclass:
class Top {
Top() {
new Exception().printStackTrace(System.out);
}
}
class Bottom extends Top {
public static void main(String[] args) {
new Bottom();
}
}
this produces something like:
java.lang.Exception
at uk.co.farwell.stackoverflow.Top.<init>(Top.java:4)
at uk.co.farwell.stackoverflow.Bottom.<init>(Bottom.java: 11)
at uk.co.farwell.stackoverflow.Bottom.main(Bottom.java: 18)
In general, there are some naming rules which are followed: If you have an outer class called Actor and an inner called Consumer, then the compiled class will be called Actor$Consumer. Anonymous inner classes are named in the order in which they appear in the file, so Actor$1 will appear in the file before Actor$2. I don't think this is actually specified anywhere, so this is probably just a convention, and shouldn't be relied upon if you're doing anything sophisticated with multiple jvms etc.
It is possible, as jmg pointed out, that you can define multiple top level classes in the same file. If you have a public class Foo, this must be defined in Foo.java, but a non-public class can be included in another file. The above method will cope with this.
Explanation:
If you disassemble the java (javap -c -verbose), you'll see that there are line numbers in the debug information, but they only apply to methods. Using the following inner class:
static class Consumer implements Runnable {
public void run() {
// stuff
}
}
and the javap output contains:
uk.co.farwell.stackoverflow.Actors$Consumer();
Code:
Stack=1, Locals=1, Args_size=1
0: aload_0
1: invokespecial #10; //Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 20: 0
LocalVariableTable:
Start Length Slot Name Signature
0 5 0 this Luk/co/farwell/stackoverflow/Actors$Consumer;
The LineNumberTable contains the list of line numbers which apply to a method. So my constructor for the Consumer starts at line 20. But this is the first line of the constructor, not the first line of the class. It is only the same line because I'm using the default constructor. If I add a constructor, then the line numbers will change. the compiler does not store the line that the class is declared on. So you can't find where the class is declared without parsing the java itself. You simply don't have the information available.
However, if you're using an anonymous inner class such as:
Runnable run = new Runnable() {
public void run() {
}
};
Then the line number of the constructor and class will match[*], so this gives you an line number.
[*] Except if the "new" and "Runnable()" are on different lines.
You can find uut current line of code:
Throwable t = new Throwable();
System.out.println(t.getStackTrace()[0].getLineNumber());
But it looks like StackTraceElements
are created by native JDK method inside Throwable
.
public synchronized native Throwable fillInStackTrace();
Event if you use byte-code manipulation framework, to add a method to a class that creates throwable, you won't get proper line of code of class declaration.
You can get a stack trace from any thread by calling getStackTrace(). Therfore for the current thread you have to call Thread.currentThread().getStackTrace()
.
For your purposes, generating an exception just for its stack trace is the right answer.
But in cases where that doesn't work, you can also use Apache BCEL to analyze Java byte code. If this sounds like heavy-handed overkill, you're probably right.
public boolean isScala(Class jvmClass) {
JavaClass bpelClass = Repository.lookupClass(jvmClass.getName());
return (bpelClass.getFileName().endsWith(".scala");
}
(Warning: I haven't tested this code.)
Another option is to build a custom doclet to gather the appropriate metadata at compile time. I've used this in the past for an application which needed to know at runtime all the subclasses of a particular superclass. Adding them to a factory method was too unwieldy, and this also let me link directly to javadoc.
Now that I'm writing new code in Scala, I'm considering using a technique like the above, and generating a list of classes by searching the build directory.
This is how I did it:
import java.io.PrintWriter;
import java.io.StringWriter;
/**
* This class is used to determine where an object is instantiated from by extending it.
*/
public abstract class StackTracer {
protected StackTracer() {
System.out.println( shortenedStackTrace( new Exception(), 6 ) );
}
public static String shortenedStackTrace(Exception e, int maxLines) {
StringWriter writer = new StringWriter();
e.printStackTrace( new PrintWriter(writer) );
String[] lines = writer.toString().split("\n");
StringBuilder sb = new StringBuilder();
for (int i = 0; i < Math.min(lines.length, maxLines); i++) {
sb.append(lines[i]).append("\n");
}
return sb.toString();
}
}
EDIT: Looking back on this, I would probably use AOP to do this now. In fact, some minor changes to this project and I could probably do it. Here is a stack question with a hint.
This answer does not cover line numbers, but it met my needs and should work for any source file you own.
This is an answer for finding the location of a source file based on a class file for an IDE that has multiple projects. It leverages the class loader and your java project conventions to solve this issue.
You will need to update your source folder (src) and output folder (bin) to match your convention. You will have to supply your own implementation of
String searchReplace(old, new, inside)
Here is the code
public static String sourceFileFromClass(Class<?> clazz) {
String answer = null;
try {
if (clazz.getEnclosingClass() != null) {
clazz = clazz.getEnclosingClass();
}
String simpleName = clazz.getSimpleName();
// the .class file should exist from where it was loaded!
URL url = clazz.getResource(simpleName + ".class");
String sourceFile = searchReplace(".class", ".java", url.toString());
sourceFile = searchReplace("file:/", "", sourceFile);
sourceFile = searchReplace("/bin/", "/src/", sourceFile);
if( new java.io.File(sourceFile).exists() ) {
answer = sourceFile;
}
}
catch (Exception ex) {
// ignore
}
return answer;
}
Is it possible given a java.lang.Class instance to get the source file name and the line number at which the class has been declared?
The source file is in most cases strongly related to the class name. There is only one line in that file in which the class is declared. There is no need for this kind of unambiguous information to be encoded in the debug information.
The data should be available in the .class file 's debug info
Why?
精彩评论