Big JARs = Big Problems?

Discussion in 'Java' started by kk_oop@yahoo.com, Sep 16, 2005.

  1. Guest

    Hi. I'm on a project that has several notional Java components. These
    components are each made up of one or more JAR files. Our JAR files
    are very big, meaning they have a lot of .class files. All the class
    files are somewhat cohesive, since they all are about the functionality
    of a particular component. However, my sense is that they can stand to
    be broken down into more cohesive pieces--more influenced by the Java
    packages than by the notional component.

    I've been getting pushback on doing this. Folks are saying that a JAR
    is just a zip file, so they're structure and interdependencies are not
    that big a deal. When I suggest narrowing the cohesiveness of the big
    JARs, they respond "Where do you stop? How small do you go?"

    Note that with respect to JAR interdependencies, one way to reduce
    those is to have bigger JARs. But this seems like an artificial way to
    manage dependencies: Less dependencies but less cohesion at the JAR
    level.

    So my questions are thus:

    1. What are some pros and cons to making more granular JAR files?

    2. What are some criteria for knowing how big is too big or how small
    is too small?

    Thanks!

    Ken
     
    , Sep 16, 2005
    #1
    1. Advertising

  2. Roedy Green Guest

    On 16 Sep 2005 12:14:42 -0700, wrote or quoted :

    > Our JAR files
    >are very big, meaning they have a lot of .class files.


    That is subjective. What order are you talking about, how many
    classes, how fat the final jar?

    Problems with big jars.

    1. bigger jars take longer to find an element -- a bigger haystack.
    However IIRC under some circumstances a ClassLoader will build a
    hashmap to help it find the elements quickly. then it would not make
    much difference.

    2. bigger jars take longer to download. If you are sending updates, if
    even one comma in one class changes you have to send the whole jar.

    The problems with small jars.

    1. You have to manage more jars, track them, make sure they are the
    right version. make sure they are on the classpath.

    2. there is no obvious way to know you have everything and everything
    is designed to fit together. Even if you don't he customer won't and
    will restore to create a mixed incompatible bag.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 16, 2005
    #2
    1. Advertising

  3. Hemal Pandya Guest

    Roedy Green wrote:
    [snip]
    > Problems with big jars.
    >
    > 1. bigger jars take longer to find an element


    jar index might help. Look at the -i option to jar.

    [snip]
     
    Hemal Pandya, Sep 17, 2005
    #3
  4. Roedy Green Guest

    On 16 Sep 2005 23:17:47 -0700, "Hemal Pandya" <>
    wrote or quoted :

    >jar index might help. Look at the -i option to jar


    The jar index is not what you might imagine, some sort of hashmap or
    btree. It is a simple list of elements, without pointers to where the
    elements are.. Its function is to provide a list of what is in OTHER
    jar files, so it really only helps when you have a group of jars.

    For very large jars, you can pack them which gives ultra-efficient
    compression. See http://mindprod.com/jgloss/jar.html
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 17, 2005
    #4
  5. Hemal Pandya Guest

    Roedy Green wrote:
    > On 16 Sep 2005 23:17:47 -0700, "Hemal Pandya" <>
    > wrote or quoted :
    >
    > >jar index might help. Look at the -i option to jar

    >
    > The jar index is not what you might imagine, some sort of hashmap or
    > btree. It is a simple list of elements, without pointers to where the
    > elements are.. Its function is to provide a list of what is in OTHER
    > jar files, so it really only helps when you have a group of jars.


    Hmmm. Thanks for the info.
     
    Hemal Pandya, Sep 17, 2005
    #5
  6. > Hi. I'm on a project that has several notional Java components. These
    > components are each made up of one or more JAR files. Our JAR files
    > are very big, meaning they have a lot of .class files. All the class
    > files are somewhat cohesive, since they all are about the functionality
    > of a particular component. However, my sense is that they can stand to
    > be broken down into more cohesive pieces--more influenced by the Java
    > packages than by the notional component.
    >
    > I've been getting pushback on doing this. Folks are saying that a JAR
    > is just a zip file, so they're structure and interdependencies are not
    > that big a deal. When I suggest narrowing the cohesiveness of the big
    > JARs, they respond "Where do you stop? How small do you go?"
    >
    > Note that with respect to JAR interdependencies, one way to reduce
    > those is to have bigger JARs. But this seems like an artificial way to
    > manage dependencies: Less dependencies but less cohesion at the JAR
    > level.
    >
    > So my questions are thus:
    >
    > 1. What are some pros and cons to making more granular JAR files?
    >
    > 2. What are some criteria for knowing how big is too big or how small
    > is too small?


    see http://sourceforge.net/projects/jpackit/

    --
    Andrey Kuznetsov
    http://uio.imagero.com Unified I/O for Java
    http://reader.imagero.com Java image reader
    http://jgui.imagero.com Java GUI components and utilities
     
    Andrey Kuznetsov, Sep 17, 2005
    #6
  7. Patrick May Guest

    writes:
    > 2. What are some criteria for knowing how big is too big or how
    > small is too small?


    "The granule of reuse is the granule of release." (See
    http://www.objectmentor.com/resources/articles/granularity.pdf.) As I
    rule, I create a jar for each package. This minimizes the need to
    update jar files and minimizes the size of files that must be
    distributed in any given release.

    Regards,

    Patrick

    ------------------------------------------------------------------------
    S P Engineering, Inc. | The experts in large scale distributed OO
    | systems design and implementation.
    | (C++, Java, Common Lisp, Jini, CORBA, UML)
     
    Patrick May, Sep 17, 2005
    #7
  8. Roedy Green wrote:
    > On 16 Sep 2005 12:14:42 -0700, wrote or quoted :
    >
    >
    >>Our JAR files
    >>are very big, meaning they have a lot of .class files.

    >
    >
    > That is subjective. What order are you talking about, how many
    > classes, how fat the final jar?
    >
    > Problems with big jars.
    >
    > 1. bigger jars take longer to find an element -- a bigger haystack.
    > However IIRC under some circumstances a ClassLoader will build a
    > hashmap to help it find the elements quickly. then it would not make
    > much difference.
    >
    > 2. bigger jars take longer to download. If you are sending updates, if
    > even one comma in one class changes you have to send the whole jar.
    >
    > The problems with small jars.
    >
    > 1. You have to manage more jars, track them, make sure they are the
    > right version. make sure they are on the classpath.


    Note that you can use the Class-Path entry in the manifest to help you
    here. For example, if foo.jar requires bar.jar and baz.jar, it can list
    them in the Class-Path entry in the manifest. Then the classpath
    specified to the JVM need only contain foo.jar; that is, bar.jar and
    baz.jar are added after the fact.

    >
    > 2. there is no obvious way to know you have everything and everything
    > is designed to fit together. Even if you don't he customer won't and
    > will restore to create a mixed incompatible bag.


    HTH,
    Ray

    --
    XML is the programmer's duct tape.
     
    Raymond DeCampo, Sep 17, 2005
    #8
  9. EricF Guest

    In article <>, lid wrote:
    >On 16 Sep 2005 23:17:47 -0700, "Hemal Pandya" <>
    >wrote or quoted :
    >
    >>jar index might help. Look at the -i option to jar

    >
    >The jar index is not what you might imagine, some sort of hashmap or
    >btree. It is a simple list of elements, without pointers to where the
    >elements are.. Its function is to provide a list of what is in OTHER
    >jar files, so it really only helps when you have a group of jars.
    >
    >For very large jars, you can pack them which gives ultra-efficient
    >compression. See http://mindprod.com/jgloss/jar.html


    If they are downloaded when used as an applet, that's a benefit for sure. But
    if run on a server, there is overhead to uncompress them.
     
    EricF, Sep 18, 2005
    #9
  10. Roedy Green Guest

    On Sun, 18 Sep 2005 04:35:14 GMT, (EricF) wrote
    or quoted :

    >If they are downloaded when used as an applet, that's a benefit for sure. But
    >if run on a server, there is overhead to uncompress them.

    that is true of any jar. I don't know if packed jars take any more
    effort to decompress. Has anyone done experiments?
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 18, 2005
    #10
  11. pkriens Guest

    This is one of the areas that the OSGi specifications specifically
    address. We have developed a modularization of Java by using JARs as
    logical modules. The manifest is used to specify imported and exported
    packages, which then allows also for private packages. Pacakges are
    versioned so that the runtime or deployment time can analyze what will
    work together. Different vendors and open source parties have developed
    tools to mkae this manageable. Most noticeable is ofcourse Eclipse.
    Release 4 of the OSGi specifications were very much driven by the needs
    you describe because Websphere and Lotus were key requirement drivers
    for the Eclipse case. That is, Eclipse had to run decently with 5000
    bundles (=jars). However, OSGi is also available now in Apache (OSCAR)
    and with Knopflerfish.

    Currently, JSR 277 is working on a further standardization of modules
    in Java; several OSGi people are working in this expert group to see if
    the OSGi modularization can be adopted in this JSR.

    OSGi is perfectly usable as a reliable deployment platform for JARs.
    However, there are additional mechanisms that support the needs for
    (very) large applications. There is the dynamic service registry to
    support service oriented architectures inside a VM and the life cycle
    management APIs that allow you update a single JAR without disrupting
    the system. Both mechanisms are extremely useful in cocnquering the
    problem of large software projects.

    Some links:
    http://www.knopflerfish.org
    http://oscar.objectweb.org
    http://www.eclipse.org/osgi
    http://www.prosyst.com
    http://www-306.ibm.com/software/wireless/smf/
    http://en.wikipedia.org/wiki/OSGi

    Kind regards,

    Peter Kriens
     
    pkriens, Sep 18, 2005
    #11
  12. Roedy Green Guest

    Roedy Green, Sep 18, 2005
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ike
    Replies:
    6
    Views:
    1,057
    Andrew Thompson
    Sep 24, 2004
  2. Replies:
    5
    Views:
    9,034
  3. JavaEnquirer
    Replies:
    2
    Views:
    519
    JavaEnquirer
    Feb 22, 2006
  4. Shaguf
    Replies:
    0
    Views:
    360
    Shaguf
    Dec 24, 2008
  5. Ulf Meinhardt
    Replies:
    2
    Views:
    1,403
Loading...

Share This Page