Should I bundle source and class files in the same JAR?_问答_开发者

Separate Jars

When creating JAR files, I've always kept the source separate and offered it as an optional extra.

eg:

Foo.jar
Foo-source.jar

It seems开发者_StackOverflow中文版 to be the obvious way to do things and is very common. Advantages being:

Keeps binary jar small
Source may not be open / public
Faster for classloader? (I've no idea, just guessing)

Single Jar

I've started to doubt whether these advantages are always worth it. I'm working on a tiny component that is open-source. None of the advantages I've listed above were problems in this project anyway:

Classes + source still trivially small (and will remain that way)
Source is open
Class loading speed of this jar is irrelevant

Keeping the source with the classes does however bring new advantages:

Single dependency
No issues of version mismatch between source and classes
Developers using this jar will always have the source to hand (to debug or inspect)

Those new advantages are really attractive to me. Yes, I could just zip source, classes and even javadoc into a zip file and let clients of my component decide which they want to use (like Google do with the guava libraries) but is it really worth it?

I know it goes against conventional software engineering logic a little, but I think the advantages of a single jar file out-weigh the alternatives.

Am I wrong? Is there a better way?

Yes, I could just zip source, classes and even javadoc into a zip file and let clients of my component decide which they want to use (like Google do with the guava libraries) but is it really worth it?

Of course it is worth it! It takes about 2 seconds to do it, or just a few minutes to change your build scripts.

This is the way that most people who distribute sources and binaries handle this problem.

EDIT

It is not your perspective you need to consider. You have to think of this from the perspective of the people deploying / using your software.

They aren't going to use the source code on the deployment platform.
Therefore putting the source code in the binary JAR is a waste of disc space, slows down deployment and slows down application startup.
If they want to do something about it, they've got a problem. How do they rebuild the JAR file to get rid of the source code? How do they know what is safe to leave out?

From the deployer / user's perspectives, there are no positives, only negatives.

Finally, your point about people not being able to track source versus binary versions doesn't really hold water. Most people who would be interested in the source code are perfectly capable of doing this. Besides, there some simple things you can do to address the issue, like using JAR filenames that include your software's version number, or putting the version number into the manifest.

I have just come across a potential pitfall for the java+classes in a single jar.

If you have java files in a jar and that jar is included in the classpath of a subsequent javac execution, you MUST make sure that the timestamps of the java file is less than the timestamp of the class file.

This scenario can happen when you copy/move the java or class files prior to packaging as a jar.

If the java file is newer than the class, then even though the java file is found on the classpath (rather than an argument to javac), javac will attempt to compile that java file and then potentially end up with duplicate class errors during the compilation stage.

For this reason I would recommend keeping the source in a separate jar to the class files.

Note that relevant flags in javac will not allow you to prefer class over source: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#searching

I prefer 'Separate Jars'.

Because binary class jar is for running on JVM, but source not. Source should be carefully maintained by your source control system(SVN). If source needs to release, zip it in separate jar. Many open source separates class jar and source one.

If you want others to test and inspect/improve your code then you can have your source with the binaries. If not, keep the source away from the jar.

How small is small and why should your jar act differently from others?

Unless you have a very good reason why your jar should have the sources, not simply debugging but something specific to this one jar then I'd say no, choice is best.

I say this because if your jar should not be different from other, then you have to work on the assumption that others should do the same as you. If so, the size of the jar is not important, because its duplicated over all "small" jars. Then my WAR is much bigger than needed which, admittedly is not a massive issue, but is not something I would chose for production when I can download sources in DEV so easily.