Then it’s useful to know which new features were added since the version you use now, or between the versions that you use now and the one you want to start using next. Therefore I’ve compiled a table with all new features added since Java 8 for each new Java version and I keep it updated for every newer Java version.

Below you can find tables for:

• New Java language features – additions to the Java language or APIs
• New Java language features in preview/incubation – additions to the Java language or APIs which aren’t in their final state yet
• New tools and features in OpenJDK – additions outside of the language, such as command line tools or JVM improvements
• Deprecated/removed features and APIs

Note that I didn’t include all the new features and API additions, only those that are useful for a wide range of developers, to keep the list brief.

This article isn’t about choosing the right Java version for you to use. But I’ll at least summarize all the Java versions since Java 8 and for your convenience:

• Java 8 – LTS release (Long Term Support), last LTS release before JPMS (modules) were introduced in Java 9
• Java 11 – LTS release
• Java 17 – LTS release, the latest LTS release until September 2023
• Java 19 – non-LTS release, the latest version released in September 2022
• all other Java versions – non-LTS releases

In most cases, you should only use LTS releases in production. That is unless you have specific needs to use the greatest and latest and are willing to upgrade to a new Java version every 6 months. To find out more about Java LTS releases, you can read The art of long-term support and what LTS means for the Java ecosystem by Oracle.

Java language features and APIs

Need help with GlassFish, Jakarta EE, Java in the cloud?

Follow me at OmniFish!

Java language features or APIs in preview/incubation

New JDK tools and features since OpenJDK 8

Deprecated/removed features and APIs:

For more details, the javaalmanac.io/ catalog is very useful to browse the changes in Java thoughout all its history. It can give you complete diff of APIs between selected Java versions, e.g. between Java 8 and Java 11. Very useful If you’re thinking about migrating to a specific Java version.

Dávid Csákvári also wrote a similar article as mine for new features between Java 8 and Java 17, which is more detailed and with a lot of useful examples.

If you want to get started with Java 17 quickly and try out all the new features, here’s a nice article to follow to get you started fast: Java 17 New Features Tutorial.

The post New features between Java 8 and Java 19 appeared first on .Lost in Coding.

Java provides a lot of mechanisms to help working with threads and concurrent tasks. As Java evolved, some new mechanisms were added while old mechanisms stayed. And it’s often not clear which of them are better and recommended to use in new applications. Jakarta EE builds on these features and makes them easier to understand and use. The standard Jakarta EE API intentionally specifies only interfaces and essential conceptual behavior. A lot of the complexity is abstracted away and provided by Jakarta EE runtimes to keep things simple. As a result, developers have a concise set of features. Easy to learn and understand but enough to build applications.

Need help with GlassFish, Jakarta EE, Java in the cloud?

Follow me at OmniFish!

What is a thread pool

The basic concept of threading and parallelism in Jakarta EE runtimes is a thread pool. This is connected with the request processing model, where most of the tasks originate as a request from an external caller, they are then processed sequentially in a single thread, and produce some response that is usually sent back to the caller, persisted into a database or sent as a message to another system. Many separate tasks can run in parallel, each using its own separate thread. So there’s usually a simple mapping – one request needs one thread. After a task is finished, a thread doesn’t have to be destroyed. It can be reused to run another task, in order to avoid creating and destroying threads too often.

Incoming tasks are not tied with any specific thread. A thread pool always makes sure there’s a thread available for a task. This is called “scheduling” and is often referred to as “thread scheduling”. Tasks are scheduled and processed either:

by an existing thread that is finished with its previous task

by a new thread if no free thread is available

or they are queued and wait until a thread is available if all threads are busy

Vice versa, threads aren’t tied to tasks either. They just take a task from a queue and process it. When threads are done with their tasks, they start processing another new task from a queue or wait for a task if the queue is empty. A group of such threads, together with the logic how they are managed and scheduled, is called a thread pool.

Why thread pools?

Thread pools are used because it’s time-consuming to dispose a thread and create a new thread later. A new thread is created only when there’s no idle thread already available. And they are disposed only when there are already too many idle threads it’s likely not going to be needed for some time.

Another aspect of thread pools is that their size is limited and adapts to the load. This is mainly for 3 reasons:

• Threads allocates some memory for their stacks and keep the memory until the threads are disposed
• The CPU can run very small number of threads at once; having too many threads can even lead to performance degradation
• Each task requires some heap memory; it makes sense to limit the maximum number of parallel tasks to avoid overwhelming the system

The memory argument is pretty clear and often it’s evident when it becomes and issue. There’s always a limited amount of memory on the system. When threads consume a big portion of that memory, it’s easy to reach the limit. The default stack size for each thread is 1MB, which means that each thread needs 1MB of system memory. If there are 1000 threads in a JVM, they clearly need 1GB of memory on top of the Java heap size just to exist. You can probably imagine the consequences if there are even more threads.

The CPU argument isn’t so straightforward but is really valid. Only X amount of threads can run on a CPU at the same time (usually 8 on an 8-core CPU). With more threads, it’s more likely that a thread will be suspended and another thread will be scheduled. Switching of threads is a relatively time-consuming operation and doesn’t contribute to the computation. Therefore, having an excessive amount of threads can actually decrease performance.

The last argument is that executing too many tasks in parallel costs too much memory as each tasks needs to store something to the heap even if it’s waiting for an I/O operation or the CPU. As described above, more parallel tasks doesn’t not always lead to increased performance. But it definitely leads to increased memory. Therefore it’s better to limit how many tasks can run in parallel and queue other tasks to be executed later.

