Introduction

So Liferay has released Liferay DXP 7.4 2024 Q2 and Liferay CE 2024 GA 120, but along with this came a bunch of other updates that affect developers.

These include:

• Blade 7.0.0
• Gradle 8.5
• Liferay Workspace Plugin 10.1.x
• JDK 17/JDK 21

That's a lot of changes, so let's talk about them...

Blade 7.0.0

For those that don't know, Blade is our developer CLI and scaffolding tool to create workspaces and modules and also support local server running and deployment. It is a critical tool for developers for the Liferay platform.

Even if you are using an IDE plugin for Eclipse or IntelliJ, you're actually still using Blade, it is just hidden from you.

Blade 7.0.0 is the latest release, but you might be asking whether you need it or whether you can continue to use your older version.

Blade 7, when creating a new Liferay Workspace, is going to automatically pick the latest version of the workspace plugin as well as Gradle 8. Other than that, Blade 7 doesn't really force any other changes on your environment. You can use Blade 7 in your current, un-upgraded workspace to create a new OSGi module project and it will work just fine.

If you are starting a brand new workspace/project, I would recommend updating to Blade 7 before you start.

Upgrading to Blade 7 is easy. Just issue the command blade update. On my Mac I got an error about no write access, I actually had to use the command sudo blade update.

Note that this will not work for those using IDE plugins; the IDE plugins use an embedded version of Blade. You'll need to wait for updated versions of the IDE plugins to get an updated version of Blade.

Gradle 8.5

When you create a new workspace using Blade 7, you will automatically be set up to use Gradle 8.5.

For the most part, this is the same old Gradle that we all know and love. Like Gradle 7, instead of using the older compile directive, we're now using the implementation directive. The compileOnly and compileInclude directives are still useful.

If you have a current workspace using Gradle 6 or 7, that's okay. As long as you're okay using 6 or 7, you don't have to update. But if your organization requires using Gradle 8, you now know that's an option.

To update to Gradle 8, just go to your existing workspace and edit the gradle/wrapper/gradle-wrapper.properties file. You need to change the distribution URL to point at Gradle 8, here's the version of the gradle-wrapper.properties file generated by Blade 7 for a new workspace:

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.5-bin.zip
validateDistributionUrl=true
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

The distributionUrl now points at 8.5, so the next gradlew (or blade gw) command you run will download Gradle 8.5 and use that to complete the command. If you were already previously running Gradle 6 or 7, you'll likely see additional messages about shutting down background daemons and stuff, but that's okay, it will have the proper outcome.

If you do update to Gradle 8, be aware that you must update your Liferay Workspace plugin to version 10.1.0 or greater. Fortunately the next section will share more about that...

Liferay Workspace Plugin 10.1.0+

The Liferay Workspace plugin has also received an update, now version 10.1.0+. I say plus because, even though the release was 2 weeks ago (calendar time from when I'm writing this), the current version is 10.1.3.

You should always try to use the latest version of the workspace plugin you can as there are tweaks for scaffolding and building and whatnot.

There is a requirement though to step up to Workspace plugin 10.1.0+, and that is that you must use Gradle 8; you can't use 10.1.0 with Gradle 6 or 7.

Is there a compelling reason to go to Workspace plugin 10.1.0+? Well, not unless you want Gradle 8, there's no compelling reason.

JDK 17 & JDK 21

The other exciting news with this release was support for JDK 17 & JDK 21!

Well, sort of?

Certainly you can start 2024.Q2 using either the JDK 17 or JDK 21. Note that my recommendation here (although I have nothing to back this up) is to purge the osgi/state directory before starting the alternate JDK. This directory is full of a bunch of binary files created to hold the state information from the OSGi runtime. Although I don't know that the formats are JDK version specific, I'm not sure I want to find that out in my runtime. Delete the directory and it will recreate at startup, so you lose a small fraction of startup time but gain confidence that your state directory has what it needs for the version of the JDK you're using. Seems to me to be a small price to pay.

From a developer perspective, honestly I'm facing a bit of confusion about how the JDKs apply to me.

Some information seems to say that compiling using 17 or 21 is not supported, but conflicting info says it is supported...

I can tell you from my own experience that I failed to build a workspace with a Service Builder module using JDK 21 and couldn't do anything to get it to build successfully.

I even tried the magical incantation added to my build.gradle files:

java {
    sourceCompatibility = JavaVersion.VERSION_11
    targetCompatibility = JavaVersion.VERSION_11

    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

This is the magic stanza that will have JDK 17 or JDK 21 treating and building your code for JDK 11.

As of yet, Liferay is not yet able to build the software using JDK 17 or JDK 21, that's still a work in progress. Until that happens, using an older JDK is still acceptable.

Yep, that's right, support is there for JDK 17 and JDK 21, but you can continue to use JDK 11 if you choose to (in fact I am, at least until the software forces my hand).

Compatibility Matrix

No, this isn't the Liferay Compatibility Matrix, in fact it's not much of a matrix at all...

When I first heard about all of these updates, I wasn't sure which ones I needed, if I needed them all, if I could mix and match, ...

So here's what I know from a matrix perspective...

There's also an additional matrix that I came up with:

The idea here is that yes, you can mix and match a bunch of these things.

The only thing you can't mix up is Gradle and the Workspace plugin version. If you're using Gradle 8, you need workspace 10.1+ and vice-versa, otherwise anything else goes.

This means you could use your existing Blade 6 to create a Gradle 7 workspace using 10.0.6 and JDK 11 targeting DXP 2024.Q2+, or you could use Blade 7 to create a Gradle 8 workspace using 10.1.3 and JDK 21 targeting DXP 2024.Q1, ...

Conclusion

So now that you've seen the matrix, you might be asking yourself what, if anything, should you change?

First let's start with the easy answer - nothing, unless you need to.

Okay, but what need might you be looking at? Well, having to move to Gradle 8 for the later version could force your hand.

JDK might also force your hand, but I'd only want to use it for the runtime until all of the build issues are squared away.

I hope this helps straighten things out for you, and let me know if you have any matrix incompatibilities that fail for you...