Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Are there no requirements for Innovation?

Hi Mihai, All,


Mihai, one can never be late to an open source party! Welcome and thanks for your question.  It looks however, I may be late in responding :). Thanks to the community with all the answers so far.


Innovation is core to any open source project, and we certainly encourage innovation in Jakarta EE, particularly through collaboration with other Jakarta EE Working Group members involved in Jakarta EE specification projects. 


In terms of requirements for certification of Jakarta EE specification implementations, I will invite you to get familiar with the certification process and compatibility requirements, that will instruct you to join Jakarta EE Work Group and that way enable you to get involved and collectively innovative on the specification projects. 


Should you further desire to certify your own implementation, that may be based on Eclipse Glassfish, and have Jakarta EE Compatible Product you need to fulfill certain requirements listed under Jakarta EE Trademark guidelines . I will copy the part you maybe interested the most here:


Use of the “Jakarta EE Compatible” mark is limited to use in conjunction with Compatible Software Products (as defined below) distributed by:

  1. Participant, Enterprise or Strategic Members of the Jakarta EE WG who are also licensees under the Jakarta EE Compatibility Trademark License Agreement; or

  2. Guest Members of the Jakarta EE WG, if:

    • Use of the Jakarta EE Compatible mark is approved unanimously by the Jakarta EE WG Steering Committee; and

    • Such Guest Members are also licensees under the Eclipse Foundation Trademark License.


Happy implementation and innovation!

Best Regards,
Tanja

On 2020-04-28 9:11 a.m., Werner Keil wrote:
Well that's more or less how Payara or TomEE started ;-)

If Eclipse Foundation and Jakarta EE WG members really have time and resources to dissect and show the internals of a compatible implementation, then why not, otherwise that could be left to vendors. 
Who else would regularly update the list of components and keep track, if say Spring Boot 3 switches from one framework by Netflix to something else or a vendor includes a number of features of MicroProfile 6 or 7 under the hood?

Any list of "using Jakarta EE" or similar should not create an impression of compatibility unless they really passed the TCK(s).

Werner


On Tue, Apr 28, 2020 at 2:54 PM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Getting back to one of Mihai's original points...
>  Looking at what we have now, it seems to me that all I have to do is take Glassfish, rebrand it and bam: I have my own certified Jakarta EE platform.

Almost all of the Jakarta EE Compatible Implementations are open-source.  So, yes, you could take Glassfish, or Wildfly, or Open Liberty, or ..., rebrand it and bam, you have your own certified Jakarta EE Platform.  But, as the notes in this string have indicated, there is much more to this.  Service and support for your own certified Jakarta EE Platform takes many resources (people and dollars).  If you are looking to add any "missing features" maybe in the area of Security, or Packaging, or Microservices, it will take additional resources.  MicroProfile is a good example of filling this hole of Microservices development.  But, it didn't come cheap.  It took several organizations and individuals to spend a great deal of resource to develop the multiple releases of MicroProfile.  The end result of this effort is that many of the Java EE and Jakarta EE certified implementations have also implemented MicroProfile.  So, innovation is not dead.  It is alive and well, both within and outside of the Jakarta EE walls.

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter



From:        arjan tijms <arjan.tijms@xxxxxxxxx>
To:        Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Date:        04/28/2020 06:44
Subject:        [EXTERNAL] Re: [jakarta.ee-community] Are there no requirements for Innovation?
Sent by:        jakarta.ee-community-bounces@xxxxxxxxxxx




Hi Mihai,

I hear you and understand what you are saying. For exactly this reason I suggested in the Jakarta EE spec committee last year that compatible implements list the components that they are using here: https://jakarta.ee/compatibility

The idea was a little to submit something like the matrix I made a long time ago, see: https://arjan-tijms.omnifaces.org/2014/05/implementation-components-used-by.htmlI think in general it's good to have a few independent implementations of every spec (at least two). Otherwise it kinda misses the point of being a spec in the first place. 

As far as full implementations are concerned, and how innovative (different) they are, it's a more difficult topic. In the current crop of compatible Jakarta EE implementations we see for instance that GlassFish and Payara use the same core- and external components. Nevertheless, Payara is not just a rebranding of GlassFish, far from it. It has many individual extra features (MicroProfile, extra authentication mechanisms, totally different hazelcast based clustering, remote EJB over HTTP, etc etc). JEUS has many similar components as well, but is not a GlassFish derivative; it's a unique server product that just uses most of the GlassFish components for the separate APIs.

