Hashtag Jakarta EE #108

Welcome to issue number one hundred and eight of Hashtag Jakarta EE!

The release reviews for the various specifications targeting Jakarta EE 10 are adding up. You can follow the progress of the reviews by looking at the Pull Requests with the materials and/or by following the ballot threads on the Public Jakarta EE Specification Committee mailing list.

There have been some discussions going on the various mailing lists regarding how to stage and release milestones and release candidates of the specification artifacts. To help with this, the Jakarta EE Platform project has written up guidelines for Milestones and Release Candidates on the Jakarta EE Platform Project Wiki.

The specification project for Jakarta RPC that I mentioned in #107 has been approved and is being set up as we speak. Join the Jakarta RPC mailing list if you are interested in participating in the project, or just want to know firsthand what’s being discussed.

Another discussion that came up on the mailing list is regarding JCache (JSR 107) and whether that could be a candidate for a Jakarta specification. Follow the email thread on the Jakarta EE Community mailing list.

If you want to learn more about what’s coming in Jakarta EE 10, do join my talk Get Ready for Jakarta EE 10! on Monday at 11:00 EST. It is streamed live on YouTube. The talk is as part of the jChampionsConference, a conference where all the speakers are Java Champions.

Hashtag Jakarta EE #107

Welcome to issue number one hundred and seven of Hashtag Jakarta EE!

My first conference of 2022 is a wrap! Read all about it in my write-up of CodeMash 2022. In-person conferences are possible in these pre-post-pandemic times as long as care is taken and local regulations are followed. The next in-person conference I am speaking at is SnowOne in Novosibirsk, Russia. There are some moving parts to be sorted out first with regard to visas, covid-regulations, and other disruptions that may or may not happen, but hopefully, I will know more in the coming days.

Before that, I will speak at the upcoming virtual jChampions Conference. This is a conference where all the speakers are Java Champions, and it is totally free! Imagine that!

So, what is going on with Jakarta EE 10? The minutes from the weekly platform call are always a good place to look for information. Another place is the Jakarta EE Platform project mailing list which is pretty active these days. There are still two weeks until the ballot for Jakarta Activation 2.1 closes. The usual ballot period for release reviews is 14 days, but for this one, it was extended to four weeks to compensate for the holiday period.

A new specification (Jakarta RPC) has been proposed and the creation review ballot is ongoing for approval by the Jakarta EE Specification Committee. The main goal of Jakarta RPC is to make gRPC easier to use within the Jakarta EE ecosystem. It is exciting to see new specifications like this one being proposed. It shows that the goal of establishing Jakarta EE as a platform for innovation is succeeding.

CodeMash 2022

CodeMash is a conference I always enjoy very much coming back to, so I was extremely pleased when they decided to have a conference this year despite all that is going on. It really shows that it is possible to arrange in-person events in a safe way.

If I should describe CodeMash in one word, it would be Friendly. It is an extremely good vibe at the conference. It does, of course, help that it is held in the conference center of an indoor water park. The organizers are 100% transparent regarding the organization, budget, and everything else.

CodeMash offers a mentoring program for new speakers. When you get a talk is accepted, you get the question of whether you would consider mentoring a new speaker or be mentored by an experienced one. Since I consider myself pretty experienced as a speaker, I signed up as a mentor this year as well.

I think mentoring programs like this one is an excellent idea and would encourage anyone offered to participate in one to do so!

My talk, Jakarta EE 10 is Coming Your Way! was scheduled for the last day of the conference. Actually to the last time slot before the conference closing session. Usually, I prefer to be scheduled earlier in the program, but I guess that’s how every speaker feels. At CodeMash they have a closing session with a raffle, so there is another incentive for the attendees to stick around rather than beat the traffic on Friday afternoon.

To sum up, CodeMash was an excellent start to the 2022 conference year and I hope to be back next year! I also look forward to speaking at lots of conferences in the upcoming months and meeting up with community members in the conferences-within-the-conference happening at meals, parties, and hallways between and after sessions.

Hashtag Jakarta EE #106

Welcome to issue number one hundred and six of Hashtag Jakarta EE!

The blog entries from the jakartablogs.ee blog aggregator are now also displayed on the new blog section on jakarta.ee. Just navigate to https://jakarta.ee/blogs, or click on the Blog menu item on the top menubar.

