Finishing Jakarta EE Release

It has been a year since the opening of Java EE has been announced. Whole year first the Oracle company and later the Jakarta EE community jumped in to be working hard on the transition of every Java EE technology to the Eclipse Foundation under Jakarta EE umbrella. Java EE reference implementation – Glassfish application server, as well as the Java EE Technology Compatibility Kit (Java EE TCK) are under the Jakarta EE umbrella, too.

As part of the transition process, couple of Java EE technologies were released recently, noticeably (from the Jersey perspective):

However, these technologies won’t be part of of the initial Jakarta EE release. Every API, and every implementation needs to be released again, with Eclipse compatible license. The initial Jakarta EE release should be (binary) compatible to the latest Java EE releases.

To prove the compatibility of Jakarta EE with JavaEE, the Jakarta EE initial release neeeds to pass Java EE TCK. The process is to stage the artifacts first, integrate to Eclipse Glassfish, pass the Java EE TCK, and then release the artifacts, the Jakarta EE initial release.

All of the Jakarta EE APIs were staged. The api artifacts are no longer javax.* jars, they are jakarta.* jars, now. JAX-RS API will be of version 2.1.3. The implementations are being staged, too. Eclipse Jersey will be of version 2.28.

Everyone works hard on the Jakarta EE release, but it is a bit overdue. All the artifacts were planned to be staged before November 5th. Currently, it looks like couple of more weeks are needed. The good news is, it’s happening, and likely everyone can get his Jakarta EE release for a Christmas gift.

 

Posted in Jakarta EE, Jersey | Leave a comment

Introducing Jersey to the Eclipse Community

Most of the Java EE projects have already transitioned to the Eclipse Foundation under the Jakarta EE umbrella of projects. One of those projects is Jersey, which is a RESTful Web services framework and reference implementation of the JAX-RS Specification. We announced the initial contribution of Jersey a few weeks ago. Since then, we saw an increase of community interest in Jersey. We registered a number of filed ideas for enhancements, discovered issues, and received pull requests from both individuals and industry. All of these are very welcome.

Jersey is used in Glassfish and Weblogic application servers, and it is often understood to be an “enterprise” framework that needs full application server with CDI, EJB, and bean validation support, or at least a servlet container, such as Tomcat. Sure, Jersey can leverage integration with other Java EE/Jakarta EE projects, but there is more.  Jersey comes with an ability to deploy JAX-RS application in a Java SE environment; it provides a container extension module that enables support for using a variety of frameworks that only understand the HTTP protocol. This is useful in the microservices world. Using Jersey, you can create a simple micro application that is capable of running inside a Docker container with just a JDK installed!

Let’s create an application that accepts queries and provides answers. First, we define the maven dependencies. Note the last hk2 dependency which is needed since Jersey 2.26:

<dependency>
  <groupId>org.glassfish.jersey.core</groupId>
  <artifactId>jersey-common</artifactId>
</dependency>
<dependency>
  <groupId>org.glassfish.jersey.core</groupId>
  <artifactId>jersey-client</artifactId>
</dependency>
<dependency>
  <groupId>org.glassfish.jersey.core</groupId>
  <artifactId>jersey-server</artifactId>
</dependency>
<dependency>
  <groupId>org.glassfish.jersey.inject</groupId>
  <artifactId>jersey-hk2</artifactId>
</dependency>

For simplicity, we can use the HTTP server from the JDK so as not to bring other dependencies, such as the widely used Grizzly. (Other deployment options are described in the Jersey User Guide, which has yet to be transitioned to the Eclipse Foundation):

<dependency>
  <groupId>org.glassfish.jersey.containers</groupId>
  <artifactId>jersey-container-jdk-http</artifactId>
</dependency>

We would like to send popular JSON, so we add a dependency for it:

<dependency>
  <groupId>org.glassfish.jersey.media</groupId>
  <artifactId>jersey-media-json-binding</artifactId>
</dependency>

We define the entity to be sent as an answer and the resource that sends responses for the ultimate question requests:

public class Answer {
  public Answer(String answer) {
    this.answer = answer;
  }
  public String answer;
}

@Path("/question")
public class QuestionResource {
  public static final String RESPONSE = "42";

  @GET
  @Path("ultimate")
  @Produces(MediaType.APPLICATION_JSON)
  public Answer getResponse() {
    return new Answer(RESPONSE);
  }
}

We start the JDK HTTP Server on port 8080 with the QuestionResource registered. We also want the entity to be wired as JSON, so we use JsonBindingFeature:

URI base_uri = UriBuilder.fromUri("http://localhost/").port(8080).build();
ResourceConfig config = new ResourceConfig(QuestionResource.class, JsonBindingFeature.class);
JdkHttpServerFactory.createHttpServer(base_uri, config);

At this point, the Jersey application is up. We can use cURL, or even better, the JAX-RS Client (implemented by Jersey of course – and we have defined the maven org.glassfish.jersey.core:jersey-client dependency for it already):

System.out.println(ClientBuilder.newClient().target(base_uri).path("question/ultimate").request().get(String.class));

And we should see the JSON response:

{"answer":"42"}

