Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Eclipse Jetty and EE4J
I agree with continuing to produce an RI for at least the short term.  I think it would be important to not start "breaking all the rules" right out of the gate.  At least in the beginning, I think that the EE4J implementations should continue to provide a standard reference implementation.  If for nothing else, the reference implementation should be available to "refer to", as Neil had mentioned.

The word "standard" means a lot to many enterprises.  I am of the belief that many corporations and organizations that utilize Java EE are doing so because it is a "standard" in the industry.  I think it is possible to produce a "standard" without an RI at some point.  Don't get me wrong, I am all for achieving a more nimble process and possibly getting rid of the RI's at some point in the future.  I do believe that it is possible to produce a very nimble process and continue to deliver an RI for the short term.

Best Regards

Josh Juneau
juneau001@xxxxxxxxx
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866


On Sat, Oct 14, 2017 at 5:25 PM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Sat, Oct 14, 2017 at 10:45 PM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

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.

I agree with that. Maybe there's something to say for "at least" one implementation, but in this case more is better indeed.

Sometimes these relative poor specifications happen when the RI and spec are developed and updated in tandem according to the consensus of the group, and the spec lead or EG member submitting the text just forgets to describe it sufficiently in the spec. This can happen even faster with the more code driven approaches. 

So the merit is there, everyone agrees, but the spec text just doesn't say it.

Perhaps less common, but it can also happen that the spec text is there, but ends up at the wrong place. I.e. in JSF I accidentally put some spec text on a non-spec/api class instead of an a spec/api one. I noticed this only after it was basically too late, but luckily spec lead Ed Burns wanted to correct it still (again my thanks for this ;)).

Kind regards,
Arjan Tijms

 

 

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


--

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community



_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community


Back to the top