Skip to main content

ECE 2019: CFP Now Open!

by Thabang Mashologu at May 22, 2019 09:47 AM

EclipseCon Europe is the leading conference for developers, architects, and open source business leaders to learn about Eclipse technologies, share best practices, and more. Taking in place in Ludwigsburg, Germany, October 21-24, 2019, ECE 2019 is our biggest event of the year and connects the Eclipse ecosystem and the industry’s leading minds under one roof. We are pleased to once again co-locate with the OSGi Alliance Community Event, adding more breadth and expertise to the program.

 

The ECE 2019 Call for Papers is now open. Please visit the CFP page for information on how to submit your talk. This year, the early-bird submission deadline is July 1 and the final submission deadline is July 15. 

 

If you have an idea for a talk that will educate and inspire the Eclipse community, we would love to hear from you! 


by Thabang Mashologu at May 22, 2019 09:47 AM

Cloud Native Java Innovation at the Eclipse Foundation

May 21, 2019 01:30 PM

The world's leading technology vendors, including Fujitsu, IBM, Microsoft, Oracle, Red Hat, SAP, and Tomitribe, are collaborating at the Eclipse Foundation to advance enterprise Java technologies to support the migration of mission-critical applications to the cloud.

May 21, 2019 01:30 PM

ECE 2019: CFP Now Open!

May 21, 2019 01:30 PM

The ECE 2019 Call for Papers is now open. The early-bird deadline is July 1 and final submission is July 15.

May 21, 2019 01:30 PM

Update for Jakarta EE community: May 2019

May 21, 2019 01:30 PM

Active participation represents the best way to drive the vendor-neutral and rapid innovation necessary to modernize enterprise systems for cloud use cases.

May 21, 2019 01:30 PM

Cloud Native Java Innovation at the Eclipse Foundation

by Thabang Mashologu at May 21, 2019 06:02 AM

The world’s leading technology vendors, including Fujitsu, IBM, Microsoft, Oracle, Red Hat, SAP, and Tomitribe, are collaborating at the Eclipse Foundation to advance enterprise Java technologies to support the migration of mission-critical applications to the cloud. Jakarta EE and Eclipse MicroProfile offer a path for migrating Java EE legacy applications to a standard enterprise Java stack for a cloud native world. Within the collaborative, vendor-neutral environment provided by the Eclipse Foundation, a vibrant community of developers is directly influencing the future of Java.

Establishing Jakarta EE as the place where Java EE will evolve to create this migration path to the cloud is a significant effort, and the community involved in supporting this effort have made tremendous strides. These have included releasing Eclipse GlassFish 5.1 as Java EE 8 certified, thus ensuring backward compatibility, and establishing an open specification process as a replacement for the JCP. Next up is to release Jakarta EE 8 as an established specification and see the commercial vendors support this release, again ensuring the migration path forward. As this happens, all developers are encouraged to participate as Jakarta EE then evolves. The first step in doing this is to join the conversation by visiting https://jakarta.ee/connect/.   

 

Jakarta EE Developer Survey Results Show Cloud Native Adoption Accelerating Dramatically with Jakarta EE

 

The Eclipse Foundation recently released the 2019 Jakarta EE Developer Survey that canvassed nearly 1,800 Java developers about their adoption of Jakarta EE and trends in Java programming. The goal of the survey, which was conducted in March 2019, was to help Java ecosystem stakeholders better understand the requirements, priorities, and perceptions of enterprise Java developer communities.

 

The findings indicate that cloud native is critically important with a third of developers currently building cloud native architectures and another 30 percent planning to within the next year. Meanwhile, the number of Java applications running in the cloud is projected to increase significantly over the next two years, with 32 percent of respondents expecting that they will be running nearly two-thirds of their Java applications in the cloud in two years. Furthermore, 43 percent of respondents consider the microservices architecture the dominant approach to implementing Java in the cloud.

 

While Spring and Spring Boot continue to dominate as the leading framework for building cloud native applications in Java, Eclipse MicroProfile’s usage growth more than doubled in adoption from 13 percent in 2018 to 28 percent today.   

 

