Skip to main content

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

Jakarta EE Community Engagement

by Tanja Obradovic at May 02, 2019 05:35 PM

 

 

The intention of the blog is to list all the ways we currently (May 2019) engage with the community.

Social media

Jakarta EE on social media

  • Twitter: @JakartaEE

  • Facebook: Jakarta EE

  • LinkedIn Group: Jakarta.EE

Mailing lists

Subscribe to our mailing-lists https://jakarta.ee/connect/

Note: people involved in a specific project have additional mailing lists available to them.

Newsletter / Blogs / emails

Eclipse Newsletter - while the EF newsletter occurs monthly, once a quarter the newsletter is dedicated to Jakarta EE

Jakarta Blogs - https://jakartablogs.ee/

In addition to the above Jakarta blogs that are covering all Java Cloud related topics, we are adding the following

Meetings

Jakarta Tech Talks - open to community jakarta.ee-community@eclipse.org

Jakarta EE Update (formerly: Jakarta EE WG) calls - open to WG jakarta.ee-wg@eclipse.org  and wider community  jakarta.ee-community@eclipse.org

  • Use the time slot for occasional updates from Eclipse Foundation and strategic members (Executive Director and panel)  - Jakarta Town Hall

Jakarta Town Hall

We had 2 very successful instances of town hall meetings - first at EclipseCon Europe 2018 and A year in review in late January 2019

EF organized Events and Conferences

JakartaOne Live - virtual one-day event, targeting users and adopters. Planned for the second week of September 2019.

EclipseCon Europe - 4-day Eclipse event, with dedicated Cloud Native Java track, community day event scheduled, likely Jakarta Town Hall.  Scheduled for October 21-24, 2019.


by Tanja Obradovic at May 02, 2019 05:35 PM

Code Duplication

by Donald Raab at May 01, 2019 03:49 AM

Duplicate code makes me itch, until I scratch it away.

Itchy scratchy hay!

I hate code duplication

Nothing bothers me quite like code duplication. I get an unbearable itch every time I spot some duplication in a code base. The only way to make the itch go away is to find a suitable way to remove the duplication.

I am always reminded of this quote from a Yahoo Groups post from Ryan King many years ago when I spot code duplication.

So, duplication sucks. The more rabidly a person hates duplication, the more I trust their opinions on managing information. A programmer, upon noticing some redundancy, should be thrown into a panic, begin hyperventilating, and stammer something about “¡El diablo! !El diablo está en mi software!”.
— Ryan King

So what can we do when we find code duplication? We can learn ways to remove it. Google and StackOverflow are great resources for finding answers to solving many common programming problems. They can be your first port of call for discovering and learning new APIs that may help reduce some of the duplicate code you may have written previously.

Simple patterns of duplication

Sometimes code duplication is easy to spot and to remove. I will start by describing some very simple common patterns of duplication I spot in code bases all the time.

Boolean Test Pattern

Testing a boolean value and returning true or false. I’ve seen this pattern of code more than you might imagine over the years.

public boolean isSomething()
{
if (!this.calculateSomeBooleanValue())
{
return true;
}
else
{
return false;
}
}

Write this instead.

public boolean isSomething()
{
return !this.calculateSomeBooleanValue();
}

Collection Factory Pattern

Here’s another simple pattern that can be fixed easily. This kind of code is very commonly written in test cases. It is important to address code duplication issues across your entire code base, including tests.

List<String> list = new ArrayList<>();
list.add("one");
list.add("two");
list.add("three");

This code can be replaced as follows using Eclipse Collections mutable factory pattern.

List<String> list = Lists.mutable.with("one", "two", "three");

Here’s an answer on StackOverflow that show different ways to initialize a List, Set, and Bag in one line with Eclipse Collections.

Unmodifiable Static Collection Initializer Pattern

The following code used to be common in Java versions prior to Java 9, for creating a static unmodifiable List.

public static final List<String> LIST;

static
{
List<String> newList = new ArrayList<>();
newList.add("one");
newList.add("two");
newList.add("three");
LIST = Collections.unmodifiableList(newList);
}

This can be written more simply as follows using plain old Java.

public static final List<String> LIST =
Collections.unmodifiableList(
Arrays.asList("one", "two", "three"));

