Skip to main content

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 by up to 500%. To make it even better, Hibernate does all of that automatically. The only thing you […]

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

An Interesting Way to Build Docker Images (by helidon.io)

by admin at June 19, 2021 03:40 PM

helidon MicroProfile quickstarter ships with an interesting, incremental, approach to build docker images. A Two Phase Build (2PB :-)):


by admin at June 19, 2021 03:40 PM

Mid-Year 2021+ Observations and Predictions

by admin at June 15, 2021 02:28 PM

  1. Kubernetes won the "Container Orchestration Wars" and became a standard for building cloud-like environments. All public clouds offer alternative orchestration solutions which are less complex and more cost-effective. For most applications, it does not matter who manages the containers. Kubernetes becomes a commodity - very comparable to Linux. Kubernetes compatibility becomes less crucial, the importance of container images and runtimes remains.
  2. Function as a service FaaS like, e.g., AWS Lambda, Azure functions, Google Cloud Functions, or Oracle Cloud Functions become more popular for their "killer features" like, e.g., event listeners and integration points. Fewer projects try to use functions as a service as a general-purpose programming model. This trend should continue.
  3. Public clouds can be expensive. After the initial excitement, slower-growing companies are starting to moving back to their data centers. We will hear the term "repatriation" more often. "Boring" enterprise apps can run more cost-effectively on-premises. "Lifting and shifting" an existing application to the cloud comes with no benefit to the end-user or business department. Refactoring a monolith into "cloud-native" microservices introduces additional complexity with no immediate added value. In 2021+, a monolith becomes another "best practice."
  4. Microservices in the clouds can be more expensive to implement and especially to run. I'm expecting a "Monthly Cloud Bill Driven Development" trend to merge sensible microservices into a less reasonable monolith for the sake of cost savings.
  5. Companies are starting to notice that clouds can be more secure, flexible and come with authentication, authorization, encryption, and vertical services like, e.g., image recognition, notifications, text to speech, text recognition, fraud detection, key rotation. Such services are hard to replicate on-premise and are the killer use case for the clouds. Running "boring" workloads on-premises and picking interesting cloud services leads to flexible and cost-effective solutions and should replace more dogmatic strategies.
  6. Serverless should be the new trend for 2021. A few years ago, "serverless" was the synonym for AWS Lambda. Now we got serverless containers, databases, workflows, and event streams. Serverless only means that you can scale down the service to zero and stop paying for scaled-down resources. I expect a noticeable trend to serverless services.
  7. The rise of next-generation runtimes like micronaut or quarkus is undisputable. They share the same principle: deployment happens at build-time, and the runtime becomes simple, fast, and nimble. No reflection, no class loading. I expect Helidon to catch up by reusing some of micronaut's annotation processing features.
  8. Quarkus' popularity exploded last year. It is hard to find a Java developer who didn't already experiment with Quarkus. The support of familiar APIs like, e.g., MicroProfile and parts of Jakarta EE combined with a small footprint, fast startup times, and GraalVM integration gives Quarkus an "unfair advantage." However, the competition doesn't sleep. Micronaut is small, if not smaller, than Quarkus but only partially implements MicroProfile and Jakarta EE APIs. Helidon is fully MicroProfile compatible, fast, but not as memory efficient as micronaut. Many micronaut and Helidon committers are working for the same company :-)
  9. The speed of Java language innovation got higher in the last years. We got Java Records, Text Blocks and instanceof Pattern Matching. Over time, fewer projects are going to use alternative JVM languages. Plain Java is going to be just "good enough."
  10. Java Records stole Lombok's main killer feature: getter / setter / builder generation. Lombok may become less relevant in enterprise projects.
  11. Plain Web Components are available on all browsers. ES Modules are available everywhere and already recognized as the future of modularization in JavaScript. The productivity and maintainability of vanilla JavaScript solutions makes JavaScript frameworks less relevant. Frameworks introduce complexity, maintenance costs, and significant time investment. The trend towards plain "standards" in and outside enterprise may increase in 2021+.
  12. The great "IntelliSense" and "refactoring" support for plain JavaScript in Visual Studio Code will make typescript less popular over time. Visual Studio Code treats JavaScript as TypeScript already.
  13. Productive, plain, modern JavaScript combined with Web Components and ESM compatible libraries like e.g. lit-html makes npm builds on developer's machines optional.
  14. Apache Kafka will be considered more as an immutable data store, a single "source of truth," and more minor as a "modern" replacement for Java Message Service / Jakarta Message Service.
  15. Apache Kafka is the natural use case for reactive programming and will make reactive programming more popular.
  16. Project Loom will eliminate reactive programming constructs for non-reactive resources.
  17. ARM-architectures are going to be more popular on servers and also PCs in the short term and could dominate the market in the longer term.
  18. GraalVM is still underestimated and often only used for native compilation. In addition to the native compilation, GraalVM is also a fast JVM and multilanguage environment. I expect the growth of GraalVM and also the appearance of a viable competitor.
  19. JavaFX combined with GraalVM presents the unique possibility to ship the same native application to run on various devices. You can develop Java applications once and submit them to various app stores - even the Apple AppStore. JavaFX's popularity should grow.
  20. Project Panama: "Interconnecting JVM and native code" or the new "JNI" become more critical and popular. Native integration between the JVM and C code plays a vital role in machine learning or GPU access.
  21. Visual Studio Code becomes a viable Java, Cloud, and web IDE, however, VSC features are still not widely known across the Java community. Therefore I expect the use of VSC in projects to increase further.
  22. "Serverless servers" like, e.g., payara cloud, is an interesting case. Payara Cloud follows opposite design decisions to the "next-generation standards." The application server cluster becomes a Kubernetes Operator and manages the nodes for you. You don't care about the server and only have to push a ThinWAR to the cloud. Payara Cloud hides the Kubernetes complexity and dramatically simplifies the infrastructure. The infrastructure is strictly separated from the business code. Payara Cloud is not GA yet but might become the most productive way to run "boring" applications everywhere.
