How to create a JAR that contains only the class files needed
Bryan
I'm sure this has been asked before but I could not find it... is
there a program out there that will create a JAR file that only
includes the class files needed by the main class to run?
Thanks in advance!
Knute Johnson
I write a batch file to do that every time I create a new project. It
is really pretty simple to do. I even have it clean up the class files
and editor backup files.
--
Knute Johnson
email s/nospam/knute/
Kuki Szabolcs
wrote:
No, really a tool like a java profiler or something that can see which
classes are loaded and used while running an application.
So for example I include log4j or xerces but I don't use every class
from there while running my application.
So the question is if there is an application which can slim down, or
make a list of actual classes that are used by a cirtain application.
Thank You,
Kuki Szabolcs
Kuki Szabolcs
Please let me know if you find an answer to this question.
I was thinking that it would require a profiler like JRat or something
like that to create a list of classes that were loaded, during the
application run.
Then rebuild the jar file with only that list of file.
Of course this method is somewhat dangerous because the application
has to be tested with all the possible code paths. Because you might
have somewhere new Class("com.xxxx").newInstance() call which
otherwise is not mapped.
sivasu...@gmail.com
I will tell you a way to create a Executable jar
First write a Manifest.mf file with contents as
Manifest-version:1.0
Main-Class:Hello
then create the archiving using the jar command
jar cmf Manifest.mf Hello.jar Hello.class
if you don't give java file then no problem
All the best....
Kuki Szabolcs
wrote:
Yes, that is a good way to create an executable jar file, but what we
would like is to have an application that would analyze which classes
are needed by a main function.
For example: when we have a source tree of 2000+ files and we create
another main class which might use only 1% of this code base, then it
would be nice to have an application that could detect which classes
are used by that newly created java/main class.
And this way be able to have a jar file with only 40 files instead of
2000+.
Hope this is clear enough ...
Chris Uppal
> I'm sure this has been asked before but I could not find it... is
> there a program out there that will create a JAR file that only
> includes the class files needed by the main class to run?
Many obfuscators have this feature (it comes almost for free as a side effect
of the analysis an obfuscator has to do anyway). E.g. ProGuard.
Some links:
http://jarg.sourceforge.net/
http://www.alphaworks.ibm.com/tech/jax/
http://www.e-t.com/jshrink.html
http://proguard.sourceforge.net/
http://www.fightingquaker.com/jaropt/
Note: I haven't so much as downloaded /any/ of those packages.
-- chris
Kuki Szabolcs
Great Thank You,
Many Thanks :)
PS: here is something nice for you :)
http://www.youtube.com/watch?v=is8bR6UtqxA
Knute Johnson
I don't keep .class files laying around in my package tree. I only
compile the classes I need for my application and then I delete them. I
never have extra classes in my .jars.
Mike Schilling
> Bryan wrote:
>
>> I'm sure this has been asked before but I could not find it... is
>> there a program out there that will create a JAR file that only
>> includes the class files needed by the main class to run?
>
> Many obfuscators have this feature (it comes almost for free as a
> side effect of the analysis an obfuscator has to do anyway). E.g.
> ProGuard.
Note that these probably won't work when classes are loaded reflectively,
e.g. using Class.forName(). They certainly won't work when a simple static
analysis won't reveal the name of the class to be found.
Joshua Cranmer
The easiest way I can think of is to use the -verbose:class option at
runtime and see which classes are listed as loaded.
Mike Schilling
> Kuki Szabolcs wrote:
>>
>> Please let me know if you find an answer to this question.
>> I was thinking that it would require a profiler like JRat or
>> something like that to create a list of classes that were loaded,
>> during the application run.
>>
>> Then rebuild the jar file with only that list of file.
>>
>> Of course this method is somewhat dangerous because the application
>> has to be tested with all the possible code paths. Because you might
>> have somewhere new Class("com.xxxx").newInstance() call which
>> otherwise is not mapped.
Java classes are always loaded lazily. Even wthout reflective calls,
different code paths can result in different classes being loaded.
>
> The easiest way I can think of is to use the -verbose:class option at
> runtime and see which classes are listed as loaded.
If you want to do it reliably, you'll need to analyze the class files and
see which classes they reference (recursively, of course.) This is
non-trivial.
Dave Glasser
in comp.lang.java.programmer:
Check this: http://www.bmsi.com/java/ZipLock.java
--
Check out QueryForm, a free, open source, Java/Swing-based
front end for relational databases.
If you're a musician, check out RPitch Relative Pitch
Ear Training Software.
Tom Hawtin
>
> I'm sure this has been asked before but I could not find it... is
> there a program out there that will create a JAR file that only
> includes the class files needed by the main class to run?
javac will automatically compile any source file for which it needs the
class file (so long as you use the correct file names). So do a fresh
build specifying only the main class and any other class you use through
reflection or other means (services, for instance). javac will compile
those files that you need. Bob is now your mother's brother.
Tom Hawtin
Joshua Cranmer
code instead of just the referenced class files. I figured it would be
quite rare that someone has classes that they don't use at all in the
code, instead the extraneous classes were referenced in unused (but
still compiled) code.
Andrew Thompson
...
> ...is
> there a program out there that will create a JAR file that only
> includes the class files needed by the main class to run?
The JVM itself (at runtime) can act as the
program which determines the classes required.
If the application is deployed using JWS, and
the packages* broken into separate parts and
specified as 'lazy' downloads, not only will
the minimum classes be downloaded for the
application, but should the end user go into
a part of the program that requires classes that
are *not* cached locally, the classes will be
downloaded, cached, and made available to the
JVM before proceeding.
* I Think it can also be done for individual
classes, as well as packages.
Andrew T.
Mike Schilling
They you'll need to exercise all of the code paths; guaranteeing that would
be tricky at best.
pkriens
wrote:
Objectweb that parses the class files. It is quite easy to create the
dependency graph from this.
I wrote a program for the OSGi headers that makes a dependency graph
but this is based on packages, not classes (OSGi is very focused on
seeing a package as a first class citizen). The program is currently
not creating the payload of the jar from this tree but that would be
quite trivial to add. You can download the code from
http://www.aqute.biz/repo/biz/aQute/bnd/0.0.115/bnd-0.0.115.jar. The
source code is in the JAR in the OPT-INF/src directory. This program
actually has its own class file parser.
Kind regards,
Peter Kriens