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

While I agree that having a single RI has drawbacks, there's also a big problem if we go without a single RI – complexity for beginners.


Currently, if people want to start with JavaEE they tart with Glassfish as the RI. Most tutorials for beginners use Glassfish. It makes sense because newcomers like to have consistency and they tend to perceive JavaEE as a framework ready to be used instead of a common set of specs. For them, it's hard to understand between specs and implementations.


I think it's safer to retain a single RI as a reference for newcomers until we find a better way to make the platform user-friendly. As Steve Millidge, the CEO of Payara explained, Glassfish still has it's value as the RI and Payara Server doesn't aspire to replace it. In some way, It's good that Glassfish isn't supported in production and no vendor is behind it.


What's not good is that Glassfish, while a great app server with lots of added value, provides a lot more than what's standardized. The RI in my view should contain only the necessary minimum and be modular and pluggable so that it can be easily reused, either as a whole or its components.


If we decide to go with just any or more RIs, then we should also specify basic behavior like app deployment, maven project setup, configuration of standard resources so that all RIs behave the same and the only difference for newcomers is a different maven dependency. Anything more complex is a pain for starters. I would like to avoid any fragmentation of elementary learning resources.




Od: Guillermo González de Agüero
Odesláno:neděle 15. října 2017 10:53
Komu: EE4J community discussions
Předmět: Re: [ee4j-community] Eclipse Jetty and EE4J



I think we're all basically saying the same. "No RI" seems equivalent "at least one, but not limited to, one RI".

Nobody wants a finished spec without a complaint implementation. The idea of the single RI made sense with a somewhat private process and closed source RIs where maybe even some EG members didn't have access to it. But a truly open process means everyone has the same rights and has access from minute 1 to everything.


I also expect to see more specifications being co-lead by multiple vendors, which will presumably like to have each their own implementation marked as the "Reference" implementation. The reference implementations for a spec version could be defined at the beginning and then the spec would be finished when the RIs are done.


More response inline.


El sáb., 14 oct. 2017 a las 23:45, Greg Wilkins (<gregw@xxxxxxxxxxx>) escribió:



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



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.




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.

It's interesting to me that certified Java EE servers are only tested for one version on some specific environments ( That means GlassFish 4.0 is Java EE 7 compatible, what we know nothing about GlassFish 4.1.


I support your idea of specific versions being considered the RI, but open TCKs will make it easy for users to test themselves. Probably most vendors will even run TCK tests as part of their CI pipelines, making the RI "upgradeable".


Anyway it's definitely an interesting thought.






ee4j-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit


Back to the top