Introduction

So, the various flavors of Java have just released the shiny new version, 11.0.20.

Like many, I'm sure, I tried to start up Liferay with this new JDK and hit an exception at startup:

Caused by: java.util.zip.ZipException: Invalid CEN header (invalid zip64 extra 
    data field size)
  at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1752) ~[?:?]
  at java.util.zip.ZipFile$Source.checkExtraFields(ZipFile.java:1268) ~[?:?]
  at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1717) ~[?:?]
  at java.util.zip.ZipFile$Source.(ZipFile.java:1444) ~[?:?]
  at java.util.zip.ZipFile$Source.get(ZipFile.java:1407) ~[?:?]
  at java.util.zip.ZipFile$CleanableResource.(ZipFile.java:756) ~[?:?]
  at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:873) ~[?:?]
  at java.util.zip.ZipFile.(ZipFile.java:271) ~[?:?]
  at java.util.zip.ZipFile.(ZipFile.java:200) ~[?:?]
  at java.util.zip.ZipFile.(ZipFile.java:214) ~[?:?]
  at org.eclipse.osgi.framework.util.SecureAction.getZipFile
    (SecureAction.java:304) ~[org.eclipse.osgi.jar:?]
  at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.getZipFile
    (ZipBundleFile.java:132) ~[org.eclipse.osgi.jar:?]
  at org.eclipse.osgi.storage.bundlefile.ZipBundleFile.open
    (ZipBundleFile.java:424) ~[org.eclipse.osgi.jar:?]
  at org.eclipse.osgi.storage.Storage.install
    (Storage.java:652) ~[org.eclipse.osgi.jar:?]
  ... 56 more

But, if you use JDK 11.0.19 or earlier, you don't see this at all.

So what's going on?

Change to JDK

