Re: [jakarta.ee-community] Are there no requirements for Innovation?

["Kevin Sutter" <sutter@xxxxxxxxxx>]

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