Aexus Answers

Open Liberty: Replacing Apache Derby

Alex Johnson
-
Open Liberty: Replacing Apache Derby

Hey guys, let's talk about a significant change happening in Open Liberty, specifically regarding its in-memory database for testing. We're looking at replacing Apache Derby due to some recent developments. This article will dive into the background, why this change is necessary, the alternatives we're considering, and the process involved in making this happen. So, buckle up, and let's get started!

Background

So, here's the deal. Open Liberty currently relies heavily on Apache Derby as its in-memory database for running tests. However, things have taken a turn. Apache Derby hasn't seen a new release in the last two years. To make matters worse, there's an active discussion about retiring the project entirely. The current maintainers have signaled that they won't be fixing bugs or releasing new versions. This situation presents a challenge, as we need a reliable in-memory database to ensure our tests function correctly and that Open Liberty can continue to be developed on.

Not only that, but other major players in the Java world are moving away from Derby. Both Hibernate and Quarkus have deprecated their support for Derby. This trend further solidifies the need for us to find a new solution. For Java-based in-memory databases, H2 and HSQLDB are the most common alternatives. After evaluating both options, we believe that H2 is the more viable choice, mainly because it is maintained more actively and releases updates more frequently. In contrast, HSQLDB appears to be primarily supported by a single individual, which is similar to the state of Derby over the last couple of years. This is obviously not a good sign for future development and support.

The Core Problem

The core problem is that we can't just sit still. Relying on an unmaintained database creates risks. It opens us up to potential issues, especially when integrating with other tools or libraries that might have dependencies on a more up-to-date database system. This switch becomes even more important because we want to keep up with the latest features and improvements in the world of Java development and make sure that Open Liberty remains a modern and robust platform. We need a database that keeps up with the times, supporting future JDBC specifications and other relevant technologies.

Overview

Now, let's discuss the plan. We should look at using H2 instead of Derby for testing. This change is crucial for the long-term health of the project. We're likely to face issues using Derby in the future, especially for features that use Hibernate or rely on future JDBC specifications. So, swapping out Derby for H2 is a proactive measure to avoid problems down the road.

Potential Hurdles

Of course, this change isn't without its considerations. First, we need to be aware of any Open Liberty defects that may arise from testing with H2. Since we haven't tested with H2 before, it's possible that the JDBC integration layer or connection pooling might reveal some edge cases. Additionally, we will need to determine the level of enhancements needed for H2. This includes inferring the datasource type from the jar, providing a properties element, and supporting metatypes. Doing it right means we must consider various aspects to ensure a smooth transition and a reliable testing environment for Open Liberty. It’s a lot of work, but it's necessary to keep the project moving forward.

What's Next?

To put it simply, we need to make sure that we can seamlessly integrate H2 into our testing processes. This involves careful testing, addressing any potential issues, and deciding on the best ways to provide support for H2 within the Open Liberty ecosystem. This will ensure a smooth transition and reliable testing for Open Liberty.

Documents

Here's where we'll keep track of the essential documents related to this change.

Process Overview

Now, let's look at the different steps involved in making this change. It's a well-defined process, and it helps keep things organized.

  • Sizing
  • Prioritization
  • Design
  • Implementation
  • Legal and Translation
  • Beta
  • GA
    • Focal Point Approvals (complete by feature complete date)
  • Other Deliverables

General Instructions

Here's a little guide on how things generally go. The steps are presented in order, but sometimes they overlap. Each step has a set of tasks that need to be done, and it's usually the feature owner's job, or someone they delegate, to get them done.

Sizing

This is where we figure out how much effort this change will take. It helps us prioritize the work by letting us know the investment needed for the new feature. The feature owner will figure out the size of the feature and let the Open Liberty Project Manager, Release Architect, or Chief Architect know what it is. We use this scale to estimate the size:

  • XS: Less than or equal to 1 person week's worth of work
  • S: 2-3 person weeks
  • M: 4-5 person weeks
  • L: 6-9 person weeks
  • XL: 10-15 person weeks
  • 2XL: 16-20 person weeks
  • 3XL: 21+ person weeks

Prioritization

Here, the OpenLiberty/chief-architect and area leads prioritize the features. Here’s how it goes:

  • The feature owner adds the Prioritization - Requested label, which puts the feature on the radar.
  • The OpenLiberty/project-manager adds the feature to the

You may also like