see also my 2020 predictions.

by admin at June 15, 2021 02:28 PM

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

How Java WebSocket Implementation Happened--and airhacks.fm podcast

by admin at June 14, 2021 06:41 PM

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

The #144 airhacks.fm episode with Justin Lee (@evanchooly) about:
early Java e-commerce, JSPs, GlassFish, Grizzly and early Java WebSocket implementation
is available for download.

by admin at June 14, 2021 06:41 PM

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

Cloud development, Logging Frameworks, Transactions, Micro Services, Testing, ETags, JPA, BCE, Batch on AWS, Exception Handling, FlywayDB, Lombok, CDI events--or 87th airhacks.tv

by admin at June 12, 2021 05:42 AM

The 87th airhacks.tv (and the first from http://youtube.com/c/bienadam/):
"Cloud development, logging frameworks, transactions and micro services, unit-, integration-, system testing, ETags and JPA, Boundary Control Entity pattern, long running processes in the cloud, exception handling, FlywayDB, lombok, CDI events"
is available:

See you every first Monday of the month at https://airhacks.tv 8pm CET (UTC+1:00).

Show is also announced at: meetup.com/airhacks.

Any questions left? Ask now: https://gist.github.com/AdamBien/8b2b52ca341285c15de7d4a9257f3f54 and get the answers at the next airhacks.tv.


by admin at June 12, 2021 05:42 AM

How Hudson and Jenkins happened--an airhacks.fm podcast

by admin at June 11, 2021 03:34 PM

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

The #143 airhacks.fm episode with Kohsuke Kawaguchi (@kohsukekawa) about:
PCs in Japan, Java, working for Sun Microsystems, Glassfish, Java EE / J2EE, XML implementing Jenkins, starting Hudson
is available for download.

by admin at June 11, 2021 03:34 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

Hashtag Jakarta EE #74

by Ivar Grimstad at May 30, 2021 09:59 AM

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

Jakarta EE 9.1 is RELEASED! Here’s what you should do now:

Step 1: Update your pom.xml

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>9.1.0</version>
</dependency>

Step 2: Migrate to jakarta.* namespace

Follow this migration guide for the namespace migration.

Step 3: Run

Download the Jakarta EE 9.1 Compatible Product of your choice.

Tomorrow is the last day to take the 2021 Jakarta EE Developer Survey! Please take a couple of minutes to help us shape the future direction of Jakarta EE. Now that we have released Jakarta EE 9.1, the focus is on the next release. The work has already started with the establishment of the new Jakarta EE Core Profile and discussions around the release- and versioning strategy going forward. Follow the discussions in the Jakarta EE Platform Weekly call. The survey will provide valuable input to this work.

The early bird deadline for EclipseCon 2021 is coming up! Make sure you submit your talk before June 1, 2021, for a chance to be one of the first five talks selected for the conference.

Timeline:
June 1: Early-Bird Submission Deadline
June 15: Final Submission Deadline
July 1: Notification Sent

Navigate to EclipseCon 2021 Call for Proposals and submit your Jakarta EE talk today!


by Ivar Grimstad at May 30, 2021 09:59 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 is RELEASED!

by Ivar Grimstad at May 25, 2021 12:35 PM

Join us in celebrating a new release of Jakarta EE!

The Jakarta EE Working Group Releases Jakarta EE 9.1 as Industry Continues to Embrace Open Source Enterprise Java! Jakarta EE 9.1 adds support for Java SE 11 runtimes to the foundational Jakarta EE 9 release. This gives developers more flexibility when migrating from previous Jakarta EE releases.

In order to upgrade to the new version, simply change the dependency version in your pom.xml to 9.1.0. If you are upgrading from a version prior to Jakarta EE 9, follow the migration steps for the namespace change from javax.* to jakarta.*.

Maven dependency for Jakarta EE Platform 9.1

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>9.1.0</version>
</dependency>

Maven dependency for Jakarta EE Web Profile 9.1

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-web-api</artifactId>
  <version>9.1.0</version>
</dependency>

by Ivar Grimstad at May 25, 2021 12:35 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

Hashtag Jakarta EE #73

by Ivar Grimstad at May 23, 2021 09:59 AM

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

Jakarta EE 9.1 will be released on Tuesday, May 25, 2021! Stay tuned for announcements on this blog, the jakarta.ee website, Jakarta EE on Twitter, and a bunch of other places.

But, we don’t rest there. The work with Jakarta EE 10 is progressing as well. The creation- and plan review for Jakarta EE Core Profile 10 was approved this week by the Jakarta EE Specification Committee. We have also started the issues for defining the scope of Jakarta EE Web Profile 10 and Jakarta EE Platform 10. Plan reviews of these are expected to be initiated shortly.

The project proposal for Jakarta Config is being processed. Since it is a project that will produce a specification under the Jakarta EE Specification Process (JESP), a creation review by the specification committee is required. This review ballot is ongoing and will end this week. Community members are encouraged to chime in and place their (non-binding) vote.

I am very pleased to announce that Eclipse Krazo, an implementation of Jakarta MVC was integrated into Eclipse GlassFish this week! This is an important milestone for the project.

If you haven’t filled out the 2021 Jakarta EE Developer Survey yet, I hope you will take a couple of minutes required to provide us with valuable input in shaping the direction of Jakarta EE!


by Ivar Grimstad at May 23, 2021 09:59 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

Monitoring Enterprise applications with OpenShift and Prometheus

by WildFly Admin (francesco@mastertheboss.com) at May 17, 2021 08:55 AM

This article covers how to monitor Java Enterprise applications using OpenShift Container Platform 4.6. For the purpose of this example, we will be using JBoss Enterprise Application platform Expansion pack which empowers JBoss EAP with Microprofile API, such as the Metrics API.


by WildFly Admin (francesco@mastertheboss.com) at May 17, 2021 08:55 AM

Hashtag Jakarta EE #72

by Ivar Grimstad at May 16, 2021 09:59 AM

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

In the Jakarta EE Platform call this week, we decided to ask the specification projects for feedback on whether October 15, 2021 is an achievable date for having their specifications ready for release. So far, the feedback has been positive. It is great to see that the specifications are moving forward again. The Jakarta EE 9 release with the associated namespace change from javax.* to jakarta.* may very well prove to be the tap on the bottle that got the ketchup flowing.

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.

Try out the Cargo Tracker!

If you are interested in contributing to the project, or just look at the code, go to the Cargo Tracker GitHub repository.

A warm welcome to The Apache Software Foundation that joined the Jakarta EE working group as a guest member this week.


by Ivar Grimstad at May 16, 2021 09:59 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. 

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.


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

May Payara Roadmap Overview Webinar

by Priya Khaira-Hanks at May 10, 2021 11:26 AM

We kicked off the year with the Payara Roadmap for 2021. In this January webinar, Steve provided: detail on benefits of the Jakarta EE model; how the Payara Platform is evolving and moving toward Payara 6; updates and progress of the Payara Cloud project, our new PaaS product; and latest news regarding the next major OpenJDK release - JDK 17 Long Term Support (LTS) and what that means for Payara Platform.

Find a full-write up here:https://blog.payara.fish/payara-roadmap-2021 

In this May update, Steve gives a check-in on how we are progressing along our roadmap, with a retrospective on the year so far and details on what the rest of the year is set to look like. He provides a snapshot of where we are in relation to the plans and projects he mapped out at the beginning of the year.

Steve also discusses the results of the Payara Platform 2021 Survey. If you haven't had a chance to read the full report and summary yet, make sure you do by following this link:https://blog.payara.fish/2021-payara-platform-survey-results


by Priya Khaira-Hanks at May 10, 2021 11:26 AM

[LIVESTREAM] Christoph Engelbert LIVE CHAT The Digitial Cowshed | Tonite #WithMe | Java Latenite

by Markus Karg at May 09, 2021 03:59 PM

Live chatting #ToniteWithMe about the digital cowshed is #JavaChampion Christoph Engelbert.

#EcoInformatics is a rather new application of information technology, and it is all about how to improve the ecological situation using hard- and software. Christoph is working on a solution (#clevabit, https://www.clevabit.com/) that improves the life of cows and chicken, and on Friday he will tell us how it works and what the actual benefit is. I am really excited to hear more about it, as it covers my two biggest interest: Informatics and Conservation!

Join this LIVE SESSION on Friday at 20:00 CET.

Just type your own questions into the chat while the show runs!

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


by Markus Karg at May 09, 2021 03:59 PM

Hashtag Jakarta EE #71

by Ivar Grimstad at May 09, 2021 09:59 AM

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

Let’s look at Jakarta EE 10! By filtering on the EE10 label in our GitHub issue tracker, you will find the list of topics currently under discussion. I would like to highlight a couple of the issues.

Jakarta EE 10 Direction Statement (#352) lists focus areas that we are working on in order to come up with a proper roadmap for the platform. The platform team has been tasked by the Jakarta EE Steering Committee to produce a statement of direction for the steering committee meeting on May 11, 2021. I think we are in pretty good shape, but it will most certainly be refined more in the platform call a couple of hours before the steering committee gathers.

Create a new core profile specification (#353) collects the discussion around creating a new Jakarta EE Core Profile. We have created the plan review record and expect the ballot for creation- and plan reviews to be started pretty soon. Check out the JESP Guide for information about what these review steps actually means.

Speaking about plan reviews, we have a lot of them going on right now. Just check out the list of pull requests for plans. The Jakarta EE 10 Plan Reviews project board shows the current status of the reviews as they flow through our process.

In addition to this, a project proposal for Jakarta Config is being drafted. I expect it to be made public for community review within short.

If you haven’t filled out the 2021 Jakarta EE Developer Survey yet, I hope you will take a couple of minutes required to provide us with valuable input in shaping the direction of Jakarta EE!


by Ivar Grimstad at May 09, 2021 09:59 AM

The Payara Monthly Catch: April 2021

by Priya Khaira-Hanks at May 07, 2021 08:56 AM

It's been an incredibly exciting month for Team Payara! We were honoured with a Queen's Award for Enterprise. This is the UK's most prestigious business award, often called the 'Knighthood for Businesses' and our award particularly recognises our international sucess. CEO and Founder Steve Millidge thanked the entire team in his blog, which also went more into detail about what this means for the wider Jakarta EE and MicroProfile community. 

In other Payara Services news, we're also 'buzzing' about our new Charity of the Year, the Bumblebee Conservation Trust - and see Payaran Lenny Primak below on Adam Bien's podcast, and Rudy De Busscher joining forces with IntelliJ IDEA! 

Community highlights included the release of the latest version of IntelliJ IDEA, with our engineersworking hard to update our Payara Platform pugins accordingly due to high demand from the community. We were also excited by news of the newMicrosoft Build of OpenJDK. 

Read more about all this and more in the below round-up of news, articles, videos and podcasts. 


by Priya Khaira-Hanks at May 07, 2021 08:56 AM

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

JUG Istanbul joins Jakarta EE Working Group!

by Tanja Obradovic at May 04, 2021 06:53 PM

We are happy to share the news with you: Java User Group Istanbul  has been invited by Jakarta EE Steering Committee to join the Working Group as a Guest member. JUG Istanbul is a driving force behind  Jakarta One Livestream - Turkish event, and its members are interested in being involved in advancing following individual specifications Jakarta Contexts and Dependency Injection and  Jakarta Concurrency . Please share the news and give warm welcome the JUG Istanbul!


by Tanja Obradovic at May 04, 2021 06:53 PM

Payara Platform 2021 Survey Results

by Priya Khaira-Hanks at May 04, 2021 09:20 AM

We’re pleased to announce that our 2021 Payara Platform Survey results are now available! 

This survey was promoted to our audience between March and April 2021. We shared with Payara Platform Enterprise customers and Community users via social media, emails and blogs. Thank you so much to everyone who took the time to contribute!


by Priya Khaira-Hanks at May 04, 2021 09:20 AM

Hashtag Jakarta EE #70

by Ivar Grimstad at May 02, 2021 09:59 AM

Welcome to the seventieth issue of Hashtag Jakarta EE!

The Jakarta EE 9.1 release is coming up shortly. The release review ballot for ratification of the specification will start this week. A special detail regarding this release is that there will be at least three, possibly four, compatible implementations used for ratification. Eclipse GlassFish, OpenLiberty, and WildFly have submitted their Compatibility Certification Requests already. We hope that Apache TomeEE will make it as well!

More compatible products will follow shortly after the release.

The plan reviews for individual specifications are ongoing. You can follow their progress by checking out the pull requests labeled plan review. As they are approved, they will pop up on their respective page under Jakarta EE Specifications.

I want to remind you about the Jakarta EE Specifications Calendar, where the specification projects are encouraged to publish there calls in order to allow more people to join the discussions.


by Ivar Grimstad at May 02, 2021 09:59 AM

Migrating a real-world JavaFX App from JDK 8 to JDK 16 | Modern Java | Head Crashing Informatics 31

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

Hey guys! How’s it going?

I’m migrating a JavaFX chat client from #Java8 to #Java16 before your own eyes to demonstrate that problems are no reason to give up!

Join me while I am migrating a real-world application, a chat client written using JDK 8 (including JavaFX and JAXB) to JDK 16. Learn which problems could pop up, where to find help and solve them within much less than one hour! Neither replacing the originally embedded #JavaFX 8 by standalone #OpenJFX 16 / the original embedded #JAXB 8 by standalone Eclipse #JAXB-RI, nor using the #MavenShadePlugin didn’t stop me! After just few minutes, the project is migrated and works better than ever before AND we could use modern Java APIs and key words now if we would like to!

So there is excuse: Migrate to #JDK16 NOW!

Stay safe and… Party on!


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

Create a Jakarta EE 8 Web Application with Payara Server and Visual Studio Code

by Rudy De Busscher at May 01, 2021 09:35 AM

In this blog, we show you how to start your next Jakarta EE application with Visual Studio Code  using the plugin for the Payara Server.

We will create a Maven project so that you can also build it outside the IDE, such as in your CI environment, so you can automate your deployments.


by Rudy De Busscher at May 01, 2021 09:35 AM

Faster startup in Open Liberty dev mode with Eclipse OpenJ9 0.26.0

April 30, 2021 12:00 AM

The 0.26.0 release of Eclipse OpenJ9 includes updates that improve startup times for Open Liberty servers that run in development mode. This post looks at the changes behind those improvements and how you can take advantage of them.

Open Liberty development mode, or dev mode, enhances the developer experience by providing hot reload and deployment, on-demand testing, and debugger support. OpenJ9 is a scalable, high-performance, Java virtual machine (JVM) implementation. One of the biggest benefits of OpenJ9 is fast startup, thanks to the Shared Classes Cache (SCC) feature, which contains both classes and previously (dynamically) compiled Ahead-of-time (AOT) Code. AOT Compilation in OpenJ9 is the process of compiling code in one JVM instance to reuse it in another JVM instance. When you use a Java SDK with the OpenJ9 VM to run Open Liberty, the VM feature that enables dev mode is called Full Speed Debug (FSD). Before OpenJ9 version 0.26.0, the VM did not have AOT support for FSD. Therefore, Open Liberty dev mode did not benefit from the fast startup that normally comes with OpenJ9. However, from version 0.26.0 onward, FSD support is added for AOT compilations, and Open Liberty dev mode gets a boost in startup time from the SCC.

How did this improvement occur? First, a significant improvement was made in FSD performance when FSD is implemented with another feature known as OSR. This new implementation naturally facilitated generalization to relocatable compilations. The main idea behind FSD is, if a debug event occurs, an application thread moves from the middle of a compiled body to the interpreter. This transition ensures that compiled code can be highly optimized because the compiler does not need to worry about the consequences of debug events. When no more debug events exist, the application thread is allowed to run compiled code again.

Adding AOT support boiled down to ensuring that all the OSR data in the compiled body’s metadata and any breakpoint guards can be relocated[1][2][3]. The OSR data is needed to ensure the transition from the compiled code into the interpreter. The breakpoint guards are needed to ensure that debug events are respected when a method gets inlined. Other subtleties are involved regarding relocations, which you can read about in the previously cited pull requests. However, the practical impact of these changes is a noticeable difference in the user experience of dev mode.

To give a more objective description of the improvement, I ran dev mode on the DayTrader7 benchmark application and I observed that the startup time was roughly halved. I measured this improvement by starting and stopping an Open Liberty server that was running on 4CPUs, without measuring the startup time for the first run. The first time dev mode runs with OpenJ9 0.26.0, it seems slower because the first run generates all the AOT code that is placed in the SCC. All subsequent invocations of dev mode are noticeably faster.

To conclude, I recommend upgrading your Java SDK to use OpenJ9 0.26.0 so you too can benefit from a drastic improvement in Open Liberty dev mode performance with OpenJ9.


April 30, 2021 12:00 AM

Open Source Scholarship | The Two Minutes Tuesday 022 | Announcement

by Markus Karg at April 27, 2021 09:00 PM

Andres and me contributed the usual skip property to the Maven Shade Plugin, and got trated rather unfair by the Maven In-Crowd: While we asked BEFORE how to proceed, they told us AFTER the PR was done that they dislike the whole idea. This is not fair, it is disrespectful as it wastes valuable time, and it is definitively annoying new contributors!

But there is way to prevent this: Apply for the iJUG Open Source Scholarship! The iJUG is the umbrella association of approx. 50 JUGs in Germany, Swiss and Austria, and will mentor you in learning the unspoken rules of open source communities. Besides other goodies, like a free Javaland conference ticket, you finally (hopefull) will become a committer at a popoular open source project. In 2021, the rules are like this:

  • Send your application to stipendium@ijug.eu.
  • Select one of the following projects: Adoptium, Jakarta EE or Microprofile.
  • Refer to three PRs that you already filed for the selected project.
  • The iJUG’s Scholarship Mentors will select one person of all applications for each project.

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 April 27, 2021 09:00 PM

April Payara Release Overview Webinar

by Priya Khaira-Hanks at April 27, 2021 11:21 AM

In this Release Overview Webinar, Rudy De Busscher discusses the recent updates and enhancements to the Payara Platform in the latest release.


by Priya Khaira-Hanks at April 27, 2021 11:21 AM

Jakarta EE/MicroProfile Alignment Survey Results!

by javaeeguardian at April 17, 2021 08:48 PM

The Cloud Native for Java (CN4J) Alliance has recently been formed to promote better alignment between Jakarta EE and MicroProfile.

One of the key issues to sort out is how Jakarta EE can consume MicroProfile specifications (such as MicroProfile Configuration). There are several alternatives as to how this could be done. These alternatives were put into a survey for the community to weigh in. In addition to choosing the option respondents believe to be best, they were able to provide comments justifying their preferred alternative. The results of the survey are summarized here. The results have been shared with the CN4J community and key decision makers.

Survey Results

More than 200 people filled out the survey. Even more remarkably, there were more than 50 comments representing the voice of the community. A fairly strong majority (57.73%) of developers want some MicroProfile specifications to move to Jakarta EE including the namespace.

This image has an empty alt attribute; its file name is survey.png
Jakarta EE/MicroProfile survey results

The results are similar to what earlier surveys have indicated and congruent with the official Jakarta EE Ambassadors joint position. It is remarkable how consistent the community view has been, even over a period of time.

The Voice of the Community

It is impossible to do justice to all the people that provided comments. Each one of the comments is invaluable. The following is a decent sampling representing the majority opinion.

“MicroProfile should evolve APIs that eventually get absorbed by Jakarta EE. MicroProfile applications should eventually be able to run with pure Jakarta EE APIs.”

“Moving MicroProfile specs into Jakarta EE including namespace will make clear where the longer term specs are maintained. Also, for MicroProfile users it’s a very easy migration path.”

“I think no matter which of these options is chosen there is going to be an effect on either end users, or developers. Therefore, I would rather make the large upfront breaking changes all at once and merge the two into the same namespace. Then, have consistency going forward.”

“I would see the movement from org.eclipse.microprofile to the jakarta namespace as a sign of maturity (and success) for MicroProfile.”

“Option A2 has fewer cons and is more end user friendly.”

“Using a different namespace makes it clear what version and expectations (e.g. backward compatibility) the user is making. Moving without a namespace is confusing.”

“The aim of a specification should always be to make something as simple and clear as possible. The entry barriers and opportunities for error for new and inexperienced developers must be as low as possible. An inconsistent namespace or even the possibility of circular dependencies make the use simply too complicated and difficult. At the end of the day, it’s all about the economic and productive development of applications.”

“Move some MicroProfile specifications (e.g. MP Config when its stable) to Jakarta EE including the namespace.”

Source Data

We really hope the results help pave the way for sensible decisions on Jakarta EE and MicroProfile alignment. For our group, gathering input and listening to people that are not necessarily involved in the lower level details of specification development is extremely important.

The Eclipse Foundation very graciously ran the survey and shared the source data publicly. Reading all the comments in full is especially insightful.


by javaeeguardian at April 17, 2021 08:48 PM

Your Voice Matters: Take the Jakarta EE Developer Survey

by dmitrykornilov at April 17, 2021 11:36 AM

The Jakarta EE Developer Survey is in its fourth year and is the industry’s largest open source developer survey. It’s open until April 30, 2021. I am encouraging you to add your voice. Why should you do it? Because Jakarta EE Working Group needs your feedback. We need to know the challenges you facing and suggestions you have about how to make Jakarta EE better.

Last year’s edition surveyed developers to gain on-the-ground understanding and insights into how Jakarta solutions are being built, as well as identifying developers’ top choices for architectures, technologies, and tools. The 2021 Jakarta EE Developer Survey is your chance to influence the direction of the Jakarta EE Working Group’s approach to cloud native enterprise Java.

The results from the 2021 survey will give software vendors, service providers, enterprises, and individual developers in the Jakarta ecosystem updated information about Jakarta solutions and service development trends and what they mean for their strategies and businesses. Additionally, the survey results also help the Jakarta community at the Eclipse Foundation better understand the top industry focus areas and priorities for future project releases.

A full report from based on the survey results will be made available to all participants.

The survey takes less than 10 minutes to complete. We look forward to your input. Take the survey now!


by dmitrykornilov at April 17, 2021 11:36 AM

Building Multipart payloads for JAX-RS client and services in Open Liberty 21.0.0.5-beta

April 16, 2021 12:00 AM

With Open Liberty 21.0.0.5-beta you can now build multipart payloads for your JAX-RS client and services. Also present in this release is Jakarta EE 9 support for oauth-2.0 and samlWeb-2.0.

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

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:

Jakarta EE 9 support for oauth-2.0 and samlWeb-2.0

The oauth-2.0 and samlWeb-2.0 features have been updated to support Jakarta EE 9. Now these features will automatically adapt to the level of Java EE or Jakarta EE that is already in use. This means that there is no change needed when using them with Jakarta EE 9.

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:

  1. Add the following dependency to your pom.xml file:

    <dependency>
      <groupId>io.openliberty.beta</groupId>
      <artifactId>openliberty-runtime</artifactId>
      <version>21.0.0.5-beta</version>
      <type>pom</type>
    </dependency>
  2. Add a dependency for the beta version of each of the APIs that you’d like to try. For example, to try MicroProfile Config 2.0:

    <dependency>
      <groupId>org.eclipse.microprofile.config</groupId>
      <artifactId>microprofile-config-api</artifactId>
      <version>2.0</version>
      <scope>provided</scope>
    </dependency>
  3. Add add the following runtimeArtifact section to the configuration section of your pom.xml file:

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

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.5-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 recent 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 release comes complete with all of the previously released Jakarta EE9 API candidates. For more information about Open Liberty’s Jakarta EE 9 compatability, view our Open Liberty beta is Jakarta EE 9 compatible blog release.

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 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-jakartaee9</artifactId>
    <version>21.0.0.5-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.5-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.


April 16, 2021 12:00 AM

Survival Guide for the Java Architect in the Cloud Era

by otaviojava at April 15, 2021 06:37 PM

Cloud Final Version of NIST Cloud Computing Definition Published Agile Manifesto 97 Things Every Cloud Engineer Should Know: Collective Wisdom from the Experts  Infrastructure as Code: Dynamic Systems for the Cloud Age Getting GitOps right CI/CD Github Action Tekton Pipelines  Cloud Native Architecting Cloud Native Applications: Design high-performing and cost-effective applications for the cloud What […]

by otaviojava at April 15, 2021 06:37 PM

#ToniteWithMe Sneak Peek | The Two Minutes Tuesday 021 | Announcement

by Markus Karg at April 13, 2021 09:00 PM

Be with us, when Andres and me are LIVE HACKING Maven’s source code 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 April 13, 2021 09:00 PM

Less is More? Evolving the Servlet API!

by gregw at April 13, 2021 06:19 AM

With the release of the Servlet API 5.0 as part of Eclipse Jakarta EE 9.0 the standardization process has completed its move from the now-defunct Java Community Process (JCP) to being fully open source at the Eclipse Foundation, including the

by gregw at April 13, 2021 06:19 AM

Back to the top