• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

The benefits of separate Jar files vs. Packages.

 
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am in a delima.

I have a library that comprises of all of my classes, about 5000 of them.
It is easier for deployment issues, to use all of this huge jar file to
distribute and version to my customers.
But, wouldn't it be easier to split up those classes into separate identities, instead of
all my classes being placed together?

So my question is:
- What is the benefits of having multiple library jar files versus using a clearly defined package structure in one huge jar file.

PS This is not a web/J2EE application.

Please shoot and give your opinions for both.

Thanks

Zak Nixon
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I can't think of any advantages to splitting your code into multiple JAR files, unless you intend for them to be separately useful. If it's just one application, then the best thing to do is just to package it all together.

I'm not sure this belongs here in the "Beginner" forum -- if you've written 5000 classes, I imagine you've been at it a while

I'm going to move this to the "Intermediate" forum.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The only advantage of several smaller JAR files that I can think of is if you are using it as a web application, which you already said you're not, so I agree, there really is no advantage to several smaller files. Just combine it into one larger package.
 
Bartender
Posts: 1844
Eclipse IDE Ruby Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It depends greatly on what purpose you want to acheive. If you only have 1 application, then 1 jar file makes sense.

I, myself, tend to write most of my classes with reusibility in mind. I just queried my base libraries, and found that I have 314 classes spread throughout 12 jar files. Each project that I work on then receives a different allocation of JAR files: one JAR file is used in all applications, one is used in applications that connect to persistence storage (that's most of them...). An application will receive one of two jar files depending on whether it's a web app or Swing-based client. All of the other JAR files are different widgits -- my reporting framework, my printing framework, etc. If an application doesn't need it, it doesn't get it.

Then I package the application-specific code in its own (executable) jar file and include in the manifest's Class-Path the path to the other, standard JAR files. This makes for nicely modular programming. The drawback to this is that you have to make sure to manage the different versions of the JAR files correctly, since there can be dependencies. (This widgit jar file requires version 2.1.3 of the persistence jar file, etc...)
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In some configurations it might be worth putting classes that change at the same time and for the same reason together. If you have some set of classes that change with every release in their own jar you might be able to deploy that jar and not touch another stable jar that never changes. Robert Martin has written extensively on package dependencies and you can scale those thoughts up to jar dependencies.

Here is a Product Ad that explains this stuff ... follow the "package design" link, too. This Index of Robert Martin's Writing will lead you to more.

The OO, UML, etc forum down the page is full of talk like this. Come on down if that grabs your interest!

[ January 25, 2005: Message edited by: Stan James ]
[ January 25, 2005: Message edited by: Stan James ]
 
Space pants. Tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic