A DESCRIPTION OF THE REQUEST :
__FILE__ should be a keyword which is replaced with a literal string uniquely identifying the
compilation unit, which in most cases would be the file name.  It should include the package directory names but not other directory names.  For instance, "com/mycompany/Foo.java" but not "/home/myname/mysrcdir/com/mycompany/Foo.java".   An acceptable alternative would be to just provide whatever would otherwise comeback from the Throwable.getFileName() method.

__LINE__ should correspond to the line number within the compilation unit, or whatever would come back from Throwable.getLineNumber() on that platform.

__CLASS__ and __METHOD__ should behave similarly, although the class name is the one piece of these 4 that can currently be accessed efficiently.

all 4 of these tokens should have the same zero run time overhead that would result from using the token "MyClass.java"  instead of __FILE__.


The extra credit feature that would leap frog other languages in its support for real developer requirements would be to support compile time efficient access to the *calling*
functions __FILE__,__LINE__,__CLASS__, and __METHOD__, eg __CALLER_FILE__, etc...

JUSTIFICATION :
Detailed logging enables a lot more programmer efficiency than stepping through a debugger.  printf() style debugging is what many java users do, which is why log4j is
such a popular project within the java community.

Creating a new throwable to get stack trace information is too inefficient to allow for detailed debug logging without imposing an unacceptable performance limitation in many cases.

Please dont close the RFE before other people have had an opportunity to vote on it, as happened the last time.(4411102)  Please dont use platform compatibility as an excuse, as happened with environment variables for years, since this doesnt need anything that isnt already in Throwable.  Please feel free to substitute equivalent solutions that are more aesthetically pleasing.


CUSTOMER SUBMITTED WORKAROUND :
The current work around is to create a Throwable object and walk up the frame stack, or
print out its stack trace and parse it.  See log4j for implementation examples of jumping through this hoop.    This workaround only works for code that can afford to be very very slow.