Survey respondents made it clear that as the community-driven evolution of enterprise Java coalesces around Jakarta EE, Java EE remains the platform they rely on most to build enterprise-class applications. According to the results, the top three community priorities for Jakarta EE are a tie at first with better support for microservices and native integration with Kubernetes (both at 61 percent) followed by product quality reference implementation (37 percent).

 

Access the full findings of the 2019 Java Community Developer Survey here.

 

Key Eclipse Projects for Cloud Native Application Development

 

In addition to Jakarta EE and MicroProfile, the Eclipse community is driving cloud native innovation with the following projects:

  • Eclipse IDE — As the leading open platform for professional developers, the standard Eclipse IDE is the critical development environment for more than 4 million active users. The Eclipse IDE was chosen by the Java developer community as the top IDE for building cloud native applications in the 2019 Jakarta EE Developer Survey.

  • Eclipse OpenJ9 — OpenJ9 is a Java virtual machine (JVM), the engine that runs Java applications, optimized for the cloud and microservices. OpenJ9 comes with improvements to memory overhead and startup times, achieved through shared classes and an aggressive focus on memory footprint.

  • Eclipse Vert.x — Vert.x is a toolkit for building reactive applications on the JVM.

  • Eclipse Jemo — Jemo is the leading open source multi-cloud function-as-a-service (FaaS) runtime for JVM based languages. Built to take advantage of Kubernetes, Jemo provides a platform, frameworks, and runtime support for building cloud native applications which run across multiple clouds without the need for re-engineering.

  • Eclipse Theia — Theia is an extensible open-source framework to develop multi-language IDEs for the cloud and desktop using state-of-the-art web technologies.

  • Eclipse Che — Che is a next-generation developer workspace server and cloud IDE that allows anyone to contribute to a project without installing any software. Che defines workspaces that include their dependencies including embedded containerized runtimes (including Kubernetes, OpenShift, and Docker support), Web IDE (based on Theia), and project code. This enables true team-based development by making workspaces distributed, collaborative, and portable.

 

How to Participate in the Future Of Cloud Native Java

 

To learn more about the collaborative efforts to build tomorrow’s enterprise Java platform for the cloud, check out the Jakarta Blogs and participate in the monthly Jakarta Tech Talks. Don’t forget to subscribe to the Eclipse newsletter and get involved in Jakarta EE, Eclipse MicroProfile and other cloud native Eclipse projects.


by Thabang Mashologu at May 21, 2019 06:02 AM

Update for Jakarta EE community: May 2019

by Tanja Obradovic at May 18, 2019 10:46 AM

The Jakarta EE community is the driving force behind the future of cloud-native Java. Active participation represents the best way to drive the vendor-neutral and rapid innovation necessary to modernize enterprise systems for cloud use cases. That said, we’d like to make sure that the community is kept up-to-speed with the latest developments in the Jakarta EE ecosystem.

We’re launching a monthly email update for the Jakarta EE community which seeks to highlight news from various committee meetings related to this platform. There are a few ways to get a grip on the work that has been invested in Jakarta EE so far, so if you’d like to learn more about Jakarta EE-related plans and get involved in shaping the future of cloud-native Java, read on. We’d also like to use this opportunity to invite you to get involved in EE4J projects and join the conversation around the Jakarta EE Platform.

Without further ado, let’s have a look at what has happened this month:

Update on Jakarta EE Rights to Java Trademarks

The process of migrating Java EE to the Eclipse Foundation has been a collaborative effort between the Eclipse Foundation staff and the many contributors, committers, members, and stakeholders that are participating. The Eclipse Foundation and Oracle have agreed that the javax package namespace will not be evolved by the Jakarta EE community. Furthermore, Java trademarks such as the existing specification names will not be used by Jakarta EE specifications.

Since the ratified Jakarta EE specifications will be available under a different license (the Eclipse Foundation Specification License), we recommend that you update your contributor and committer agreements.

Read more about the implications and what’s next for the Jakarta EE Working Group in Mike Milinkovich’s latest blog.

In order to evolve Jakarta EE, we must transition to a new namespace. In an effort to bootstrap the conversation, the Jakarta EE Specification Committee has prepared two proposals (Big-bang Jakarta EE 9, Jakarta EE 10 new features and incremental change in Jakarta EE 9 and beyond) on how to make the move into the new namespace smoother. These proposals represent a starting point, but the community is warmly invited to submit more proposals.

