Mailing-List: contact jcp-open-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: jcp-open@apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <47BB213A.3050206@Stolsvik.com>
Date: Tue, 19 Feb 2008 19:34:34 +0100
From: =?UTF-8?B?RW5kcmUgU3TDuGxzdmlr?= <Endre@stolsvik.com>
Organization: Picorg
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: jcp-open@apache.org
Subject: Re: Handling Innovation and Producing an RI
References: <9deac9fd0802190546s6007dc50g43a48069a49e0236@mail.gmail.com>
 <47BAE675.2040805@Stolsvik.com>
 <56F0DAE6-321F-4469-9B42-7F1B0DE418FC@pobox.com>
 <47BB17D8.2040504@Stolsvik.com>
 <B6A64781-2FBE-421B-A11B-83046B200BF9@pobox.com>
In-Reply-To: <B6A64781-2FBE-421B-A11B-83046B200BF9@pobox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Geir Magnusson Jr. wrote:
> 
> On Feb 19, 2008, at 12:54 PM, Endre Stølsvik wrote:
> 
>> Geir Magnusson Jr. wrote:
>>> On Feb 19, 2008, at 9:23 AM, Endre Stølsvik wrote:
>>>> kelvin goodson wrote:
>>>>> I would like to understand how Apache projects which develop JSR 
>>>>> reference implementations (RI) handle the apparent conflict between 
>>>>> developing an RI,  and having a project that innovates outside the 
>>>>> specification.
>>>>
>>>> Very good question. It seems a bit to me like Apache finds it 
>>>> flattering that RIs are developed (or rather, "dumped") here, while 
>>>> there is no actual standard, formal or de-facto, of how to handle 
>>>> the obvious conflict you describe.
>>> Where is the conflict?
>>
>> That a RI should be as lean and simple and obvious and cleanly coded 
>> as possible - ONLY demonstrating the exact specification* so that it 
>> is easy to compare the specification wording to the implementation - 
>> and so that actual implementations can look in the code and use that 
>> as a addendum to the specification, "aha, so that's what they mean".
> 
> There's no requirement of that.
> 
>>
>>  Note that "clean" here might not be the correct word - all code 
>> should be clean, but RIs should be clean as in "simple", in the 
>> "cheap" meaning of the word. Just do what is needed, and do that 
>> efficient, not going about having nice extension points etc.
>>
>> On the opposite side, a "production product" should have lots of 
>> features, lots of configurability, add-ons and -ins, modular, have 
>> deep monitoring capabilities, JMX/management consoles, be embeddable 
>> .. and what have you.
>>
>> This is the same distinction between writing code for an instruction 
>> manual, a programming book or an article for a blog entry, as opposed 
>> to making a comprehensive solution suitable and tailorable to 
>> thousands of settings and situations.
>>
>> Seriously, isn't this exceptionally obvious? What hidden message are 
>> you trying to convey, Geir?
> 
> My point is that there's no requirement that an RI do that.  It's nice, 
> but not required.  We've had the codebase for servlet RI in Tomcat for 
> years.  Would you call that "clean"?

No, and I wouldn't call that a good *RI* either.

> I think it's really up to the implementing community - as long as it 
> passes the TCK and is the implementation offered by the spec lead as 
> proof of implementability, it's the RI.

How many successful RIs are there at Apache?

I'd say Tomcat - but I don't think that's a good RI *at all*.

It is cool that Apache hosts RIs for various JSRs. I don't think, 
however, that the RI should be Apache's implementation of the JSR. At 
least not necessarily. I'd say that Tomcat shows that it is _possible_ - 
but that's a proof of one. And also, at least when I followed the 
development of Tomcat, I believe I saw that during the RI implementation 
phases, there has been a flurry of coding coming from the dedicated Sun 
employee(s) to reach the "deadline" of when the JSR goes through.

One could argue that Tomcat is quite special: it is basically a 
exceptionally "open source JSR" - it has a particularly large market 
share of that JSRs implementation, AFAIK. So, it is both the RI, and the 
most used implementation, of that set of JSRs. As a side note, it is 
also one of the oldest Java technologies around, predating the JCP.

Can this be easily copied in other projects? Do one have the dedication 
from the dumpsters to pull this through, as one has _had_ with Sun on 
Tomcat? .. or the dedication from other vendors, having full-time 
employees basically owning the implementation, as JBoss on Tomcat?

It most definitely didn't work with IBM on Pluto, IMO.

Endre.