Yes, I'm curious about this too. There are different developer styles.
Some developers end up with lots of packages with a few classes in each
with public methods for communicating with each other.
Other developers opt for putting the same number of classes all in one
package (with the advantage of not being forced to use public)
Question:
10 packages with 100 classes each loads *much* faster than 100 packages
with 10 classes each?
Jeanfrancois Arcand wrote:
> Salut,
>
> Sahoo wrote:
>
>> We are currently exporting every package, which is not desirable. The
>> attached zip file contains a file called bundles.xml, which lists
>> packages being exported by each module. Please take some time to
>> analyze your module and come up with the appropriate package list. It
>> does not give a good picture of modularity when we have so many
>> packages exported. If we can reduce the number of exported packages,
>> the system will not only boot faster, it will also run a lot faster.
>
>
> Hum..can you elaborate why we will run faster if we reduce the number
> of exported package? Is it because of our classloader architecture?
>
> Thanks
>
> -- Jeanfrancois
>
>
>
> This is in
>
>> addition to improving the overall design of the modules.
>>
>> To identify the packages to be exported, you may like to use
>> wires.xml file in the same zip file to get an idea of current package
>> dependencies. Copy wires.xml and wires.xsl into the same folder and
>> open wires.xml in any XSL aware editor (like firefox). If you see a
>> package is imported only by the module that exports it, then that's
>> likely to be removed from exported package list. Please note, this
>> may not always be true, so use your own judgment. I am hoping that
>> this should reduce the total number of exported packages drastically.
>> Then we need to take the second step which is to identify the real
>> module boundaries as per the module's design goals. The two steps can
>> be done as one or more check-ins.
>>
>> Once you have identified correct set of exported package names,
>> please *update* pom.xml of your module. We are investigating the
>> possibility of adding some package level annotation to automatically
>> generate this list during build, but until then when you add or
>> remove any package, please also update the pom.xml.
>>
>> You may be tempted to ask why we are currently exporting every
>> package. Well, without knowing what each module does, I had little
>> choice but to export all the packages. It's not that big a problem
>> when every module owner takes care of their individual modules.
>>
>> Thanks,
>> Sahoo
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
--
Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell 650-784-4123 - Sun Microsystems, Inc.