For these reasons, it’s good to have some reasonable amount of threads ready to handle new tasks immediately. It’s also necessary to limit the number of threads to a reasonable amount. And threads should also be disposed after some time if they are really not needed. With this, it’s possible to avoid system become thrashed and unusable under high load. If there are too many requests to handle, some of them simply need to wait while others can be efficiently processed. This will make the system usable at least for some requests/users.

Sometimes a single request needs to be processed by multiple threads in parallel. This doesn’t fit the simplified thread-per-request model but it’s also supported by Jakarta EE runtimes. Applications can use a specialized concurrency API, which allows splitting a task and execute each part in a separate thread. This again works on top of thread pools to retain all the advantages mentioned above.

The post Introduction to concurrency and threads in Java web apps appeared first on .Lost in Coding.

There’s still a small catch – this only works in the servlet context and EJB context. Or, in other words, when processing an HTTP request or inside any type of EJB. The good thing is that this covers most of the cases in which you’ll ever need to retrieve user information. In the other rare cases, you need to use one of the APIs which I also describe in this post.

Need help with GlassFish, Jakarta EE, Java in the cloud?

Follow me at OmniFish!

Unified access to user info using Security API

With the Security API, retrieving information about the current user is pretty easy straightforward:

• Inject SecurityContext
• Get the name of the user
  • Call the method getCallerPrincipal()
  • If the result is null, no user is logged in
  • Otherwise, call the method getName() to get the name of the logged-in user
• Verify that a user has a specific role (permission)
  • Call the method isCallerInRole(roleName)

Full example of a servlet that prints user’s name and whether the user is in role “admin”:

@WebServlet(urlPatterns = "/servlet")
public class UserInfoServlet extends HttpServlet {

    @Inject
    SecurityContext userContext;
    
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {

        // retrieve the principal and later check whether it's null or not
        Principal callerPrincipal = userContext.getCallerPrincipal();

        resp.getOutputStream().println(String.format(
                "<html><body>"
                + "<p>User: %s</p>"
                + "<p>Is admin: %s</p>"
              + "</body></html>", 

        // print user's name only if the user is logger in and principal is not null
                callerPrincipal != null ? callerPrincipal.getName() : "not logged in",
        // true if user has admin role
                userContext.isCallerInRole("admin")));
    }
    
}

Code language: Java (java)

Alternative ways to access user info

In case you can’t use the Security API, you can still use one of the other APIs that provide similar access to user information. A lot of other specification APIs provide similar methods to retrieve the name of the logged-in user and to check whether the user is in a specific role. Below is a summary of all possible ways:

The Security specification also provides a summary of all the available methods to retrieve user’s name and role information in 4.5. Relationship to Other Specifications.

What’s the best way?

I’d certainly recommend using only the Security API’s SecurityContext whenever possible, for the following reasons:

• It’s a unified API so you can learn and remember a single way to access user information
• It’s easy to use, just inject it as a CDI bean
• It provides all the information provided by any of the other APIs
• It’s cleaner in case the user isn’t logged – returns null Principal instead of a Principal with a default name

The only drawback is that currently it only works in Servlet and EJB contexts. Even though these 2 contexts are the most widely used, it’s still possible that in some rare cases the Security API can’t be used. Hopefully, the future versions of the Security specification will also cover other contexts. And even if not, the contexts where it wouldn’t work are related to some legacy and old Jakarta APIs and are nowadays very rarely used. In fact so rarely that you will probably not use any of them ever.

The post Get logged-in user info in Jakarta EE – the simplest way appeared first on .Lost in Coding.

But injection doesn’t work out of the box on JAX-RS sub-resources. How to create sub-resources so that both injection mechanisms work also in sub-resources? I’ll show you, it’s very easy.

How to do it (for the impatient)

• Inject the sub-resource into the JAX-RS resource via the @Inject annotation
• Initialize the sub-resource using the ResourceContext object injected via the @Context annotation

@Path("request")
@RequestScoped
public class RestResource {

    @Inject // inject subresource as CDI bean
    SubResource subResource;
    
    @Context // inject from JAX-RS container
    ResourceContext resourceContext;
    
    @Path("subresource")
    public SubResource getSubresource() {
        return resourceContext.initResource(subResource);
    }
}Code language: CSS (css)

Need help with GlassFish, Jakarta EE, Java in the cloud?

Follow me at OmniFish!

Full story

First, let’s briefly explain what a sub-resource is. It’s a class that looks similar to a usual JAX-RS resource but it’s not used standalone. Instead, an instance of this class can be returned from a JAX-RS resource to map it to a subpath of that resource. Therefore a JAX-RS resource can delegate processing of a specific subpath to another class. Sub resources look like any other JAX-RS resources but don’t specify the @Path annotation. The path is defined on the resource method that returns the sub resource:

// Sub-resource - no @Path annotation on the class
@RequestScoped
@Produces(MediaType.TEXT_PLAIN)
public class SubResource {
    
    @GET
    public String getMessage() {
        return "This is a sub-resource.";
    }
}Code language: PHP (php)

@Path("request") // defines the path "request" for this resource
@RequestScoped
@Produces(MediaType.TEXT_PLAIN)
public class RestResource {

    @GET
    public String getMessage() {
        return "This is a JAX-RS resource.";
    }

    @Path("subresource") // defines the subpath for the sub-resource: "request/subresource"
    public SubResource getSubresource() {
        return new SubResource();
    }
}Code language: PHP (php)

If you access path /request, the response will contain “This is a JAX-RS resource.”

If you access path /request/subresource, the response will contain “This is a sub-resource.”

