Support for oJDK17

[krismarc]

Dear @kevin-ortega and other buildpack contributors,

is there any plan for enabling support for oJDK17?

We did open a case with IBM (TS008791818) Seems like colleagues assigned to the ticket are not really familiar with the Buildpack itself. Could you please get in touch with them and sort this out? They do suspect that liberty is wrongly getting started with java17. However, this is handled by the Buildpack, right?

Basically 'trade' test app is unable to get started with java17 2022-03-21 14:25:32 [APP/PROC/WEB/0] OUT [INFO ] FFDC1015I: An FFDC Incident has been created: "java.lang.IllegalAccessException: class com.ibm.ws.kernel.pseudo.internal.PseudoContextFactory cannot access class com.sun.jndi.ldap.LdapCtxFactory (in module java.naming) because module java.naming does not export com.sun.jndi.ldap to unnamed module @f630ab39 com.ibm.ws.kernel.pseudo.internal.PseudoContextFactory 48" at ffdc_22.03.21_13.25.32.0.log

We would really appreciate your help and support :)

Best regards, K.M.

[kevin-ortega]

@krismarc Thanks for reaching out. I read through the SF case. I will reach out to the Liberty team.

You are correct, the buildpack is providing Java 17 to the application because it has been configured:

-----> Downloading IBM 17.0.2_001 JRE from https://ojdk-j9-17-0-2-0-01.appcloudtest-np.swissre.com/linux/sr-openj9-java-jre-17.0.2.0_01-linux.tar.gz ... (0.7s)

At this time, we have no specific plans to enable Java 17 in the buildpack.

[krismarc]

@kevin-ortega Thanks for quick answer, highly appreciated. Indeed, that's our so called offline repo and we did put new java there as usual. As I understand this requires some extra actions in order to get it started properly using the Buildpack. Manually using a standalone Liberty we are able to get all things up and running without any issues. Even if we figure this out, we would like to avoid having the Buildpack customized by ourselves.

btw, are there any differences between Buildpacks posted here in the github and IBM's downloads center ? ibm-websphere-liberty-buildpack-v3.44.0.0.zip (222.7 MB)

Best regards, K.M.

[kevin-ortega]

@krismarc They suggesting setting JAVA_HOME to $PWD/.java/jre instead of $PWD/.java/. Have you forked the repo and built the buildpack? I'm assuming you have since the staging output shows liberty and java that is not available in the buildpack.

The buildpack available on fixcentral is built from the buildpack here. If I recall correctly, it is an admin buildpack and has liberty and java cached in it.

[kevin-ortega]

Can you ssh into the app and navigate to ~/app/.java and provide output of ls? I pushed an app using openjdk v17 and I don't see a jre directory.

[kevin-ortega]

@krismarc I pushed an app using semeru openj9 v17 and openjdk v17 and neither had a jre directory in ~/app/.java. But, your message.log shows java.home to be /home/vcap/app/.java/jre.

And JAVA_HOME is $PWD/.java, according to your staging log. The liberty team believes that is the problem.

[kevin-ortega]

@krismarc I pushed an app using both semeru openj9 v17 JRE and JDK. In both cases, JAVA_HOME=\"$PWD/.java\" and java.home = /home/vcap/app/.java are set correctly.

The liberty team believes JAVA_HOME is not set correctly based on where the JRE is actually installed.

[krismarc]

@kevin-ortega yes, there's jre directory inside .java but this never changed in our setup. We use the same with java8 and 11 without any issues in starting any app using your Buildpack. Should we change it just for 17? And yes, we are using forked buildpack, however without any code changes. We just put our offline repo urls there and we maintain our java/liberty versions via index.ymls. Keeping the source code is important for us to avoid maintenance of customized changes in the future.

As I understand, JAVA_HOME and java.home should be the same? I am still not sure where we could have messed this up . As said, we never had issues with this until now.

I'll take closer look at this tomorrow. Thanks for your input, I'll keep you posted.

[kevin-ortega]

Yes, JAVA_HOME and java.home should be the same. But the real issue is JAVA_HOME is not pointing to the JRE, it's pointing one directory up. The buildpack is not expecting ~/app/.java/jre and sets JAVA_HOME to ~/app/.java. I don't know if the particular java17 you're downloading is different from the semeru v17 JDKs and JRE I tried but neither had a jre directory.

This is the semeru jdk I used:

 -----> Downloading OpenJDK jdk-17.0.2+8_openj9-0.30.0 from https://github.com/AdoptOpenJDK/semeru17-binaries/releases/download/jdk-17.0.2%2B8_openj9-0.30.0/ibm-semeru-open-jdk_x64_linux_17.0.2_8_openj9-0.30.0.tar.gz 

I am out of the office until Monday April 18th.

[krismarc]

Hey @kevin-ortega,

so you all were right. It's indeed JAVA_HOME problem. The one which is in use during the staging phase.

"web": ".liberty/create_vars.rb wlp/usr/servers/defaultServer/runtime-vars.xml && .liberty/calculate_memory.rb && WLP_SKIP_MAXPERMSIZE=true JAVA_HOME=\"$PWD/.java/jre\" WLP_USER_DIR=\"$PWD/wlp/usr\" exec .liberty/bin/server run defaultServer"

..so, it means we never really had this JAVA_HOME set properly and this never caused any issue to us :) Applications always used to start properly without it.

In order to resolve our initial problem with the lack of accessibility between Liberty classes and Internal java ones. Java changes described here.

"java.lang.IllegalAccessException: class com.ibm.ws.kernel.pseudo.internal.PseudoContextFactory cannot access class com.sun.jndi.ldap.LdapCtxFactory (in module java.naming) because module java.naming does not export com.sun.jndi.ldap to unnamed module @79c12353 com.ibm.ws.kernel.pseudo.internal.PseudoContextFactory 48"

We had to add exports manually or make a use of default java9.options file. ..and this file is enabled only if you meet some conditions in the script which runs liberty (server) (which is a check of proper JAVA_HOME set)

  if [ -z "${JAVA_HOME}" ]; then
    JAVA_PATH_FROM_PATH=$(command -v java)
    if [ -n "${JAVA_PATH_FROM_PATH}" ] ; then
      JPMS_MODULE_FILE_LOCATION=$(dirname $(dirname $JAVA_PATH_FROM_PATH))/lib/modules
    fi
  else
    JPMS_MODULE_FILE_LOCATION="${JAVA_HOME}/lib/modules"
  fi

  # If we are running on Java 9, apply Liberty's built-in java 9 options
  if [ -f "${JPMS_MODULE_FILE_LOCATION}" ]; then
    mergeJVMOptions "${WLP_INSTALL_DIR}/lib/platform/java/java9.options"
  fi

Thanks for the right hint!

One more question comes to my mind.. what is also going to get enabled or disabled by turning on the right JAVA_HOME? I am afraid this might be not enabling the java9.options file only. I am worried about unexpected side effects of some new configurations enabled/disabled.

Best regards, K.M.

[kevin-ortega]

Please reopen if you need additional assistance.