Skip to main content

Jar files against open source?

3 replies [Last post]
Joined: 2005-12-22
Points: 0

I have a colleague from the Smalltalk world who asked me, "why is that, Java people keeps on making things difficult? Why are source files not included in Jar distributions?! They are making me this on purpose."

I explained him that this was not made on purpose, but I couldn't explain why are source files ripped away from distributions if almost every jar is produced by open source community!

Why are we giving source files in differente archive, if jars can contain sources?
There is a performance reason maybe?
It's easier to take off the sources once you get them, than getting them.

Does anyone know the reason?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-10
Points: 0

Why force someone to download source they don't need and are unlikely to look at? Some jar files (e.g. Java Help) are signed, and I don't think you can remove entries from a signed jar without invalidating the signature.
As regards performance, I believe some implementations memory map jar files (that is the whole file), so in this case the source bloated jar file would use a bit more address space.
In any case it isn't exactly difficult downloading an extra archive containing the source code.

Joined: 2005-12-22
Points: 0

I think attaching source files is more "open" than not doing so.
I'm not telling that just one method should be chose, but the default should be attaching sources. Unless performance problems exist.

If you have 2 versions of the jar you can choose whichever fits your needs.
Nowadays just one distribution is done, you are forced to skip sources unless you find other way to get it.

You are "generally" right, many source files are easy to get, but not all of them. (Especially with old ones). I tell you so, because I work in a company with "sources in" policy.
I tried to get every source but:
- Some were imposible to get: "sqljdbc.jar" (from microsoft), "javax.transaction:jta:1.0.1B" (from sun).
-Some required downloading sources: "aspectj:aspectjweaver:" (I had to download sources from repository to make the jar).
-Some required separating sources: "spring modules" few spring modules don't come with individual sources, so you have to make one striping sources.

This would be unnecesary, if "jar with sources" version existed. And every member of the community follow this.

What do you think?

Joined: 2004-05-06
Points: 0

In my opinion libraries should not bundle source in their JAR files - they can have another JAR with just the source files. Maven, a popular open source build tool, follows this approach (and even has the ability to build a javadoc JAR as well).

The first issue: size. Source files would increase the size of library JARs significantly. Maybe that doesn't matter to an enterprise application where the server has gigs of disk space, but it does matter to applet developers and application developers that use WebStart. Downloading 3 MB worth application versus downloading 10 MB of application is a big difference to some users and can mean the difference between waiting for an app to load and giving up in frustration and pressing cancel.

The second issue: performance, it increases the number of entries in the JAR file making loading take longer. I'm not sure how JARs are loaded exactly or whether the table of contents remains in memory.

Yes, it is possible to strip our source files from JARs after you download them - but this defeats JAR signing and I'm not too comfortable modifying library binaries - it can become difficult to do comparisons (e.g. two users have same library but different size and date because they deleted different files from it).

If the issue is that you are losing track of source files for libraries, consider a build tool such as Maven that handles this for you - there are massive repositories of open source libraries around for it (check out Ibiblio - These repositories contain many source JARs as well - and they can be browsed and downloaded even if you don't use Maven.