JAVA_TOOL_OPTIONS can't be picked up when the params length > 1024 in JAVA8

[zhoufenqin]

What happened?

The java_opts helper will adding $JAVA_OPTS to $JAVA_TOOL_OPTIONS", see java_opts.go
When using java8, if configured JAVA_OPTS params length is too long(>1024), then the JAVA_TOOL_OPTIONS can't be loaded into the process.
I saw some issues about this, is there any way to workaround?

for JAVA 11, the JAVA_TOOL_OPTIONS works well

• What were you attempting to do?
  Using JAVA8 and config JAVA_OPTS with multiple parameters.

• What did you expect to happen?
  The configured JAVA_OPTS can be loaded into the main process

• What was the actual behavior? Please provide log output, if possible.
  If the length is too long(> 1024), the JAVA_OPTS will be ignored and JAVA_TOOL_OPTIONS can't be picked up.

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.
  kpack 0.5.2

• What buildpacks are you using? Please include versions.
  libjvm 1.36.1

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

[dmikusa]

I saw some issues about this, is there any way to workaround?

Besides upgrading to Java 11+, it doesn't seem like it. The SO post you linked to indicates that it is a hard-coded limit in Java. Let me double-check with our OpenJDK vendor though and see if they have any suggestions.

[zhoufenqin]

Thanks @dmikusa-pivotal, any update about this?

[dmikusa]

Yes, I talked to our JVM vendor and they said there's no way around the limit. It's hard coded.

We talked about a couple of options here. Minimally, making the process error out when you exceed the 1024 limit, that way things don't silently fail. Depending on how the OpenJDK community feels, they might also be able to backport support to remove the size restriction. That's more work though and it's Java 8, so it ultimately depends on what the community is willing to accept. I don't think there will be a quick turnaround on this.

In the meantime, the best we could do would be to add a helper which checks the size of JAVA_TOOL_OPTIONS when Java 8 is being used. That would run before your app and we could make it fail, which would, in turn, fail the application. Would that be of interest?

[zhoufenqin]

thank you @dmikusa-pivotal, I don't think failing the application directly is a good choice, can we log the size error and provide an env to decide whether fail the application or not? I think it's more flexible for us

[zhoufenqin]

@dmikusa along with the increasing length of our internal JVM parameters, 1024 is not enough for our customers' JAVA 8 applications.
I saw that the libjvm buildpack will add lots of jvm parameters, like -Djava.security.properties=/layers/paketo-buildpacks_microsoft-openjdk/java-security-properties/java-security.properties -XX:+ExitOnOutOfMemoryError -XX:ActiveProcessorCount=16 -XX:MaxMetaspaceSize=148644K -XX:MaxDirectMemorySize=10M -Xmx592732K -XX:ReservedCodeCacheSize=240M -Xss1M, can you provide environments to allow us disable the JVM parameters, like don't set -XX:MaxDirectMemorySize=10M -XX:MaxMetaspaceSize=148644K automatically in buildpacks, allow customer to determine to use it or not. if it's not set, just use the default value that JVM provides

[dmikusa]

can you provide environments to allow us disable the JVM parameters, like don't set -XX:MaxDirectMemorySize=10M -XX:MaxMetaspaceSize=148644K automatically in buildpacks, allow customer to determine to use it or not. if it's not set, just use the default value that JVM provides

No, sorry, that would break buildpack functionality. We can't do that.

[zmssp]

If customer have own jvm parameters, which one will be used. The buildpack jvm parameters or customers?

[dmikusa]

Both. If a user sets JAVA_TOOL_OPTIONS those they are merged with the buildpack added options.

If a user sets the property foo and the buildpack also sets the property foo, it depends. In some cases, like memory settings, the buildpack is specifically written to look for user-set options and back off, i.e. the user's setting wins. In other cases, it will override the user setting. That is done when the buildpack needs to enforce something specific to prevent failures, like if a setting requires a path to something in the buildpack environment. The buildpack will take ownership and override the value so that the path is set correctly.