The highly anticipated Java Enterprise Edition 8 released two exciting new APIs (json-binding 1.0 and Java EE Security 1.0) and improved the existing API (Jax-rs 2.1,bean Vali Dation 2.0,JSF 2.3,CDI 2.0,json-p 1.1,JPA 2.2 and Servlet 4.0). This is the first release of Oracle's enterprise-class Java platform in nearly four years, with hundreds of new features, feature upgrades, and bug fixes.
Which new features are the best? I am trying to answer this very subjective question in this article.
Summary: Five more features
New security API: annotation-driven authentication mechanism. This new security API contains three great new features: The abstraction layer of identity storage, the new security context, and a note-driven authentication mechanism--which makes it obsolete in the way that the Web. xml file is declared. The last feature we'll be talking about today.
Jax-rs 2.1: The new responsive client. The new responsive client in Jax-rx 2.1 incorporates a responsive programming style that allows combination of end-point results.
The new JSON binding API. The new JSON binding API provides a native Java EE solution for serializing and deserializing JSON.
CDI 2.0: Using CDI in Java SE. This interesting new feature in CDI 2.0 allows CDI to be booted in Java SE.
Servlet 4.0: Server push. The server push feature in Servlet 4.0 makes the servlet specification and HTTP/2 consistent.
Are you ready? Here we go.
1. New Security API
The new security APIs added by Java EE 8 may be one of the most important new features.
The primary motivation for this new API is to simplify, standardize, and modernize the approach to security issues across containers and across implementations. The existing results are satisfactory.
The configuration of Web authentication was modernized with three new annotations, and the XML became redundant. I'll talk about that later.
The new security context API standardizes the way that Servlets and EJB containers perform authentication.
The new Identity storage abstraction layer simplifies the use of identity storage.
Let's take a closer look at the first of these new features.
Annotation-driven authentication mechanism
This feature is primarily used to configure WEB security. The old way requires a declaration in the Web. xml file.
Thanks to the httpauthenticationmechanism interface, we no longer have to use the old way. The Httpauthenticationmechanism interface represents an HTTP authentication and comes with three built-in CDI support implementations, each of which represents one of the three configurable Web security methods.
Use one of the following annotations to trigger a specific implementation.
@BasicAuthenticationMechanismDefinitionbr/> @FormAuthenticationMechanismDefinition
They replicate traditional HTTP Basic authentication, forms, and forms-based custom authentication capabilities that are already in the servlet container.
For example, to enable Basic authentication, all you have to do is add the basicauthenticationmechanismdefinition annotation to your servlet.
@BasicAuthenticationMechanismDefinition (realmname= "${' User-realm '}") br/> @WebServlet ("/user")
@ServletSecurity (@HttpConstraint (rolesallowed = "user")
public class Userservlet extends HttpServlet {...}
Now you can discard the XML configuration and use the annotations above to drive the Web security.
2, Jax-rs 2.1: New Responsive client
Let's take a look at the new responsive client in Jax-rs 2.1 and how it blends with responsive programming styles.
The core concept of a responsive approach is data flow and an execution model that propagates changes through a stream. A typical example is the Jax-rs method call. When the call returns, the next action (possibly continuation, completion, or error) is performed on the result of the method call.
You can see it as: Data becomes an asynchronous process pipeline, and the latter process executes based on the results of the previous process, and then passes the results of its process to the next process in the chain. The modular flow allows you to combine and convert multiple streams into one result.
This enables responsive functionality by invoking the method in the RX () Invocation.builder instance that is used to construct the client instance. This method returns a Completionstage instance that carries the Response type. The Completionstage interface is introduced in Java 8 and presents some interesting possibilities.
For example, in this code snippet, two calls are made to different endpoints, and then the results are merged:
completionstage<response> CS1 = Clientbuilder.newclient ()
. Target (".../books/history")
. Request ()
. Rx ()
. get ();
completionstage<response> CS2 = Clientbuilder.newclient ()
. Target (".../books/geology")
. Request ()
. Rx ()
. get ();
Cs1.thencombine (CS2, (R1, R2)
R1.readentity (String.class) + r2.readentity (String.class))
. Thenaccept (System.out::p rintln);
3. New JSON Binding API
Now let's take a look at the next great new feature. The new JSON binding API provides a native Java EE solution for JSON serialization and deserialization.
Before that, if you wanted to serialize and deserialize JSON, you would have to rely on third-party APIs like Jackson or Gson. It's not the same now, with the new JSON binding API, all the features you might need are native supported.
Generating a JSON document from a Java object is straightforward. Just call the ToJson () method and pass the instance you want to serialize.
String Bookjson = Jsonbbuilder.create (). ToJson (book);
It is also easy to deserialize a JSON document into a Java object. You only need to pass the JSON document and the target class to the Fromjson method to get the Java object.
Book book = Jsonbbuilder.create (). Fromjson (Bookjson, Book.class);
But its function is more than that.
Behavioral customization
You can customize the default serialization and deserialization behavior by using annotation fields, JavaBean methods, and classes.
For example, you can customize the order of attributes specified at the class level by using @JsonbNillable to customize the empty processing and @JsonbPropertyOrder annotations. You can also use the @JsonbNumberFormat () annotation to specify a number format and use @JsonbProperty () annotations to change the name of the field.
@JsonbNillablebr/> @JsonbPropertyOrder (propertyorderstrategy.reverse)
@JsonbProperty ("cost")
Private Float Price;
}
Alternatively, you can choose to use the run-time custom builder Jsonbconfig to handle your customizations:
Jsonbconfig jsonbconfig = new Jsonbconfig ()
Withpropertynamingstrategy (propertynamingstrategy.lower_case_with_dashes)
Withnullvalues (True)
Withformatting (TRUE);
Jsonb jsonb = jsonbbuilder.create (jsonbconfig);
Either way, the JSON binding API provides a wide range of functionality for serializing and deserializing Java objects.
4. CDI 2.0: Using CDI in Java SE
Now let's go ahead and look at the next API. CDI 2.0 API. This version has many new features, and one of the more interesting features is the ability to boot CDI in a Java SE application.
To use CDI in Java SE, you must explicitly boot the CDI container. This is accomplished by invoking the static method Newinstance () of the Secontainerinitializer abstract class. This method returns a Secontainer instance that is a handle to the CDI runtime that you can use to perform CDI parsing, as shown in the code snippet. It can access Beanmanager, which is the core entry point of CDI.
Secontainer Secontainer =
Secontainerinitializer.newinstance (). Initialize ();
Greeting greeting = Secontainer.select (greeting.class). get ();
Greeting.printmessage ("Hello World");
Secontainer.close ();
Retrieve the CDI bean by passing the class name of the bean that you want to retrieve and use to the Select () method.
Configuration options
You can add interceptors, Extensions, alternatives, Properties, and decorators to further configure Secontext.
Enableinterceptors ()
Addextensions ()
Selectalternatives ()
SetProperties ()
Enabledecorators ()
On the Secontainer, the Close () method is used to close the container manually because the Secontainer expands the Autocloseable interface, or the container can be automatically closed using the try-with-resources structure.
5. Servlet 4.0: Server push
Finally, the server push feature in Servlet 4.0. This keeps the servlet specification and HTTP/2 consistent.
To understand this feature, you first need to know what server push is.
What is server push?
Server Push is one of many new features in the HTTP/2 protocol, designed to push these resources into the browser's cache by predicting client resource requirements, and the client sends a Web request and receives a response from the server, and the resources it needs are already in the cache. This is a performance enhancement that increases the speed of Web page loading.
How is this feature exposed in Servlet 4.0?
In Servlet 4.0, the server push function is exposed through an Pushbuilder instance, which is obtained from the HttpServletRequest instance.
Take a look at this piece of code. As you can see, you set the path of header.png on the Pushbuilder instance through the path () method and push it to the client by calling push (). When the method returns, the path and the conditional header are cleared so that the builder can reuse it. The Menu.css file, the JavaScript file Ajax.js, is then pushed to the client.
protected void doget (HttpServletRequest request, httpservletresponse response) {
Pushbuilder Pushbuilder = Request.newpushbuilder ();
Pushbuilder.path ("Images/header.png"). push ();
Pushbuilder.path ("Css/menu.css"). push ();
Pushbuilder.path ("Js/ajax.js"). push ();
Return JSP that requires these resources
}
When the servlet's Doget () method finishes executing, the resource will reach the browser. The HTML generated from the JSP requires these resources, but does not have to request them from the server because they are already cached by the browser.
The five latest features of Java EE8