Bill Shannon wrote:
> Maybe we need a variant on this that maintains a cache of unpacked jars,
> much like Java Web Start does?
Feasible if we generated a small new main JAR as indexed (which of
course we can) and packaged that along with the user's JARs in the
cooked JAR. The smart class loader would know from the index which
nested JAR to extract when resolving a particular class or resource.
Advantages: defers expansion of a required JAR as long as possible,
avoids expanding unused JARs entirely. Disadv: engineering time needed
to build and test the smart class loader (probably not a lot of effort
but also not zero).
Depending on the particular app client this might help a lot or it might
help very little. If the client's access to items in the various JARs
is spread out over its lifetime this would spread the extraction
overhead. If the client's access pattern touches all JARs quickly then
it's about the same as we have in v2 which expands the cooked jar
entirely before starting the client. My guess: in practice, the lazy
extraction approach would let the client shows signs of life to the user
quite a bit faster than the expand-it-all-first approach.
>
> It would be really good to contact some customers who use application
> clients and find out what they want.
I can open a topic in the GF forum and send mail pointing people to it.
The key question, I think, is how they would feel about GF using the
download directory to hold multiple files for a single app client and,
therefore forcing them to do things differently:
- copying multiple files from there if they wanted to copy the
downloaded app client elsewhere, and
- using different download dirs for different clients (because this
changes would open up the possibility of collisions if a customer
currently downloads multiple clients to the same directory).
Is that along the lines you were thinking? What we have heard already
from users is that launching of large clients is too slow, and a good
deal of that is due to the expand-it-all-up-front approach in v2.
> If being concise doesn't come naturally to you (:-)), I'd suggest trying
> to break up a large topic into smaller topics, one per message.
What doesn't come naturally to me is being remote! So I guess I tend to
write more to try conveying as full a picture as possible, absent
in-person conversations with white boards handy. It's a trade-off
between brevity vs. the choppiness that can result when addressing
various pieces of a larger topic in different messages. Looks like I
missed the sweet spot on this one.
>
> On this subject, it might be worthwhile scheduling some time with asarch
> to continue the discussion.
We should do this at the asarch's earliest convenience. Let me know
when and I'll prepare an outline of the topics.
- Tim