Java (via Lucee) unable to create temp files after upgrade to 11

OS: Win2012R2 / Java: OpenJDK / Lucee: / Tomcat: 9.0.24

We’ve recently upgraded Java from 8 to 11 for 2 identically configured Windows Lucee servers, one of which is working perfectly, but the other throws “access denied” exceptions when attempting to write temp files using java, for example:

file = CreateObject( "java", "" );
file.createTempFile( "tmp", ".txt" );

The stack trace begins

lucee.runtime.exp.NativeException: Access is denied at
java.base/ Method) at
java.base/ at
java.base/$TempDirectory.generateFile( at
java.base/ at java.base/jdk.internal.reflect.

The Lucee service account has full write access to the default temp folder (within Tomcat’s installation directory), and we can write files to it happily using Lucee’s FileWrite() BIF, or using java methods other than createTempFile().

I’ve also tried using a custom temp directory (with adequate permissions) with the same result.

As I say, we have another server with the exact same config which has no problem writing temp files.

Anyone else experienced this after a Java upgrade?

For now we’ve had to revert to Java 8 for Lucee on this machine, which has fixed the problem but is not a long term solution.

In case you’re wondering why we need to create temp files with Java, the answer is: we don’t explicitly, but certain java libraries we use do, such as POI when streaming SXSSF files.

Did you try Java’s getProperty(“”) to see what directory Java is looking at?

Yes, the default JVM temp directory is under the Tomcat install directory, which is the same as for Java 8 and the Lucee service has full permissions there.

What’s strange is that some temporary files are being written there and, as I say, I can write files there with no problem using Lucee’s FileWrite() or It’s just createTempFile() that’s denied.

You can pass a custom directory to createTempFile() and I tried specifying another folder to which Lucee had full access but it made no difference.

It’s as if the createTempFile thread is using a different process or something.

I tried completely re-installing Java 11 too in case I’d botched that in some way, but again no difference.