The Jakarta EE Platform team started 2022 with the weekly calls on January 4. These calls happen every Tuesday at 11:00 ET and are open for anyone interested to join. Check the Jakarta EE Specifications public calendar for details. These calls are an excellent opportunity to discuss matters directly with everyone involved. Don’t underestimate the power of direct, synchronous communication! Especially in these times where we are stuck behind our webcams, with email threads and slack channels flowing over and important information tending to get lost in the ever-increasing amount of spam hitting us every day. If you miss a call or are interested in seeing what is being discussed, check out the meeting minutes.

The first milestone of Spring 6.0 was released this week. Check out Juergen Hoeller’s announcement. For those of you waiting for Spring Boot 3.0, the good news is that there is a milestone planned to be released later in January. Spring 6 and Spring Boot 3 are the first versions of Spring supporting the jakarta.* namespace.

Hashtag Jakarta EE #105

Welcome to issue number one hundred and five of Hashtag Jakarta EE!

Happy New Year!

2021 is soooo last year as we now are entering 2022. This year is an important year for the Jakarta EE Community. First and foremost, 2022 is the year of Jakarta EE 10! It looks like the final release will slip a little into Q2, but the work with getting the first specifications over the finishing line is progressing. Just before New Year, Jakarta Activation 2.1 was put forward for ballot by the Jakarta EE Specification Committee. More specifications will follow now that we start returning to our desks and webcams again after a well-deserved holiday.

On the funny side, I came over the Weekend Reading List blog series by Rodrigo Graciano, JUG leader of the NYJavaSIG. He reached Weekend Reading List #104 by the end of 2021, the same as I did with my Hashtag Jakarta EE #104. That means that we must have come up with the idea to start a weekly blog series at about the same time. Keep up the good work, Rodrigo! I hope to be able to visit NYJavaSIG soon.

Hashtag Jakarta EE #104

Welcome to issue number one hundred and four of Hashtag Jakarta EE!

I’m sure most of you have better things to do during the holidays than reading my rambling here, so I will keep this issue of Hashtag Jakarta EE short.

The Jakarta EE Tutorial has been updated to match Jakarta EE 9.1. You can find it by navigating to https://start.jakarta.ee or accessing it directly here. If you are interested in contributing to open source, the tutorial, and other Jakarta EE learning resources are excellent places to start. For example, the First Cup of Jakarta EE needs to be updated to the latest version.

Hashtag Jakarta EE #103

Welcome to issue number one hundred and three of Hashtag Jakarta EE!

All sessions from JakartaOne Livestream 2021 are now available on the Jakarta EE YouTube Channel.

We thank everyone involved in making JakartaOne Livestream 2021 a success!

The Jakarta EE Platform team will now take a well-earned break over the holidays. The next weekly Platform call will be on January 4, 2022. Make sure to att the Jakarta EE Specifications Calendar to your calendar. The minutes from all these calls are always published on the Jakarta EE Platform Team project pages.

Logging Ad Nauseum

I guess I have to mention logging in one way or the other this week. A lot of good stuff has been written and communicated about this. All I want to say is that you should follow the advice to always use the latest recommended versions of your dependencies. Another piece of advice I will throw in is that you should always consider whether you actually need that particular dependency you just added. Take logging, for example. I have always been happy with Java Util Logging (JUL). It is provided for me by the platform, and provides the functionality I have needed.

package dukes;

import java.util.logging.Logger;

class DukeLogs {

    public static final Logger LOGGER = Logger.getLogger("dukes");

    void doStuff() {
        LOGGER.info(() -> "Duke says hello");
    }

}

This may not be the case for everyone. Log4j provides a lot of useful stuff that you may benefit from in your particular use case. But if you choose to rely on third-party dependencies, always make sure that you follow the recommendations to which version to use (usually the latest)!

See Eclipse and log4j2 vulnerability (CVE-2021-44228) to see the status of the various projects at Eclipse Foundation. Please help keep this list up-to-date for the projects you are involved in!

Hashtag Jakarta EE #102

Welcome to issue number one hundred and two of Hashtag Jakarta EE!

JakartaOne Livestream 2021 is a wrap!

I hope you enjoyed it as much as we did hosting the event! Don’t worry if you missed some of the talks, we have got you covered. All the videos from the talks and the Studio Jakarta EE sessions will be made available on the Jakarta EE YouTube Channel shortly.

Here is a reminder of the Jakarta EE social cards made available for you to use freely. Pick the card that fits your engagement and spread the word!

There is a new project proposal for Jakarta Commons. The intention of this project is to be a shared space for the community to define utilities, annotations, and APIs to be used by other Jakarta specification projects. Please take a look at it and provide feedback on the proposal creation tracking issue.

If you missed it, take a look at the Get to Know Jakarta MVC I posted last week.

Get to Know Jakarta MVC