WildFly and JBoss EAP are basically the same though, where EAP is essentially a specific snapshot from the WildFly branch and then stabilised/hardened (extra bug fixes, tests, secure build, etc) and supported. So as products they are two different things and it makes sense IMHO to certify those separately.

With Piranha we're also trying to build a Jakarta EE product, and it takes a middle approach kinda like JEUS but also like the now defunct Jon AS; all the server bits and the Servlet, JNDI and some other implementations are our own code, but for Jakarta Faces, Jakarta REST etc we integrate existing implementations.

Kind regards,
Arjan Tijms













On Tue, Apr 28, 2020 at 11:48 AM Mihai A. <amihaiemil@xxxxxxxxx> wrote:
Hi Werner, hi Suren, 

By "Innovation" I mean new implementations of certain specs, not necessarily adding proprietary functionalities.

Take JAX-RS for example. Even if there is an implementation which can be reused in any platform, I would ask the platform implementors to
come up with their own JAX-RS implementation: maybe they'll come up with a better one. One that is faster, with less bugs, better exception messages etc.
 
Of course, you have to let people reuse especially opensource products if they want, but I think there should be a requirement for a
minimum of new implementations.

Best regards,
Mihai
On Tue, 28 Apr 2020 at 12:06, Werner Keil <werner.keil@xxxxxxxxx> wrote:
Hi,

Not sure, what you mean with "rules" but I assume it's APIs or specs?

CXF implements mainly WS related JSRs like JAX-WS, but so far it doesn't look like it migrated to Jakarta EE yet.
Weblogic on the other side was at least until Java EE 7 compatible with the Full Profile, it has not shown any signs of doing this for Jakarta EE 8, but let's see. Tomcat was the RI for Servlet a long time ago, Jetty hopes to be compatible with the new Jakarta EE Servlet spec and maybe others (I heard from its leadership team) and Helidon again I am not aware, that it passes the Servlet TCKs, but it should pass a few MicroProfile TCKs.

There are other examples for projects that use the Servlet spec, Spring probably the most commonly known.
I'm not entirely sure, what these examples have to do with innovation, but there are some new Jakarta EE specs especially NoSQL that seem pretty innovative and recent, although they could take a bit before they are stable and mature enough for the platform.

Werner






On Tue, Apr 28, 2020 at 12:57 AM Suren Konathala <konathalasuren@xxxxxxxxx> wrote:
My POV:

JakartaEE (don’t know much about CXF) is standards/specifications https://jakarta.ee/specifications/ 
To make sure your application works per-JakartaEE standards, it needs to follow/implement (say) A,B,C rules. 

JakartaEE (and most standards) define these A, B, C rules and leave the implementation details to the implementor. 

As an implementor, develop your software to conform to A,B,C to be JakartaEE Complaint + do whatever on top of it (your innovations). Obviously the better your innovations/makes things easy/simple for users the more adaptable your product/service is. 

As an example: All the below are servlet containers + (additional features): Apache Tomcat, Jetty, Weblogic, Helidon  

Thanks
Suren

On Sun, Apr 26, 2020 at 5:53 AM Mihai A. <amihaiemil@xxxxxxxxx> wrote:
Hi All,

I know I may be late to the party with the following question, but it just struck me the other day: are there no innovation requirements for certifying a platform as Jakarta EE compatible?

Looking at what we have now, it seems to me that all I have to do is take Glassfish, rebrand it and bam: I have my own certified Jakarta EE platform.

Or take Apache CXF and other bits and pieces implementing the required specs, put them together under a new brand and again, jackpot!

Shouldn't there be a requirement for a minimum of actual implementation effort?
Or maybe there are such requirements and I'm not aware of them...

Best regards,
Mihai


--

amihaiemil.com
https://www.github.com/amihaiemil

_______________________________________________
jakarta.ee-community mailing list

jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list

jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list

jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community


--


amihaiemil.com
https://www.github.com/amihaiemil

_______________________________________________
jakarta.ee-community mailing list

jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community


_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--

Tanja Obradovic

Jakarta EE Program Manager | Eclipse Foundation, Inc.

Twitter: @TanjaEclipse

Eclipse Foundation: The Platform for Open Innovation and Collaboration


Back to the top