«

Kuki Szabolcs wrote:
> On Mar 13, 9:39 am, Knute Johnson <>
> wrote:
>> Bryan wrote:
>>> Hello all,
>>> 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!
>> 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/
>
> 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.
>

The easiest way I can think of is to use the -verbose:class option at
runtime and see which classes are listed as loaded.

Joshua Cranmer wrote:
> 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.

"Bryan" <> wrote on 12 Mar 2007 21:54:10 -0700
in comp.lang.java.programmer:

>Hello all,
>
>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?



Check this: http://www.bmsi.com/java/ZipLock.java


--
Check out QueryForm, a free, open source, Java/Swing-based
front end for relational databases.

http://qform.sourceforge.net

If you're a musician, check out RPitch Relative Pitch
Ear Training Software.

http://rpitch.sourceforge.net

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?

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

Mike Schilling wrote:
> Joshua Cranmer wrote:
>> 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.
>
>
The problem with doing it like that is that one needs to analyze dead
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.

On Mar 13, 3:54 pm, "Bryan" <BTRichard...@gmail.com> wrote:
....
> ...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.

Joshua Cranmer wrote:
> Mike Schilling wrote:
>> Joshua Cranmer wrote:
>>> 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.
>>
>>
> The problem with doing it like that is that one needs to analyze dead
> 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.

They you'll need to exercise all of the code paths; guaranteeing that would
be tricky at best.

On Mar 13, 11:30 pm, "Mike Schilling" <mscottschill...@hotmail.com>
wrote:
> Joshua Cranmer wrote:
> > 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.
Actually, it is not that hard. There is a library called ASM from
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/...nd-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