However, the catch is that with the simple example above, no injection works in the subresource. it’s not possible to inject anything into the SubResource class, any atempt to do so will result in null values for injected fields. It’s created as a plain Java object in the getSubresource() method and thus it’s not managed by any container. The @RequestScoped annotation is ignored in this case and anything marked with the @Inject or @Context annotation would be also ignored and remain null.

Injection works on JAX-RS resources because they are created by the JAX-RS container and not using the new keyword. If CDI is also enabled on the resource class, Jakarta EE runtime will first create the JAX-RS resource as a CDI bean and then pass it to the JAX-RS container, which then does its own injection.

None of this happens if a sub resource is created using new, therefore we must create it in a different way.

Solution

2 simple steps are needed to add support for both types of injection in JAX-RS sub-resources:

• Inject the sub-resource into the JAX-RS resource. This enables the CDI injection
• Initialize the sub-resource using the ResourceContext object provided by the JAX-RS container. This enables JAX-RS injection for values annotated with @Context

This is how the RestResource class should look like to create the sub-resource properly:

@Path("request")
@RequestScoped
@Produces(MediaType.TEXT_PLAIN)
public class RestResource {

    @Inject // inject subresource as CDI bean
    SubResource subResource;
    
    @Context // inject from JAX-RS container
    ResourceContext resourceContext;
    
    @GET
    public String getMessage() {
        return "This is a JAX-RS resource.";
    }

    @Path("subresource")
    public SubResource getSubresource() {
        return resourceContext.initResource(subResource);
    }
}Code language: PHP (php)

NOTE: You need to use the initResource method of ResourceContext and not the getResource method. The getResource method creates a new JAX-RS sub-resource from a class but it’s not guaranteed that it also enables CDI injection for it. Although some Jakarta EE runtimes will enable CDI injection if you call the getResource method, it’s known that some of them like OpenLiberty and Payara don’t do it. In the future, this will very probably be improved when the @Context injection will be replaced by CDI injection, which is already planned.

Now you can use both types of injection and all will work as expected:

@RequestScoped
@Produces(MediaType.TEXT_PLAIN)
public class SubResource {

    @Inject
    SomeCdiBean bean;

    @Context
    UriInfo uriInfo
    
    @GET
    public String getMessage() {
        return bean.getMessage() + ", path: " + uriInfo.getPath();
    }
}Code language: CSS (css)

The post How to properly inject CDI beans into JAX-RS sub-resources appeared first on .Lost in Coding.

Specifically for users of Jakarta EE it might be even more interesting to attend the Jakarta EE Community Day, which happens the day before the main conference on 25 October 2021. It’s open to all people that register for the main EclipseCon event. There’s a packed agenda centered on the Jakarta EE, MicroProfile and Cloud Native Java communities, including topics like the present and future of MicroProfile and Jakarta EE, and upcoming features in Jakarta Security, Jakarta Concurrency, Jakarta REST, and Jakarta NoSQL.

If you’re interested, I recommend reading an article of Reza Rahman about what’s happening at the Community Day and why to attend it. Or simply go ahead and register for EclipseCon 2021!

The post Jakarta EE experts at EclipseCon 2021 appeared first on .Lost in Coding.

UPDATE: The Arquillian project has moved forward and it now supports JUnit5 with an official extension. This makes it even easier to combine Arqullian with JUnit5. I’ve updated my article to refer to this official extension.

The problem with the current standalone Batch TCK is that it’s based on TestNG and only supports Batch implementations that run on the same classpath as the test suite. Therefore it doesn’t support running tests in Java containers like application servers. Such containers are now supported only by the Jakarta test suite (CTS) which contains a copy of Batch TCK tests uses a proprietary technology to run tests in containers.

There are other Jakarta EE specifications with a standalone TCK or with plans to create it:

• CDI TCK – uses TestNG with Arquillian
• Bean Validation – uses TestNG with Arquillian
• JSON-B – in progress, uses JUnit 4 with Arquillian
• DI TCK – JUnit 4

It’s clear that Arquillian is pretty popular among them. Only DI TCK doesn’t use it. But DI TCK also doesn’t support execution in a remote container natively, it only supports setting up a local container, e.g. using the CDI SE API if the implementation supports it.

I had 3 goals with my proof of concept:

1. improve the TCK to make it possible to integrate with a Java container
2. adapt the existing example project to run JBatch with the TCK
3. create another example of integrating the TCK with a typical Jakarta EE server such as Payara Server

I prefer gradual evolution rather than big bang development if it makes sense. And I realized that I will probably need Arquillian to integrate with Payara Server for my third goal anyway, even if I find a solution using JUnit 5. So I started with adding support for Arquillian into the current Batch TCK and later I hoped to reuse it to integrate Payara Server with JUnit 5. It turned out that it was a good approach and no code went to waste.

Adding support for Arqullian

Adding support for Arquillian into the Batch TCK was pretty straightforward because the tests already use TestNG and Arquillian supports TestNG out of the box. The only tricky part was to create a deployment package for each test which is required by Arquillian. In the end, this was pretty easy and required no modification of the test sources. Arquillian allows to create an extension to define a deployment package for each test so I was able to move creation of a deployment package to a separate extension. This extension can be used by implementations that need to run the tests in a container but it’s not needed in the TCK itself.

The only change needed in the TCK was to change each test to extend the Arquillian TestNG base class and that was it.

On top of the test suite, the Batch TCK contains an example TCK runner project that runs the TCK against the JBatch implementation. This also needed to be changed slightly. I added Arquillian Weld SE connector, which runs the Arquillian TestNG tests in a Weld CDI container. This means the tests are executed on the same classpath as the test suite and no Arquillian deployment is needed.

You can see the end result in my fork here: https://github.com/OndroMih/batch-tck/pull/4. In summary, I added a single line of code to each TCK test and modified pom.xml of the Batch TCK and the TCK runner for JBatch.

