Posted on

Framewars: The Battle Between NoSQL and Java in the Cloud Arena by Java2Days

This lecture’s objective is to make comparisons between points and weaknesses of Java frameworks that integrate with databases. On the one hand, the NoSQL MongoDB, Redis, Neo4J, and Cassandra, and on the other, the Java frameworks that integrate with them: Spring, Quarkus, Jakarta EE, Micronaut. The arena: the cloud! In this ring, the one who best analyzes each tool’s trade-offs wins, participates, and is the judge of this epic battle.

Posted on

Jakarta Security and REST in the Cloud Part 3: Knowing the OAuth2

Security is generally a topic that is left out when talking about software architecture, but that doesn’t mean that it is not essential. To talk more about it, we created this series on Java API security with Jakarta EE. In this third part, we will talk about the OAuth2 authentication process, moving it quickly to the cloud, and how to implement it with two MongoDB and Redis databases.

OAuth 2.0 is a protocol that allows permission to access authorization resources between systems or sites with the benefits of a better encapsulation of critical information such as username and password. An overview of OAuth 2.0:

Posted on

DTO: Hipster or Deprecated?

Data Transfer Objects, known affectionately as DTOs, is the subject of a lot of discussions when we talk about the development of Java applications. DTOs were born in the Java world in EJB 2 for two purposes. 

First, to circumvent the EJB serialization problem; second, they implicitly define an assembly phase where all data that will be used for presentation is marshaled before actually going to the presentation layer. Since the EJB is no longer used on a large scale, can DTOs also be discarded? The purpose of this article is to talk a little bit about the usefulness of DTO and address this question.

Posted on

Get to Know JSF: An Easy and Straightforward a Jakarta Framework

Developing web systems is a reality in the current market, and the Jakarta Server Faces framework is a standard Jakarta EE option to solve this type of problem. One of the characteristics of JSF is to work in a way oriented towards screen components and their events (for example, clicks). In this way, we can associate these components with different aspects of our system, such as the execution of business operations, value conversions, field validations, etc. In this article, we'll talk about this JSF and how to move this application to the cloud with Platform.sh.

To celebrate the new year, let's create a small wish list in Java with Jakarta EE technologies. In the front end, we'll use Java Server Faces (JSF), a Java-based web application framework that simplifies the development and integration of web-based user interfaces with several already-made components. To store the list, let's use MongoDB.

Posted on

What’s New With Jakarta NoSQL? (Part II)

Moving to Cloud-Native

Cloud computing has brought many methodologies and techniques that have revolutionized both the business and technical worlds. Among the terms that came up were cloud-native. To meet and cover these expectations in the Java universe, Jakarta EE emerged. The purpose of this post is to talk about the concept of cloud-native and to run an application with this concept using the latest milestone version of Jakarta EE NoSQL.

You may also like: From javax.* to jakarta.*: A Simple Proof of Concept

Posted on

Rise, the Jakarta EE Ambassadors!

Over the years, Java EE has included many powerful key open standards, and the Java EE Guardians were created to ensure that these standards move forward for the community and industry. Now that the transition of Java EE to the Eclipse Foundation is complete, and Jakarta EE is out in the wild, it’s important that the group re-brand as the Jakarta EE Ambassadors in order to make our intention clear: empowering efforts to ensure these standards continue to evolve and thrive.

The key to accomplishing this under the new Jakarta EE banner is community advocacy, facilitating participation and ensuring rank-and-file developers are heard. We invite you to learn about what we are doing and re-engage with us once more towards these ends now as Jakarta EE Ambassadors.

Posted on

From javax.* to jakarta.*: A Simple Proof of Concept

Experiment with code that uses the new jakarta.* APIs.

Now that the Jakarta EE project is planning to release its next version (Jakarta EE 9), where the major change is the update of all its APIs to use jakarta.* instead of javax.* in the package names, and hence the issue of breaking binary compatibility, I decided to experiment a little bit with how code that uses javax.* APIs can be dynamically modified (without the need to recompile) so that it runs against the target jakarta.* namespace.

You may also like:  Jakarta EE and the Great Naming Debate

It would also be a good opportunity to learn more about Javassist, which I'll be using to do the renaming at the bytecode level. Note that this post is not intended to propose a solution to this problem of API compatibility. It simply shares experimentation related to the subject.

Posted on

Jakarta EE: A Clean Slate

The announcement that Jakarta EE cannot use the javax.* namespace is great news and provides Jakarta EE with a clean slate on which to build and innovate the future of Enterprise Java.

The Original Proposal

It had been envisioned that the javax.* and jakarta.* namespaces would coexist after Java EE 8 and, as it evolved, the jakarta.* namespace would be used for new features of exiting APIs and the innovation of new APIs. This would have ensured backward compatibility from the start. And overtime the use of jarkata.* would eclipse the old namespace, but never actually replacing javax.* namespace. So, forever more Enterprise Java developers would have to explain why there are two namespaces. A constent reminder of Enterprise Java’s past (something we are trying to move on from).

Posted on

Thoughts on the Jakarta EE Package Name Change

The Eclipse Foundation announced that Jakarta EE cannot continue to use the javax package name. Apparently, this comes with the fact that while Java EE is based on this name, no further modifications are allowed to classes or packages starting with that name.

While this is certainly bad news, for me, the bad news already started when it was announced that Jakarta EE can’t use the javax name for new specifications and sub-packages. That would have already meant continuing to evolve a platform that becomes more inconsistent over time.

Posted on

Transitioning Jakarta EE to the “Jakarta” Namespace

As described in Jakarta Going Forward, we need to transition the Jakarta EE specifications to the jakarta.* namespace/base package. After long and intense discussions in the Jakarta EE Specification, we have proposed two possible ways forward to kick-start the discussions on this thread.

In this post, I am highlighting some of the content of the initial post to the mailing list for reference.