posted 20 years ago
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.