This allowed me to create an example project for running the TCK with a remote server like Payara Server. This example project contains the Arquillian extension I mentioned above. This extension uses Maven resolver library to resolve JAR dependencies from the project’s pom.xml file and package them into a WAR deployment for Arquillian. It’s not complicated, it requires just a few lines of code: MavenTestDependenciesDeploymentPackager.java

Converting the TCK to JUnit5

Converting a TestNG-based TCK to JUnit 5 was pretty straightforward. Besides replacing all TestNG annotations with JUnit 5 equivalents, I also needed to replace TestNG reporting with the standard Java JUL logging. At that time, I didn’t know that JUnit 5 also supports reporting from tests via TestReporter. For a final solution, I would use that instead of JUL logging.

You can see the final result of my conversion here: https://github.com/OndroMih/batch-tck/pull/3. The TCK is changed and the JBatch runner project also uses it and runs without test failures. This solves my first 2 goals.

The hardest thing was to connect a JUnit 5 test suite with Payara Server to meet my 3rd goal. For that, I needed to solve the following problems:

• create a deployment package to deploy tests to Payara Server
• create a JUnit 5 extension to run the tests in Payara Server and report the results back

I already solved the first problem with an Arquillian extension in the previous step. And it seems there’s an unofficial JUnit 5 extension to run Arquillian tests. And yes, it worked, I was able to merge all this to a final solution for all of my 3 goals.

Running the JUnit 5 TCK with Arquillian

Luckily, the Arquillian community has been working on support for JUnit 5. Although this effort was stuck for a while waiting for an essential extension point only added in JUnit 5.5, there’s now an unofficial arquillian-junit5-extension with some fixes in this fork.

UPDATE: Arquillian now provides an official JUnit 5 extension, which can be used instead. It’s based on the unofficial extension that I used but is available in Maven Central and contains some additional fixes.

So I tried to pull all what I already had together to try if I can get the converted JUnit 5 Batch TCK running against Payara Server:

• use the JUnit 5 Batch TCK as a dependency
• add the arquillian-junit5-extension
• add the Arquillian deployment extension I created earlier
• configured Arquillian to run with the Payara connector as I did earlier

So I did it, started Payara Server, configured the necessary JDBC resources, and executed the following:

mvn verify

… and prayed.

After a few minues:

Results: 
Tests run: 164, Failures: 0, Errors: 0, Skipped: 3

All worked! This includes all TCK tests, including the tests that require other Jakarta EE functionality and which are not run for standalone Batch implementations like JBatch. Those 3 skipped tests are currently being skipped by the TCK and not by my configuration.

Summary

I was able to demonstrate there are multiple ways to improve existing standalone Jakarta EE TCKs or create new ones from the full Jakarta CTS suite in a modern way.

One of them is an already proven way of adding Arquillian into a JUnit 4 or TestNG test suite and expect that all implementations provide an Arquillian container to run the tests with them. As demonstrated, this is pretty easy with a few lines of code, writing a simlple Arquillian extension to define deployments for all tests.

But there’s also an interesting new way which uses JUnit 5, one of the most modern test frameworks for Java. JUnit 5 provides enough extension points and also allows enabling extensions globally for all tests. This means that the tests don’t need to include any boiler-plate code required to enable the extensions. Implementers can use Arquillian to run the tests via an existing JUnit 5 Arquillian extension once it’s officially released, or they can create their own JUnit 5 extension to connect the tests with their implementation. Or they are free to use the existing unofficial JUnit 5 Arquillian extension already and even modify it if needed because they can really use anything they want.

The post Possible ways to use Arquillian in Jakarta EE TCKs appeared first on .Lost in Coding.

This topic and much more will be described in more detail in my upcoming book Java EE 8 Microservices, which I co-author with Mert Çaliskan and Pavel Pscheidl

If our service calls multiple microservices and waits for each call to finish and return results before doing another call, it’s a good candidate to refactor using reactive API. In order to make the service more efficient, it could do all the calls to external services in parallel if they don’t depend on each other. This would decrease the time spent waiting and thus speed up the microservice.

In order to call REST services in parallel, we’ll use the new reactive client API in JAX-RS. We’ll combine it with the RxJava library to combine their results when available. This combination will allow us to write clean and efficient code. And with an additional benefit that the current thread can be released for further processing while waiting for results from remote calls.

We’ll build a pipeline which processes the results as they arrive and finally merges them into a single response. The first part of the pipeline will call each remote service. Instead of waiting for the results, we’ll specify what to do with each received result and continue with calling other services. Using the rx() method on the JAX-RS client request builder allows us to call a version of the get() method, which immediately returns instead of waiting for the result. In order to process results when they arrive, we can chain method handlers onto a CompletionStage returned from the rx version of the get()  method:

CompletionStage<Forecast> stage = temperatureServiceTarget
  .request()
  .rx()
  .get(Temperature.class)
  .thenApply(temperature -> new Forecast(temperature));Code language: HTML, XML (xml)

The above code will call a temperature service and then register a lambda expression to process the resulting temperature when it arrives. This maps the temperature to a forecast object, which can be accessed with the stage  variable later.

However, we want to use another variant of the get()  method together with an RxJava Flowable Invoker from the Jersey project to get a Flowable  from RxJava instead of a CompletionStage. The Flowable interface makes it easier to combine multiple asynchronous results with much simpler code than CompletionStage and also more efficiently.

With the following code, we will call an external service and return a Flowable:

