• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

The benefits of separate Jar files vs. Packages.

 
Zak Nixon
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
  • 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
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • 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.
 
Keith Biddlecomb
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • 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.
 
Joel McNary
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • 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...)
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • 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 ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic