www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre Stølsvik <En...@stolsvik.com>
Subject Re: Handling Innovation and Producing an RI
Date Tue, 19 Feb 2008 17:54:32 GMT
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".
   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?

Endre.

*) This obviously didn't go for Pluto, which was convoluted, badly 
coded, dirty sticky ugly spaghetti - but it should be the ideal.

Mime
View raw message