Flowable<Forecast> flowable = temperatureServiceTarget
  .register(RxFlowableInvokerProvider.class)
  .request()
  .rx(RxFlowableInvoker.class)
  .get(Temperature.class)
  .map(temperature -> new Forecast(temperature);Code language: HTML, XML (xml)

We register additional RxFlowableInvokerProvider, which allows to request RxFlowableInvoker  later. This invoker then gives us the Flowable  return type from RxJava. These classes are not in the JAX-RS API and we must add them with the Jersey RxJava2 library:

<dependency>
  <groupId>org.glassfish.jersey.ext.rx</groupId>
  <artifactId>jersey-rx-client-rxjava2</artifactId>
  <version>2.26</version>
</dependency>Code language: HTML, XML (xml)

On the first sight it seems we made the code more complicated while doing the same thing. But a Flowable instance allows us to combine multiple calls easily:

Flowable.concat(flowable1, flowable2)
  .doOnNext(forecast -> {
    forecasts.add(forecast);
  })
  .doOnComplete(() -> {
    asyncResponse.resume(Response.ok(forecasts).build());
  })
  .doOnError(asyncResponse::resume)
  .subscribe();
}Code language: PHP (php)

For each forecast received from any flowable, we add it to a list of forecasts. Finally, we send the list of forecasts as a response or send an error response. The final call to subscribe()  is necessary to register the listeners, otherwise they would be ignored.

You may have also noticed the asyncResponse  variable used to send the final response or signal an error. This is a JAX-RS asynchronous response instance, which is used to complete a REST response at later time, when the data is available, without blocking the initial processing thread. Using the asynchronous response helps us save thread resources while waiting for results from external REST services. In order to turn on asynchronous processing in our REST endpoint, we will inject javax.ws.rs.container.AsyncResponse as the REST method argument, together with the @Suspended annotation. We will also change the return type to void because we’ll be building the response using the AsyncResponse instance:

@GET
@Produces(MediaType.APPLICATION_JSON)
public void getForecasts(@Suspended AsyncResponse asyncResponse) {
  /* ...here come some asynchronous calls to REST services... */
  asyncResponse.resume(...)
}Code language: CSS (css)

Final code example

The following code will:

• turn on asynchronous processing of REST requests in the getForecasts method
• set 5 minute timeout on the asynchronous response
• execute the temperature service twice, for London and Beijing, without waiting for results
• combine the results into a sequence of forecasts
• add every forecast in the sequence into a list
• send the complete list when all results processed
• send an error result in case of an exception
• register the handlers with the subscribe method

private Flowable<Forecast> getTemperature(String location) {
  return temperatureTarget
    .register(RxFlowableInvokerProvider.class)
    .resolveTemplate("city", location)
    .request()
    .rx(RxFlowableInvoker.class)
    .get(Temperature.class)
    .map(temperature -> new Forecast(location, temperature));
}

@GET
@Produces(MediaType.APPLICATION_JSON)
public void getForecasts(@Suspended AsyncResponse asyncResponse) {
  List<Forecast> forecasts = new ArrayList<>();
  asyncResponse.setTimeout(5, TimeUnit.MINUTES);
  Flowable.concat(getTemperature("London"), getTemperature("Beijing"))
    .doOnNext(forecast -> {
      forecasts.add(forecast);
    })
  .doOnComplete(() -> {
    asyncResponse.resume(Response.ok(forecasts).build());
  })
  .doOnError(asyncResponse::resume)
  .subscribe();
}Code language: JavaScript (javascript)

Republished at

• DZone.com
• JavaCodeGeeks.com

The post Speed Up Services With Reactive API in Java EE 8 appeared first on .Lost in Coding.

Specifying passwords from file

The key thing in working with passwords in scripts is to provide them in a file. Each asadmin command accepts argument --passwordfile  to instruct it to read all the necessary passwords from it to avoid asking for passwords interactively. But it’s a bit tricky to find out how to define passwords in this password file, because it’s used for multiple types of passwords. Oracle documentation for GlassFish v3 which also applies to GlassFish v4 and v5 and Payara v4 and v5 documents 4 types of passwords. Each type of password can be specified in the password file with a variable that starts with the AS_ADMIN_  prefix.

• admin password with prefix AS_ADMIN_PASSWORD, default is empty password
• master password with prefix AS_ADMIN_MASTERPASSWORD , default is “changeit”
• user password with prefix AS_ADMIN_USERPASSWORD
• alias password with prefix AS_ADMIN_ALIASPASSWORD

So for example, if we need to run a command with admin password “mypassword”, the following line has to be in the password file:

AS_ADMIN_PASSWORD=mypassword

And then we can use the password with the --passwordfile argument, like this:

asadmin list-applications --passwordfile=mypasswordfileCode language: PHP (php)

The above command won’t wait for typing the password but will immediately list all applications on the server. If the password is incorrect, the command would fail.

Need help with GlassFish, Jakarta EE, Java in the cloud?

Follow me at OmniFish!

Changing passwords non-interactively from script

So far, all was documented at least in the old GlassFish v3 documentation. What’s missing in the documentation though is how to specify a new password from file if we want to change it from a script. When we execute a command to change any password (e.g. admin password or master password) without a password file, the command would ask for 2 passwords – the old one and the new one. Therefore we need to specify 2 passwords in a file.

The solution is to add another variable for a new password into the same password file. Variables for new passwords are prefixed with AS_ADMIN_NEW  prefix. Therefore to change the master password, we need the following 2 lines in our password file:

AS_ADMIN_MASTERPASSWORD=oldmasterpassword
AS_ADMIN_NEWMASTERPASSWORD=newmasterpassword

And then we can use the 2 passwords with the –passwordfile argument, like this:

asadmin change-master-password --passwordfile=mypasswordfile