Community discussion on how to transition to the jakarta namespace will conclude Sunday, June 9th, 2019.

EFSP v1.1

Version 1.1 of the Eclipse Foundation Specification Process was approved on March 20, 2019. The EFSP leverages and augments the Eclipse Development Process (EDP), which defines important concepts, including the Open Source Rules of Engagement, the organizational framework for open source projects and teams, releases, reviews, and more.
 

JESP v1.0

Jakarta EE Specification Process v1.0 was approved on April 3, 2019. Therefore, the Jakarta EE Specification Committee now adopts the EFSP v1.1 as the Jakarta EE Specification Process with a few modifications, including the fact that any changes or revisions of the Jakarta EE Specification Process must be approved by a Super-majority of the Specification Committee.

 

TCK process:

Work on the TCK process is in progress, with Tomitribe CEO David Blevins leading the effort. The TCK process is expected to be completed in the near future. The document will shed light on aspects such as the materials a TCK must possess in order to be considered suitable for delivering portability, the process for challenging tests and how to resolve them and more.      
 

Jakarta EE 8 release

Jakarta EE 8 is a highly-anticipated release, especially since it represents the first release that’s completely based on Java EE to ensure backward compatibility. It relies on four pillars of work, namely specifications for the full platform, TCKs, including documents on how to use them, a compatible implementation for the release of Jakarta EE 8, and marketing aspects such as branding, logo usage guidelines, and marketing and PR activities.

All parties involved are far along with the planning process and work on specifications has already started. Please look at Wayne Beaton’s blogs on the work in progress with regard to specification project names and specification scopes.

 

EE4J GitHub

Get involved in Eclipse EE4J! There are currently three projects that you can be a part of, namely Specification Document Names, Jakarta Specification Project Names, and Jakarta Specification Scope Statements (for the specifications). Furthermore, there are plenty of repos that require your attention and involvement.

But before you dive right in, you should read the latest blog from the Jakarta EE Specification committee, which recently approved a handful of naming standards for Jakarta EE Specification projects. While you’re at it, you should read Wayne Beaton’s blog on why changing the names of the specifications and the projects that contain their artifacts is a necessary step.

Head over to GitHub and join the conversation!
 

Jakarta EE Platform

There’s no better time to get involved in the work for the Jakarta EE Platform than the present. As of now, the projects that demand the community’s attention are the Jakarta EE 8 Platform Specification, which is meant to keep track of the work involved with creating the platform specification for Jakarta EE 8, Jakarta EE 9 Platform Specification, intended to keep track of the work involved with creating the platform specification for Jakarta EE 9 and Jakarta EE.Next Roadmap Planning, which seeks to define a roadmap and plan for the Jakarta EE 9 release.

Community Engagement

Speaking of community engagement, there are a few ways to get a grip on the work that has been invested in Jakarta EE so far, learn more about Jakarta EE-related plans and get involved in shaping the future of cloud-native Java. One way to do that is by reading Tanja Obradovic’s blog series on how to get involved.

You should also be aware of the newly-created Jakarta EE community calendar, which is now open to the public and offers an overview of all the activities surrounding Jakarta EE. The community is invited to participate in Jakarta Tech Talks, which take place on a monthly basis, attend Jakarta EE Update monthly calls (the next one is on May 8), help build the Jakarta EE wiki with all relevant links and look for opportunities to engage and become part of the community.

Last but not least, the Jakarta EE Developer Survey will be released in the next few days. Head over to jakarta.ee to discover the latest trends, the community’s top priorities regarding the future of Jakarta EE and more. Stay tuned!

Conclusion:

Thank you for your interest in Jakarta EE. To help us build tomorrow’s enterprise Java platform, join the Jakarta EE community now or get involved by becoming a contributor or committer to one of the EE4J projects.   

Help steer Jakarta EE toward its exciting future by joining the Jakarta EE working group!


by Tanja Obradovic at May 18, 2019 10:46 AM

One size fits all – Rendering Material Design with React and Angular

by Jonas Helming and Maximilian Koegel at May 17, 2019 09:52 AM

