DrClap, schapel, jschell whats better architecture jar files or class files

Question

What would be a better architecture for deployment. Jar files or class files. We were recently having a debate at work as to generate installation scripts that put jar files on the system where the app is being installed or to make the script generate class files at the desired location.
It would be good to know as to what you ppl think and what are the pros and cons of both.
Some claimed with class files it would be easier to put in patches later on and I kinda agree with that. However your thoughts would be appreciated.
Come on DrClap, schapel, jschell, jsalonen....... I am a fan of yours already

Answer 1

This, of course, is why topics shouldn't be addressed to individuals - they are likely to never see it. Today is the first time I have seen this, and that is due solely to a search that I was running.
Why would you use one over the other?
----Distribution costs
It takes more time to send a bunch of class files down the wire than a single jar file. However, it takes more time to send a jar than a single class file. So there is a delicate trade off in a web application where one is using java. If you send the jar every time it is modified the entire jar must be moved. Class files take less time, but all of them must be moved for a new person.
So in this case if you have a fixed based of users (internal use), and a majority of the files do not change then class files are better. If the user base is transitory and large (external use) then a jar file is probably better.
----Usage:
You can use reflection to dynamically add functionality to an application. If you use a jar file then the application must be restarted for the changes to take effect. If you use class files then the application does not have to be restarted. Obviously the second only works if you have some way to dynamically notify the application that new classes are available - like a database.
This becomes very relevant if you do not want to restart the application and you do not have a distributed application base in place.
Also the older classes, even if not used, are still loaded in the application unless it is restarted (presuming a class loader is not used.) Most of the time this does not make difference.
Since in the above it is likely that there is not a large distribution problem, when the usage is a concern then the best strategy is as class files. They allow the most flexibility and there is unlikely to be any concern at all how it is packaged.
-------Misc
Speed. Someone suggested speed. Guessing I would say that the jar file is going to be faster. Once the Sun jvm gets the file it doesn't let go. And as pointed out opening files is rather costly. However, I doubt this is going to be a significant cost on any system. Startup costs, although sometimes annoying, are seldom significant in terms of application performance.
Security. The is a certain level of security with a jar file. You have one jar file and distribute it to the help desk people. And one of them deletes it accidently. It is going to be a lot easier to figure that out than if they deleted one class file. Additionally it is probably easier to encrypt/decrypt a jar file (if you really must) than class files.
Dynamic class loading. If you are storing classes in non-traditional places, like a database rather than files, then it is probably going to be easier if you do it as class files.
Testing. It is easier to replace a class file in a testing environment to fix a bug than a jar file. Particularily if the make process for the jar file rebuilds everything.