The above command won’t wait for typing or retyping any password but will immediately change the master password on the server to newmasterpassword . If the old password is incorrect, the command would fail.

Changing passwords in docker image

In Docker, the preferred way is to configure the server in the image so that when a container is executed, the configuration is applied automatically. Avoid configuring containers because it’s not easy to run asadmin commands in a container and changing some passwords, such as master password, requires server restart.

The default Payara Server Docker image already contains asadmin commands which change the admin password. You can copy the lines that create /opt/tmpfile  and use it with the change-admin-password  command to change the admin password.

The same can be done to change the master password. Below is an example custom Dockerfile to change the master password to newpassword :

FROM payara/server-full
# specify a new master password "newpassword" instead of the default password "changeit"
RUN echo 'AS_ADMIN_MASTERPASSWORD=changeit\nAS_ADMIN_NEWMASTERPASSWORD=newpassword' >> /opt/masterpwdfile

# execute asadmin command to apply the new master password
RUN ${PAYARA_PATH}/bin/asadmin change-master-password --passwordfile=/opt/masterpwdfileCode language: Dockerfile (dockerfile)

With the above Dockerfile in your current directory, you can build your custom docker image with:

docker build -t my-payara/server-full .

And then run my-payara/server-full  instead of payara/server-full.

You can verify that the master password is changed in the docker container when you run it with:

docker run -t -i --entrypoint keytool payara/server-full:masterpwd -list -keystore /opt/payara41/glassfish/domains/domain1/config/keystore.jksCode language: PHP (php)

If you type the new master password, you should see the contents of the key store with the list of certifictes.

NOTE: After you change the master password, the Docker image will still run Payara with the old master password, which is not the correct password and Payara will not start. After you change the master password, you also need to update the value of AS_ADMIN_MASTERPASSWORD in the file ${PASSWORD_FILE} (/opt/payara/passwordFile) to the value of the new master password, so that Payara is started with the new password.

Republished at: JavaCodeGeeks.com

The post Configure Payara Server passwords in Docker appeared first on .Lost in Coding.

Many developers know that JRebel can help a lot with updating the code on the fly. There’s been a lot of effort put into it to support all sorts of code and resource changes and refresh them with virtually any Java framework used by the application. But the downside is that it’s pretty expensive for a casual developer, doing just some hacking on his/her own or working on a non-commercial project. I have some experience with JRebel and I liked it a lot, but I was using it on a commercial project where I didn’t pay for the license. I tried HotswapAgent and it has worked very well as a free alternative of JRebel for me for my personal Java EE projects. I’m going to write up how I got it running in my IDE and my Java EE server of choice – Payara Server.

Getting started with HotswapAgent

Hotswap Agent itself is just a java agent, which has to be attached to the application. It essentially scans the classpath to detect the presence of known frameworks and tries to refresh the frameworks after a code or resource change is detected. It’s also possible to write custom plugins for any project or even specifically for your application. However, getting the most of Hotswap Agent requires installing an alternative DCEVM engine into your JRE installation, which does much better job in reloading code changes than the standard VM engine in the HotSpot VM. The alternative VM engine is basically a patched version of the standard engine, which improves code hot swap via the debugging interface, without impacting other functions of the JVM.

So to summarize, we are going to do this to work with HotSwap from our IDE of choice:

1. Install the DCEVM engine into a Java installation (JRE or JDK)
2. Configure the IDE to start the application with the HotswapAgent JAR as java agent and using the DCEVM engine instead of the standard JVM engine
3. Configure the IDE to refresh plain text resources like XML, property files, in the running application (this has to be done by the IDE because it’s not supported by Java debugger)
4. Start the application in debug mode and connect to it via the debugger interface from withing IDE
5. Continue coding and see the changes in your app immediately

Installing the DCEVM engine

First, download the DCEVM installer for your Java installation. The project is pretty quick to release new versions for new Java updates. At the time of writing this blog post, there was a build for Java 8 update 144 available, released 12 days ago, just a month after the actual Java 8 update 144 had been released. There aren’t releases of DCEVM for every Java update, but I always just used the latest version with my Java installation and never had any issues.

The installer is a plain executable JAR file, which you can start with java -jar DCEVM-installer.jar . In Linux, I usually start this with admin privileges (using sudo), because it will add/modify files in the Java installation, which is usually read-only for standard users if installed system-wide:  sudo java -jar DCEVM-installer.jar

The installer will open a window, which lists all the detected Java installations on the system.

The DCEVM installer windows showing all detected Java installations

set configs.config.server-config.java-config.java-home=”$DCEVM_JAVA_HOME”

It’s possible to install the DCEVM engine in 2 ways:

• replace the current VM engine with DCEVM
• as an alternative engine into a Java installation, which won’t affect the standard bahavior of the JVM

If you install DCEVM as an alternative engine, you can enable it by passing -XXaltjvm=dcevm  command line option to the java  command along with the other options, like:

java -XXaltjvm=dcevm -Xmx500m -jar application.jar

I was usually successful with installing DCEVM as an alternative engine, which is less intrusive and very transparent. The DCEVM engine can then be enabled by a command line option only if you want it and you can have the same Java installation for both running third-party Java programs and development. The second option of replacing the current VM engine with DCVEM is convenient if you can’t pass additional command line arguments to the java program. In that case, I recommend using a separate Java installation to replace the default engine by DCEVM and use to it only during development.

The second option of replacing the current VM engine with DCVEM is convenient if you can’t pass additional command line arguments to the java program. In that case, I recommend using a separate Java installation to replace the default engine by DCEVM and use to it only during development.

Configure the IDE to use HotswapAgent

