Name: rmT116609			Date: 04/01/2004


A DESCRIPTION OF THE REQUEST :
Provide a tool (or a javac option) that directly generates a jar file from a given set of source files. This would combine the functionality of the javac and jar tools, but the value of this would be greater than the sum of the parts. 

For example:
javac -jar app.jar A.java B.java C.java
This command compiles exactly the files A.java, B.java, and C.java. It does not compile any other files. It does not write class files to disk. Instead, it creates a new jar file app.jar (overwriting the file if it already exists) and writes into it exactly all class files generated from A.java, B.java, and C.java.

Another example:
javac -exejar app.jar A.java B.java C.java
This does the same thing as the previous example, except that it also checks that exactly one class declared in the named source files declares a main method. Otherwise, the command fails. It includes a manifest in the generated jar file with a Main-Class attribute.

Another example:
javac -exejar app.jar -mainclass MyMainClass A.java B.java C.java
Obvious semantics.

Another example:
javac -exejar app.jar A.java B.java C.java -resource D.gif -resource E.jpg
Any number of -resource options can be given. Resource files are included in the jar file verbatim.

Another example:
javac -exejar app.jar A.java B.java C.java -resource D.gif,mypackage/D.gif
Specify the desired path of the resource in the generated jar file

JUSTIFICATION :
The user knows exactly which source files are read and compiled, and which files are written. This is a huge improvement over the current state of affairs, where only advanced users have a complete understanding of what happens when they type "javac A.java B.java C.java".

How to get the same functionality today:
del *.class
javac -sourcepath C:\nonexistingpath A.java B.java C.java
echo "Main-Class: MyMainClass" > Manifest.txt
jar cmf Manifest.txt app.jar *.class
del *.class
del Manifest.txt

I delete the class files beforehand, so that no class files from a previous compilation (which might have created a different set of class files) are included in the jar file, and, if the classpath includes the current directory, so that class files from a prior compilation are not included in the current compilation.
I use "-sourcepath C:\nonexistingpath" to make sure no other source files are accidentally included in compilation. I assume that C:\nonexistingpath is a non-existing path. If I were to use -sourcepath "", javac would ignore the option and use the classpath as the sourcepath, which is undesirable.
I delete the class files and the manifest file afterwards, which I consider to be temporary files about which I do not care and for which I have no use.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A simple semantics, where you know what goes in and you know what comes out.
ACTUAL -
A complex semantics, where the set of files included in compilation, either source files or class files (for resolution and type checking) is highly context-dependent and hard to tell, and the set of files generated is very hard to predict and also simply not useful in many scenarios. We often do not want a bunch of funky-named class files; we want a simple executable jar file.


(Incident Review ID: 242520) 
======================================================================