On Fri, Jan 16, 2009 at 7:55 AM, Petr Slechta <Petr.Slechta at sun.com> wrote: > > I strongly believe that nobody will fix jar libraries. If there is a > problem and new library is available, we can get it and replace it. We > don't need to compile it.
Trust, but verify.... http://blogs.zdnet.com/security/?p=2016&tag=nl.e589 http://it.slashdot.org/article.pl?sid=08/12/29/0155249 http://news.bbc.co.uk/1/hi/technology/7583805.stm And that's just the last few months. Repeatable builds is at least one of the principles at play here. I, as a consumer of the software, might like to repeatably and reliably rebuild the binary artifacts from source myself, using the appropriate tools and process. While I do agree that conventionally, most Java based projects do practice bundling pre-built libraries in their distributions, this isn't most Java based projects. There is a whole community out there that expects to see the source behind it to preserve their right to tinker with it. Partly because this same community conventionally uses only internally housed meta data describing the library (whereas traditional binary libraries at least provide hints via naming), it's difficult to tell versions of java libraries on their face. That means that if you ship the binary I would expect to see a very detailed accounting the chain of custody of this jar -- what EXACT version was it built on?, where did it come from EXACTLY?, how did THEY build it?, who touched it afterwards?, was it modified in any way? How do I rebuild it myself?, etc. Just provide the source and there's no question. I raised the question of whether there should be a rule or advice requiring that java jars be explicitly named according to version (much like other libraries), and that some serious thought given to how we're going to handle 233,242 private copies of dom4j-guess-my-version-and-lineage.jar, but the jars included were declared project private which negated any such requirement and the case went through. I believe you had renamed the jars just before this last point was made. I have no problem with that, personally, other than to sigh quietly and move on, but it looks like others are catching the same thing now that you're delivering. I fear that in the worst case you may setting the precedent that I was asking about. If Sun's internal policies (c-team? x-team?) requires source for all library components then that's between you and them. I'll tell you as an external community participant -- not bundling the source will be a mistake.