To help you get to know the Jakarta MVC specification, here’s a recap of its history and status, and a brief introduction to the technology.

Jakarta MVC History and Status

The story of Jakarta MVC started back in 2014 when Java Specification Request (JSR) 371 was proposed in the Java Community Process. The work progressed very well, and the specification became popular in the community as a frequently requested addition to Java EE. When the specification was dropped for Java EE 8, the community took over and released MVC 1.0 as an independent specification in January 2020. After this release, it was transferred to the Eclipse Foundation and renamed to Jakarta MVC. 

Jakarta MVC 1.1 was released in September 2020 under the Eclipse Foundation Specification License. Just three months later, in December 2020, Jakarta MVC 2.0 was released with the jakarta.mvc.* namespace and aligned with Jakarta EE 9.

Jakarta MVC 2.0 is the most recent version of the specification, and there are currently two compatible implementations: 

Work on Jakarta MVC 2.1 is ongoing, and it is expected to be released in the Jakarta EE 10 timeframe. The Jakarta MVC project will continue to seek inclusion in the Jakarta EE Web Profile

MVC Styles 

In the Model-View-Controller (MVC) design pattern, the controller responds to a request by updating the model and selecting which view to display. The view then retrieves the data to display from the updated model (Figure 1).

MVC-1
Figure 1: Model-View-Controller Relationships

This widely used design pattern can be used in two ways: component-based and action-based. 

Component-Based MVC

Component-based MVC is made popular by component frameworks, such as Jakarta Server Faces. In this style of MVC, the framework provides the controller. This allows application developers to focus on implementing models and views, leaving controller logic to be handled by the framework (Figure 2).

MVC-2
igure 2: Component-Based MVC


Action-Based MVC

In the action-based style of MVC, the application defines the controller, giving application developers a little more fine-grained control (Figure 3).

MVC-3
Figure 3: Action-Based MVC


Jakarta MVC is an action-based MVC framework, which makes it complementary to the component-based MVC framework provided by Jakarta Server Faces. Other examples of action-based MVC include Spring MVC and Apache Struts.

Jakarta MVC Basics

Jakarta MVC is built on top of Jakarta RESTful Web Services. That means everything you know about Jakarta RESTful Web Services can be applied to your Jakarta MVC application as well.

Let’s take a closer look at what you can do with Jakarta MVC. 

The Controller

The @Controller annotation defined by Jakarta MVC marks a resource as the controller. If the annotation is applied to the resource class, all resource methods in the class become controllers. 

@Controller
@Path("hello")
public class Hello {
 
    @Path("one")

    public String oneController() {
    }

    @Path("another")
    public String anotherController() {
    }
}

The annotation can also be applied to a specific resource method. This approach is useful if you want to combine MVC controllers with REST resources in the same class.

@Path("hello")
public class Hello {

    @Controller
    @Path("one")
    public String oneController() {
    }

    @Controller
    @Path("another")
    public String anotherController() {
    }
 
    @Path("not-a-controller")
    public String notAController() {
    }
}

There are three ways to define which view a controller should select in a Jakarta MVC application:

  • First, if a controller returns void, it must be decorated with an @View annotation 
  • Second, a String returned is interpreted as a view path
  • Third, a Jakarta RESTful Web Services Response object where the entity is one of the first two 

The example below illustrates all three approaches.

@Controller
@Path("hello")
public class HelloController {

    @GET @Path("void")
    @View("hello.jsp")
    public void helloVoid() {
    }

    @GET @Path("string")
    public String helloString() {
        return "hello.jsp";
    }

    @GET @Path("response")
    public Response helloResponse() {
        return Response.status(Response.Status.OK)
            .entity("hello.jsp")
            .build();
    }
}


That’s all there is to the controller in Jakarta MVC. The rest is exactly as you know from Jakarta RESTful Web Services, such as how to handle and validate path parameters, query parameters, and bean parameters.

The Model

Jakarta MVC supports two ways of handling models:

  • Use any CDI @Named beans as your model
  • Use the provided Models interface as your model

For the CDI approach, you simply inject the CDI @Named bean into the controller, update it as needed, and return the view, as shown in the example below.

@Named("greeting")
@RequestScoped
public class Greeting {
    private String message;
    // getters and setters
}

@Path("hello")
public class HelloController {

    @Inject
    private Greeting greeting;

    @GET
    @Controller
    public String hello() {
        greeting.setMessage("Hello there!");
        return "hello.jsp";
    }
}

If the view model does not support CDI, or you want to use the provided Models interface for a different reason, you can inject the Models map and update it as shown below.

