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.

Reply via email to