Skip to main content

The Payara Monthly Catch: July 2021

by Priya Khaira-Hanks at July 29, 2021 02:45 PM

Welcome to our July Payara Monthly Catch - a collection of articles, videos & podcasts around Java, Jakarta EE, MicroProfile, open source and cloud computing. This month, the list mixes up quirky content you may not have seen - weird programming facts, tips on using the Snowflake Database - to insight from some of the most esteemed experts in the industry. Payara Platform has also been appearing all over the web, as influencers and our community use it in demos and discuss our products in conferences. Find out where Payara can be found across external blogs, conferences and media outlets in our 'Featuring Payara and Payarans' section.

On the internal news side, we announced that Payara Server Community 6.2021.1.Alpha1 is now a Certified Jakarta EE 9.1 9.1 (Full Profile) Compatible Product! Even though we aren't encouraging users to run Payara Server 6 in production yet - you can achieve the same result, migrating to Java SE 11, in Payara Server 5 - this is important news in the journey of Payara Platform products alongside Jakarta EE.

We also published a full summary of what we got up to for our annual team-bonding company event, Payara Week - from chocolate Payara fishes to cocktail making challenges, open source business model learning to daily workshops. Make sure you read ithere! You can also watch videos from our summer webinar series, 'Dismiss the Myths: Get to know Java EE / Jakarta EE'here - the second half of the sessions took place this month.


by Priya Khaira-Hanks at July 29, 2021 02:45 PM

Jakarta Community Acceptance Testing (JCAT)

by javaeeguardian at July 28, 2021 05:41 AM

Today the Jakarta EE Ambassadors are announcing the start of the Jakarta EE Community Acceptance (JCAT) Testing initiative. The purpose of this initiative is to test Jakarta EE 9/9.1 implementations testing using your code and/or applications. Although Jakarta EE is extensively tested by the TCK, container specific tests, and QA, the purpose of JCAT is for developers to test the implementations.

Jakarta EE 9/9.1 did not introduce any new features. In Jakarta EE 9 the APIs changed from javax to jakarta. Jakarta EE 9.1 raised the supported floor to Java 11 for compatible implementations. So what are we testing?

  • Testing individual spec implementations standalone with the new namespace. 
  • Deploying existing Java EE/Jakarta EE applications to EE 9/9.1.
  • Converting Java EE/Jakarta EE applications to the new namespace.
  • Running applications on Java 11 (Jakarta EE 9.1)

Participating in this initiative is easy:

  1. Download a Jakarta EE implementation:
    1. Java 8 / Jakarta EE 9 Containers
    2. Java 11+ / Jakarta EE 9.1 Containers
  2. Deploy code:
    1. Port or run your existing Jakarta EE application
    2. Test out a feature using a starter template

To join this initiative, please take a moment to fill-out the form:

 Sign-up Form 

To submit results or feedback on your experiences with Jakarta EE 9/9.1:

  Jakarta EE 9 / 9.1 Feedback Form

Resources:

Start Date: July 28, 2021

End Date: October 1, 2021


by javaeeguardian at July 28, 2021 05:41 AM

Introduction to Panache

by Thorben Janssen at July 27, 2021 12:00 PM

The post Introduction to Panache appeared first on Thorben Janssen.

Panache is a Quarkus-specific library that simplifies the development of your Hibernate-based persistence layer. Similar to Spring Data JPA, Panache handles most of the repetitive boilerplate code for you. Its implementations of the repository and the active record pattern provide methods to create, update, and remove records, perform basic queries, and define and execute your […]

The post Introduction to Panache appeared first on Thorben Janssen.


by Thorben Janssen at July 27, 2021 12:00 PM

CDI Lite, MicroProfile, Helidon, Micronaut and Serverless--an airhacks.fm podcast

by admin at July 25, 2021 03:05 PM

Subscribe to airhacks.fm podcast via: spotify| iTunes| RSS

The #149 airhacks.fm episode with Graeme Rocher (@graemerocher) about:
optimizing CDI for serverless with CDI Lite, Micronaut - Helidon cooperation and move fast, follow standards and sometimes break things with MicroProfile
is available for download.

by admin at July 25, 2021 03:05 PM

Hashtag Jakarta EE #82

by Ivar Grimstad at July 25, 2021 09:59 AM

Welcome to the eighty-second issue of Hashtag Jakarta EE!

One of the goals the Jakarta EE platform project is working towards is to create some sort of predictability regarding Java SE with future Jakarta EE releases. It seems that we are approaching something that looks like a strategy regarding this goal.

As previously announced, Jakarta EE 10 will be based on Java SE 11. That means that the specification projects will be able to use Java SE 11 language features in their APIs.

The TCK will be possible to run with any version from 11 and above.

For Jakarta EE 11, the Java SE version will be raised to the next LTS release, which will be Java SE 17. And so on…

What this means for the individual component specification teams, is that they can embrace Java SE language features of the version supported by the platform they plan to target. An example:

The specification Jakarta Wombat 1.1 use Java SE 11 language features and target Jakarta EE 10 while Jakarta Wombat 1.2 use Java SE 17 language features (e.g. Records) and thus target Jakarta EE 11
An implementation of Jakarta Wombat, e.g. Possum can use Java SE 17 features both for Possum 1.0 which implements Jakarta Wombat 1.1, and Possum 2.0 which implements Jakarta Wombat 1.2.

The release plan for Jakarta EE 10 is out for review by the Jakarta EE platform project. Hopefully, we will be able to wrap up the discussions in the platform call on Tuesday, and propose this plan for review by the Jakarta EE specification committee.

Earlier this year, I participated in the Foojay Virtual Tour with a talk at KnoxJava JUG. For the upcoming Virtual Foojay OpenJDK 17+ JUG Tour, I have a new talk called Leveraging OpenJDK 17 features with Jakarta EE. If you would like to hear about this in your JUG, do follow the instruction on foojay.io to sign up.


by Ivar Grimstad at July 25, 2021 09:59 AM

Hosting Web Components on Amazon S3

by admin at July 24, 2021 10:52 AM

Static assets like e.g. html,css or JavaScript files can be directly deployed to Amazon S3 with the AWS Cloud Development Kit (CDK) in Java.

You will have to create the S3 bucket first:


public class CDKStack extends Stack {

public CDKStack(final Construct scope, final String id, final StackProps props) {
    super(scope, id, props);

    var bucket = Bucket.Builder.create(this, id+"-bucket").
                    bucketName("wc-on-s3-with-airhacks").
                    publicReadAccess(true).
                    websiteIndexDocument("index.html").
                build();

...and then deploy the website from a folder:


    BucketDeployment.Builder.create(this, id+"-deployment").
        sources(List.of(Source.asset("./website/src/"))).
        destinationBucket(bucket).
    build();

The website's URL becomes available after a successful deployment: mvn package && cdk deploy with the following output:


CfnOutput.Builder.create(this, id + "-url").value(bucket.getBucketWebsiteUrl()).build();

In a production system, you could use AWS CloudFront for global caching. The SSL certificate is available via AWS ACM, and a nicer domain name can be registered and configured with AWS Route 53.

The example website in the screencast was taken from: github.com/AdamBien/bce.design and the "streamlined CDK starter" is available from: github.com/AdamBien/aws-cdk-plain.

See it in action:


by admin at July 24, 2021 10:52 AM

OpenJDK Live Hacking | The Two Minutes Tuesday 028 | Core #Java

by Markus Karg at July 20, 2021 09:00 PM

In my LIVE SHOW #ToniteWithMe on next Friday, 20:00 CDE, you can take a look inside of the #OpenJDK team: Roman Kennke, the lead of Shenandoah GC, will talk with me about his work on the #JVM!

Ask you own questions in the LIVE CHAT and get answers from a professional JVM coder!

If you like this video, please give it a thumbs up, share it, subscribe to my channel, or become my patreon https://www.patreon.com/mkarg. Thanks! 🙂

CU!


by Markus Karg at July 20, 2021 09:00 PM

How and when to use JPA’s getReference() Method

by Thorben Janssen at July 20, 2021 12:00 PM

The post How and when to use JPA’s getReference() Method appeared first on Thorben Janssen.

With the T getReference(Class<T> entityClass, Object primaryKey) and the T find(Class<T> entityClass, Object primaryKey) method, JPA’s EntityManager seems to provide 2 methods that do the same. Both of them seem to get an entity by its primary key from the database. There obviously is a difference between the 2 methods. An established and well-defined API […]

The post How and when to use JPA’s getReference() Method appeared first on Thorben Janssen.


by Thorben Janssen at July 20, 2021 12:00 PM

A Serial Duke Choice Award Winner--an airhacks.fm podcast

by admin at July 18, 2021 06:30 PM

Subscribe to airhacks.fm podcast via: spotify| iTunes| RSS

The #148 airhacks.fm episode with Mohamed Taman (@_tamanm) about:
early serverside Java, mission critical projects with Java EE, Jakarta EE and MicroProfile for United Nations and eFinance, and the Duke Choice Awards
is available for download.

by admin at July 18, 2021 06:30 PM

Hashtag Jakarta EE #81

by Ivar Grimstad at July 18, 2021 09:59 AM

Welcome to the eighty-first issue of Hashtag Jakarta EE!

Last week we hosted the Jakarta EE Update call. If you missed it, don’t despair as it was recorded. As usual, it will be cut into smaller themed pieces and published on the Jakarta EE YouTube channel.

The Jakarta EE Platform project has stated a clarification regarding the Java SE level for Jakarta EE 10. The component specifications are recommended, not recommended to compile their API jar files to Java SE 11. That means that they can compile to lower Java SE levels if it fits them better. The recommendation, however, is still to compile to Java SE 11 using the --release option to the compiler. Exemplified here by the maven compiler plugin configuration.

...
    <maven.compiler.release>11</maven.compiler.release>
...

The topic of release cadence and time-based vs feature-based continues. I suspect this to be the major discussion point in the platform call next week. One of the questions that are being discussed is whether to tie the roadmap and release cadence to the Java SE LTS releases, effectively meaning a three-year release cycle for the Jakarta EE Platform and Profiles. Please join in on the discussions on the mailing list and the weekly platform project calls.

The JakartaOne Livestream 2021 Call-for-Paper is open! Take this opportunity and submit your talk to the third edition of this one-day virtual conference. If you are a new speaker, take a look at the previous editions for inspiration. If you have spoken at any of, or both, the previous events, make sure to complete your collection of the JakartaOne Livestream buttons.


by Ivar Grimstad at July 18, 2021 09:59 AM

Understanding Jakarta Security with TomEE

by Jean-Louis Monteiro at July 15, 2021 05:13 PM

There are many blogs explaining how to get Jakarta Security on Tomcat using all sorts of libraries and wiring everything manually. So many opportunities to get it wrong, if you are evaluating or currently using Apache TomEE.

In TomEE, the good news is that, like JAX-RS, CDI or Bean Validation, Jakarta Security is out of the box ready to be used like Servlet, and CDI for example.

This blog is a high-level view so you have the big picture of the technologies and how they interact with each other in the security landscape. The goal is to be able to use them when needed, and quickly!

If you are looking into something detailed for each technology, I would suggest joining the mailing lists for the different Jakarta projects and get in touch with the committers. Good opportunity to contribute now that everything is open sourced. For further TomEE contributions or inquiries, you can also join the TomEE mailing lists.

Why is Jakarta Security important?

Jakarta Security API (code name JSR 375) first appeared quite recently, in Java EE 8. Most people would say, it’s been on the platform for quite a long time. Why is there a need for another specification?

First, it actually took over 20 years for Java EE to start having some kind of lightweight security for applications. Before that, the only thing available was in Java SE to secure the code itself, and that was mainly in the context of the Applets because they were running on the client-side. On a regular Java EE / Jakarta EE environment, the code is trusted as it is ours and it’s also running in our trusted environment (static user with static permissions or roles depending on the environment they were running in). So I don’t know if many companies are really using that. What needs to be addressed, in this context, isn’t how to secure the code itself, but who is calling us, and what can he/she do.

Servlet and Principal

The first notion of Principal and roles appeared in a very light, blurry, and hard-coded manner in the Servlet specification (J2EE 1.2). It’s still there today, security roles and security constraints defined in the web.xml, some HttpServletRequest request methods to retrieve the Principal or to test if a user has a role or not. Then, in terms of authentication, a finite list of hard-coded values (like BASIC, FORM, etc), that each implementation could implement the way they wanted. Even in Tomcat, until recently at least, the concepts of Realm and Authenticator were hardcoded and not extensible. With these improvements based on the Servlet specification, users and roles were a variable, but there was nothing specified for the authentication mechanisms. So each server was doing its own thing, again preventing any kind of portability.

JAAS (Java Authentication and Authorization Service)

It is only in J2EE 1.4, that an answer was given with JAAS. At first glance, it looked like the missing part of the puzzle was to implement user centric security in Java EE. In practise, it added a bit more fuzzy zone allowing application servers to keep implementing their own stuff. For example, JAAS did not really define how to assign Login modules to a specific application. It did not mention, either how to distinguish between the Principal returned by the getUserPrincipal, or the list of Principals representing the roles. And finally, still, nothing to address the notion of identity store where users and roles will be stored.

One gap was filled in J2EE 1.4 with JACC (explained here after). It took out some misunderstandings and unspecified areas, especially on how to model URL constraints in Servlets, and the same for method permissions in Java SE (yes, back to the beginning lol). Even though it allowed some clarifications, it also introduced a significant complexity draining all the efforts. 

For some reason, it took another 10 years after Servlet security was introduced, for the Java platform to realize the authentication part never got addressed. JASPIC was added very recently in Java EE 6. It really added value by clarifying the interfaces and standards around authentication mechanisms. Again, something was missing, it was the ability for an application to register an authentication module. Tomcat 8.5, for instance, implemented JASPIC, and allowed such a thing with a jaspic-provider.xml configuration file.

JACC – Authorization 

In France, we have a well known joke, “Pourquoi faire simple quand tu peux faire compliqué ?”, which literally means, “Why should you do it simple when you can do it complicated?”

This has always been my feeling with JACC (Java Authorization Contract for Containers). It was added back in J2EE 1.4 to define a contract between Java EE application servers and an authorization policy provider. This is, in essence, an entry point that allows you to define your own java.security.Permission classes. It got a few minor updates over the course of the Java EE releases, but nothing that makes it easier to understand. 

If you start asking around, you will probably get the answer, “I have no idea what this thing does and what it’s for”, and that’s putting it politely.

JACC provides you with a hook into the authorization process. I said only authorization, aka can the user/caller access resource A (a web URL for instance). It does not, at all, address the authentication part (identify the caller and make sure it’s the person it’s pretending to be).

Then, there is the part to actually use it:

  • Like in Servlet, EJB or JAX-RS, you can get at any time the caller/user logged in. In this case, you will simply do `Subject subject = (Subject) PolicyContext.getContext(“javax.security.auth.Subject.container”);`

You can, of course, realize that: 

  • In EJB, you would get SessionContext (or any other subclass of EJBContext) injected so you could call `getCallerPrincipal()`. It returns a Principal and not a Subject.
  • In Servlet, you can, from the HttpServletRequest call, `getUserPrincipal()`. It also returns a Principal. Notice that it’s user, and not caller, for HttpServletRequest.
  • In JAX-RS, you can get the jakarta.ws.rs.core.SecurityContext injected (be careful with the package as there are more …) and then call getUserPrincipal().

JASPIC – Authentication

Arjan Tijms summarizes it as “It’s a thin API that enables building fully standardized and pluggable authentication modules”.

The primary goal was to create a standard interface for Servlet containers supported mechanisms. Even though today, most of the Servlet containers such as Tomcat (and therefore TomEE) or Jetty support JASPIC, the adoption of it was very slow.

Like any specification in the early days, JASPIC had its own set of issues:

  • Too generic because we wanted it to be flexible and usable for any kind of application and authentication,
  • But there was no way for an application to register its own authentication module.

In the end, portability was impossible most of the time. And even more so, because the TCK is lacking coverage in that area, which means everyone can pretty much claim to be compliant.

Java EE 7 came with an updated version of JASPIC, 1.1 to fix those issues and also clarify some interaction with the Servlet API.

So what’s up with Jakarta Security API?

Jakarta Security API depends on JASPIC and is implemented as a JASPIC authentication module. The goal was to use JASPIC under the cover, but address issues especially the ability for an application to configure its security. This is, of course, particularly important for cloud deployments, because we don’t want anything outside of the war deployment.

The goal was also to remove all unspecified parts leading to vendors having their own configuration, solutions for very simple things like: 

  • switching from one identity provider to another
  • switching from Basic to Form authentication mechanism
  • applying session to propagate authentication to subsequent http requests
  • supporting remember me

Did you find this blog useful? Get ready for the next couple of blog posts that are going to technically demonstrate some of the features of Jakarta Security with TomEE.

 

The post Understanding Jakarta Security with TomEE appeared first on Tomitribe.


by Jean-Louis Monteiro at July 15, 2021 05:13 PM

JakartaOne Livestream 2021 CFP is OPEN!

by Ivar Grimstad at July 15, 2021 01:43 PM

JakartaOne Livestream is a one-day virtual conference that focuses on Cloud Native Java, MicroProfile, and Jakarta EE. The Call for Paper is open from July 15 to September 15. But don’t wait, submit your abstract NOW for a chance to speak at an event attended by more than 1000 participants. Check out the previous events for inspiration:

JakartaOne Livestream 2019
JakartaOne Livestream 2020


by Ivar Grimstad at July 15, 2021 01:43 PM

Infrastructure as Java Code (IaJC): Setting AWS System Manager Parameter

by admin at July 15, 2021 10:27 AM

Static assets like e.g. html,css or JavaScript files can be directly deployed to Amazon S3 with the AWS Cloud Development Kit (CDK) in Java.

You will have to create the S3 bucket first:


public class CDKStack extends Stack {

public CDKStack(final Construct scope, final String id, final StackProps props) {
    super(scope, id, props);

    var bucket = Bucket.Builder.create(this, id+"-bucket").
                    bucketName("wc-on-s3-with-airhacks").
                    publicReadAccess(true).
                    websiteIndexDocument("index.html").
                build();

...and then deploy the website from a folder:


    BucketDeployment.Builder.create(this, id+"-deployment").
        sources(List.of(Source.asset("./website/src/"))).
        destinationBucket(bucket).
    build();

The website's URL becomes available after a successful deployment: mvn package && cdk deploy with the following output:


CfnOutput.Builder.create(this, id + "-url").value(bucket.getBucketWebsiteUrl()).build();

In a production system, you could use AWS CloudFront for global caching. The SSL certificate is available via AWS ACM, and a nicer domain name created with AWS Route 53.

The example website in the screencast is: github.com/AdamBien/bce.design and the "streamlined CDK starter" github.com/AdamBien/aws-cdk-plain:

See it in action:


by admin at July 15, 2021 10:27 AM

Why are you not using [the language of the year] instead of Java?

by admin at July 14, 2021 03:53 PM

Over the years, I get asked frequently: "Why are you not using [the language of the year] instead of Java?" At my very first serverside project, I had to justify myself for using Java instead of Perl. In the early Java years, I got frequent questions about whether we should switch to Python, later Jython.

I collected the languages for the question Why are you not using (...) instead of Java? in chronological order:

  1. Perl (~1994)
  2. python (~1995)
  3. jython (~1997)
  4. Groovy (~2004)
  5. Scala (~2004+)
  6. Ruby on Rails / jRuby (~2006)
  7. CoffeeScript (~2010)
  8. Ceylon (~2011)
  9. Clojure (~2012)
  10. Dart (~2013)
  11. TypeScript (~2014+)
  12. Kotlin (2017+)

Because of the high project workload, I never managed to learn anything else than Java and JavaScript. Therefore we never had to migrate to anything else. However, if I had to pick one language from the list above, I guess Python would be the most useful one to know.

I'm already curious about the next programming language of the year 2021+.

Maybe it is going to be the compact and expressive COW-language (2006 blog post)?


by admin at July 14, 2021 03:53 PM

Quarkus & Hibernate – Getting Started

by Thorben Janssen at July 13, 2021 12:00 PM

The post Quarkus & Hibernate – Getting Started appeared first on Thorben Janssen.

The Quarkus project enables you to develop Kubernetes-native applications based on Java and a huge list of well-established, Java-based frameworks. Hibernate is, of course, one of these frameworks. But the project not only enables you to build native applications with incredibly fast boot times and a very small memory footprint. It also provides a bunch […]

The post Quarkus & Hibernate – Getting Started appeared first on Thorben Janssen.


by Thorben Janssen at July 13, 2021 12:00 PM

Are Java EE Application Servers Heavy? Watch The Video.

by Priya Khaira-Hanks at July 13, 2021 08:00 AM

Our summer webinar series continued with 'Are Java EE Application Servers Heavy?'

In thismyth-busting webinar, Steve Millidge (founder of Payara), showed viewers that Java EE application servers are NOT resource-heavy or slow.  His live demonstrations showed it’s possible to have a small footprint and low resource usage in Jakarta EE runtimes.

If you missed the webinar earlier this month, you can now watch the video!


by Priya Khaira-Hanks at July 13, 2021 08:00 AM

MicroProfile 4.1 plus more exciting features now in Open Liberty 21.0.0.8-beta

July 12, 2021 12:00 AM

Open Liberty 21.0.0.8-beta introduces MicroProfile 4.1 with updates to the MicroProfile Health feature. A new logging format (TBASIC) is made available. The Stale Connection Identification feature makes it possible to provide additional configuration for a data source. A couple of Jakarta EE 9.1 convenience features are also included in the "All Beta" package.

We have two beta packages for Open Liberty:

  • All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.

  • Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try one of these packages, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

MicroProfile Updates

In Open Liberty 21.0.0.8-beta we have two updates: MicroProfile 4.1 improves developer experience with updates to the Health feature; MicroProfile Health 3.1 enables you to provide your own Startup health check procedures to be invoked by Open Liberty. Find out more below.

MicroProfile 4.1

MicroProfile 4.1 improves developer experience with updates to the Health feature. MicroProfile 4.1 also defines compatible implementation requirements for runtimes, which must pass all of the MicroProfile component specification TCKs including Config 2.0, Fault Tolerance 3.0, Rest Client 2.0, Health 3.1, Metrics 3.0, Open Tracing 2.0, Open API 2.0, and JWT propagation 1.2. This beta driver will be used as a compatible implementation for releasing MicroProfile 4.1.

<featureManager>
    <feature>microProfile-4.1</feature>
</featureManager>

To find out more take a look at the MicroProfile 4.1 Release.

MicroProfile Health 3.1

MicroProfile Health enables you to provide your own health check procedures to be invoked by Open Liberty, to verify the health of your microservice. A service checks its own health by performing necessary self-checks and then reports its overall status by implementing the API provided by MicroProfile Health. A self-check can be a check on anything that the service needs, such as a dependency, a successful connection to an endpoint, a system property, a database connection, or the availability of required resources. MicroProfile offers checks for both Liveness and Readiness. MicroProfile Health 3.1 introduces a new Health Check called Startup, which allows applications to define startup probes that are used for initial verification of the application before the Liveness probe takes over. This is useful for applications which require additional startup time on their first initialization.

In the previous versions of MicroProfile Health, there were no unique APIs or endpoints to distinguish the start up status of your microservices. MicroProfile Health 3.1 introduces a new convenient @Startup annotation to create your own health check procedures to verify that your microservices have fully initialized. The status of the Startup health checks of your microservices can be viewed with the new REST endpoint /health/started. You can now configure the Kubernetes Startup probe with this new endpoint as well. In Open Liberty, you can use the Startup endpoint, /health/started, to verify if your deployed applications have started or not.

When deployed application(s) are not started yet, the overall default Startup status will be DOWN, with an empty payload response until all the deployed application(s) have started. A new MicroProfile Config property (mp.health.default.startup.empty.response=UP) is available to change the overall default Startup check status to UP, during application start up.

Applications are expected to provide health check procedures by implementing the HealthCheck interface with the @Startup, @Liveness, or @readiness annotations. These are used by Open Liberty to verify the respective Startup, Liveness, or Readiness of the application. Add the logic of your health check in the call() method, and return the HealthCheckResponse object, by using the simple up()/down() methods from the API:

**Startup Check**
@Startup
@ApplicationScoped
public class StartupMemUsageCheck implements HealthCheck {
...
    @Override
     public HealthCheckResponse call() {
       ...
       if (getMemUsage() < 0.95) {
           return HealthCheckResponse.up("memUsage");
       }
       return HealthCheckResponse.down("memUsage");
       ...
     }
}

To view the status of each health check, access the http://<hostname>:<port>/health/started endpoint.

To enable the new beta features in your app, add them to your server.xml:

<feature>mpHealth-3.1</feature>

To find out more viist:

TBASIC Logging Format

A new logging format, TBASIC, is added to match the Websphere Application Server basic logging format. This new format option can be used for consoleFormat, messageFormat, or traceFormat. TBASIC format matches the existing trace BASIC format (so now either TBASIC or BASIC can be used to refer to this format for trace). Using this new format option will allow users that utilize log parsers that work with the Websphere Application Server basic format to use the same parsers with Open Liberty logs.

The new options can be used in the bootstrap.properties file:

com.ibm.ws.logging.message.format=tbasic
com.ibm.ws.logging.console.format=tbasic
com.ibm.ws.logging.trace.format=tbasic

You can also change the format by editing the server.env and adding the following lines:

WLP_LOGGING_MESSAGE_FORMAT=TBASIC
WLP_LOGGING_CONSOLE_FORMAT=TBASIC

TBASIC Logs Example:

[24/03/21 15:04:10:331 EDT] 00000001 FrameworkMana A   CWWKE0001I: The server defaultServer has been launched.
[24/03/21 15:04:11:338 EDT] 00000001 FrameworkMana I   CWWKE0002I: The kernel started after 1.177 seconds
[24/03/21 15:04:11:465 EDT] 0000003e FeatureManage I   CWWKF0007I: Feature update started.
[24/03/21 15:04:11:635 EDT] 00000033 DropinMonitor A   CWWKZ0058I: Monitoring dropins for applications.

Customizing Stale Connection Identification

Open Liberty maintains a pool of JDBC connections to improve performance. It is necessary for Open Liberty to be able to identify when connections have become stale and are no longer usable so that such connections can be removed from the pool. Open Liberty leverages multiple standards made available by the JDBC and SQL specifications, as well as relying on some built-in knowledge of vendor-specific behavior for some JDBC drivers in order to achieve this.

Not all JDBC drivers completely follow the JDBC/SQL specifications in identifying stale connections. If you are using such a JDBC driver, it is now possible for you to provide additional configuration for a data source that helps identify the vendor-specific SQL states and error codes that are raised by the JDBC driver, enabling Liberty to better maintain the connection pool.

Configure one or more <identifyException> subelements under <dataSource> to provide the SQLException identification detail.

<featureManager>
  <feature>jdbc-4.2</feature>
  <feature>jndi-1.0</feature>
  ... other features
</featureManager>

<dataSource id="DefaultDataSource" jndiName="jdbc/myDataSource">
    <jdbcDriver libraryRef="myJDBCLib"/>
    <properties databaseName="TESTDB" serverName="localhost" portNumber="1234"/>
    <!-- identify the following as stale connections, -->
    <identifyException sqlState="08000" as="StaleConnection"/>
    <identifyException errorCode="2468" as="StaleConnection"/>
    <!-- remove built-in identification of SQL state S1000 -->
    <identifyException sqlState="S1000" as="None"/>
</dataSource>

<library id="myJDBCLib">
    <file name="C:/drivers/some-jdbc-driver.jar"/>
</library>

Jakarta EE 9.1 convenience features

Jakarta EE 9.1 convenience features are included in this beta release in the "all beta" zip file, but not yet in the Jakarta EE 9 beta zip file. The 9.1 convenience features are duplicates of the Jakarta EE 9.0 convenience features. In a future beta release, the 9.0 convenience features will be removed and only the 9.1 ones will remain. Users of the Jakarta EE 9 convenience features should look to transition to use 9.1 in preparation of 9.0 being removed.

To enable the Jakarta EE 9.1 convenience features, add them to your server.xml or client.xml:

<featureManager>
    <feature>webProfile-9.1</feature>
</featureManager>
<featureManager>
    <feature>jakartaee-9.1</feature>
</featureManager>
<featureManager>
    <feature>jakartaeeClient-9.1</feature>
</featureManager>

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 15, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.8-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[20.0.0.8-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

Open Liberty 21.0.0.2-beta was the first vendor product to be Jakarta EE Web Profile 9.0 compatible. Similarly, Open Liberty 21.0.0.3-beta was the first vendor product to be added to the Jakarta EE Platform 9.0 compatibility list.. Open Liberty 21.0.0.8-beta maintains that compatibility while continuing to make quality and performance enhancements.

Try it now

To try out these Jakarta EE 9 features on Open Liberty in a lightweight package, just update your build tools to pull the Open Liberty Jakarta EE 9 Beta Features package instead of the main release. The beta works with Java SE 16, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.8-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.8-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.


July 12, 2021 12:00 AM

Hashtag Jakarta EE #80

by Ivar Grimstad at July 11, 2021 09:59 AM

Welcome to the eightieth issue of Hashtag Jakarta EE!

Our next Jakarta EE Update call is coming up on Wednesday, July 14th. Join in to get the latest updates from the Jakarta EE working group. It is an informal event where you will be able to ask any questions you may have, and hopefully get them answered. Refer to the Jakarta EE Community Calendar for details.

The weekly calls in the Jakarta EE Platform project continue. Last week’s call was largely dominated by discussions around versioning schemes. I expect that this will continue in this week’s call as well.

Check out the Jakarta EE Specifications Calendar for meeting details. There are several other regular calls listed here as well. The Jakarta CDI project meets weekly. The same goes for Jakarta Config, while Jakarta MVC has monthly calls.

If you arrange calls for your Jakarta specification project, please do remember to add them to the calendar, so everyone interested is able to join. Both for once-in-a-while, ad-hoc as well as regular calls.

The number of compatible products for Jakarta EE 9.1 continues to rise. The Jakarta EE 9.1 Platform Compatible Products are Eclipse GlassFish, ManageFish Server, Open Liberty, Payara Server Community, and WildFly.

The Jakarta EE 9.1 Web Profile Compatible Products are Apache TomEE, Eclipse GlassFish, Open liberty, and WildFly.

Get Listed!

If you are doing some interesting work that involves Jakarta EE technologies, please do reach out to me. I will be happy to add it to an upcoming issue of Hashtag Jakarta EE.


by Ivar Grimstad at July 11, 2021 09:59 AM

Compiling my own JDK! | Modern Java | Head Crashing Informatics 34

by Markus Karg at July 10, 2021 03:00 PM

I am sick of several #performance flaws of the #JRE, so I downloaded the source code of #OpenJDK 17 and compiled my own custom #Java runtime! If you also want to do that, just follow the instructions in this video and start hacking on OpenJDK!

Please share this video with all Java programmers you do know, so everybody will be able to contribute funny hacks and helpful to OpenJDK!

Don’t miss my next conference talks: * September 2021: Java Forum Stuttgart * October 2021: EclipseCon (https://www.eclipsecon.org/2021/sessions/jakarta-restful-web-services-31-and-40-javas-official-rest-api-today-and-tomorrow)

If you like this video, please give it a thumbs up, share it, subscribe to my channel, or become my patreon https://www.patreon.com/mkarg. Thanks! 🙂

Stay safe and… Party On!


by Markus Karg at July 10, 2021 03:00 PM

EclipseCon and Java Forum Stuttgart: I am speaking… about JAX-RS 3.1 and 4.0!

by Markus Karg at July 10, 2021 01:18 PM

As you know, I am a committer to the JAX-RS API and co-author of the Jakarta RESTful Web Services specification. Also I am a contributor to Eclipse Jersey, the former reference implementation of JAX-RS. Due to that, you might be interested to hear that this year, besides JavaLand, I will only speak on two more conferences. So if you like to get the latest news on JAX-RS, the greatest features added to 3.1 (which will be published soon) and planned for 4.0 (which will be published a bit later), how to use them in real world projects with the diverse implementing frameworks like Jersey, CXF, RESTeasy, then you definitively must not miss the following conferences:


by Markus Karg at July 10, 2021 01:18 PM

Payara Server Community 6.2021.1.Alpha1 is now a Certified Jakarta EE 9.1 (Full Profile) Compatible Product

by Debbie Hoffman at July 07, 2021 08:39 AM

Payara has released Payara Server Community 6 (Alpha version) which has passed the Jakarta EE 9.1 TCK on JDK 11. This means Payara Server Community 6.2021.1.Alpha1 is a certified Jakarta EE 9.1 implementation. 


by Debbie Hoffman at July 07, 2021 08:39 AM

Got my first shot | The Two Minutes Tuesday 027 | Blog

by Markus Karg at July 06, 2021 09:00 PM

On short term I got an invitation for a #Biontec #Covid19 vaccination, so I instantly grabbed my cam and headed into the next county to get my first shot!

If you like this video, please give it a thumbs up, share it, subscribe to my channel, or become my patreon https://www.patreon.com/mkarg. Thanks! 🙂

CU!


by Markus Karg at July 06, 2021 09:00 PM

Hibernate’s Read-Only Query Hint For Faster Read Operations

by Thorben Janssen at July 05, 2021 11:45 PM

The post Hibernate’s Read-Only Query Hint For Faster Read Operations appeared first on Thorben Janssen.

By default, Hibernate loads all entity objects in read-write mode. It performs dirty checks to detect changes it needs to persist in your database for each of them. That makes entities very easy to use, but it also creates an overhead if you don’t want to change anything. You can avoid this by setting Hibernate’s […]

The post Hibernate’s Read-Only Query Hint For Faster Read Operations appeared first on Thorben Janssen.


by Thorben Janssen at July 05, 2021 11:45 PM

Hashtag Jakarta EE #79

by Ivar Grimstad at July 04, 2021 09:59 AM

Welcome to the seventy-ninth issue of Hashtag Jakarta EE!

I have previously described how to migrate manually from the javax.* to jakarta.* namespace in this migration guide. While this migration is a pretty easy task, it can be time-consuming and error-prone. But don’t despair, the community is coming to your help by providing tools that can do this for you, or at least assist you in the process. Just take a look at these:

The Tomcat Migration Tool for Jakarta EE provides easy-to-use command-line tooling for transforming Jakarta EE applications on the javax.* namespace over to jakarta.*. You can choose between two profiles depending on whether you are using the Jakarta EE APIs supported by Apache Tomcat, or the entire suite of specifications.

The Eclipse Transformer also provides transformation of Jakarta EE applications on the javax.* namespace to jakarta.*. It can operate on source files as well as class files and has an extensive set of configuration options. The Eclipse Transformer can also be used as a custom class loader, so it can perform the transformation at runtime.

In the upcoming 2021.2 version of IntelliJ IDEA, there will be built-in support for migrating from javax.* to jakarta.*. Check out Automatic migration from Java EE to Jakarta EE for a description of the functionality. If you look closely, you will notice that the sample application they are using is my Complete Duke application that I use to demo the namespace change. You can find it, and others in my Jakarta EE Duke sample projects. It is awesome that the folks at JetBrains found my demo app useful enough to use for showcasing this feature!

As I mentioned above, the Eclipse Transformer provides custom classloader capabilities so the namespace migration can be done at runtime. Many of the Jakarta EE implementations are using this technology in the Jakarta EE 9 and Jakarta EE 9.1 compatible products. I have included an example here of how you can run a Jakarta EE 8 application transformed to Jakarta EE 9.1 and packaged in a WildFly bootable JAR.


by Ivar Grimstad at July 04, 2021 09:59 AM

The Payara Monthly Catch: June 2021

by Priya Khaira-Hanks at July 02, 2021 09:00 AM

June has been another busy month here at Payara Services, both internally - with our biggest yearly company event, Payara Week, taking place - and externally - with our 'Dismiss the Myths' Webinar series kicking off and proving to be one of our most popular community events yet. 

We're halfway through 'Dismiss the Myths: Get to Know Jakarta EE (Java EE)' , a series of 6 webinars where our CEO and Founder Steve Millidgedismantles common misconceptions one by one. Check out thisblog for links to watch webinars that have already taken place, and sign up to the next three! 

As for Payara Week, you may have seen the social media content around our team-building, future-planning, fun-having annual company summit - this time virtual, but no less engaging! We'll be following up with a full blog with pictures and details, but peek at one of the reimagined Payara Fishes from the week's photo competitions below. 

We also got a Twitter blue-tick this month - proving once and for all that we are 'authentic, notable and active' - in our case, when it comes to providing top Jakarta EE and Java EE, MicroProfileand cloud content!

Momentum also continued to grow for our next-generation cloud native application runtimePayara Cloud, with key influencer Adam Bien presenting on it as an alternative toHelidon and Quarkus at the j4k conference. You can find out what he already had to say in his initial trial of the product here. 

But it hasn't all been 'the Payara Show'. We've also searched for and shared the best tutorials, updates, news, articles and videos from our wider community - find them below! 


by Priya Khaira-Hanks at July 02, 2021 09:00 AM

Migrating from JPA 2.x to 3.0

by Thorben Janssen at June 30, 2021 12:00 PM

The post Migrating from JPA 2.x to 3.0 appeared first on Thorben Janssen.

I recently got a lot of questions about JPA 3.0, and since EclipseLink and Hibernate now offer full support for it, it’s time to take a closer look at the latest update of the specification. As part of the transformation from Java EE to Jakarta EE, the Java Persistence API (JPA) was renamed to Jakarta […]

The post Migrating from JPA 2.x to 3.0 appeared first on Thorben Janssen.


by Thorben Janssen at June 30, 2021 12:00 PM

Is Java EE Outdated and Dead? Watch The Video.

by Priya Khaira-Hanks at June 30, 2021 09:00 AM

We are almost halfway through our summer webinar series! Across 6 online events, our CEO and FounderSteve Millidgeis discussing common misconceptions aroundJava. He's broken down false views of the programming language, and its enterprise-orientated iteration Jakarta EE, into 6 topics - tackling them one by one and showing that Java is still relevant. 

Each session is concise - around 30 minutes - and you don't need any previous knowledge of Java or Jakarta EE. 


by Priya Khaira-Hanks at June 30, 2021 09:00 AM

Hashtag Jakarta EE #78

by Ivar Grimstad at June 27, 2021 09:59 AM

Welcome to the seventy-eighth issue of Hashtag Jakarta EE!

Summer is here (at least for those of us located in the Northern hemisphere…) and things are slowing down a little everywhere. But, the Jakarta EE Platform project continues to check items off the list preparing for Jakarta EE 10.

In our last call, we summarized the vote we have had running on the public mailing list regarding which version of Java SE to use the base for Jakarta EE 10. The preferred selection by the community (committers and non-committers) was the one labeled “Option 1”. This option establishes Java SE 11 as the base for Jakarta EE 10. That means that the Jakarta EE APIs will be able to take advantage of up-to Java SE 11 language features and the API JARs will be compiled to Java SE 11 byte code level.

The option also states that the TCK should be able to test runtimes that are using any Java SE level of 11 and above. This is actually the most interesting part for Jakarta EE application developers. As long as the implementation of my choice is offering to run on e.g. Java SE 17, I can use all the Java SE 17 features I want in my application. The fact that the APIs are compiled with Java SE 11 and aren’t exposing any language features above 11, does not really affect me that much.

It is really a win-win since it allows more conservative organizations to stay on Java SE 11 for as long as they wish while the ones more eager to stay up-front can move on to Java SE 17 and above.

Do check out the meeting minutes from our weekly platform calls, and don’t forget to subscribe to the platform project mailing list if you want to participate in these discussions.


by Ivar Grimstad at June 27, 2021 09:59 AM

Maven Contribution – Second Attempt! | The Two Minutes Tuesday 026 | Java Live Coding

by Markus Karg at June 22, 2021 09:00 PM

The story continues! Back in April, Andres hacked a Maven Shade Plugin in #ToniteWithMe, and I reported that the Maven guys did not want to merge it. Time to make some adjustments! So next Friday in the next live show, Andres Almiray will be back and implement all the changes the Maven guys want to have. So be with us, when Andres and me are LIVE HACKING Maven’s source code AGAIN on this Friday’s Live Show #ToniteWithMe on 20:00 CET right here on this channel!

If you like this video, please give it a thumbs up, share it, subscribe to my channel, or become my patreon https://www.patreon.com/mkarg. Thanks! 🙂

CU!


by Markus Karg at June 22, 2021 09:00 PM

Hibernate’s Query Plan Cache – How It Works and How to Tune It

by Thorben Janssen at June 22, 2021 12:24 PM

The post Hibernate’s Query Plan Cache – How It Works and How to Tune It appeared first on Thorben Janssen.

Hibernate’s Query Plan Cache speeds up the preparation of your queries. That reduces their overall execution time, and improves the performance of your application. In the test scenario of this article, it improved the performance of the query preparation by up to 500%. To make it even better, Hibernate does all of that automatically. The […]

The post Hibernate’s Query Plan Cache – How It Works and How to Tune It appeared first on Thorben Janssen.


by Thorben Janssen at June 22, 2021 12:24 PM

Create a Jakarta EE 8 Web App with Payara Server and Your Favorite IDE

by Debbie Hoffman and Rudy De Busscher at June 22, 2021 09:44 AM

 

Payara Server works well with most IDEs, including four of the most commonly used IDEs for Jakarta EE developers: NetBeans, Eclipse IDE, IntelliJ IDEA Ultimate, and Visual Studio Code. Here's how to use each of the IDEs to create a Jakarta EE 8 Web App with Payara Server:


by Debbie Hoffman and Rudy De Busscher at June 22, 2021 09:44 AM

Hashtag Jakarta EE #77

by Ivar Grimstad at June 20, 2021 09:59 AM

Welcome to the seventy-seventh issue of Hashtag Jakarta EE!

The 2021 JVM Ecosystem Report by Snyk was published this week. The focus of the report is on the most important aspects for Today’s JVM developers. The report shows that Java SE 11 is the dominant version of Java in production environments. It is good to see that the industry is moving past Java SE 8. This is also great input to the decision on what Java SE version to use as a baseline for Jakarta EE 10. The report also touches on application frameworks. Jakarta EE (and Java EE) is doing very well with a market share of 12.7% and 24.2% respectively.

The article Java EE and Jakarta EE: What IT leaders should know in The Enterprisers Project highlights how Jakarta EE helps bridge old and new technologies in hybrid cloud environments.

On Tuesday, June 24, I will be presenting Beyond Jakarta EE 9.1 at jOnConf 2021. At the end of the day, I will be participating in a panel with the topic Software Architectures: Enterprise Java.

Eclipse GlassFish 6.2.0 was released this week! This version includes Eclipse Krazo, which means that Jakarta MVC is supported out of the box. A huge milestone for Jakarta MVC!


by Ivar Grimstad at June 20, 2021 09:59 AM

Hibernate Proxies – Why they’re used and how to unproxy them

by Thorben Janssen at June 15, 2021 11:31 AM

The post Hibernate Proxies – Why they’re used and how to unproxy them appeared first on Thorben Janssen.

Hibernate generates proxies to provide lazy loading for to-one associations, and you can use them to improve the performance of some of your write operations. You might have seen the class names of these proxies in your debugger or some log messages. They consist of the name of your entity class and a postfix that […]

The post Hibernate Proxies – Why they’re used and how to unproxy them appeared first on Thorben Janssen.


by Thorben Janssen at June 15, 2021 11:31 AM

Demystifying Java SE Level for Jakarta EE

by Ivar Grimstad at June 14, 2021 09:13 AM

As I mentioned in Hashtag Jakarta EE #76, the Jakarta EE Platform project is in the process of determining the Java SE requirements for Jakarta EE 10. In this post, I try to shed some light on the implications of the various options currently up for a vote. What do these options actually mean for:

a) the Jakarta EE API developers
b) the vendors/projects implementing Jakarta EE specifications, and
c) the application developers.

I have discussed the options and the implications for these three groups below.

Option 1: source=Java SE 11, bin=Java SE 11, TCK=Java SE 11+

Java SE 11 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 11 or higher.

a) API developers are restricted to the language features in Java SE 11. This means that features such as Records can not be used in the APIs. The API JARs must be compiled to Java SE 11 class level.

b) Implementors can implement their compatible implementations using any language features from any Java SE version. They may choose to certify using any version from 11 and higher. For example, a vendor may choose to support only Java SE 17 and higher if they wish. Or they may choose to support any Java SE version from 11 and higher.

c) Application developers can develop their applications using any language features from any Java SE version. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like. However, some mapping, or conversion, may be needed when interacting with the Jakarta EE APIs. The upper limit of the Java SE version will depend on what version their selected implementation (runtime) supports.

Option 2: source=Java SE 11, bin=Java SE 17, TCK=Java SE 17+

Java SE 11 as source/language level and Java SE 17 as the binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.

a) API developers are restricted to the language features in Java SE 11. This means that features such as Records can not be used in the APIs. The API JARs must be compiled to Java SE 17 class level.

b) Implementors can implement their compatible implementations using any language features from any Java SE version. They have to certify using Java SE 17 or higher.

c) Application developers can develop their applications using any language features from any Java SE version. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like. Some mapping, or conversion, may be needed when interacting with the Jakarta EE APIs.

Option 3: source=Java SE 17, bin=Java SE 17, TCK=Java SE 17+

Java SE 17 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.

a) API developers can use any language features from any Java SE version. This means that features such as Records can be used in the APIs. The API JARs must be compiled to Java SE 17 class level.

b) Implementors can implement their compatible implementations using any language features from any Java SE version. They have to certify using Java SE 17 or higher.

c) Application developers can develop their applications using any language features from any Java SE version. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like.

Conclusion

As an application developer, I would always want to use the highest version of Java SE possible, so option 3 would be my obvious choice. However, should I think as a vendor with an existing customer base, I would probably prefer option 1. This option offers full flexibility. I could please my more slow-moving customers by certifying on 11. In addition to that, I could also certify on 17 and thereby please the more impatient developers. It would also enable me to offer an upgrade path for the existing customers from 11 to 17, ensuring them that the future is bright for them as well. Option 2 doesn’t make sense to me at all. Why should the API developers be restricted to 11 language features, but required to compile to 17? And everyone else are required to use 17?