@Path("hello")
public class HelloController {

    @Inject
    private Models models;

    @GET
    @Controller
    public String hello() {
        models.put("string_greeting", "Howdy!");
        return "hello.jsp";
    }
}

The View

Views in Jakarta MVC applications are processed by a mechanism called view engines. View engines for Jakarta Server Pages and Facelets must be supported by all implementations, although the requirement to support Facelets is likely to be removed in future versions of Jakarta MVC. Additional view engines can be added using a well-defined CDI extension mechanism.

In Jakarta Server Pages views, the model is available using the Jakarta Expression Language, as shown in the example below.

<!DOCTYPE html>
<html>
    <head>
        <title>Hello</title>
    </head>
    <body>
        <h1>${greeting.message}</h1>
        <h1>${string_greeting}</h1>
    </body>
</html>

The rendered view would look something like this:

Hello   
Hello there!
Howdy!

Advanced Jakarta MVC Topics

The Jakarta MVC specification document provides a very good overview of what’s included in Jakarta MVC. I introduce some of the items here, but please refer to the specification document for details.

Data Binding

Jakarta MVC extends the data binding provided by Jakarta RESTful Web Services with support for internationalization and handling of binding errors within the controller. The Jakarta MVC-specific data binding is enabled by adding the @MvcBinding annotation to the relevant field or method parameter. Binding errors are handled in the controller by injecting BindingResult and using it to handle the error before the next view is rendered. 

@Controller
@Path("form")
public class FormController {

    @MvcBinding
    @FormParam("age")
    @Min(18)
    private int age;

    @Inject
    private BindingResult bindingResult;

    @POST
    public String processForm() {

        if( bindingResult.isFailed() ) {

            // handle the failed request
        }
 

        // process the form request
    }
}

Security

Jakarta MVC provides support to protect applications from Cross-Site Request Forgery (CSRF). To provide this support, the Jakarta MVC implementation generates a CSRF token that is available via the MvcContext object. To verify a request, simply add the @CsrfProtected annotation to the controller, as shown below.

@Path("csrf")
@Controller
public class CsrfController {

    @GET
    public String getForm() {
        return "csrf.jsp"; // Injects CSRF token
    }

    @POST
    @CsrfProtected // Required for CsrfOptions.EXPLICIT
    public void postForm(@FormParam("greeting") String greeting) {
        // Process greeting
    }
}

Events

Jakarta MVC specifies a number of events that occur while processing requests. The event mechanism is based on Jakarta Contexts and Dependency Injection (CDI), and can be observed using the @Observer annotation defined by Jakarta CDI.

Internationalization

Jakarta MVC uses the term “request locale,” which can be used for locale-dependent operations. Example use cases for locale-dependent operations include data binding, data formatting, and language-specific validation error messages. The request locale is available through the MvcContext object.

@Controller
@Path("/foobar")
public class MyController {

    @Inject
    private MvcContext mvc;

    @GET
    public String get() {
        Locale locale = mvc.getLocale();
        NumberFormat format = NumberFormat.getInstance(locale);
    }
}

For more insight into Jakarta MVC:

Learn More About Jakarta MVC and Get Involved

We welcome everyone who would like to get involved in Jakarta MVC. To discover the many different ways you can contribute to the project, click here.

This article was first published in the Eclipse Newsletter, November 29, 2021.

Hashtag Jakarta EE #101

Welcome to issue number one hundred and one of Hashtag Jakarta EE!

There is an interesting discussion around Java SE 17 support in Jakarta EE going on the Jakarta EE Community mailing list. As you probably are aware, the upcoming Jakarta EE 10 release will raise the API source- and binary levels to Java SE 11. Does this mean that Jakarta EE doesn’t support Java SE 17?

Absolutely NOT! The key is the + in TCK run with: Java SE 11+ in the image below.

There are already several compatible implementations certified with Java SE 17 for Jakarta EE 9.1. And I would say it is a pretty safe bet that all of these, as well as others, will be certified on Java SE 17 for Jakarta EE 10 as well. So it is safe to say that Jakarta EE supports Java SE 17, even if the APIs aren’t incorporating any language features introduced after Java SE 11.

When we look beyond Jakarta EE 10, the plan is to raise the baseline to Java SE 17. So here is a question for the community: Which language features available in Java SE 17 make sense to build into the APIs, and for which specification?

Next week is all about JakartaOne Livestream. Join us there to learn more about Jakarta EE and much more from an amazing lineup of speakers. Tanja and I will also host Studio Jakarta EE between the sessions with lots of interesting content you don’t want to miss!