The JDK has been updated (of course, you're now on 11.0.20, yeah?), but the important bit is here: JDK-8302483. They added some cool new zip file validation, but now our portal can't start up properly.

Avoiding the Problem

Well, the easy way to avoid this is to not update to 11.0.20, but this isn't really a long-term fix, is it. For example, they're not likely to remove this fix from 11.0.21 or later when they come out, are they?

A proper fix is to add this to your command line:

   -Djdk.util.zip.disableZip64ExtraFieldValidation=true

You can go into the tomcat/bin/setenv.sh or tomcat/bin/setenv.bat file and add it to the JDK_JAVA_OPTIONS (or even the CATALINA_OPTIONS) variable.

Liferay does plan on setting this as a proper system property, but that won't help you if you're running on 7.0, 7.1, 7.2, 7.3 or an earlier 7.4...

So it's probably best just to go ahead and add this to your environments now, rather than wait until it surprises you later...

Oh, and you can read the confirmation response from Liferay: https://help.liferay.com/hc/en-us/articles/17904500197389

Update 07/26/2023

Some clients and community members are now reporting issues trying to build their workspaces under Java 11.0.20...

Our team is looking into it, but the best advice that I can provide at the moment is to hold off using 11.0.20 for anything, especially until the Developer Tools team can address the build issues.

And note that it might require changing versions of different workspace plugins for this to work, so if you're building for an older version, 7.0 - 7.3 and maybe even 7.4 bundles before say 85, you might be stuck at 11.0.19 until your toolchain can be updated completely...

Update 08/07/2023

So I actually have two updates to provide here...

First, if you want to stick with your current workspace plugin versions, you may find cases where you need to add the parameter above.

For example, the initBundle command will fail, so you can go into the build.gradle file at the root of your workspace and add the following:

initBundle {
	jvmArgs = ['-Djdk.util.zip.disableZip64ExtraFieldValidation=true']
}

The second update, though, is that instead of adding this kind of thing to your workspaces, you can go into the settings.gradle file and update the workspace plugin to version 7.0.1 as follows:

  classpath group: "com.liferay", name: "com.liferay.gradle.plugins.workspace", 
    version: "7.0.1"

Using 7.0.1 you don't need (and in fact you should remove) the parameter for initBundle.

You might be thinking "my path is clear, I'll just update the workspace plugin and be done with it." In cases where you're targeting 7.4, I would believe this probably to be an accurate statement.

However, if you are targeting 7.3 or older, personally I would want to prove this out. Updating the workspace plugin version inherently updates all of the other plugins the workspace uses (such as Service Builder and REST Builder, for example). It may actually be more important to you that you continue using versions of those plugins that are correctly targeting your version of Liferay...

Here's my suggestion...

If you have been using blade init to create your workspaces (like I do), it is highly likely that your workspace plugin version is still like 4.0.30, and that's quite out of date with many of the recent workspace plugin versions.

So, as always, I suggest caution... Have a backup of your workspace, something that you can roll back to in case your tests go sideways.

Update your workspace to 7.0.1. Next, though, you have to test this all out. If you have a local bundles directory, delete it (remember we have a backup). Also do a gradlew clean initBundle deploy and then start up your local bundle and make sure everything looks good.

If you have ServiceBuilder or REST Builder projects, go and re-run those guys, rebuild and redeploy those modules too.

Basically make sure that by switching to 7.0.1 you haven't broken your builds at all...

And, if you find that something isn't working right, then toss this all out and restore your backup and just do the initBundle change mentioned above. You don't want to create work for yourself if 7.0.1 isn't going to fly, you just want to test it first before running off and changing things that may prove to be hard to roll back later on.

Well, this should do it on the updates... Going forward, I think this now gives us some paths to build using 11.0.20+ and run using 11.0.20+, so hopefully we can put this behind us...

Update 08/17/2023

Yet another update...

So there are still issues with 7.0.2 and JDK 11.0.20+.

Currently the recommendation is to set your settings.gradle to the following:

buildscript {
  dependencies {
    classpath group: "org.yaml", name: "snakeyaml", version: "1.32"
    classpath group: "biz.aQute.bnd", name: "biz.aQute.bnd", version: "5.2.0"
    classpath group: "com.liferay", 
        name: "com.liferay.portal.tools.bundle.support", version: "3.7.4"
    classpath(group: "com.liferay", 
        name: "com.liferay.gradle.plugins.workspace", version: "7.0.1") {
      exclude group: "biz.aQute.bnd", module: "biz.aQute.bnd"
      exclude group: "com.liferay", 
          module: "com.liferay.portal.tools.bundle.support"
    }
    classpath group: "net.saliman", 
        name: "gradle-properties-plugin", version: "1.4.6"
  }
  repositories {
    mavenLocal()
    maven {
      url "https://repository-cdn.liferay.com/nexus/content/groups/public"
    }
  }
}
apply plugin: "com.liferay.workspace"

Is this the final update? Honestly, I don't know.

My recommendation though to stay at 11.0.19 still seems to be rock-solid though...

Update 08/18/2023 #1

The saga continues...

So previously you might have seen that I was referring to workspace plugin version 7.0.2. Today I have updated the blog to say 7.0.1.

Apparently 7.0.2+ are going to be for Gradle 7 support (that's going to be a whole other can of worms that I suggest you avoid at the moment).

So if you've been following along and have 7.0.2 listed, you may want to revert to 7.0.1.

Update 08/18/2023 #2

Okay, so this is hopefully the final word on this for developers who need to use 11.0.20+...

The only thing that you need to do to support 11.0.20+ in your workspaces is to add the tools bundle support plugin version 3.7.4 or higher.

To demonstrate the change, here's the settings.gradle from a new workspace that I've just created with Blade, with the necessary change applied:

buildscript {
  dependencies {
    classpath group: "biz.aQute.bnd", name: "biz.aQute.bnd", version: "5.2.0"
    classpath group: "com.liferay", 
        name: "com.liferay.portal.tools.bundle.support", version: "3.7.4"
    classpath(group: "com.liferay", 
        name: "com.liferay.gradle.plugins.workspace", version: "4.0.30") {
      exclude group: "biz.aQute.bnd", module: "biz.aQute.bnd"
      exclude group: "com.liferay", 
          module: "com.liferay.portal.tools.bundle.support"
    }
    classpath group: "net.saliman", 
        name: "gradle-properties-plugin", version: "1.4.6"
  }

  repositories {
    maven {
      url "https://repository-cdn.liferay.com/nexus/content/groups/public"
    }

    maven {
      url "https://repository.liferay.com/nexus/content/groups/public"
    }
  }
}

apply plugin: "net.saliman.properties"

apply plugin: "com.liferay.workspace"

So, just to explain so we're all on the same page...

The com.liferay.portal.tools.bundle.support module is the one that contains the initBundle task implementation code, so he has been the one responsible for tripping up on JDK 11.0.20+ usage.

The 3.7.4 version of the module has been updated to address the issue.

So in the buildscript above, we're including version 3.7.4 of the tools support module, but we're also excluding the older one that the workspace plugin would normally use.

With these two changes, this workspace should be ready for 11.0.20+ usage without throwing any kind of JDK errors.

Famous last words, right?

I hope they're the last words. Anyway, give them a try and let me know if you are successful or, more importantly, if you encounter any other JDK-related exceptions...