In order to enable the HotswapAgent, it has to be passed to the java program as an agent, via the -javaagent command line parameter. Then you have to pass additional parameters to enable the debug mode. Before configuring the IDE, I’ll explain how to start an application from command line, which is essentially what you need to configure in any IDE.

First, download the HotswapAgent JAR to some shared location. The JAR file will remain there and will be referenced by the  -javaagent command line parameter. Additionally, we’ll enable remote debugging on port 9009, with suspend=n so that the application doesn’t wait for the debugger to be attached. We can then attach a debugger at any time we want to update the application with code changes. This is an example of the command line to start an application with the HotswapAgent JAR located in /development/hotswap-agent.jar :

java -XXaltjvm=dcevm -javaagent:/development/hotswap-agent.jar \
  -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9009 \
  -jar application.jar

If you haven’t installed DCEVM as an alternative JVM but replaced the default JVM engine, you should omit the -XXaltjvm=dcevm argument.

To configure HotswapAgent in your IDE, you have to do the following steps:

1. Make sure that the IDE can apply your code changes via the debugger. In most IDEs this means that
   • automatic compile on saving is turned on
   • compiled classes are automatically replaced in the running application if it’s attached to the IDE via the debug interface
2. Make sure that the IDE uses the Java installation with the DCEVM engine
   1. if DCEVM was installed as an alternative engine, the IDE has to pass the -XXaltjvm=dcevm argument when starting the application in debug mode
3. Turn off any restart/redeployment of the application on code change (this applies mostly when using application servers via an IDE server plugin)

Detailed instructions how to do it in major Java IDEs can be found on the HotswapAgent Wiki.

Using HotswapAgent with Payara Server

Some frameworks or application servers require additional configuration. This is mostly because the hotswap-agent.jar has to be added to the classpath and the agent isn’t able to modify the classloader to add the required classes automatically, or the framework or server spawns additional JVM process and has to be configured to use a JVM with DCEVM.

To use HotswapAgent with DCEVM while developing applications with Payara Server, it requires doing the following changes:

1. copy the hotswap-agent.jar  into the lib/ext folder in the Payara Server’s domain directory. If you’re using the default domain1 domain, it would be glassfish/domains/domain1/lib/ext/hotswap-agent.jar (this is required to add HotswapAgent JAR to the server’s classpath, at least until HotswapAgent can do it automatically in Payara Server)
2. point Payara Server to the Java installation with the DCEVM engine, if it’s not the default system installation
   • set the Java Home property in JVM general settings to point to the root of your alternative Java installation (with asadmin command you would do this by calling asadmin set configs.config.server-config.java-config.java-home=”$ALTERNATIVE_JAVA_HOME” )
3. modify the JVM options:
   • remove any -client  or -server  JVM options (they would prevent using DCEVM as an alternative engine even if the -XXaltjvm  option is present)
   • add the -XXaltjvm  option
   • add the -javaagent option with the path to the hotswap-agent.jar, e.g.-javaagent:/development/hotswap-agent.jar. It can reference the same JAR file which is in the  lib/ext  folder, even using a relative reference to the domain folder, like this: -javaagent:${com.sun.aas.instanceRoot}/lib/ext/hotswap-agent.jar

If starting Payara Server from IDE, you may have to apply the step 2. and 3. in the configuration of your IDE, because the Payara Server plugin in most IDEs bypasses the standard Payara Server configuration and starts Payara Server with the Java runtime and command line parameters specified in the IDE. Mind that in that case, you have to use the full path to the hotswap-agent.jar  and avoid using the ${com.sun.aas.instanceRoot}  variable.

In the IDE, you should also disable automatic redeployment of the application on code change. Most IDE plugins do that by default because under normal circumstances, it’s the only reliable way to change update the application to reflect code changes. Since with HotSwapAgent and DCEVM the usual class reloading is enough, automatic redeploy isn’t necessary and should be disabled.

Using HotswapAgent with Payara Micro

Payara Micro is an application runtime that, unlike application servers, is packaged as a single executable JAR file and can be started as such. It deploys applications passed as command line parameters, within the same JVM process. Therefore it’s very easy to start it with the HotswapAgent in the same way as any other executable JAR:

java -XXaltjvm=dcevm -javaagent:/development/hotswap-agent.jar \
  -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9009 \
  -jar payara-micro.jar --deploy application-war

After it’s started like this, it listens on port 9009 for debugger requests and any IDE can attach its debugger to it.

The web application is deployed from an exploded directory called application-war  (not to be confused with a war file package) so that changes in resources like XML or JSF pages are also picked up automatically. Most IDEs support building a web application as an exploded directory. Maven also stages the application in a directory in the target  folder before creating the WAR file and you can deploy your application from that directory using Payara Micro.

Summary: Using HotswapAgent in Netbeans with Payara Server

I’ll quickly summarize the steps required to get HotswapAgent running with Payara Server from the Netbeans IDE.

Install DCEVM

• Use the DCEVM installer to install DCEVM as an alternative VM into a Java installation (you may need to run the installer as administrator)

Configure Payara Server

• Download the HotswapAgent JAR into the lib/ext folder in the Payara Server’s domain directory as lib/ext/hotswap-agent.jar
• modify the JVM options:
  • remove any -client  or -server  JVM options
  • add the -XXaltjvm  option
  • add the -javaagent:${com.sun.aas.instanceRoot}/lib/ext/hotswap-agent.jar option

Configure Netbeans

• In Netbeans, open the configuration of the Payara Server service
  • ensure that the Java installation with the DCEVM is selected as the Java Platform
  • there’s no way to configure JVM options – the plugin reads the standard Payara Server configuration which we modified earlier