JSON Forms is a framework for efficiently developing form-based UIs based on JSON Schema. It provides a simple declarative JSON-based language...

The post One size fits all – Rendering Material Design with React and Angular appeared first on EclipseSource.


by Jonas Helming and Maximilian Koegel at May 17, 2019 09:52 AM

Incompatible Eclipse workspaces

by Andrey Loskutov (noreply@blogger.com) at May 16, 2019 12:11 PM


Eclipse has mechanism to recognize if the workspace to be used is created with older Eclipse version.
In such case, to be safe, Eclipse shows dialog like:




As of today (Eclipse 4.12 M1), if you click on "Cancel" button, Eclipse will behave differently, depending on the use cases "history":

A. If the workbench was not started yet:

  1. If Eclipse was started without "-data" argument and user selects incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer workspace selection dialog.
  2. If Eclipse was started with "-data" argument pointing to the incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will terminate (instead of offering to select another workspace).

B. If the workbench was started:

  1. If user selects compatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts fine.
  2. If user selects incompatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts, shows the "Older Workspace Version" dialog above and by clicking on "Cancel" it will terminate (instead of offering to select another workspace).
This behavior is inconvenient (at least), so we have bug 538830.

Fix Proposal #1

The proposal is, that independently on the way Eclipse was started, if user clicks on the "Cancel" button in the "Older Workspace Version" dialog, we always show the default workspace selection dialog (instead of termination):



In this dialog above user has two choices: launch any workspace or finally terminate Eclipse via "Cancel".

Proposal #1 Matrix

A1. If the workbench was not started yet:

  1. If Eclipse was started with or without "-data" argument and user selects incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer workspace selection dialog. To terminate Eclipse, user has to click "Cancel" in the workspace selection dialog.

B1. If the workbench was started:

  1. If user selects compatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts fine.
  2. If user selects incompatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts, shows the "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer to select another workspace.

Fix Proposal #2

The proposal is, that depending on the way Eclipse was started, if user clicks on the "Cancel" button in the "Older Workspace Version" dialog, we may or may not show the default workspace selection dialog. So what happens after "Older Workspace Version" dialog is shown is not predictable by just looking on this dialog - it depends on the history of this dialog.

Proposal #2 Matrix

A2. If the workbench was not started yet:

  1. If Eclipse was started without "-data" argument and user selects incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer workspace selection dialog.
  2. If Eclipse was started with "-data" argument pointing to the incompatible workspace, Eclipse will show "Older Workspace Version" dialog above and by clicking on "Cancel" it will terminate (instead of offering to select another workspace).

B2. If the workbench was started:

  1. If user selects compatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts fine.
  2. If user selects incompatible workspace in the "File -> Switch Workspace" dialog, Eclipse restarts, shows the "Older Workspace Version" dialog above and by clicking on "Cancel" it will offer to select another workspace.

Similarities

Both proposals fix second bullet in the use case B2.

Differences

We see that Proposal #1 has no second bullet for A1 case, and is always consistent in the way how UI behaves after clicking on "Cancel" in the "Older Workspace Version" dialog. Proposal #2 fixes only B2 use case, inconsistency in UI behavior for the second part of A1 use case remains.

Technical (biased) notes:

  1. Proposal #1 is implemented and the patch is available, along with the demo video. To test it live, one has to build Eclipse - but here I have SDK binaries with the patch applied. The patch is relatively simple and only affects Platform UI internal code.
  2. Proposal #2 is not implemented yet. I assume that this will require more work compared to the patch #1. We will need a new command line argument for Eclipse to differentiate between "I want you not to terminate even if incompatible -data is supplied because I'm calling you from UI" and "Please terminate if incompatible data is supplied because I'm calling you from the command line". A new command line argument for Eclipse means not just Platform UI internal change, but also requires changes in the Equinox and Help, and also means public interface change.

Question to the masses!

We want to know your opinion - which proposal should be implemented?

Please reply here or on the bug 538830.



by Andrey Loskutov (noreply@blogger.com) at May 16, 2019 12:11 PM

Eclipse Foundation Launches openMobility Working Group

May 13, 2019 10:30 PM

