Re: [ee4j-community] Eclipse Jetty and EE4J

[Greg Wilkins <gregw@xxxxxxxxxxx>]

On 15 October 2017 at 08:13, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

 

It's not the prettiest of examples, but we kinda did that with the JASPIC 1.1 register session feature. It was unfortunately quite a bit underspecified, so vendors basically had no clue how to implement it at all and had to follow the way it was done in the RI.

Arjan,

I think that example is indeed not pretty, but actually argues for why RIs facilitate lazy specifications.   If the process required several implementors to implement the draft and do interop testing before going final, than such poor specifications would be noticed earlier, without making one implementors version the defacto standard regardless of merit.

Note also that most implementations continue to be developed after the specification is pronounced final, and who is to say that an RIs  subsequent development direction actually expresses the intent of the expert group?  If difficult problems are subsequently discovered, surely they should be taken back to the expert group for resolution rather than be left in the hands of one specially anointed implementation?

 

It's also an important requirement; the spec can not be released without an implementation proving it's at least possible to implement.

Absolutely working code should be required.  But I'm suggesting that a sample of 1 is not sufficient to test a spec and that the process should encourage multiple implementations during the draft stage.   In fact having an implementation that substantially passes the draft TCK may be a good qualifier to give voting rights for deciding if the spec is ready to go final!

So perhaps we should think of the process allowing multiple RIs rather than none?    More over, perhaps it is specific versions of those implementations that should be noted as being reference implementation at the time the spec goes final.

cheers

--

Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com