• Open the project properties
  • in Build -> Compile, ensure that the Compile On Save option is enabled
  • in Run, ensure that the Deploy on Save option is disabled
• In Netbeans Options (Tools -> Options), in Java -> Java Debugger, ensure that Apply code changes after save is enabled
  • you can also force applying code changes manually with the Apply Code Changes button in the debug toolbar while debugging

Now, you can debug the application in a standard way from within Netbeans. The IDE will automatically compile all classes, update them in the server. It will also copy all changed resources into an exploded directory which it used to deploy the application so that these resources are refreshed too, because Payara Server monitors them for changes.

Summary: Using HotswapAgent in Netbeans with Payara Micro

The following steps will get you to get HotswapAgent running with Payara Micro and the Netbeans IDE:

• install the DCEVM as an alternative VM (the same step as for Payara Server)
• In Netbeans, open the project properties
  • • in Build -> Compile, ensure that the Compile On Save option is enabled
• In Netbeans Options (Tools -> Options), in Java -> Java Debugger, ensure that Apply code changes after save is enabled
  • you can also force applying code changes manually with the Apply Code Changes button in the debug toolbar while debugging
• Find out where Netbeans outputs the exploded directory of your application (before it packages it as a WAR file)
  • for maven projects, it’s in the target  folder and has the same name as the final WAR file, without the WAR extension
• Download the HotswapAgent JAR into the same folder that contains your exploded application
• Run the application from the exploded directory, with the following command line (assuming that the exploded application directory is called application-war  and that payara-micro.jar is in the same folder):

  • java -XXaltjvm=dcevm -javaagent:hotswap-agent.jar \
      -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9009 \
      -jar payara-micro.jar --deploy application-war

• Attach Netbeans debugger to the application – menu Debug -> Attach Debugger, use the port 9009 as the debug port

Republished at:

• DZone.com

The post Using HotswapAgent to speed up development appeared first on .Lost in Coding.

Opening the process of Java EE development and moving it under an open source foundation is certainly a good news. I’m hopeful that this will finally address many concerns that the community and vendors have had with the current process in the past years, frequently having called for improvements. I appreciate that the process within the JCP has been very open compared to the development of other similar standards or frameworks and that the JCP is evolving in a good and promising direction. But the process is still driven mostly by Oracle and involves many administrative and legal obstacles to community contributions. The collaboration within the Java EE community and most vendors is maturing much faster, in a more and more open and agile way, and the JCP processes and Oracle’s leadership of Java EE is still too far behind, only catching up with this trend. I credit Oracle my respect that they’ve realized and admitted this and they decided to transfer the platform into an open foundation, which would be more ready to support the way the Java EE community wants to progress.

It’s also very promising that Oracle is very open to discussion about the future direction of the Java EE platform, inviting respected partners and members of the community to join a call to discuss Oracle’s intentions and answer questions. On this call, some concerns were raised, especially about the continuity of the platform after it’s transferred to an independent foundation. It’s still uncertain whether the platform can retain its current name Java EE due to trademark licenses and whether the API can evolve continually without breaking changes, again due to license issues. But Oracle seems to be very open and cooperative to resolve these concerns and my hope is that the Java EE platform will be transferred without significant harm. Another thing to keep in mind is that Oracle admitted that their leadership in Java EE development will decrease a lot, becoming just a regular contributor like many others. I can certainly understand that because Oracle’s been investing heavily in leading most of the Java EE specifications and the current process hasn’t allowed delegating most of that work because of legal issues. Moving to a foundation will distribute the responsibility for the platform equally among all that benefit from it. This means that with freedom will also come responsibility and the community and vendors will need to invest a lot more into Java EE development than they’ve used to. But I wouldn’t be afraid, because the community is already doing this at different levels, most notably within the Eclipse MicroProfile project. For some open source projects like Payara, which shares a lot of code with the GlassFish reference implementation, or DeltaSpike, which provides lots of useful extensions to Java EE, it would be even a lot easier to contribute than now.

I can say that the community and vendors are looking forward to more open collaboration with fewer restrictions. The Eclipse Microprofile project, supported by many Java EE community members and Java EE vendors, already proves that the community is prepared to embrace the platform within an open foundation. The MicroProfile project started as an open initiative to move enterprise Java forward, with focus on delivering the functionality in a very open way and leaving any legal matters as an afterthought, which was welcomed by the community. The Eclipse Foundation then did their best to provide a solid legal and collaboration foundation. This is again a proof that a development platform like Java EE can be safely transferred and continue to thrive under an opensource foundation. MicroProfile is based on Java EE foundations and initiated from discussions within the Java EE community, so both have a lot in common. In my view, MicroProfile can be used as an example of how an API platform can be adopted by an open source foundation, namely the Eclipse Foundation. Java EE can benefit from MicroProfile even more, with MicroProfile providing more agile platform for experimenting with ideas that can be adopted by Java EE when matured. In fact, this is not only a promise but it’s already happening, as the Eclipse Foundation submitted a MicroProfile JSR to the JCP with the aim to become a part of a future Java EE version.

Compared to some rather unpopular things that Oracle did in the past, like shutting down the java.net community portal, it seems that they are doing the right thing now. I believe that the community will hugely benefit from Oracle’s recent plans and that Java EE will thrive under an open source foundation in harmony with the existing Eclipse MicroProfile project.

UPDATE:

Oracle’s announced that they have chosen the Eclipse Foundation to transfer Java EE to. This is a very natural choice for Java EE and is very welcome by the Java EE and MicroProfile communities.

Republished at:

• DZone.com

The post Oracle announced to open JavaEE – what to expect in the future? appeared first on .Lost in Coding.