This can also be replaced as follows using Eclipse Collections.

public static final List<String> LIST =
Lists.mutable.with("one", "two", "three").asUnmodifiable();

As of Java 9, you can also write the following. The method List.of() returns an unmodifiable List.

public static final List<String> LIST = 
List.of("one", "two", "three");

You can also use an ImmutableList from Eclipse Collections if you want to have a contractually immutable interface like ImmutableList which has no mutating methods.

public static final ImmutableList<String> LIST = 
Lists.immutable.with("one", "two", "three");

Static Map Initializer Pattern

Initializing a static Map can be a bit more challenging, if you have more than three or four key/value pairs in the Map.

public static final Map<Integer, String> MAP;

static
{
Map<Integer, String> newMap = new HashMap<>();
newMap.put(1, "one");
newMap.put(2, "two");
newMap.put(3, "three");
newMap.put(4, "four");
newMap.put(5, "five");
MAP = Collections.unmodifiableMap(newMap);
}

Refactored to use an Eclipse collections unmodifiable map.

public static final Map<Integer, String> MAP =
Maps.mutable.<Integer, String>empty()
.withKeyValue(1, "one")
.withKeyValue(2, "two")
.withKeyValue(3, "three")
.withKeyValue(4, "four")
.withKeyValue(5, "five")
.asUnmodifiable();

Refactored to use an Eclipse collections ImmutableMap which also has no mutating methods in its interface.

public static final ImmutableMap<Integer, String> MAP =
Maps.mutable.<Integer, String>empty()
.withKeyValue(1, "one")
.withKeyValue(2, "two")
.withKeyValue(3, "three")
.withKeyValue(4, "four")
.withKeyValue(5, "five")
.toImmutable();

Here’s a an answer on StackOverflow that shows various ways to initialize a static map with Eclipse Collections.

Iteration Patterns

One of the primary reasons I started building Eclipse Collections was that I would see developers writing the same for-loops over and over again. Developers were constantly reimplementing collection iteration patterns in Java. I saw code duplication everywhere! Developers did this prior to Java 8 because the iteration patterns available to Java developers then were limited to what could be found on the Collections utility class. Eclipse Collections has been in development and used in production since JDK 1.4. Eclipse Collections has been my preferred solution for removing duplicate iteration pattern code for the past fifteen years in Java.

Filter Pattern

Prior to Java 8, the following was the usual way of filtering a source collection to a target collection based on some condition.

List<Integer> source = Arrays.asList(1, 2, 3, 4, 5);
List<Integer> target = new ArrayList<>();
for (Integer value : source)
{
if (value % 2 == 0)
{
target.add(value);
}
}

Here’s the same code refactored using the Eclipse Collections select method.

MutableList<Integer> source = Lists.mutable.with(1, 2, 3, 4, 5);
MutableList<Integer> target = source.select(each -> each % 2 ==0);

Here’s an answer on StackOverflow to the question of “What is the best way to filter a Java Collection?”

Transform Pattern

Prior to Java 8, the following was the typical way of converting one collection type to another.

List<Integer> source = Arrays.asList(1, 2, 3, 4, 5);
List<String> target = new ArrayList<>();
for (Integer value : source)
{
target.add(value.toString());
}

Here’s the same code refactored using the Eclipse Collections collect method.

MutableList<Integer> source = Lists.mutable.with(1, 2, 3, 4, 5);
MutableList<String> target = source.collect(Object::toString);

Any / All / None Patterns

Prior to Java 8, you would either use a break statement with a boolean variable or a direct return from inside an if statement to see if any, all, or none of the elements of a collection match a given condition.

Any Pattern

List<Integer> source = Arrays.asList(1, 2, 3, 4, 5);
boolean anyEvens = false;
for (Integer value : source)
{
if (value % 2 == 0)
{
anyEvens = true;
break;
}
}

Refactored with Eclipse Collections anySatisfy method.

MutableList<Integer> source = Lists.mutable.with(1, 2, 3, 4, 5);
boolean anyEvens = source.anySatisfy(each -> each % 2 == 0);

All Pattern

List<Integer> source = Arrays.asList(1, 2, 3, 4, 5);
boolean allEvens = true;
for (Integer value : source)
{
if (value % 2 != 0)
{
allEvens = false;
break;
}
}

Refactored with Eclipse Collections allSatisfy method.

MutableList<Integer> source = Lists.mutable.with(1, 2, 3, 4, 5);
boolean allEvens = source.allSatisfy(each -> each % 2 == 0);

None Pattern

List<Integer> source = Arrays.asList(1, 2, 3, 4, 5);
boolean noneEvens = true;
for (Integer value : source)
{
if (value % 2 == 0)
{
noneEvens = false;
break;
}
}

Refactored with Eclipse Collections noneSatisfy method.

MutableList<Integer> source = Lists.mutable.with(1, 2, 3, 4, 5);
boolean noneEvens = source.noneSatisfy(each -> each % 2 == 0);

Other Iteration Patterns

There are many other iteration patterns available in Eclipse Collections that can help you remove duplicate code. There are over one hundred variations of iteration patterns and other APIs available on the RichIterable parent interface alone.

RichIterable APIs

Sometimes code duplication is necessary

Occasionally code duplication is the best available solution to solve a performance problem. A great example in Eclipse Collections is the primitive collections. Eclipse Collections has primitive collection support for Lists, Sets, Bags, Stacks and Maps for all eight primitive combinations (boolean, byte, char, double, float, int, long, short). The code to implement all of these container types is nearly identical. So if you read the code for an IntArrayList it will look eerily similar to the code in ShortArrayList and LongArrayList. What is important in cases where you want to provide library support for primitive types in Java is to leverage a code generation strategy wherever possible and to not duplicate the code by hand. With Eclipse Collections, we use the StringTemplate library and write templates once for each container type that are then used to generate the eight container types required to support all of the primitives.

In the future, if the work in Project Valhalla becomes part of a JDK release and we get support for generic specialization over primitive types, we may have new language level strategies in Java to reduce the amount of generated code we have to produce today to support primitive types. I am very excited to see how this support may potentially reduce our code duplication burden.

Additional Patterns of Duplication

There are a lot more patterns of duplication out there. Your IDE and various code analysis tools can sometimes help you find the obvious ones caused by copy and paste. Other times you may just need to read your code and see if you can recognize patterns where some code is going into too much detail about how to do something (for loops are sometimes a cue). Code that is written well should tell you clearly what it is doing, not how it is doing it.

Deleting duplicate code makes me feel very satisfied. It helps reduce the total cost of ownership for a an application or library. Less code to read, test, maintain, and deploy means less potential bugs to discover, debug and fix.

Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub.


by Donald Raab at May 01, 2019 03:49 AM

Ways your company can support and sustain open source

by Chris Aniszczyk at April 30, 2019 01:49 PM

Note: this article was original posted on https://opensource.com/article/19/4/ways-support-sustain-open-source

To make sure open source continues to thrive, we all need to find ways to sustain the communities and projects we depend on

The success of open source continues to grow; surveys show that the majority of companiesuse some form of open source, 99% of enterprises see open source as important, and almost half of developers are contributing back. It’s important to note that companies aren’t contributing to open source for purely altruistic reasons. Recent research from Harvard shows that open source-contributing companies capture up to 100% more productive value from open source than companies that do not contribute back. Another research study concluded countries adopting modern open source practices saw:

“a 0.6%–5.4% yearly increase in companies that use OSS, a 9%–18% yearly increase in the number of IT-related startups, a 6.6%–14% yearly increase in the number of individuals employed in IT related jobs, and a 5%–16% yearly decrease in software-related patents. All of these outcomes help to increase productivity and competitiveness at the national level. In aggregate, these results show that changes in government technology policy that favor OSS can have a positive impact on both global social value and domestic national competitiveness.”

In the end, there are many ways for a company or organization to sustain open source. It could be as simple as training your organization to contribute to open source projects you depend on or hiring engineers to work on open source projects. Here are eight ways your organization can contribute back to open source, based on examples in the industry.

Hire open source maintainers to work on open source

Companies with strategies to leverage open source often find the highest returns from hiring a maintainer of the projects they depend the most on. It’s no surprise if you look at the Who Writes the Linux Kernel report that the top contributors are all employed by companies like ARM, Google, Facebook, Intel, Red Hat, Samsung, and more.