The ability to run the JAX-RS application in the Java SE environment is a new feature in the planned JAX-RS 2.2 release.

JAX-RS is evolving fast. There are already plans for 3.0, which Jersey needs to reflect. Also there are MicroProfile features that Jersey should either implement or integrate with. And JDK 9/10/11 need to be fully supported. There is a lot of work for the future and we are looking forward to hearing from the community. Your feature proposals, bug reports, and pull requests are very much appreciated!

Posted in Jersey | 2 Comments

Email to Jersey Community: Jersey has been contributed to Eclipse Foundation

Dear Jersey enthusiasts, Jersey users,

As you likely have noticed, Oracle is in the process of transitioning Java EE and related projects to the Eclipse Foundation [1]. Jersey is included in this list of projects and we are pleased to announce that the initial contribution has taken place. Jersey is being contributed to Eclipse Foundation as Eclipse Jersey[2].

We would like to take this opportunity to thank all of our community members for their effort and dedication to Jersey for these many years. Thank you for your many contributions and assistance improving the quality of the project, the documentation, and identifying issues.

The original Jersey project repository has been transitioned to Archive status — which renders it “Read Only.” All issues have been migrated to the Eclipse Jersey project. Any remaining PRs that are still relevant will need to be migrated to the new Eclipse Jersey project repository at GitHub [3].

We hope that you will join us as we continue evolving the new Eclipse Jersey project. Jersey will use the Eclipse developer mailing list for product announcements and updates [4]. If you want to track issues, don’t forget to follow Eclipse Jersey at it’s new GitHub location. The new process for contributions under Eclipse is described under “Contributing file” at this link [5].

We look forward to your continued contributions as part of the Eclipse Foundation. We hope that this transition is easy and smooth.

Thank you again for making Jersey the best that it can be.

Kind Regards,

The Jersey Team

[1] https://blogs.oracle.com/theaquarium/ee4j%3a-an-update
[2] https://projects.eclipse.org/projects/ee4j.jersey
[3] https://github.com/eclipse-ee4j/jersey
[4] mailto:jersey-dev[at]eclipse.org, subscribe at https://accounts.eclipse.org/mailing-list/jersey-dev
[5] https://www.eclipse.org/projects/tools/about.php?id=ee4j.jersey

Posted in Jersey | Leave a comment

Jersey 2.27 Released

We have just released the 2.27 version of Jersey, reference implementation of JAX-RS 2.1.

To download Jersey 2.27, please check out our download page.

You can also check out the refreshed Jersey 2.27 documentation:

Let us know how you like it!

Posted in Jersey | 12 Comments

What’s going on with Jersey

Jersey is on a journey to Eclipse Foundation. There are some consequences, unfortunately, the visible activity around the project is not great. The number of open issues is growing. New pull requests are not accepted. All because of the work being done on the donation.

But we are getting to the final. Jersey 2.27 is going to be released soon, it is legally approved for the transition to the Foundation which happens next, and then hurray! Long live Eclipse Jersey!

The Jersey code is going to be pushed to EE4J repository. The issues and PRs are going to be migrated, too. The commit history, branches, and tags are of course not donated (imagine the legal code validation needed for every commit, every tag and branch – it would take a lifetime to process through). Those will remain in current GitHub repository – which will be for reading only – any new commits and issues should go to the new Eclipse Jersey repository.

Eclipse Jersey needs to pass through legal CQ process, build infrastructure (CI/CD) needs to be set up, and that’s it, work can get started!

Posted in Jersey | 1 Comment

What’s going on with Java EE?

As it has been announced, Oracle decided to open up Java EE and donate each Java EE technology owned, to the Eclipse Foundation. This comes in four stages, and a current status is reported for instance by Java Evangelist. The umbrella of once Java EE projects in the Foundation has a code name Eclipse Enterprise for Java (EE4J) and Java EE is called Jakarta EE now. There is an EE4J Project Management Committee (PMC) that sets the future development course of Jakarta EE.

This does not mean Oracle stops working on the technologies immediately after the donation. On contrary, more activity around the projects is expected, and the community would be more involved in bringing up new ideas and features. The donation, however, comes with a side effect. Every Java EE project needs to go through the code evaluation by legal. Every piece of code, as well as each dependency, needs to be verified whether the license allows it to be donated. This is a lengthy process, the bigger the project, the longer the evaluation. This process means that every Java EE project needs to be frozen, no new features can be accepted, no pull requests (PR) are merged, since each new piece of code would need to be legally processed and the donation would get longer and longer. A similar legal process is on the donor side, as well as on the Foundation side, taking even a little bit more time. Unfortunately, someone feels that’s wrong. That the project is abandoned. That no one is responding. Apologies, here are the reasons.

So does that mean the pull requests can be accepted as soon as the Java EE project is donated? Well, for each donated project, the plan is to create one last release. The same code base should be used for a very first release within the Foundation. So after the last Java EE project is donated (including the big guys Glassfish and CTS), the first release takes place. No new features, no new code, only critical fixes allowed. The PRs are merged to another branch waiting for the second release. That eventually will be the proper Jakarta EE!

Posted in Jakarta EE | Leave a comment