Today we announced the launch of the openMobility Working Group that will focus on open and shared collaboration around one of the major issues in urban planning around autonomous vehicles and future transportation requirements.

May 13, 2019 10:30 PM

Quarkus

by jeffmaury at May 13, 2019 12:23 PM

You’ve probably heard about Quarkus, the Supersonic Subatomic Java framework tailored for Kubernetes and containers.

We wrote an article on how to create your first Quarkus project in an Eclipse based IDE (like Red Hat CodeReady Studio).


by jeffmaury at May 13, 2019 12:23 PM

The Cloud Native Imperative - Results from the 2019 Jakarta EE Developer Survey

May 10, 2019 07:00 PM

The results of the 2019 Jakarta EE Developer Survey are out. Almost 1,800 Java developers from around the world have spoken.

May 10, 2019 07:00 PM

The Cloud Native Imperative — Results from the 2019 Jakarta EE Developer Survey

by Mike Milinkovich at May 10, 2019 03:17 PM

The results of the 2019 Jakarta EE Developer Survey are out. Almost 1,800 Java developers from around the world have spoken. Taken together with the engagement and response to my recent posts on the future of Jakarta EE (see my latest blog here), the survey makes clear the developer community is focused on charting a new course for a cloud native future, beginning with delivering Jakarta EE 8. The Java ecosystem has a strong desire to see Jakarta EE, as the successor to Java EE, continue to evolve to support microservices, containers, and multi-cloud portability.

Organized by the Jakarta EE Working Group, the survey was conducted over three weeks in March 2019. Just like last year (see the 2018 results here), Jakarta EE member companies promoted the survey in partnership with the London Java Community, Java User Groups, and other community stakeholders. Thank you to everyone who took the time to participate. Access the full findings of the survey here.

Some of the highlights from this year’s survey include:

  • The top three community priorities for Jakarta EE are: better support for microservices, native integration with Kubernetes (tied at 61 percent), followed by production quality reference implementations (37 percent). To move mission-critical Java EE applications and workloads to the cloud, developers will need specifications, tools, and products backed by a diverse vendor community. Jakarta EE Working Group members have committed to deliver multiple compatible implementations of the Jakarta EE 8 Platform when the Jakarta EE 8 specifications are released.
  • With a third of developers reporting they are currently building cloud native architectures and another 30 percent planning to within the next year, cloud native is critically important today and will continue to be so;
  • The number of Java applications running in the cloud is projected to substantially increase, with 32 percent of respondents expecting that they will be running nearly two-thirds of their Java applications in the cloud within the next two years;
  • Microservices dominates as the architecture approach to implementing Java in the cloud, according to 43 percent of respondents;
  • Spring/Spring Boot again leads as the framework chosen by most developers for building cloud native applications in Java;
  • Eclipse Microprofile’s adoption has surged, with usage growing from 13 percent in 2018 to 28 percent today;
  • Java continues to dominate when it comes to deploying applications in production environments. It comes as no surprise that most companies are committed to protecting their past strategic investments in Java.

Once again, thanks to everyone who completed the survey and to the community members for their help with the promotion.

Let me know what you think about this year’s survey findings. We are open to suggestions on how we can improve the survey in the future, so please feel free to share your feedback.


by Mike Milinkovich at May 10, 2019 03:17 PM

New Eclipse Foundation Community Survey of Java Developers Shows Cloud Native Adoption Accelerating Dramatically with Jakarta EE

May 09, 2019 07:00 PM

Eclipse Foundation enterprise Java survey shows cloud deployments increasing over 2018 findings with 62% of Java developers building cloud native architectures now or within the year

May 09, 2019 07:00 PM

Eclipse Contributor Agreement 3.0

May 08, 2019 03:00 PM

The Eclipse Foundation's IP Team has been working hard to get the various agreements that we maintain between the Eclipse Foundation and community updated.

May 08, 2019 03:00 PM

Frequently Asked Questions About Jakarta EE 8

May 08, 2019 03:00 PM

Have questions about Jakarta EE 8? Check out Mike Milinkovich's newest FAQ blog!

May 08, 2019 03:00 PM

Frequently Asked Questions About Jakarta EE 8

by Mike Milinkovich at May 08, 2019 12:00 PM