Having a maintainer (full time or part time) on your staff can help your organization learn how to work within the project community and enable prioritization of upstream contributions based on understanding of what the community is focused on. Hiring the maintainers also means that the project will have people with enough time to focus on the details and the rigor that’s needed for a project to be useful; think security reviews, bug cleanup, release management, and more. A more predictable and reliable upstream project can benefit many in your organization while also improving the overall project community. As a bonus, maintainers can also become advocates for your organization and help with recruiting too!

Develop an open source award program or peer bonus fund

It is common for companies to have internal employee recognition programs that recognize individuals who go above and beyond. As an example, Red Hat has a community award program through Opensource.com. Some other companies have expanded their recognition programs to include open source contributors. For example, Google has an open source peer bonus program that recognizes external people who have made exceptional contributions to open source.

Start an open source program office

Many internet-scale companies, including Amazon, Google, Facebook, Twitter and more, have established formal open source programs (colloquially called OSPOs) within their organizations to manage open source strategy along with the consumption and contribution of open source.

If you want to increase your contributions to open source, research has shown that companies with formal open source programs are more likely to contribute back. If you want to learn from organizations with formal open source programs, I recommend you read the TODO Group Open Source Program Guides.

Launch an open source fund

Some organizations contribute fiscally to the open source projects that are important to them. For example, Comcast’s Open Source Development Grants “are intended to fund new or continued development of open source software in areas of interest to Comcast or of benefit to the Internet and broadband industries.” This isn’t just for big companies; small companies have open source funds, too. For example, CarGurus launched an open source fund and Eventbot is supporting open source with a small percentage of its company revenue. Another interesting approach is what Indeed has done by democratizing the open source funding process with its employees.

Contribute a portion of your company equity to open source

Consider donating a portion of your organization’s equity to an open source project you depend on. For example, Citus Data recently donated one percent of its equity to the PostgreSQL community. This worked out nicely; Citus Data was acquired by Microsoft recently, so the PostgreSQL community will benefit from that acquisition, too.

Support and join open source foundations

There are many open source foundations that house open source projects your organization depends on, including the Apache FoundationEclipse FoundationCloud Native Computing Foundation (home of Kubernetes), GraphQL FoundationLet’s EncryptLinux FoundationOpen Source Initiative (OSI), OpenStack FoundationNodeJS Foundation, and more.

Fund and participate in open source internships or retreats

There are many open source internship programs that you can participate in and help fund. Google Summer of Code (GSoC) is the largest, and it requires mentorship from employees who work on open source projects as part of the program. Or you can sponsor internships for underrepresented minorities in open source through Outreachy and CommunityBridge.

Another approach is to host an open source retreat at your company. For example, Stripe hosts open source retreats to contribute to open source projects it depends on.

Include open source in your corporate philanthropy initiatives

If your organization has a corporate sustainability or philanthropic arm, consider working with that team to include open source as a part of its work. For example, Bloomberg has a software philanthropy budget for projects it depends on, from Git to Eclipse to Python and more. In the future, I hope to see more corporate sustainability and philanthropy efforts—like Pledge 1%—that focus on funding critical open source infrastructure.

Conclusion

In conclusion, giving back to open source is not only the right thing to do, according to research, it’s also good for your business. To make sure open source continues to thrive and is sustainable in the long run, we all need to ensure that companies find ways to sustain the open source communities they depend on.


by Chris Aniszczyk at April 30, 2019 01:49 PM

Announcing Ditto Milestone 0.9.0-M2

April 29, 2019 04:00 AM

The second milestone of the upcoming release 0.9.0 was released today.

Have a look at the Milestone 0.9.0-M2 release notes for what changed in detail.

The main changes and new features since the last milestone 0.9.0-M1 are

  • rewrite of Ditto’s “search” service in order to use the same index and have the same query performance for API v1 and v2
  • several contributions in order to operate Eclipse Ditto on Microsoft Azure

Artifacts

The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central.

The Docker images have been pushed to Docker Hub:



Ditto


The Eclipse Ditto team


April 29, 2019 04:00 AM

Eclipse Foundation on the move!

April 25, 2019 08:00 PM

After 15 years at 102 Centrepointe Drive in Ottawa, the Eclipse Foundation is on the move!

April 25, 2019 08:00 PM

Back to the top