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.
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.
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.
Keith Biddlecomb<br />Computer Science<br />University of Virginia
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...)
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.
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.