Google Grupper har inte längre stöd för nya Usenet-inlägg eller -prenumerationer. Historiskt innehåll förblir synligt.
Dismiss

Big Jar, Slow Startup - Help !!!!

0 visningar
Hoppa till det första olästa meddelandet

Steve Webb

oläst,
18 maj 2003 05:26:582003-05-18
till
Hi,

Im working on an application on a PocketPC system. Its fairly large
and everything is included in a few JAR files some of which are fairly
big. One or two are from seperate suppliers and do things such as
supply Corba interfaces. My problem is that it takes ages for the JVM
to load everything and I suppose check all the classes.

Is there anyway (maybe a class loader ?) to load the jars but only do
checks on them when a particular class is actually first loaded. Also
how do I go about putting a loading screen up anyway as this would be
better for the user to see than a blank screen ?

Oh one final thing, in java is there an easy way to run an application
and at the end find out all the classes included in jars that weren't
actually used. I suspect a fair few of the classes that I load in the
jar files aren't actually used by our application, such as some of the
corba ones.

Thanks for any help.

Steve

Scott Hightower

oläst,
18 maj 2003 09:39:462003-05-18
till
Steve Webb wrote:

> Hi,
>
> Im working on an application on a PocketPC system. Its fairly large
> and everything is included in a few JAR files some of which are fairly
> big. One or two are from seperate suppliers and do things such as
> supply Corba interfaces. My problem is that it takes ages for the JVM
> to load everything and I suppose check all the classes.

Bad thought habit. Don't "suppose" a problem and then tackle a drastic
solution, such as a custom class loader. Find out. Solicit opinions and
make some guesses, yes, but verify them with performance analysis.

>
>
> Is there anyway (maybe a class loader ?) to load the jars but only do
> checks on them when a particular class is actually first loaded. Also
> how do I go about putting a loading screen up anyway as this would be
> better for the user to see than a blank screen ?
>
> Oh one final thing, in java is there an easy way to run an application
> and at the end find out all the classes included in jars that weren't
> actually used. I suspect a fair few of the classes that I load in the
> jar files aren't actually used by our application, such as some of the
> corba ones.
>

A static analyzer (looks at the source files) is what you want. Dynamic
analysis will miss static final constants and any code that didn't happen
to be used in your test run. JDepend is one tool you could use:
http://www.clarkware.com/software/JDepend.html
classdep is another: http://private.addcom.de/remotejava/classdep/

>
> Thanks for any help.
>
> Steve

One question that might help: do you have a lot of asterisk imports? For
example, "import com.bigjar.bigpackage.*" I don't know if that is a
factor, especially since I am not familiar with PocketPC, but if that
causes the JVM to load all the classes in a large package, and you only
use one or two, that could contribute. I say "if" because I don't
know--it's something to investigate.

Just as a for instance, "import java.util.*" refers to sixty interfaces,
classes and exceptions. It would be unusual for one class to need very
many of these.

You can use JLint to check for this, among other things.
http://artho.com/jlint/index.shtml

Regards,
Scott


Neil Campbell

oläst,
18 maj 2003 09:36:152003-05-18
till
Scott Hightower wrote:

> One question that might help: do you have a lot of asterisk imports? For
> example, "import com.bigjar.bigpackage.*" I don't know if that is a
> factor, especially since I am not familiar with PocketPC, but if that
> causes the JVM to load all the classes in a large package, and you only
> use one or two, that could contribute. I say "if" because I don't
> know--it's something to investigate.
>

Are you shure about this? The impression I had was that the import
statements were used purely for compilation, to avoid you having to
fully-qualified names for all the classes you use. I don't believe it
causes all the classes to be loaded at run-time.

--
Neil Campbell
batneil[AT]lineone[DOT]net

Neil Campbell

oläst,
18 maj 2003 10:09:572003-05-18
till
Neil Campbell wrote:

> Are you shure about this? The impression I had was that the import

'sure', even. Oops.

Jim Sculley

oläst,
18 maj 2003 10:21:292003-05-18
till

That is correct. In class files, type names are always fully qualified,
so the type of import statements that appear in the source code will not
affect runtime behavior in any way.

One way to shrink class files is to use a tool such as JAX from IBM
which makes class files as small as possible. JAX used to be freely
available, but IBM has 'graduated' it into the Websphere Studio Device
Developer product.

http://www.alphaworks.ibm.com/tech/jax

Jim S.
--
Remove my extraneous mandibular appendages to reply via e-mail.

David Thielen

oläst,
18 maj 2003 12:29:122003-05-18
till
Step 1 is to use JProbe or another program like that and find out what
is causing the slowdown. Unless you have some kind of signing going on
that is verifying the entire jar file when first used, the size of the
jar file should make no difference. And in some operating systems is
faster as you have the link table for the jar file cached and so reads
will be faster.

- dave


On 18 May 2003 02:26:58 -0700, sw...@totalise.co.uk (Steve Webb)
wrote:


Windward Reports -- http://www.WindwardReports.com
DefendTek -- http://www.DefendTek.com
Page 2 Stage -- http://www.Page2Stage.com
Enemy Nations -- http://www.EnemyNations.com
me -- http://dave.thielen.com
Barbie Science Fair -- http://www.BarbieScienceFair.info
Hillary Clinton -- http://www.HillaryIn2004.org
(yes I have lots of links)


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Tim Tyler

oläst,
18 maj 2003 12:56:262003-05-18
till
In comp.lang.java.programmer Steve Webb <sw...@totalise.co.uk> wrote:

: Oh one final thing, in java is there an easy way to run an application


: and at the end find out all the classes included in jars that weren't
: actually used.

IBM's JAX does this - though you have to look through its log file to find
out what it did.

Other things that may be useful are "Code Coverage" tools (search).

Alternatively, you can get the classloader to report on classes as
it loads them - and compare.

You can do that using java -verbose:class
...as described on:
http://java.sun.com/j2se/1.4/docs/tooldocs/win32/java.html
--
__________
|im |yler http://timtyler.org/ t...@tt1.org

David Thielen

oläst,
18 maj 2003 13:46:192003-05-18
till
A lot of the obfusticators do this too - they remove all classes and
methods that are never called by any other method. Much safer than
removing code that did not get called when running it one time.

Bent C Dalager

oläst,
18 maj 2003 13:48:522003-05-18
till
In article <HF3Dq...@bath.ac.uk>, Tim Tyler <t...@tt1.org> wrote:
>In comp.lang.java.programmer Steve Webb <sw...@totalise.co.uk> wrote:
>
>: Oh one final thing, in java is there an easy way to run an application
>: and at the end find out all the classes included in jars that weren't
>: actually used.
>
>IBM's JAX does this - though you have to look through its log file to find
>out what it did.

How do you run an application in such a way as to be sure that you
used all of the classes that can potentially be used?

Cheers
Bent D
--
Bent Dalager - b...@pvv.org - http://www.pvv.org/~bcd
powered by emacs

Scott Hightower

oläst,
18 maj 2003 16:34:562003-05-18
till
Neil Campbell wrote:

No, I am not sure. I said "if."

At one time, it was a problem with applets, because it caused all the classes
to be sent across the Internet, whether used or not. I seem to remember that
was fixed, but that's why I brought it up. As I said, I am not familiar with
the PocketPC environment. I certainly don't want to start a rumor. It's one
of the things I would think of when encountering long start time--if profiling
my application didn't explain it (clearly the first thing the OP needs to do).
And then I would research it and find out if that's what happens when you use
asterisk imports.

Personally, I don't use them--probably because I started programming applets.
It's also a maintenance nuisance--trying to guess which package a class belongs
to when all the packages are imported generically. I like finding a complete
list of imported classes when I look at someone else's code. Some folks are
bothered by long lists--but then, maybe that's a sign the class is too big and
should be broken up.

Regards,
Scott

Jon Skeet

oläst,
19 maj 2003 04:21:402003-05-19
till

Indeed it doesn't. It shouldn't affect the bytecode at all.

--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Tim Tyler

oläst,
19 maj 2003 08:04:242003-05-19
till
In comp.lang.java.programmer Bent C Dalager <b...@pvv.ntnu.no> wrote:

: In article <HF3Dq...@bath.ac.uk>, Tim Tyler <t...@tt1.org> wrote:
:>In comp.lang.java.programmer Steve Webb <sw...@totalise.co.uk> wrote:

:>: Oh one final thing, in java is there an easy way to run an application
:>: and at the end find out all the classes included in jars that weren't
:>: actually used.
:>
:>IBM's JAX does this - though you have to look through its log file to find
:>out what it did.

: How do you run an application in such a way as to be sure that you
: used all of the classes that can potentially be used?

That's not quite what JAX does. It uses a conservative technique.

It traces outwards from main, taking every possible path - thus
covering every runtime possibility in one go.

If your application uses reflection, or "Class.forName" you have to
advise JAX about that manually, if you still want it to work reliably.

me

oläst,
19 maj 2003 09:47:252003-05-19
till
>
> One question that might help: do you have a lot of asterisk imports? For
> example, "import com.bigjar.bigpackage.*" I don't know if that is a
> factor, especially since I am not familiar with PocketPC, but if that
> causes the JVM to load all the classes in a large package, and you only
> use one or two, that could contribute. I say "if" because I don't
> know--it's something to investigate.
>
> Just as a for instance, "import java.util.*" refers to sixty interfaces,
> classes and exceptions. It would be unusual for one class to need very
> many of these.

* only opens the namespace at compiletime, it has nothing to do with
what u put in your jar file.

0 nya meddelanden