I’d like to thank the community for the level of engagement we’ve seen in response to my post from last week.   This post, which again represents the consensus view of the Jakarta EE Steering Committee, answers some questions about Jakarta EE 8, which is planned as the initial release of Jakarta EE, and is intended to be fully compatible with Java EE 8, including use of the javax namespace.   We thought it would be useful to reiterate the messages we have been delivering about this release.

Note that this post is not about future Jakarta releases where the namespace will be changed. There is a vigorous discussion going on right now on the jakarta-platform-dev@eclipse.org list (archive), so if you are interested in that topic, I would suggest you participate there. We expect that it will be about a month before the Jakarta EE Spec Committee will determine the next steps in the Jakarta EE roadmap.

Will Jakarta EE 8 break existing Java EE applications that rely upon javax APIs?

No, Jakarta EE 8 will not break existing existing Java EE applications that rely upon javax APIs.   We expect Jakarta EE 8 to be completely compatible with Java EE 8. We expect Jakarta EE 8 to specify the same javax namespace, and the same javax APIs and the same behavior as is specified in Java EE 8.    We expect that implementations that pass the Java EE 8 TCKs will also pass the Jakarta EE 8 TCKs, because the Jakarta EE 8 TCKs will be based on the same sources as the Java EE 8 TCKs. Jakarta EE 8 will not require any changes to Java EE 8 applications or their use of javax APIs.

What will Jakarta EE 8 consist of?

The Jakarta EE 8 specifications will:

  • Be fully compatible with Java EE 8 specifications
  • Include the same APIs and Javadoc using the same javax namespace
  • Provide open source licensed Jakarta EE 8 TCKs that are based on, and fully compatible with, the Java EE 8 TCKs.
  • Include a Jakarta EE 8 Platform specification that will describe the same platform integration requirements as the Java EE 8 Platform specification.
  • Reference multiple compatible  implementations of the Jakarta EE 8 Platform when the Jakarta EE 8 specifications are released.
  • Provide a compatibility and branding process for demonstrating that implementations are Jakarta EE 8 compatible.

Will there be Jakarta EE 8 compatible implementations?

Yes.  Multiple compatible implementations of the Jakarta EE 8 Platform will be available when the Jakarta EE 8 specifications are released.  We expect that any Java EE 8 compatible implementation would also be Jakarta EE 8 compatible, and the vendors in the Jakarta EE Working Group intend to certify their Java EE 8 compatible implementations as Jakarta EE 8 compatible.  In addition, because the Jakarta EE TCKs are available under an open source license, we will “lower the bar” for other technology providers to demonstrate Jakarta EE compatibility for their implementations. The lower cost and more liberal Jakarta EE trademark licensing will allow more technology providers to leverage and strengthen the Jakarta EE brand in the Enterprise Java community.  Jakarta EE 8 will provide a new baseline for the evolution of the Jakarta EE technologies, under an open, vendor-neutral community-driven process.

What is the process for delivery of Jakarta EE 8

The process for delivery of Jakarta EE 8 specifications will be fully transparent and will follow the Jakarta EE Specification Process.  Expect to see in coming weeks the delivery of initial, draft Jakarta EE 8 component specifications corresponding to Java EE 8 component specifications.  These will contain Javadoc defining the relevant APIs, and TCKs for compatibility testing. To publish specification text, we need to acquire copyright licenses for this text.  We have obtained Oracle and IBM’s copyright licenses for their  contributions, and intend to obtain the remaining copyright licenses required to publish the text of the Jakarta EE 8 Platform specification, and as much as possible of the component specifications. If you contributed to the Java EE specifications at the JCP in the past, expect to be contacted by the Eclipse Foundation to provide a license to use your contributions in Jakarta EE going forward. Providing such a license will be an important step in supporting the new specification process and the Jakarta EE community.  You will see these draft specifications evolve to final specifications in an open community process. Join the specification projects and participate!

When will Jakarta EE 8 be delivered?

The Jakarta EE Working Group intends to release final Jakarta EE 8 specifications by the fall of 2019.    This is an open community-driven effort, so there will be transparency into the process of driving the Jakarta EE 8 specifications, delivery of the Jakarta EE 8 TCKs, and Jakarta EE 8 compatible implementations.


