20

I'm searching a way to include __LINE__ as a compile-time constant in outputted messages.

Various solutions seem to exist, but with a big runtime penalty as suggested in __LINE__ in JS and __LINE__ in C#. They are usually always based upon a runtime object StackFrame as log4j.

Using the log4j possibility of enabling/disabling on a needed basis isn't an option either since usually when an error happens, it's too late to enable the line numbers, and inlined code doesn't seem to have any line numbers any more. . Would it be possible to either :

  1. Pre-process the java source files before compilation, ideally with something integrated with Eclipse1, so the it can be tested on the developpement platform also.
  2. Be able to pre-process the class at loading time. The overhead would then be negligible by being amortized.

1. Actually I do use an ugly hack: calling a custom preprocessor just after checkout on the build server via ANT tricks

Community
  • 1
  • 1
Steve Schnepp
  • 4,620
  • 5
  • 39
  • 54
  • Just for my curiosity: Why do you need the line number in the logs? When an error occurs, you have the complete stacktrace, which indicates the line number... – Romain Linsolas Aug 28 '09 at 11:22
  • 4
    Sometimes in the exception, instead of the line number I have something like `Util.java(Inlined Compiled Code)`. And sometimes I don't have any exception, just logging information : "be here", "be here", I didn't want to bother having unique messages (the line number makes them unique anyway) – Steve Schnepp Aug 28 '09 at 11:32
  • The JVM should be able to handle that situation. What version of Java do you use? – Thorbjørn Ravn Andersen Aug 28 '09 at 15:59
  • To romaintaz question: We create GWT application, which is Javascript compiled from Java. During compilation, class names and line numbers are lost, so stack trace gives me useless information. It points me to compiled Javascript code, but it is difficult or impossible to find corresponding Java code from it. – Radium Jul 16 '15 at 14:40
  • 2
    Note - as of 2016 modern versions of Java do not throw line number information away when inlining. – Thorbjørn Ravn Andersen Dec 01 '16 at 12:57

7 Answers7

13

It's impossible to get the effect of __LINE__ in C which happens at compile time.

You can get line number by calling a function like this at runtime,

public static int lineNumber() {
    return Thread.currentThread().getStackTrace()[2].getLineNumber();
}
ZZ Coder
  • 74,484
  • 29
  • 137
  • 169
  • 2
    The debug-information about the line has to be compiled into the class-file, to access this information. – Mnementh Aug 28 '09 at 12:58
9

If you compile with the debug=line option, the line information exists in the class file but the VM can throw that away at runtime. This depends on some options which you can specify when you start the Java program. Usually, the performance penalty for running with debug infos is around 5% plus a bit more memory in the perm gen space. Since this information is so invaluable, I see no reason to strip this information.

Your comment (Util.java(Inlined Compiled Code)) suggest that you're using aggressive optimizations. If you can, turn those off. That way, you can simply:

// For Java 1.4, use new Exception().getStackTrace()
int line = Thread.currentThread().getStackTrace()[0].getLineNumber();

when you need it (i.e. inside of catch or if (log.isInfoEnabled())).

As for __LINE__, the Java compiler has no support for this. Your only option is to use some hacks to filter the source. I suggest to define a variable int __LINE__ somewhere and set that to some random value (0 being random enough) when you need it. Then write a filter that replaces the number in __LINE__ = \d+ with the current line number. This allows to fix the line number in place.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • Why `new Exception().getStackTrace()` rather than `Thread.currentThread().getStackTrace()`? – David Moles Aug 28 '09 at 12:12
  • No reason but the fact that I didn't bother to search the Thread class for how to get the current stack and I knew that an Exception has it :) – Aaron Digulla Aug 28 '09 at 12:51
  • +1 for the a solution that could be used also on my dev environnment (just search&replace `Thread....` with the line number in the build process) – Steve Schnepp Aug 28 '09 at 13:23
  • `Thread.currentThread().getStackTrace()` doesn't seems to exists in 1.4.2... `new Exception().getStackTrace()` it will be then. And replaced at build time with the real line number for production. – Steve Schnepp Aug 28 '09 at 14:30
  • Why do you say `Thread.currentThread().getStackTrace()[0].getLineNumber();` while answer below says `Thread.currentThread().getStackTrace()[2].getLineNumber();` and another answer below use `getStackTrace()[3]` ? Also, I tried this in my code, got a message displaying line number=1503 while it is actually line 20 in the source file. Why is that? – remi Feb 25 '13 at 13:36
  • @remi: It probably depends on your code and the Java VM. Look into the other values of the `StackFrame` to see in which class/method the line number is. That should give you an idea how to fix it. – Aaron Digulla Feb 25 '13 at 14:10
8

I've found this class makes things easy if you're looking for "got to here, got to here" type logging. I have a file Here.java that I add to my projects that contains just the following class definition:

public class Here {
    public static String at () {
        StackTraceElement ste = Thread.currentThread().getStackTrace()[3];
        String where = ste.getClassName() + " " + ste.getMethodName() + " " + ste.getLineNumber() + " ";
        return where;
    }
}

To use it in its simplest form:

Log.v(TAG, Here.At());

Or, if you want to see other stuff:

Log.v(TAG, Here.At() + String.format("interesting value = %d", my_val));

This would give "com.otherpackagenamestuff.MyClass myMethod 225" in the first case, and the same but with "interesting value = 123" appended in the second case.

Flexo
  • 87,323
  • 22
  • 191
  • 272
William T. Mallard
  • 1,562
  • 2
  • 25
  • 33
  • I use the same trick to get the line number. Depending upon how the method is coded, the index may need to be 2 instead of 3. – Santosh Tiwari Sep 18 '18 at 05:07
5

That true that out the box, these macros are not available. However, using instrumentation, and debug information you can implements it. check http://www.gallot.be/?p=85

Dominique
  • 2,019
  • 1
  • 15
  • 5
1

I would use a logging framework for this, and let it deal with the messy details. Both java.util.logging and logback can easily show information about the caller similar to what LINE can provide.

The major benefit is that the information is only computed if necessary, so not outputting means no overhead.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
0

Out of the box I don't think Java offers what you need.

However if you were to write your own annotation processor and use the Java 6.0 compiler APIs I think you could solve this problem. I wouldn't care to guess how much work it would be to do so.

Note that Eclipse allows you to include your own annotation processing in its build mechanism.

djna
  • 54,992
  • 14
  • 74
  • 117
0

I don't know about such a thing in the Java-compiler. But you could write a simple program, that replaces a token like __LINE__ with the linenumber in the file and configure your buildprocess to execute this tool before compiling. Some sort of a preprocessor.

Mnementh
  • 50,487
  • 48
  • 148
  • 202