Name: gm110360 Date: 03/07/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Windows 2000 Pro Sp1

ADDITIONAL OPERATING SYSTEMS :
Windows NT 4.0
Linux
etc.


A DESCRIPTION OF THE PROBLEM :
I would like to be able to get at execution time, the
compilation date/time of a class. Right now, I can do this
by:

1. If the class file is in a JAR file, getting the JAR URL,
then the JAR File, then the JarEntry, and then the
date/time.

2. If the class file is NOT in a JAR file, getting the path
to the class file, and getting its lastModified date/time.

While I have this working just fine in my Java
applications, it would really be nice to be able to
retrieve the compilation date/time of the class as an
attribute of the class; e.g.:

long dateTime = MyClass.class.getBuildTime();

This would be a LOT simpler and more portable as well.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. N/A
2.
3.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
try {
    jarUrl = Main.class.getResource( "Main.class" );
    jarFile = ((JarURLConnection) jarUrl.openConnection()).getJarFile();
    log( logLevel_DEBUG, "Jar file: " + jarFile.getName() );
} catch ( Exception exception ){ // No JAR file
    log( logLevel_DEBUG, exception );
}

try {
    return new Date( pathName != null ? new File( pathName
+ fileName ).lastModified()
: jarFile != null ? jarFile.getEntry( fileName ).getTime()
: new File( fileName ).lastModified() );
} catch ( Exception exception ){
    log( logLevel_DEBUG, exception );
    throw new FileNotFoundException( fileName );
}

---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Code segment above
(Review ID: 143826)
======================================================================

Name: jl125535 Date: 03/07/2002


FULL PRODUCT VERSION :
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)


FULL OPERATING SYSTEM VERSION :
Windows NT Version 4.0

ADDITIONAL OPERATING SYSTEMS :
(All others)


A DESCRIPTION OF THE PROBLEM :
Unrelated bugs: 4615070

It would be nice to add predefined identifiers to the Java
language which evaluate at compile time to strings that
specify the date and time of compilation. These would be
similar in spirit to the predefined '__DATE__' and
'__TIME__' macros of C/C++, but could be provided without
all of the ugliness of a preprocessor.

Rather than invent new keywords for this, it would probably
be better to invent a new "compile-time information" class
that is specially handled by the javac compiler.

For example, I'd like to embed the date and time that my
class was compiled, in the form of a "what-string" that
is accessible by the unix what(1) utility:

    class Foo
    {
        // Embedded identification info
        static final String REV =
            "@(#)$Header$\n";

        static final String BUILT =
            "@(#)Built: " + CompileTime.DATE
            + " " + CompileTime.TIME + "\n";

        ...
    }

RCS users will recognize the first constant, 'REV', which
is expanded into source code revision information about
the source file, which winds up being embedded within the
bytecode (.class) file, and which can be displayed by a
user with the what(1) utility.

The second constant, 'BUILT', utilizes the proposed
'java.lang.CompileTime' class, which contains the members
'DATE' and 'TIME'. These members are evaluated at compile
time to the date and time, respectively, that the Java
compiler was run on the source file. The resulting string
constant winds up being embedded in the bytecode (.class)
file.

A recommended format for each of these constants is:

    DATE: "yyyy-mm-dd" (e.g., "2002-03-15")
    TIME: "hh:mm:ss.mmm" (e.g., "14:33:08.166")

These formats are based on the ISO 8601 formats for
specifying dates and time, and thus do not reflect any
particular region-specific format. It would also be
convenient if these values were relative to UTC instead of
the local timezone, making their values independent of
the location that the source file was compiled.

Other uses include things like:

    System.out.println("Class " + this.getClass.getName()
        + " compiled on "
        + CompileTime.DATE.substring(5, 10) + " at "
        + CompileTime.TIME.substring(0, 5) + ".");

which would display something like:

    Class Foo compiled on 03-15 at 14:33.

Formally, the CompileTime class is:

    public final class java.lang.CompileTime
    {
        public static final String DATE = "yyyy-mm-dd";
        public static final String TIME = "hh:mm:ss.mmm";
    }

Other compile-time member constants could be added (e.g.,
user-ID, working directory, source filename, etc.), but we
don't want to overdesign this feature just yet. Perhaps
one more member:

    public static final String VERSION = "x.x.x";

which is the version number of the compiler/JDK.


This bug can be reproduced always.

CUSTOMER WORKAROUND :
I use a specially written program as part of my compilation
process that generates Java source code containing the
current date and time (and a few other informational items)
as constant members in a class, which I then have to
compile separately and include in my package jarfile.
(Review ID: 143771)
======================================================================