by Mike Milinkovich at May 08, 2019 12:00 PM

Eclipse and Oracle Unable to Agree on Terms for javax Package Namespace and Trademarks

by Erik Costlow at May 08, 2019 05:00 AM

The Eclipse Foundation and Oracle were unable to agree on a path forward for enhancing Java EE's javax namespace, requiring all applications to be ported to a new namespace for Jakarta EE.

By Erik Costlow

by Erik Costlow at May 08, 2019 05:00 AM

Eclipse Contributor Agreement 3.0

by waynebeaton at May 07, 2019 09:03 PM

The Eclipse Contributor Agreement (ECA) is an agreement made by contributors certifying the work they are contributing was authored by them and/or they have the legal authority to contribute as open source under the terms of the project license.

The Eclipse Foundation’s IP Team has been working hard to get the various agreements that we maintain between the Eclipse Foundation and community updated. Our first milestone targeted the ECA, and we’re happy to report that a very significant number of our community members have successfully updated theirs. Today, we retired all of the rest of them. Specifically, we’ve revoked all ECAs that predate the ECA version 3.0.

We’re confident that we’ve managed to connect and update the ECA for everybody who still wants to be a contributor, so there should be no interruption for anybody who is actively contributing. If we missed you, you’ll be asked to sign the new ECA the next time you try to contribute. Or you can just re-sign it now.

We’ve made some changes with the new agreements that make contributing easier, (but explaining harder). Committers who have signed the Individual Committer Agreement (ICA) version 4.0 or work for a company that has signed the Member Committer and Contributor Agreement do not require an ECA.

Contact emo_records@eclipse.org if you’re having trouble with an agreement.


by waynebeaton at May 07, 2019 09:03 PM

Update on Jakarta EE Rights to Java Trademarks

May 03, 2019 08:00 PM

Summary of progress to date and implications of the agreement between Eclipse and Oracle on Jakarta EE and use of Java trademarks and the javax namespace.

May 03, 2019 08:00 PM

Update on Jakarta EE Rights to Java Trademarks

by Mike Milinkovich at May 03, 2019 10:00 AM

Summary of progress to date and implications of the agreement between Eclipse and Oracle on Jakarta EE and use of Java trademarks and the javax namespace.

Introduction

The migration of Java EE to the Eclipse Foundation has been an enormous effort on behalf of the Eclipse Foundation staff and the many contributors, committers, members, and stakeholders that are participating.

This post was reviewed and represents the consensus view of the Jakarta EE Steering Committee.

Earlier this year GlassFish 5.1 was certified at Eclipse using the Java EE 8 TCK at the Eclipse Foundation. Since then under the direction of the working group the community established a Jakarta EE Specification Process (JESP) for the evolution of the Jakarta EE specs at the Eclipse Foundation. Specification projects are being created for all of the Jakarta EE specifications. The TCK process is being refined for Jakarta EE in concert with the new Jakarta EE compatibility logo. This is all being done in support of the Jakarta EE 8 release.

Progress to Date

The Jakarta community has been busy.

  • Oracle contributed GlassFish and the Java EE APIs and TCKs to Jakarta EE.
  • The Jakarta EE Working Group was formed and supporting committees to provide governance to the community and facilitate collaboration.
  • Eclipse GlassFish was certified with the Java EE TCK at the Eclipse Foundation.
  • The Eclipse Foundation Specification Process was created, and customization created and approved for the Jakarta EE Specification Process.
  • Specification projects are being created and work is underway now within the community to deliver the Jakarta EE 8 release later this year.
  • There is an initiative underway for Oracle, IBM, Red Hat and other members of the JCP to contribute their specification documents created at the JCP to Jakarta.

It had been the mutual intention of the Eclipse Foundation and Oracle to agree to terms that would allow the evolution of the javax package namespace in Jakarta EE specifications.   Unfortunately, following many months of good-faith negotiations, the Eclipse Foundation and Oracle have been unable to agree on terms of an agreement for the Eclipse Foundation community to modify the javax package namespace or to use the Java trademarks currently used in Java EE specifications.   Instead, Eclipse and Oracle have agreed that the javax package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications.  Because of the complexity and confidential nature of our negotiations, the Eclipse Foundation and Oracle have also agreed that we will not attempt to characterize here what has resulted in this outcome. It is the best outcome we could mutually achieve for the community. Some additional context is provided in the Eclipse Foundation Board and Jakarta EE Steering Committee meeting minutes.

What restrictions does this outcome impose on the Eclipse community?

Oracle’s Java trademarks are the property of Oracle and the Eclipse Foundation has no rights to use them.   The implications of this are as follows:

  1. The javax package namespace may be used within Jakarta EE specifications but may be used “as is” only.  No modification to the javax package namespace is permitted within Jakarta EE component specifications. Jakarta EE specifications that continue to use the javax package namespace must remain TCK compatible with the corresponding Java EE specifications.
  2. Jakarta EE component specifications using the javax package namespace may be omitted entirely from future Jakarta EE Platform specifications.
  3. Specification names must be changed from a “Java EE” naming convention to a “Jakarta EE” naming convention.  This includes acronyms such as EJB, JPA or JAX-RS.

In addition to the above, any specifications which use the javax namespace will continue to carry the certification and container requirements which Java EE has had in the past. I.e., implementations which claim compliance with any version of the Jakarta EE specifications using the javax namespace must test on and distribute containers which embed certified Java SE implementations licensed by Oracle. These restrictions do not apply to Jakarta EE specifications which do not utilize javax, including future revisions of the platform specifications which eliminate javax.

Note that the ratified Jakarta EE specifications will be available under a different license (the Eclipse Foundation Specification License). This is the reason why the Eclipse Foundation is currently asking the community to update their contributor and committer agreements.

What is next for the Jakarta EE Working Group?

The Jakarta EE Working Group including Oracle will continue to do what they set out to do: namely, move Java EE to the Eclipse Foundation. The group remains committed to creating a Jakarta EE 8 specification, logoed under the Eclipse Foundation’s Jakarta trademark. Further, the group is also committed to future versions of the Jakarta EE specifications that deliver on the original promises of innovation and evolution in cloud-native Java.

What does it mean for Jakarta EE to not modify the javax package namespace?

The Agreement does allow for modification and evolution under a new namespace, such as jakarta. It is expected that all future evolution and innovation will not use the javax namespace.

What happens to the Jakarta EE brand?

The Jakarta EE compatibility and the Jakarta EE member logos have both been decided on by the community and published. Work is underway to deliver the branding usage guidelines and supporting trademark license agreement. We expect to see the usage of these brands later this year.

Will there be a Jakarta EE 8?

Yes. The community is working hard to deliver the Jakarta EE 8 release, which is Java EE 8 delivered from Eclipse. We expect that many application servers will certify as Jakarta EE 8 compatible.

What happens beyond Jakarta EE 8?

The guiding principle for Jakarta EE 9 will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.  This will most likely involve two key topics: migration of some or all of the Jakarta EE specification source to a new namespace for future evolution; means to provide backwards compatibility with javax at a binary level, allowing old applications to run on Jakarta 9 implementations with some form of build or runtime tooling.

So while there will be a point in time where future versions of specifications will have to go through a source code incompatible change with respect to the previous javax based packages, this will be a straightforward transformation.

Further plans are being evolved by the Jakarta EE community via the Jakarta EE Platform Project. Your comments and participation are encouraged.

What does this mean for the EE4J projects?

The specification projects need to be renamed to not use Oracle’s Java trademarks. The Jakarta community gets to decide on the new names. This is an opportunity to tighten up the naming and get a better level of consistency. The future of Eclipse Enterprise for Java (EE4J) projects will be determined by the community who participate in those specifications and open source projects.

What is next for Eclipse GlassFish?

Work is underway at the Eclipse GlassFish project running the Jakarta EE 8 TCK and being ready to support its role in the TCK for interop testing. The future of Eclipse GlassFish will be determined by the community who participate in the project.

How will specs be updated beyond Jakarta EE 8?

Jakarta EE specifications will be updated according to the approved Jakarta EE Specification Process (JESP). The actual enhancements will be determined by the community who participate in those specification projects.


by Mike Milinkovich at May 03, 2019 10:00 AM

Back to the top