When I think about it, there aren’t that many language features between Java SE 11 and 17 that would make life that much easier for the API developers, except maybe Records that would make sense to build some support around in some of the APIs. But I don’t think that justifies the cost of leaving so many users of the technology behind as many of them are still on Java SE 8. Java SE 17 could be the baseline for Jakarta EE 11, which would allow the API developers time to let the best idioms for the newer language features be established before adding them to the specifications.

So, if you’ve read this far, you’ve probably also guessed that my favorite is Option 1.


by Ivar Grimstad at June 14, 2021 09:13 AM

New Webinar Series! Dismiss the Myths: Get to Know Jakarta EE

by Priya Khaira-Hanks at June 14, 2021 09:08 AM

Last week, we announced our exciting new webinar series, 'Dismiss the Myths: Get to Know Jakarta EE (Java EE). This is a series of 6 webinars, every Wednesday at 3.00pm BST for the next 6 weeks - with the first one taking place this Wednesday! 

Our CEO and FounderSteve Millidge is leading this series, taking one common misconception about Jakarta EE ( previously Java EE ) at a time. Turns out, you might be wrong in thinking Java is behind the times...

This is also the perfect webinar series if you have heard Jakarta EE or Java EE mentioned but aren't sure what it is, what the namespace change means or where its future lies. Steve will be catering to users who are new to the technology as well as long-time Jakarta EE developers. 


by Priya Khaira-Hanks at June 14, 2021 09:08 AM

Hashtag Jakarta EE #76

by Ivar Grimstad at June 13, 2021 09:59 AM

Welcome to the seventy-sixth issue of Hashtag Jakarta EE!

One of the goals for the Jakarta EE Platform project is to define a predictable way the Jakarta EE specifications are aligned with Java SE. For example: Which Java SE version should Jakarta EE 10 require? This is one of the questions currently being discussed on the weekly Jakarta EE Platform calls. We have narrowed it down to three options that are currently being voted on:

Option 1: source=Java SE 11, bin=Java SE 11, TCK=Java SE 11+
Java SE 11 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 11 or higher.

Option 2: source=Java SE 11, bin=Java SE 17, TCK=Java SE 17+
Java SE 11 as source/language level and Java SE 17 as the binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.

Option 3: source=Java SE 17, bin=Java SE 17, TCK=Java SE 17+
Java SE 17 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.

Everyone is encouraged to chime in on the mailing list with their opinion. Remember to mark the committer flag in your vote to true only if you are a committer on the Jakarta EE Platform project.

The intention of the Jakarta EE Core Profile specification is to target smaller runtimes and allow them to be certified as Jakarta EE compatible products. The set of Jakarta EE specifications that will be included in the profile has not been defined yet, but here is the latest suggestion for how it could potentially look like.

Do check out the Dismiss the Myths: Get to know Jakarta EE (Java EE) webinar series from Payara to get some common myths dismissed. Among other things, you will experience that Java is highly relevant, and keeps up-to-date with the changes in the IT world. And that there is a bright future for Jakarta EE!

The Call for Proposals for EclipseCon 2021 ends on Tuesday, June 15, so there is still time for you to submit your Jakarta EE talk to have a chance of being a speaker!


by Ivar Grimstad at June 13, 2021 09:59 AM

TYPE-SAFE Generic Java Annotation Parameters | Modern Java | Head Crashing Informatics 33

by Markus Karg at June 12, 2021 03:00 PM

#Java’s Annotation Parameters are a great way to configure strategies in a declarative way, but how to do that in a TYPE-SAFE manner using #Generics? I nearly drove nuts to find a good example for you on the web, and ended up finally recording this video tutorial in the hope that it is beneficial to you.

Please share this video with all Java programmers you do know, so they will have the final solution at hand once they need it!

If you like this video, please give it a thumbs up, share it, subscribe to my channel, or become my patreon https://www.patreon.com/mkarg. Thanks! 🙂

Stay safe and… Party On!


by Markus Karg at June 12, 2021 03:00 PM

Jakarta EE Application Deployment to Kubernetes Cluster in Jelastic PaaS

by Tetiana Fydorenchyk at June 09, 2021 08:09 AM

Recently, we were asked to sponsor cloud hosting of a Jakarta EE project, called Cargo Tracker. Being a member of Jakarta EE Working Group, Jelastic wanted to support the community and thus we started to run this application at one of our service providers (Scaleforce). In this article, we would like to show how to deploy such Jakarta EE projects to Kubernetes cluster within Jelastic PaaS using Cargo Tracker as an example.

by Tetiana Fydorenchyk at June 09, 2021 08:09 AM

Boosting InputStream::transferTo Performance | The Two Minutes Tuesday 025 | Java Inside

by Markus Karg at June 08, 2021 09:00 PM

