Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Java EE Guardians Statement on Oracle/Eclipse Agreement
Hey Ryan,

I would like to share my thoughts on this matter as well.

As far as my information goes, initially we aimed to release Jakarta EE 8 as a Java EE 8 as-is compatible platform on the specification level. When this thought was brought into existence, the javax renaming discussion did not exist yet. So as of today, we could initially release Jakarta EE 8 compatible with Java EE 8, but with the implementations and specifications rebranded/renamed form javax.* to jakarta.*. This is likely to break back-wards compatibility, but on a code level, not on a functional level.

Therefore I personally prefer the big-bang renaming approach since that would provide the most solid base to start off with Jakarta EE. Advantages of this approach are that Jakarta EE is immediately no longer tied to Oracle copyrights and can therefore sail on it's own as a standalone platform, just like any other Java-based enterprise platform that is not owned by Oracle. This also means that it is a contained release that only requires extra work ONCE, which we can regulate with release notes, migration guides or any other form of support. Since the renaming needs to be done anyway, why not just do it as soon as possible, in a contained fashion?

I feel that if we progress gradually with the renaming, we keep taking into account what to rebrand or not with every evolutionary step of Jakarta EE. I think this approach will generate complexity on several levels, for example how the application servers are going to support this hybrid situation and how new specifications are going to handle this. This can slow down the evolution the Jakarta EE platform, a situation that is preferrably to be avoided if we want to adhere to the Eclipse Foundation's vision for evolving Jakarta EE.

Hope this helps to get to the collective decision on how to progress forward.


PS: Another thing that is on my mind is the naming convention for Jakarta EE. Does that necessarily need to be 8, 9, 10 etc? I feel that this can provide a psychological barrier for "increasing the number" that might feel as a big thing. What if we would adopt a naming convention like <year>.<release> (19.0, 19.1, 20.0 .20.1 etc), would that benefit the evolution of platform? This should provide a more intuitive release convention when we want to release Jakarta EE more often on a steady rythm like MicroProfile. Is that something that we would want to explore in this discussion, take into a separate thread or just ignore and continue with the current convention?


Kind regards,

Edwin Derks

On Wed, 5 Jun 2019 at 17:57, Wesley Jackson <wesleyalanjackson@xxxxxxxxx> wrote:
As part of the Java EE Guardians, I agree with the statement sent out.  I would like to see a big-bang change for the new naming convention to avoid confusion and make releases faster.  I think any decision made to speed up the development process benefits everyone in the long run.

Regards,
Wesley

On Wed, Jun 5, 2019 at 9:48 AM Ralph Soika <ralph.soika@xxxxxxxxx> wrote:
Hi Ryan,

here is my opinion concerning the Java EE transition to Jakarta EE:

  • javax* should be replaced by jakarta* at a one-time, immediate transition!
    Get rid of old things and show the community that a new platform is rising (I know that technical this is not so easy as it sounds)
  • Jakarta EE 9 should contain the core components (EJB, JSF, Servlet, Jax-Rs, CDI) and made it available sooner
    We do not need to support backward compatibility in this situation. Everyone who need to ran a legacy application can use one of the available Java EE Application servers.
  • Jakarta EE should include the Eclipse Microprofile APIs : Config, Metrics, Health and fault-tolerance in its core.
    In long-term Microprofile should become part of Jakarta EE.
    For now most Open Application Servers (OpenLiberty, Payara, Wildfly) already support Microprofile and so if Jkarata EE 9 does not include Microprofile in its core spec, this is not the biggest problem



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

Back to the top