Java 25 version can fail to startup

Problem Statement

Running dotCMS with Java 25 in the containerized environment can hang when and ByteBuddy tries to init. Below is a stack trace.

"main" #3 [48] prio=5 os_prio=0 cpu=10948.99ms elapsed=18.58s tid=0x000070e316a3ea10 nid=48 waiting on condition  [0x000070e318fe8000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@25.0.2/Native Method)
	- parking to wait for  <0x0000000754837ab0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(java.base@25.0.2/LockSupport.java:369)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base@25.0.2/AbstractQueuedSynchronizer.java:520)
	at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base@25.0.2/ForkJoinPool.java:4364)
	at java.util.concurrent.ForkJoinPool.managedBlock(java.base@25.0.2/ForkJoinPool.java:4310)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@25.0.2/AbstractQueuedSynchronizer.java:1752)
	at java.lang.ProcessImpl.waitFor(java.base@25.0.2/ProcessImpl.java:423)
	at net.bytebuddy.agent.ByteBuddyAgent.installExternal(ByteBuddyAgent.java:684)
	at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:612)
	at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:592)
	- locked <0x0000000754b80928> (a java.lang.Class for net.bytebuddy.agent.ByteBuddyAgent)
	at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:544)
	at net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:521)
	at com.dotcms.business.bytebuddy.ByteBuddyFactory.init(ByteBuddyFactory.java:92)
	at com.dotcms.business.bytebuddy.ByteBuddyFactory.<clinit>(ByteBuddyFactory.java:78)
	at com.dotmarketing.listeners.ContextLifecycleListener.contextInitialized(ContextLifecycleListener.java:66)

Steps to Reproduce

Start dotcms/dotcms:java-25 in k8s

Acceptance Criteria

• dotCMS should start up cleanly

dotCMS Version

26.05.05

Cause

⏺ Root cause: ByteBuddyAgent.install() falls back to installExternal which spawns a child JVM to attach back to the parent, then blocks on process.waitFor(). In Java 9+ self-attach is disabled by default; Java 21/25 tightened it further. In a
Kubernetes container this external-attach process either can't find the JDK attach binaries (JRE-only image) or is blocked, so the parent hangs forever at ByteBuddyFactory. line 78.

Fix — add this JVM flag so ByteBuddy uses in-process self-attach and skips spawning a child:

-Djdk.attach.allowAttachSelf=true 

Optional belt-and-suspenders for Java 25:

  --enable-native-access=ALL-UNNAMED                                                                                                                                                                                                                     
  -Djdk.instrument.traceUsage=false  

Where to set it:

• Tomcat: CATALINA_OPTS (or JAVA_TOOL_OPTIONS env in the K8s Deployment)
• dotCMS docker entrypoint typically reads JAVA_OPTS / CATALINA_OPTS

Verify the container has a full JDK (not JRE) — jcmd/jattach binaries must exist for any external-attach fallback to work, but with allowAttachSelf=true you won't need them.

Long-term hardening options in ByteBuddyFactory.init() (lines 90-97):

1. Call ByteBuddyAgent.install(AttachmentProvider.ForEmulatedAttachment.INSTANCE) to force self-attach and fail fast instead of hanging.
2. Or load ByteBuddy as a real -javaagent:byte-buddy-agent.jar at JVM start — eliminates runtime attach entirely and is the recommended path for production/containers.

Reproduce the startup hang with dotcms/dotcms:java-25 in Kubernetes, then inspect ByteBuddyFactory.init() around lines 78 and 90-97 and the container's JVM option handling. Confirm the chosen startup or ByteBuddy change makes dotCMS start cleanly without blocking at ByteBuddyAgent.install().