As I explained in a recent video (https://youtu.be/qgDfZgreN40), InputStream::transferTo() is the most comfortable way to tell java we want to transfer the remaining content of one stream into another stream, but that it apparently is the slowest one, too! The reason is scary, as you will see in this inside look under OpenJDK’s hood. But rescue is on the way! I have filed a PR with #OpenJDK to make it lightning fast: https://github.com/openjdk/jdk/pull/4263.

If you like this video, please give it a thumbs up, share it, subscribe to my channel, or become my patreon https://www.patreon.com/mkarg. Thanks! 🙂

CU!


by Markus Karg at June 08, 2021 09:00 PM

Jakarta EE Community Update May 2021

by Tanja Obradovic at June 08, 2021 03:21 PM

The month of May was very busy with activities related to Release 9.1! Jakarta EE development and innovation is definitely taking off with full speed. I would like to take this opportunity and invite you all to join the momentum, please get involved and help contribute to the future success of Jakarta EE.

The highlights in May 2021 are as follows:

Jakarta EE 9.1 released May 25th! 

After only six months of the Jakarta EE 9.0 release, the Jakarta EE Working Group has released Jakarta EE 9.1. As requested by the community, the main driver for this release is Java SE 11 support. The additional importance of this release is the fact that we, for the very first time, have multiple compatible products at the time of the release.

Please visit Jakarta EE 9.1 release page, and review all the available compatible products and proceed to the compatible products download page.

For more information please refer to the press release: The Jakarta EE Working Group Releases Jakarta EE 9.1 as Industry Continues to Embrace Open Source Enterprise Java

 

The Jakarta EE community and Working Group is growing

 It is great to see new members continuously joining the Working Group.

This month I am very happy to welcome Apache Software Foundation (ASF) as a guest member of the Jakarta EE Working Group! I strongly believe that ASF does not need any introduction. However, I want to put emphasis on the importance of Apache Tomcat and Apache TomEE to the Jakarta EE ecosystem. Note that Apache TomEE 9.0.0-M7 is now a Web Profile Jakarta EE 9.1 Compatible Product.

I am also very excited to see another member in China, Beijing Baolande Software Corporation joining the Jakarta EE Working Group! Beijing Baolande Software Corporation develops and sells middleware software, cloud management platform software, and application performance management software. The Company develops and sells application server software, transaction intermediate software, cloud management platform, and other products. Beijing Baolande Software provides related technical services.

SouJava, a Brazilian Java User Group,  involvement in Jakarta EE is well known, as their members are actively involved in Jakarta EE projects and community events. 

SouJava's members are heavily involved with Jakarta EE Specifications and are members of Adopt-A-Spec program for the following specifications

 - Jakarta MVC

 - Jakarta NoSQL

 - Jakarta RESTful Web Services

 - Jakarta Persistence

SouJava was involved in organizing JakartaOne Livestream Brazil 2020 event and is now involved in organizing JakartaOne Livestream Portuguese 2021.

This is a call to other JUGs to explore the possibility of joining Jakarta EE Working Group. Approach us and let us know if membership is something you would be interested in.

 

JakartaOne Livestream events for the rest of the year!

Our popular JakartaOne Livestream virtual conference series for the rest of the year is scheduled. We are having language specific events as well as our annual JakartaOne Livestream 2021 in English.

Please save these dates:

  • August 21st, 2021 if you speak Turkish, here is an event for you: JakartaOne Livestream - Turkish

  • September 29th, 2021 if you speak Portugese, this one's for you: JakartaOne Livestream - Portugese

  • October 1st, 2021 if you speak Spanish, keep an eye for the website for  JakartaOne Livestream - Spanish

  • December 7th, 2021 is reserved for our annual event in English! JakartaOne Livestream 2021


Jakarta EE 10 is taking shape!

I am beyond excited to see all the progress we see related to Jakarta EE 10 in GitHub (label EE10).  The creation/plan review for Jakarta EE Core Profile 10 was approved by the Jakarta EE Specification Committee. Jakarta EE Web Profile 10 and Jakarta EE Platform 10 issues are in discussion and plan reviews are expected soon. Please join the discussion and Jakarta EE Platform call to provide your input, refer to  Jakarta EE Specifications Calendar (public url, iCal)  for details on all technical calls.

 

Jakarta EE Individual Specifications and project teams 

We have organized a public calendar Jakarta EE Specifications Calendar (public url, iCal) to display all Jakarta EE Specification project teams meetings. Everyone interested is welcome to join the calls. Do note that the Jakarta EE Platform team is extremely busy and productive. The call is public and is welcome to all people who would like to contribute to technical discussions.

Individual specifications are planning their next release. You can review all the plans submitted for review, some are still open and quite a few are closed, here. I would like to draw your attention to a new specification, Jakarta Config:

“Jakarta Config is a Java API for working with configurations. It supports externalized configuration allowing applications to use different configurations for different environments (dev, test, prod), and allows reading data from different layered configuration sources such as property files, environment variables, etc.”

Select the one that you are interested in and help out. Each specification team is eager to welcome you! 

 

Want to learn how to use Jakarta EE?  

The Eclipse Cargo Tracker is a fantastic example of an end-to-end Jakarta EE application that showcases core Jakarta EE technologies. Thanks to Scaleforce and Jelastic for providing resources to deploy the demo application to the cloud.

Give the Cargo Tracker a try and consider contributing to the project at Cargo Tracker GitHub repository.

 

Hibernate as compatible Jakarta Persistence implementation

More exciting news about compatible implementations of individual specifications! Well known object relational mapping tool Hibernate, is implementing Jakarta Persistence specifications!

The latest stable version of Hibernate 5.5, is a compatible implementation of Jakarta Persistence 3.0 and Jakarta Persistence 2.2

 

EclipseCon 2021 CFP is open till June 15!

Mark your calendars: EclipseCon 2021 is taking place October 25th - 27th 2021! The call for papers is open for another week! We are looking forward to your submission. You can see accepted talks here


Book your 2021 Jakarta EE Virtual Tour and Adopt-A-Spec

We are looking for the opportunity to virtually visit you, so don’t hesitate to get in touch (tanja.obradovic@eclipse-foundation.org) if you’d like to hear about Jakarta EE 9.1 and beyond.

We need help from the community! All JUGs out there, please choose the specification of your interest and adopt it. Here is the information about the Adopt-A-Spec program. 

 

______________________________

Stay Connected With the Jakarta EE Community

The Jakarta EE community is very active and there are a number of channels to help you stay up to date with all of the latest and greatest news and information. Subscribe to your preferred channels today:

·  Social media: Twitter, Facebook, LinkedIn Group, LinkedIn Page

·  Mailing lists: jakarta.ee-community@eclipse.org, jakarta.ee-wg@eclipse.org, project mailing lists, slack workspace

·  Calendars: Jakarta EE Community Calendar, Jakarta EE Specification Meetings Calendar 

·  Newsletters, blogs, and emails: Eclipse newsletter, Jakarta EE blogs, Hashtag Jakarta EE

·  Meetings: Jakarta Tech Talks, Jakarta EE Update, and Eclipse Foundation events and conferences

You can find the complete list of channels here.

To help shape the future of open source, cloud native Java, get involved in the Jakarta EE Working Group.

To learn more about Jakarta EE-related plans and check the date for the next Jakarta Tech Talk, be sure to bookmark the Jakarta EE Community Calendar.

We always welcome your feedback!


by Tanja Obradovic at June 08, 2021 03:21 PM

Hibernate’s @Filter Annotation – Apply Dynamic Filters at Runtime

by Thorben Janssen at June 08, 2021 09:06 AM

The post Hibernate’s @Filter Annotation – Apply Dynamic Filters at Runtime appeared first on Thorben Janssen.

Hibernate provides 2 proprietary features that enable you to define additional filter criteria that Hibernate applies to every query that selects a specific entity class. This article will show you how to use the @FilterDef and @Filter annotations, which is the more flexible approach. You can activate and deactivate filter definitions for your current session […]

The post Hibernate’s @Filter Annotation – Apply Dynamic Filters at Runtime appeared first on Thorben Janssen.


by Thorben Janssen at June 08, 2021 09:06 AM

Hashtag Jakarta EE #75

by Ivar Grimstad at June 06, 2021 09:59 AM

Welcome to the seventy-fifth issue of Hashtag Jakarta EE!

The Jakarta EE Platform project does not rest on its laurels! Vivid discussions are going in the weekly platform calls as well as on the mailing lists. Read the minutes from the platform calls to keep informed in case you are not able to join the calls.

Talking about keeping up-to-date, I will be speaking at J4K this week. My talk, Jakarta EE Core Profile – A Slimmer Jakarta EE, is about the Jakarta EE Core Profile which you may say is very much a work-in-progress. This talk will give you the latest status update as well as pointers to how to contribute and influence the direction of the specification.

I am extremely happy to see that Hibernate ORM 5.5.0 is now certified as a compatible implementation of Jakarta Persistence! They have passed the TCKs for both Jakarta Persistence 2.2 and Jakarta Persistence 3.0 which means that they are aligned with both Jakarta EE8 and Jakarta EE 9 supporting both the jakarta.* namespace as well as javax.*. This is an important milestone. Provides a migration path for all those applications out there using Hibernate ORM for persistence.

The Call for Proposals for EclipseCon 2021 ends on June 15, so there is still time for you to submit your Jakarta EE talk to have a chance of being a speaker!

The planning for JakartaOne LiveStream 2021 has just started. Mark December 7, 2021 in your calendar today. More details and dates for the Call For Paper will be announced shortly. Stay tuned!


by Ivar Grimstad at June 06, 2021 09:59 AM

The Payara Monthly Catch for May 2021

by Priya Khaira-Hanks at June 01, 2021 09:58 AM

The big community news of this month was the release of Jakarta EE 9.1! The Eclipse Foundation brought out Jakarta EE 9.1 Platform and Web Profile specifications and related TCKs - the first release since the breaking namespace change to jakarta. We've rounded up our articles & announcements on this subject below - and watch this space, as Payara Platform is very close to launching our own Compatible Implementation. 

We also released the results of our Payara Platform Survery 2021 . Read in fullhere, including what we've learnt about the infrastructure you are using with the Payara Platform, what features you want to see, and our findings on how our users are adopting MicroProfileAPIs and new Jakarta EE versions. 

We're already using the results of the survey to shape content that responds to recurring issues users are encountering. See Rudy'sblog on why you might be finding Payara Server slow and an easy fix you may not have tried, as issues with deployment speed was a common theme in our survey results. 

As well as Payara's own content, the 'Monthly Catch' also includes our pick of the best from Java EE/Jakarta EE, MicroProfile, Java SE and DevOps influencers and authors this month, and wider industry news. We hope you enjoy, and make sure you are following us onLinkedIn and Twitter, and signed up to our blog, to get this content as it comes! 


by Priya Khaira-Hanks at June 01, 2021 09:58 AM

Java File I/O Performance Shootout | Modern Java | Head Crashing Informatics 32

by Markus Karg at May 29, 2021 03:00 PM

Java’s way to access files changed a lot in past generations, and as files play an essential role in many #Java applications, it is time to look into the #Performance of the different API’s available for #FileIO: How does good old FileInputStream compare to current Java’s Files.copy()? Is it worth backporting new APIs into existing legacy applications?

In this video, you learn how to precisely measure performance using the #JavaMicrobenchmarkHarness (JMH), and how scaring the access times of some APIs in fact are. And certainly, what the fastest and most comfortable ways are to access files in Java. And last but not least, that OpenJDK contains a real performance bummer! 

If you like this video, please give it a thumbs up, share it, subscribe to my channel, or become my patreon https://www.patreon.com/mkarg. Thanks! 🙂

Stay safe and… Party On!


by Markus Karg at May 29, 2021 03:00 PM

GlassFish 6.1 Should Not Be Used In Production: Here’s Why

by Rudy De Busscher at May 27, 2021 10:33 AM

Earlier this week, Jakarta EE 9.1 was released. This is an update to Jakarta EE 9, adding support for JDK 11 - you can read more about it in our bloghere.

Alongside the Jakarta EE 9.1 release, GlassFish 6.1 has been released as a Compatible Implementation

However, although GlassFish is still used by many - a legacy of the time it was supported by Oracle - we would argue it is NOT a good choice for running your enterprise applications in production.

If you are considering updating to more recent GlassFish versions, it might be better to consider more reliable, supported, and up-to-date alternatives. In this blog, I explain why GlassFish 6.x is not the best choice for your mission critical deployments.


by Rudy De Busscher at May 27, 2021 10:33 AM

Jakarta EE 9.1 Accelerates Open Source Enterprise Java

by Mike Milinkovich at May 26, 2021 11:05 AM

Just a little more than five months ago, I was sharing news about the Jakarta EE 9 platform release. Today, I’m very pleased to tell you that the Jakarta EE Working Group has released the Jakarta EE 9.1 Platform and Web Profile specifications and related Technology Compatibility Kits (TCKs). Congratulations and thanks to everyone in the Jakarta EE community who made this release possible.

The accelerated innovation we’re seeing in Jakarta EE, and the growing number of compatible implementations, are clear signs that enterprise Java is experiencing a renaissance.

Enterprises Have New Agility to Develop and Evolve Java Applications

Jakarta EE 9 opened the door to the next era of innovation using cloud native technologies for Java by delivering the “big bang” namespace change to jakarta.*. 

Jakarta EE 9.1 takes that rejuvenation to the next level. The release includes a number of updates and new options, and is compatible with Java SE 11, which is seeing increasing adoption. The 2020 Jakarta EE Developer Survey revealed that 28 percent of respondents were using Java SE 11, compared to 20 percent of respondents in 2019.

Together, the advances in Jakarta EE 9.1 give enterprises the flexibility to make more choices, and to mix and match technologies as needed to meet their unique application development and migration requirements. With Jakarta EE 9.1, enterprises can:

  • Develop and deploy Jakarta EE 9.1 applications on Java SE 11, the most current LTS release of Java SE, as well as Java SE 8
  • Leverage Java SE 11 features that have been added since Java SE 8 in their Jakarta EE 9.1 applications 
  • Take advantage of new technologies that support Java SE 11 in their Jakarta EE 9.1 applications
  • Move existing Jakarta EE 9 applications to Java SE 11 without changes
  • Migrate existing Java EE and Jakarta EE 8 applications to Jakarta EE 9.1 using the same straightforward process available for migration to Jakarta EE 9

With a variety of paths to choose from, every enterprise can develop and migrate Java applications in a way that aligns with their technical objectives and business goals.

There Are Already Five Jakarta EE 9.1-Compatible Applications

As we announce Jakarta EE 9.1, five products from global leaders in the Java ecosystem have already been certified as compatible with the release:

  • IBM’s Open Liberty
  • Eclipse Glassfish
  • Apache TomEE
  • Red Hat’s Wildfly
  • ManageCat’s ManageFish

These implementations are proof positive the Java ecosystem recognizes the value Jakarta EE brings to their business and the technologies they develop.

The rapid technology adoption we’re seeing with Jakarta EE is thanks to the openness of  the Jakarta EE Specification Process. This simplified process dramatically lowers the barrier to entry, making it much easier for organizations of all sizes to have their products certified as a compatible implementation and leverage the Jakarta EE brand for their own business success.

The number of compatible implementations across Jakarta EE releases is growing all the time, so be sure to check the Jakarta EE compatible products webpage for the latest list. To be listed as a Jakarta EE-compatible product, follow the instructions here.

Learn More About Jakarta EE 9.1 and Get Involved

To learn more about the Jakarta EE 9.1 release contents, read the Jakarta EE 9.1 release plan and check out the specifications.

As the focus shifts to Jakarta EE 10, the Jakarta EE Working Group and community welcome all organizations and individuals who want to participate. To learn more and get involved in the conversation, explore the benefits of membership in the Jakarta EE Working Group and connect with the community.


by Mike Milinkovich at May 26, 2021 11:05 AM

Open Liberty beta is Jakarta EE 9.1 compatible

May 26, 2021 12:00 AM

JakartaEE Logo Compatible color

This blog post serves as a follow-up to my last blog post about Open Liberty’s support of Jakarta EE 9.0. Over the last several months, the Jakarta EE community has updated the Jakarta EE 9 TCK to enable it to use either Java SE 8 or Java SE 11. This new version of the TCK was the bulk of the work required to complete the Jakarta EE 9.1 specification. Java SE 11 support in the TCK makes it possible to validate whether an application server that uses Java SE 11 is compatible with the Jakarta EE 9 specification.

The Jakarta EE 9.1 specification was made available this week. On day one of this new release, Open Liberty is one of the vendor implementations used to ratify the specification. The Open Liberty product is compatible for both the Jakarta EE 9.1 Web Profile and Platform specifications using both Java SE 8 and Java SE 11. What is most notable is that Open Liberty was ahead of the curve for Jakarta EE 9.1. The Open Liberty beta version that was tested with the 9.1 TCK is the same version that was marked compatible for the Jakarta EE 9.0 specification. As I stated in my previous blog post, Jakarta EE 9.1 support was anticipated due to Open Liberty’s support of Java SE 11 for over two years.

Since my last blog post, more resources are available to help you make the transition to Jakarta EE 9. A blog post with detailed instructions on using the Eclipse Transformer was created a few months ago to help guide you when updating your applications to work with Jakarta EE 9. Also, this presentation provides more details about Jakarta EE 9 and Open Liberty, including a live demo of using the Eclipse Transformer to update your applications and server configurations without doing any manual changes to source or configuration.


May 26, 2021 12:00 AM

Stuttering Performance! | The Two Minutes Tuesday 024 | Informatics

by Markus Karg at May 25, 2021 09:00 PM

Ever wondered why #performance is not scaling linear, but more like in steps? This episode of #TheTwoMinutesThuesday explains why!

Watching your computer copying large files you will notice that the overall progress is everything but smooth nor linear! Some data blocks seem to be transferred faster than others. The reason for this encountered phenomenon lies in #ComputerEngineering: Data is transported in blocks, blocks need to be found on disk, fill up caches, and take time to be flushed!

If you like this video, please give it a thumbs up, share it, subscribe to my channel, or become my patreon https://www.patreon.com/mkarg. Thanks! 🙂

CU!


by Markus Karg at May 25, 2021 09:00 PM

Jakarta EE 9.1 Launches!

by Priya Khaira-Hanks at May 25, 2021 11:06 AM

Payara Services are celebrating the release of Jakarta EE 9.1 Platform and Web Profile specifications and related TCKs.

With Jakarta EE 9.1, global source community Eclipse Foundation brings to Java developers the first incremental Jakarta EE release since the new namespace was introduced last year. Read the Eclipse Foundation announcement here - featuring a quote from our Founder and CEO Steve Millidge.

Payara's team have not only worked hard to ensure Jakarta EE 9.1 applications can be run in Payara Platform 5, but Payara Platform 6 alpha one is very close to being ready as a Compatible Implementation. Watch this space! 


by Priya Khaira-Hanks at May 25, 2021 11:06 AM

Apache TomEE Jakarta EE certified after 10 years

by David Blevins at May 25, 2021 10:53 AM

We are extremely excited to spread the word that Apache TomEE 9.0.0-M7 has reached Jakarta EE 9.1 Web Profile certification.

Speaking with our Apache-contributor hats on, this is not just our first certification in 10 years, but we are doubly proud Apache TomEE is on the list of certified servers on the day of the Jakarta EE release. Moreover, after 3 years of behind-the-scenes work, we’re very excited the Apache Software Foundation has joined Jakarta EE Working Group as a Guest Member. And finally, not to be overlooked, the Apache TomEE project has a fresh new website:

https://tomee.apache.org/

As many of us in Tomitribe were there at the beginning in 2011, hacking on TomEE’s Java EE 6 Web Profile certification in our spare time and taking vacations from work to travel and hack together, we couldn’t be more proud. It felt like old times. Even down to the 20 hour days, sleep deprivation and adrenaline rush you get when you know you’re kicking butt.

Why 10 years?

Apache had a 10-year license to Java EE that expired in 2013 about 2 months before the release of Java EE 7. Because of the legal situation around Apache Harmony, not getting a Java SE TCK license and Apache leaving the JCP, Apache was not willing to sign again with the contracts as they were. Several of us in Apache including Dan Kulp (CXF), Mark Thomas (Tomcat) and myself worked with Cameron Purdy (then SVP of Development at Oracle) for 2 years to come up with a Java EE license agreement both Apache and Oracle would sign. I posted in May 2015 that I thought were close, detailing all progress to date. Unfortunately, Cameron and Oracle parted ways in August 2015 and not only did our progress stop, but so did Java EE. Our fight to get a TCK became a fight to save Java EE.

We’re all familiar with the story from here. The industry started to notice the lack of work being done, groups were formed such as the Java EE Guardians, MicroProfile was launched, Java EE 8 was announced as back-on 3 days later, and Java EE 8 was released in August of 2017. After 2 years of fighting alongside many others and co-founding MicroProfile, Java EE was saved. However, while the industry enjoyed the victory, things for Apache were still the same or worse; Apache still had no TCK license, 4 years had gone by and TomEE was now two major versions behind with no way to catch up. Tomitribe bought a Java EE TCK license, but with no way to share it with Apache it just didn’t have the impact we hoped.

Needless to say that when Oracle announced Java EE would be open sourced, Tomitribe was 100% in as it was our best chance to restore Apache’s TCK access and get back on track. We were extremely aggressive as we knew we had just one shot to get it right. We rallied the community around the Jakarta EE name, acquired the jakarta.ee domain, twitter handle, github org, Facebook id, etc. We played key roles in establishing the TCK certification process, release PR process, system to sign the binaries, and designed the Jakarta EE Compatible logo. When it was clear we could no longer use the javax namespace we wrote the tools to perform bytecode analysis across all Java EE APIs which was used to inform the final set of options and votes on which namespaces would move to jakarta. We led efforts to get tool vendors to adopt the new namespace and created the jakarta.ee/news/ section used to announce Jakarta EE 9.1.

We’re not alone in our dedication. Payara has led efforts to ensure Eclipse GlassFish is compatible on time for all our releases. Red Hat has taken the mantle of TCK lead. IBM has led the last 3 releases. Oracle has played critical roles in everything, doing their best to enable others. And of course, the Eclipse Foundation and staff who built jakarta.ee, produces all live events, performs countless other jobs, and makes all of this legally possible.

The amount of cooperation, collaboration, and just plain hard work and sacrifice we’ve all made to get to this point is unparalleled. Each of us has a similar story. Jakarta EE is truly a marvel.

Apache is Vital to Jakarta EE’s Diversity

For the 10 years that Apache did have a Java EE TCK license it united forces across the industry. During the Apache Geronimo years we worked hard to ensure there was an Apache implementation of everything Java EE we needed. Many of these are the only other implementations in our industry and without Apache there’d be just one implementation of CDI, Bean Validation, JSF, JSONB, Mail, Activation, and more. In several cases Apache TomEE is the only server out of 16 certified servers to ship them — the other 15 all sharing the same implementation.

If the point of creating specifications and TCKs is to allow for multiple implementations, that makes Apache absolutely critical to Jakarta EE’s mission statement.

It also means we can’t take Apache for granted. You have to contribute to the open source you use. If you don’t it won’t last and you’ll spend the time/energy/resources endlessly migrating between a dwindling number of choices. I have a saying, “If you look at open source and don’t like what you see, remember you’re looking in a mirror.”

Thank You and What’s Next

All of us at Tomitribe would like to thank all the customers who have supported us over the years. These victories are your victories. Be proud of your diverse choices and the impact you’ve made on Apache TomEE and the industry. None of this would have been possible without you.

As for what is next, many of us in Tomitribe are looking forward to shifting our contributions to TomEE’s MicroProfile certification. The MicroProfile 5.0 release will likely be the first under the jakarta namespace and would be a fantastic goal and a great fit with TomEE’s Jakarta EE 9.1 certification.

Above all, we’re thrilled to pick up where we left off in 2013 and the rebirth of TomEE. While some of this post may read as excesses for being “slow”, we see it as the opposite. Jakarta EE 8 was released on September 10th, 2019. That means we and the other Apache contributors were able to recover from 6.5 years of setbacks and close the gap on 3 major Java EE and Jakarta EE versions in 20 months. All while still contributing to Jakarta EE itself and without the benefit of the 15 other Jakarta EE implementations shipping many of the components we ship.

I’d say the accomplishment is nothing short of remarkable.

Please help us celebrate this community achievement the way it deserves and above all, please join us as contributors. We’ll be thrilled to see you.

The post Apache TomEE Jakarta EE certified after 10 years appeared first on Tomitribe.


by David Blevins at May 25, 2021 10:53 AM

The Apache Software Foundation has joined Jakarta EE Working Group

by Tanja Obradovic at May 20, 2021 04:28 PM

I am extremely happy to let you know that The Apache Software Foundation (Apache, ASF) has joined Jakarta EE Working Group! 

Apache needs no introduction, but let me remind everyone about their involvement with Jakarta EE / Java EE  community goes way back, with Apache TomEE and Apache TomCat  implementations. We are looking forward to this, now even tighter, collaboration and all contributions in any / all Jakarta EE related projects and initiatives. Our Jakarta EE members page is now showcasing Apache as well!

Please join me in welcoming the Apache Software Foundation to Jakarta EE Working Group!


by Tanja Obradovic at May 20, 2021 04:28 PM

Getting Started with Jakarta EE 9: Context And Dependency Injection (CDI)

by Rudy De Busscher at May 18, 2021 09:34 AM

In this series about getting started with Jakarta EE 9, we look at various specifications and how you can use them for your next application. In the previous blogs of this series, we set up our development environment and had a closer look at implementing REST endpoints.

This time, I will explain a few features of Context and Dependency Injection (CDI). The CDI specification is an important backbone of Jakarta EE as it brings several specifications together. Over the years, it became more and more important as an increasing number of specifications started using CDI as the basis for it.

In this blog, I will tell a bit about the different scopes, the interceptor mechanism, and the Event system.


by Rudy De Busscher at May 18, 2021 09:34 AM

Request Timing Metrics and new Jakarta EE9 support in Open Liberty 21.0.0.6-beta

May 18, 2021 12:00 AM

Open Liberty 21.0.0.6-beta brings improvements to the MicroProfile Metrics feature, allowing for information gathered via the Request Timing feature to be displayed on the metrics endpoint. Also included are a number of new Jakarta EE9 supporting features, including OAuth/SSO authorization and automatic certificate management.

We have two beta packages for Open Liberty:

  • All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.

  • Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

Request Timing now supported by MicroProfile Metrics

The request timing feature (requestTiming-1.0) is used to keep track of the slow and hung requests for servlet requests with a RequestTimingStats MXBean. The Microprofile Metrics features (mpMetrics-X.X) on the other hand provides vendor metrics that are distinct to the Open Liberty runtime.

Starting with the Open Liberty 21.0.0.6-beta the RequestTimingStats MXBean will now have it’s data retrieved by the MicroProfile Metrics feature for reporting on the /metrics (or /metrics/vendor) endpoint. This functionality is compatible with both the 2.X and 3.X MicroProfile Metrics features.

Below is a sample output of the new request timing metrics:

# TYPE vendor_requestTiming_activeRequestCount gauge
# HELP vendor_requestTiming_activeRequestCount The number of servlet requests currently running.
vendor_requestTiming_activeRequestCount 1

# TYPE vendor_requestTiming_requestCount_total counter
# HELP vendor_requestTiming_requestCount_total The number of servlet requests since the server started.
vendor_requestTiming_requestCount_total 3

# TYPE vendor_requestTiming_hungRequestCount gauge
# HELP vendor_requestTiming_hungRequestCount The number of servlet requests that are currently running but are hung.
vendor_requestTiming_hungRequestCount 0

# TYPE vendor_requestTiming_slowRequestCount gauge
# HELP vendor_requestTiming_slowRequestCount The number of servlet requests that are currently running but are slow.
vendor_requestTiming_slowRequestCount 0

To be able to retrieve request timing metrics from /metrics you will need to enable both the requestTiming-1.0 feature in combination with one of the following MicroProfile Metric features: mpMetrics-2.0, mpMetrics-2.2 or mpMetrics-2.3 or mpMetric-3.0.

To begin recieving metrics you will need to configure the request timing thresholds for slow or hung requests. The following example demonstrates enabling request timing metrics for mpMetrics-3.0, with a sample threshold configuration for both slow and hung servlet requests.

    <featureManager>
      <feature>mpMetrics-3.0</feature>
      <feature>requestTiming-1.0</feature>
      <!-- other features omitted for brevity -->
    </featureManager>

    <requestTiming sampleRate="1" slowRequestThreshold="10s">
      <servletTiming
        slowRequestThreshold="2s"
        hungRequestThreshold="10s"/>
    </requestTiming>

For more information regarding Request Timing with MicroProfile Metrics:

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 16, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.6-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.6-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

As of the 21.0.0.2-beta release, Open Liberty is the first vendor product to be Jakarta EE Web Profile 9.0 compatible. With the Open Liberty 21.0.0.3-beta release, Open Liberty is the first vendor product to be added to the Jakarta EE Platform 9.0 compatibility list.

This Open Liberty beta introduces the following Jakarta EE 9 features which now possess their all-new Jakarta EE 9 package names:

The openidConnectClient-1.0, openidConnectServer-1.0, socialLogin-1.0 and acmeCA-2.0 features will automatically adapt to the level of Java EE or Jakarta EE that is already in use, so no change is needed when using them with Jakarta EE 9.

Enable the Jakarta EE 9 beta features in your app’s server.xml. You can enable the individual features you want or you can just add the Jakarta EE 9 convenience feature to enable all of the Jakarta EE 9 beta features at once:

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

To try out these Jakarta EE 9 features on Open Liberty in a lightweight package, just update your build tools to pull the Open Liberty Jakarta EE 9 Beta Features package instead of the main release. The beta works with Java SE 16, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.6-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.6-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.


May 18, 2021 12:00 AM

LDAP user registry authentication and JAX-RS multipart payloads new in Open Liberty 21.0.0.5

May 14, 2021 12:00 AM

Open Liberty 21.0.0.5 comes complete with a new Kerberos authentication method, allowing for the use of an LDAP user registry to easily and quickly authorize connections originating from the same source. Also included is the ability to create and exchange multipart payloads using JAX-RS clients and services.

In Open Liberty 21.0.0.5:

View the list of fixed bugs in 21.0.0.5.

Run your apps using 21.0.0.5

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>21.0.0.5</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[21.0.0.5,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

LDAP connection support for Kerberos authentication

LDAP bind operations are used to authenticate clients (and the users or applications behind them) to the directory server. This establishes an authorization identity that is used for subsequent operations that are processed on that connection, and specifies the LDAP protocol version that the client uses. Before this update, the LdapRegistry element supported binding either anonymously or by using simple authentication with a user (bindDN) and password (bindPassword). This update adds an option to bind to LDAP: GSSAPI/Kerberos. Kerberos is an authentication mechanism that allows a client and service to mutually authenticate by a Key Distribution Center (KDC). In Open Liberty 21.0.0.5, you can use either a Kerberos credential cache (ccache) or a Kerberos keytab file.

To update an LdapRegistry to use the GSSAPI/Kerberos option, you can set the bind authentication mechanism type using the new LdapRegistry attribute, bindAuthMechanism:

bindAuthMechanism="GSSAPI"

You also need the Kerberos principal or Service Principal Name:

krb5Principal="user1@EXAMPLE.COM"

If you are using a Kerberos credential cache (ticket cache or ccache) to store the Kerberos credentials, add the ticket cache file name to the LdapRegistry with the new attribute, krb5TicketCache:

krb5TicketCache="${server.config.dir}/security/krb5-user1.cc"

If you are using a custom Kerberos configuration file (krb.conf or krb.ini), set the file name using the global Kerberos configuration element:

<kerberos configFile="${server.config.dir}/security/krb5.conf"/>

If you are using a Kerberos keytab file to store encrypted keys for principals, set the file using the global Kerberos configuration element:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf"/>

If the Kerberos configuration file is not defined, Open Liberty will attempt to resolve by using the JDK default locations and the operating system default locations.

For the Kerberos credentials, the locations are checked in the following order: the ticket cache (if provided), the configured keytab file, and finally the JDK default location.

The following example shows how to configure the LdapRegistry element using a ticket cache and custom Kerberos config file:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf"/>

<ldapRegistry id="LDAP" realm="SampleLdapADRealm" host="ldap_hostname" port="389" ignoreCase="true" baseDN="DC=example,DC=com" bindAuthMechanism="GSSAPI" krb5Principal="user1@EXAMPLE.COM" krb5TicketCache="${server.config.dir}/security/krb5-user1.cc" ldapType="Custom" />

The following example shows how to configure an LDAP Registry using a keytab and custom Kerberos config file:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf" />

<ldapRegistry id="LDAP" realm="SampleLdapADRealm" host="ldap_hostname" port="389" ignoreCase="true" baseDN="DC=example,DC=com" bindAuthMechanism="GSSAPI" krb5Principal="user1@EXAMPLE.COM" ldapType="Custom" />

For more information on LdapRegistry, see the LDAP User Registry documentation.

To enable this new function in your app, add the LDAP User Registry 3.0 feature to your server.xml file:

<featureManager>
  <feature>ldapRegistry-3.0</feature>
</featureManager>

Build multipart payloads for your JAX-RS client and services

Often, a RESTful service or client will need to send multiple disparate pieces of data in the same request, for example, uploading a resume/CV with a picture and text for name and address. This is usually done using multipart/form-data.

While Liberty currently has APIs to enable users to receive multipart/form-data payloads, it does not have any APIs to enable users to send multipart payloads - until now. With the new AttachmentBuilder API, users can now send multipart requests from their JAX-RS clients or send multipart payloads as responses from their JAX-RS resources.

To send a multipart request, you will need to enable the jaxrs-2.0 or jaxrs-2.1 feature. Presumably, if you are already using JAX-RS, one of these features will already be enabled. To send a multipart payload, you must send an instance of List<IAttachment>. Each object in that list represents a single attachment part. Here is an example of creating and sending a multipart request from a JAX-RS client:

List<IAttachment> attachments = new ArrayList<>();

attachments.add(AttachmentBuilder.newBuilder("blogPost")
                                 .inputStream(new FileInputStream("/path/to/yesterdaysBlogPost.xml"))
                                 .fileName("myRenamedBlogPost.asciidoc")
                                 .contentType("text/asciidoc")
                                 .contentId("myBlogPostID")
                                 .header("X-PriorityLevel", "Medium")
                                 .build());

attachments.add(AttachmentBuilder.newBuilder("file1")
                                 .inputStream("some.xml", new FileInputStream("/path/to/myPicture.png"))
                                 .contentType("image/png")
                                 .build());

attachments.add(AttachmentBuilder.newBuilder("authorName")
                                 .inputStream(new ByteArrayInputStream("John Doe".getBytes()))
                                 .build());

Response response = client.target(BLOG_SITE_URI)
                          .request()
                          .post(Entity.entity(attachments, MediaType.MULTIPART_FORM_DATA));

For more information vist:

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 21.0.0.5.

  • Application context path can not end with a slash

    Within Open Liberty you are able to retrieve the current context path by calling ServletContext.getContextPath(), the Jakarta EE specification states that this method should return a string that begins with a / character and does not end with a / character. Prior to Open Liberty 21.0.0.5, it was possible for this method to return a context root with a / appended to it, this behaviour has been corrected and will now always remove any trailing / characters.

  • JDBC kerberos problems on IBM JDK 8

    With the release of Open Liberty 21.0.0.5 the following issues have been resolved when using JDBC kerberos with an IBM Java 8 installation:

    • Fixed needing to use a file:/ URL pattern for keytab and ccache files.

    • Fixed incorrectly identifying when a password is set.

    • Fixed various problems related to interactive vs non-interactive modes.

    • Fixed Received fatal alert: protocol_version error.

  • Ensure MP Config properties from the application are visible when mpOpenApi-2.0 runs filters

    When using mpOpenApi-2.0, OpenAPI filters can look up MicroProfile Config values from a microprofile-config.properties file included in the application. Previously this functionality did not work and MicroProfile Config would erroneously report that the configuration property did not exist. This behaviour has been corrected and OpenAPI filters will now function as expected.

  • Correct the synchronization when mpOpenApi-2.0 processes applications

    Prior to the release of Open Liberty 21.0.0.5, when using mpOpenApi-2.0, starting two applications concurrently could occasionally produce a number of errors and ultimately OpenAPI documentation may not be created correctly for either application. This behaviour has now been corrected and OpenAPI documentation will be created for one of the applications.

    For more information visit the MicroProfile OpenAPI documentation

Get Open Liberty 21.0.0.5 now


May 14, 2021 12:00 AM

On Patents and Specifications

by Mike Milinkovich at May 13, 2021 07:20 PM

We’ve been fielding a number of questions lately about the intersection of our spec process and patents. A couple of these community discussions have gone off in directions that are off target, factually incorrect, or both. Therefore, the purpose of this short FAQ is to explain the patent license options provided by the Eclipse Foundation Intellectual Property Policy for use by specifications developed by specification projects under the Eclipse Foundation Specification Process (EFSP). 

Disclaimer: This is not legal advice. I am not a lawyer. It has not been reviewed by counsel. Consult your own attorney. In addition, this note does not form part of any official Eclipse Foundation policy or process, but rather is provided for informational purposes only to aid those involved in our specification projects to better understand the EFSP and the choices available. I’ll update the content as needed.

One important point to keep in mind when reading this: we believe that the EFSP fully complies with the Open Standards Requirement for Software established by the Open Source Initiative. In other words, the EFSP is designed specifically to be open source friendly.  

Why do specifications require patent licenses?

The purpose of every specification is to stimulate the development of implementations. These implementations may be derived from open source code maintained at the Eclipse Foundation or elsewhere, or they may be independently developed. They may be made available under open source licenses or proprietary. In order to facilitate and encourage these implementations, all specification processes provide some notion of patent licenses from the parties involved in developing the specifications.

What types of patent licenses are used by various specification organizations?

There are a wide variety of specification patent license options available from various sources. 

Some terms that you may hear are:

  • FRAND means fair, reasonable, and non-discriminatory licenses. This means that before you can implement the specification you are required to obtain a license from the patent holders who developed the specification. FRAND is generally considered to be antithetical to open source development, as it requires permission and money to implement a specification or potentially even to use an implementation of such a specification.
  • FRAND-Z is FRAND where the cost of the license is set to zero. Note that although this removes the cost concerns of FRAND, permission may still be required for use and/or implementation. 
  • RF or royalty-free provides a priori royalty-free licenses from the participants developing the specifications to downstream users and implementers. This is considered a best practice for enabling open source implementations of a specification. All Eclipse Foundation specifications are developed on a royalty-free basis. 
  • Non-assert is another legal mechanism which provides a result effectively similar to royalty-free. A non-assert says that a patent holder will not assert their patent rights against an implementer or user. 

Do these licenses mean that an implementer or user can never be sued for patent infringement?

No. The patent licenses are intended to ensure that an implementer or user doesn’t need to be worried about being sued by the parties involved in developing the specifications. It does not provide protection from uninvolved third parties who may believe they have intellectual property rights applicable to the specification. 

Note that the above implies that it is in the interests of the entire community and ecosystem that many participants (particularly patent-owning participants) be involved in developing the specifications. It also explains why it is in the best interest of the community that all participants in the specification process have signed agreements in place documenting their commitment to the patent licensing under the EFSP. 

What patent licenses are granted by the EFSP?

The patent licenses provided via the EFSP apply to all downstream implementations of Final Specifications, including independent implementations. They cover all patents owned by each Participant in the specification project that are essential claims needed by any implementer or user of the specification. Note that the licenses cover the entire specification, not just to the parts of the specification that a participant may have contributed to. We provide our specifications two options for patent licenses: the Compatible Patent License and the Implementation Patent License. The differences between those two are explained below.

But my open source license already has a patent license in it. Why do I need more than that?

The patent licenses provided in open source licenses such as APACHE-2.0 grant a license for contributor-owned patents which apply to their contribution either alone or as combined with the work. The patent license is only to that program/implementation. Note that the APACHE-2.0 patent license  “…applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work…”. Relative to the EFSP, such grants are deficient in both scope (applies only to their contributions) and target (applies only to that implementation). 

What is the difference between the two patent license options provided by the EFSP?

The only difference between the Compatible Patent License and and the Implementation Patent License is the timing of when the patent license grant comes into effect. In the Compatible Patent License, the license grant only happens when the implementation has demonstrated that it is fully compatible with the specification by passing the relevant TCK. The Implementation Patent License provides immediate patent licenses to all implementers, even to partial or work-in-progress implementations. The first choice emphasizes the importance of compatibility. The latter choice emphasizes the importance of open development. Both are valuable options available to Eclipse specification projects. 

Is one of these patent license options better than the other?

No. There are perfectly valid reasons why a specification project may choose either one of these options. Both options provide downstream implementers of the specifications royalty-free licensing to the patents of the participants who developed the specification. The Implementation Patent License favours open development as there is less concern that a work-in-progress implementation does not have access to the patent licenses. Where there is a strong emphasis on desiring compatibility across all implementations, the Compatibility Patent License is a valid choice. Another scenario is a small company with few patents. They may also prefer the Compatibility Patent License to ensure that they’re not providing an open-ended patent license to any competitors who may only partially implement the spec. 

Does the Eclipse Foundation recommend either of these two choices?

As an open source foundation our default preference is the Implementation Patent License as we always want to promote open collaborative development. But as described above, there are perfectly valid reasons why a specification project may prefer the Compatibile Patent License. Ultimately it is up to each working group to make their own selection.

I’ve read the EFSP and I don’t see anything about patent licenses. WUWT?

The patent licenses are provided in the Eclipse Foundation Intellectual Property Policy. A future version of the EFSP will make this clearer.

Is the Eclipse Foundation itself granted any licenses to patents? 

No. The Eclipse Foundation itself does not acquire any patent rights in the specifications. The patent licenses are granted from the participating patent owners directly to implementers and users of those specifications. More specifically, the patent license grants are “… to everyone to make, have made, use, sell, offer to sell, and import…” implementations of the specifications.

(Updated on 2021-07-05 to add two FAQ entries.)


by Mike Milinkovich at May 13, 2021 07:20 PM

Real Men Drink Milk! | The Two Minutes Tuesday 023 | Announcement

by Markus Karg at May 11, 2021 09:00 PM

Java Champion Christoph Engelbert, best known for Hazelcast, is digitizing the cowshed — and I wonder what that shall be good for and how it works!

Discuss with us on this Friday’s LIVE show #ToniteWithMe on 20:00 CET right here on this channel!

If you like this video, please give it a thumbs up, share it, subscribe to my channel, or become my patreon https://www.patreon.com/mkarg. Thanks! 🙂

CU!


by Markus Karg at May 11, 2021 09:00 PM

Jakarta EE Ambassadors Joint Position on Jakarta EE and MicroProfile Alignment

by javaeeguardian at May 11, 2021 03:32 AM

The Jakarta EE Ambassadors are encouraged by the continued progress and relevance of both Jakarta EE and MicroProfile. We believe a clear, collaborative, and complementary relationship between Jakarta EE and MicroProfile is very important for the Java ecosystem. 

Unfortunately the relationship has been unclear to many in the Java community, sometimes appearing to be disconnected, overlapping and competitive. MicroProfile builds on top of some Jakarta EE specifications and many Jakarta EE applications now use MicroProfile APIs. For the success of both, it is imperative that the technology sets clarify alignment to ensure continuity and predictability. 

The Cloud Native for Java (CN4J) Alliance was recently formed to address these concerns. The alliance is composed of members from both the Jakarta EE and MicroProfile working groups. The Jakarta EE Ambassadors view this as a positive step.  This joint position statement and the additional slide deck linked below summarize what the Jakarta EE Ambassadors would like to see from CN4J as well as the alignment between Jakarta EE and MicroProfile. 

We see Jakarta EE and MicroProfile fulfilling distinctly important roles. Jakarta EE will continue to be the stable core for a very broad ecosystem. MicroProfile will continue to strongly focus on microservices, velocity, and innovation. Our perspective on each is as follows:

Jakarta EE

  • One major release per year
  • Targets monolithic applications, microservices and standalone (Java SE/command line) applications – both on premises and on the cloud
  • Maintains a stronger commitment to backwards compatibility
  • Enables specifications to be used independently
  • Enables the ecosystem to build on Jakarta EE technologies, including MicroProfile and Spring

MicroProfile

  • Multiple releases per year
  • Targets microservices and cloud native applications
  • Strongly focuses on innovation and velocity including domains such as OpenTelemetry, gRPC, and GraphQL
  • Depends on core technologies from Jakarta EE
  • Less stringent requirements on backwards compatibility

It does appear the majority of our community would like to see eventual convergence between the technology sets. It is nonetheless understood this may not be practical in the short term or without its drawbacks. It is also clear that some very mature MicroProfile specifications like Configuration need to be used by Jakarta EE. We believe the best way to meet this need is to move these specifications from MicroProfile to Jakarta EE. The specifications being moved should adopt the jakarta.* namespace. The transition should be a collaborative effort. This is in accordance with what we believe developers have said they want, including through multiple surveys over time.

Jakarta EE also needs to make some significant changes to better serve the needs of MicroProfile and the Java ecosystem.  One key aspect of this is enabling specifications to be used independently, including standalone TCKs. Another key aspect is focusing on Jakarta EE Profiles that make the most sense today:

Core Profile

  • Core Jakarta EE specifications needed by MicroProfile
  • Some specifications moved from MicroProfile such as Configuration
  • CDI Lite

Full Profile

  • All Jakarta EE specifications
  • Deprecate/make optional older technologies

Jakarta EE and MicroProfile are both critical to the continued success of Java. We are committed to working with all key stakeholders towards a strong alignment between these technology sets. We invite all developers to join us in ensuring a bright future for both Jakarta EE and MicroProfile.

Additional Material


by javaeeguardian at May 11, 2021 03:32 AM

An Overview Between Java 8 and Java 11

by otaviojava at May 10, 2021 07:33 PM

This tutorial covers the basics of Java 8 and Java 11; it is a start to prepare you for the next LTS: Java 17. https://dzone.com/articles/an-overview-between-java-8-and-java-11

by otaviojava at May 10, 2021 07:33 PM

Automatic WildFly Clustering in Managed Domain Mode and Scaling inside Containers

by Tetiana Fydorenchyk at May 06, 2021 08:00 AM

Nowadays it’s easy to get up and running WildFly standalone server in a container. But what if you need to enable clustering in Managed Domain mode which is one of the key features of Jakarta EE in general. That is not so easy task. Integrated Jakarta EE clustering provides functionality that people are interested in, including high-availability and automated deployment among distributed Java application servers regardless of underlying infrastructure, and, of course, Admin Panel to manage your cluster using a nice UI.  Explore how to automate WildFly clusterization and scaling with Jelastic PaaS.

by Tetiana Fydorenchyk at May 06, 2021 08:00 AM

Jakarta EE Community Update for March and April 2021

by Tanja Obradovic at May 04, 2021 08:58 PM

Our update this month is jam-packed with highlights, as March and April were busy with many events and new developments in the Jakarta EE Community! 

The highlights for the past two months are as follows:

The Jakarta EE 2021 Developer Survey is now open!

It is that time of the year: the Jakarta EE 2021 Developer Survey is now open until May 31st. Please, if you haven't already provided your response, I encourage you to do so now. Help us gather input from the wider java enterprise community and shape the future of Jakarta EE!

Here are insights for 2020 Jakarta EE Developer Survey.

 

The Jakarta EE community and Working Group is growing

 We continue to have steady membership growth, and more interest from JUGs to be closely involved in various Jakarta EE projects.

Jakarta EE Working Group welcomes iJUG as a participant member and Istanbul JUG as a guest member!

iJUG involvement in Jakarta EE is well known, as their members are actively involved in Jakarta EE projects and community events. Now they have officially become members of not just Jakarta EE Working Group, but both MicroProfile and Adoptium Working Groups as well. 

JUG Istanbul has joined as a Guest member also. JUG Istanbul is a driving force behind  Jakarta One Livestream - Turkish, and its members are interested in being involved in advancing following individual specifications Jakarta Contexts and Dependency Injection and  Jakarta Concurrency.

This is a call to other JUGs to explore the possibility of joining Jakarta EE Working Group. Approach us and let us know if membership is something you would be interested in.

 

Jakarta EE 9.1 release

I hope you are all already familiar with the Jakarta EE 9.1 Release Plan! The main driver for this release is Java SE 11 support.

Eclipse GlassFish 6.1.0-RC1 Web (https://download.eclipse.org/ee4j/glassfish/web-6.1.0-RC1.zip )  and Full Profile (https://download.eclipse.org/ee4j/glassfish/glassfish-6.1.0-RC1.zip)  are now on Eclipse downloads. Please download and take a look!

Multiple Compatible Products on the release date of the Jakarta EE 9.1

The compatibility certification request for Jakarta EE 9.1 release keep coming, and we are super proud and happy about it

The Jakarta EE 9.1 release will be the first release that will have more than one compatible implementation used for the ratification of the final specification. 

 

Jakarta EE Individual Specifications and project teams 

We have organized a public calendar Jakarta EE Specifications Calendar (public url, iCal) to display all Jakarta EE Specification project teams meetings. Everyone interested is welcome to join the calls.

The Jakarta EE Platform team (meeting on Feb 9th, 2021) has invited all specification project team members and leads to submit their release plans for review by April 15th, so the planning for release after 9.1 can start. The response was great! 25 individual specifications that have provided the plan review can be viewed here

The work towards the next release is emerging, and I would like to draw your attention towards Jakarta EE Core Profile Creation and Plan Review. Please review and join the Jakarta EE Platform team meetings to provide your input.

 

Statement direction for Jakarta EE 10 is on its way!

Jakarta EE Steering Committee has requested from the Jakarta EE Platform team to formulate a statement of direction for the release 10. You can join the discussion in this GitHub issue , but sharing here main points


A traditional roadmap with deliverables is still premature, so we need to highlight areas of focus that will build into an eventual roadmap. Areas of focus that need progress before a proper roadmap can be defined include:

  • Addressing lack of specification standalone TCKs that can be composed into new platforms

  • Defining the makeup of the core profile

  • Defining how profile specifications can be released independently and what versioning would look like under this approach

  • Promoting individual specification releases

  • Address integration of MicroProfile Config as Jakarta Config

  • Updating core profile specifications to enable build time capable implementation

  • Handling of optional specification features

  • Removing the current circularity between specifications at the TCK level

  • Java SE version and JPMS strategy

  • Improve architecture guidelines and address specification cohesion


Compatible Products and Compatible Implementations

Our list of Compatible Products, implementations of Jakarta EE Platform and Web Profile, is growing, and not just for Jakarta EE 8, but also for Jakarta EE 9.

The current Jakarta EE 8 list is impressive

 

And the Jakarta EE 9 list is growing

 

Jakarta EE White Paper: Why Jakarta EE Is the Right Choice for Today's Java Applications

In collaboration with the community leaders we have published the  Jakarta EE  White Paper: “Why Jakarta EE is the Right Choice for Today’s Java Applications”. Please promote and share this Whitepaper amongst your community--we appreciate your support in sharing it with others.

 

EclipseCon 2021 CFP is now open!

Please mark your calendars: EclipseCon 2021 is taking place October 25th - 27th 2021! The call for papers is now open, so do not miss this chance to showcase your work! We already have quite a few talks related to Jakarta EE and Cloud Native Technologies submitted and you can review them here


Book your 2021 Jakarta EE Virtual Tour and Adopt-A-Spec

We are looking for the opportunity to virtually visit you, so don’t hesitate to get in touch (tanja.obradovic@eclipse-foundation.org) if you’d like to hear about Jakarta EE 9 and beyond.

We need help from the community! All JUGs out there please choose the specification of your interest and adopt it. Here is the information about the Adopt-A-Spec program. 

 

Stay Connected With the Jakarta EE Community

The Jakarta EE community is very active and there are a number of channels to help you stay up to date with all of the latest and greatest news and information. Subscribe to your preferred channels today:

·  Social media: Twitter, Facebook, LinkedIn Group

·  Mailing lists: jakarta.ee-community@eclipse.org, jakarta.ee-wg@eclipse.org, project mailing lists, slack workspace

·  Calendars: Jakarta EE Community Calendar, Jakarta EE Specification Meetings Calendar 

·  Newsletters, blogs, and emails: Eclipse newsletter, Jakarta EE blogs, Hashtag Jakarta EE

·  Meetings: Jakarta Tech Talks, Jakarta EE Update, and Eclipse Foundation events and conferences

 

You can find the complete list of channels here.

 

To help shape the future of open source, cloud native Java, get involved in the Jakarta EE Working Group.

 

To learn more about Jakarta EE-related plans and check the date for the next Jakarta Tech Talk, be sure to bookmark the Jakarta EE Community Calendar.

 


by Tanja Obradovic at May 04, 2021 08:58 PM

Back to the top