> John Arthorne wrote:
> > Having said that, altering the runtime structure of plugins to
> > workaround development time limitations seems to be a poor reason
> > not doing this valuable optimization.
> I agree that having jar'ed plug-ins is of great value but is nested
> really an optimization? I might be wrong (haven't tested) but I doubt
> that any gain in performance, memory consumption, or even significant
> size on disk can be proven.
Well, it really depends on the situation. If a plugin
contains a nested jar, plus thousands of other files, there is certainly
performance gain in install time, disk space, etc, from jarring. The benefit
of jarring tends to accumulate over a large body of plugins - it might
be a small gain for a single plugin, but for an application with a 1000
plugins, it adds up.
> > It's certainly not the case that all plugins that contain nested
> > cannot be jarred.
> Of course not. My point is that the since the compiler fails to
> recognize nested jars, any downstream project depending on such plug-ins
> have to go through the hassle that I described earlier. I'm questioning
> why that is recommended and why it's considered good citizenship.
I think the problem is that it's hard
to come up with a simple recommendation that applies in all cases. Plugins
with nested jars would probably need to be evaluated on a case by case
basis to see what the best solution is. Sometimes a nested jar is fine
(such as the common ant task case). Sometimes the right answer is to split
the nested jars out into separate plugins. Perhaps as with the "should
do" for ICU4J, it should instead say "Projects should have jarred
plugins where appropriate", with a link to a document with more details
on what "appropriate" is.