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.
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.
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)!
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.
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).
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).
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).
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.
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);
}
}
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!
Is it number 100 already? I started the Hashtag blog series as an experiment to see if I could establish a drum beat with weekly updates from the Jakarta EE community. By reaching 100 consecutive weekly posts, I think I have succeeded in that. Now, let’s look forward and see if we can reach a thousand…
JakartaOne Livestream 2021 is only one week away. The third edition of this annual online event is an excellent opportunity to keep up with what’s going on in and around the Jakarta EE community. Check out this amazing list of speakers!
I have had a couple of weeks with traveling and in-person events. It has been absolutely awesome to actually meet people again! Let’s keep our fingers crossed and hope the trend of going back to in-person events continues. There are quite a few in the pipeline for next year. Until then, make sure to sign up for the greatest Jakarta EE online event of the year: JakartaOne Livestream 2021.
Another topic that is being discussed in the Jakarta EE Platform project lately is to tighten up the language around the @Priority annotation. The intention is to have a consistent way of determining priorities across the specifications using the annotation. What it boils down to is this: Should a higher number mean higher priority? Or should the lower number have higher priority, thus sorted in ascending order?
My personal opinion on this topic is that there should be one way of doing this, and it should be consistent throughout the platform (Option Ax or Bx). I don’t want to introduce any new annotations to bypass the problem (Option C), and doing nothing (Option E)is just as bad. I guess I would prefer HIGHER number means HIGHER priority (Option Ax), but with be comfortable with the opposite as well, i.e. LOWER number means HIGHER priority (Option Bx).
Java on Rails
This week, I was on the road (or on rails actually) with Simon Ritter, Mattias Karlsson, and Jeanne Göthberg. We did a tour of three Swedish JUGs in three days. First Malmö, then Gothenburg, and finally Stockholm. We had great fun, three successful events, and great conversations. It felt really good to be out meeting the community again. This was the first in-person event for all the three JUGs in a while.
On stage after my talk on the last day, Mattias announced that I got a Jakarta EE talk accepted for Jfokus 2022. The conference is fully booked, but there is a waiting list if you haven’t gotten hold of your ticket yet. See you in Stockholm in February next year!
JakartaOne Livestream is coming up in a couple of weeks! Register for this free, one-day virtual event now!
Last year, we had a cake theme, where we encouraged everyone to bake a cake and submit pictures to win great prizes. Before that, we had a cupcake theme. This year, we are going for PIZZA!
I am looking forward to seeing the creative spins on this challenge. I guess I could make the yellow and orange colors of the Jakarta EE sailing ship with some looks-like-cheese-melts-like-cheese-certainly-doesn-t-taste-like-cheese kind of substance, but how to get the blue color on a pizza that is still possible to digest goes beyond my cooking skills. Writing Jakarta EE with pepperoni is as far as my creativity goes.
JakartaOne Livestream 2021 is just a couple of weeks away. I know that having a virtual conference is not that unique nowadays, but when we did the first edition of JakartaOne Livestream back in 2019, it was somewhat unchartered territory. It was an immediate success that was followed up in 2020. In the 2020 edition, we brought in the concept of having 15-minute long Studio Jakarta EE sessions between the regular talks. These were a mix of technical and non-technical short talks as well as interviews.
This year, we are going one step further with Studio Jakarta EE. It is still in the concept phase, but I am confident it will be amazing!
Even if you are suffering from zoom fatigue and pretty fed up with online conferences by now, please do register for JakartaOne Livestream 2021. If you’re still not convinced, look at the amazing lineup of speakers we have for this year!
Jakarta EE 10 is moving forward. The pull requests used to initiate release reviews by the Jakarta EE Specification Committee have started appearing. Check out the specification you are interested in to see if you can do anything to help get it over the finishing line.
From discussions on the Jakarta EE Platform mailing list and weekly calls, it has become apparent that there is a need to handle common APIS, functionality, libraries, and such to ensure consistency between the specifications. Thus, there is a proposal for a Jakarta Commons project being worked on. Take a look and let us know what you think!
This week was a flashback of the past, a return to normal, and a promise of the future! First, I traveled to London, UK to speak at Devoxx UK where I presented Jakarta EE Core Profile – A Slimmer Jakarta EE. It was awesome to meet so many community members and hang around with them in the exhibition hall and at dinner parties.
I then continued to the Netherlands and J-FALL. This was an even bigger conference with 1300 attendees onsite at the venue. My talk about Jakarta EE 10 was well received.
I even met Duke there. A slightly smaller version than the Duke that used to roam the corridors of JavaOne, but Duke is Duke…
The work with Jakarta EE 10 continues. There are a couple of specifications that have started preparing pull requests for their release reviews. One of the tasks associated with Jakarta EE 10 is to establish JPMS Module Names for all the specifications. See Jakarta EE Project Names and Codes for an overview of policy around the module names.
I am spending the upcoming week at home, but after that, I will be traveling again. This time a three-day tour of the major Java User Groups in Sweden. The tour is called Promising Future with Java 17 and the schedule looks like this:
