JavaLoader Needs Access To Internal ColdFusion Java Components In ColdFusion 2018
This past week, I updated my blog from ColdFusion 10 to ColdFusion 2018. ColdFusion is generally backwards compatible; so I figured this would be a seamless transition. However, I ended up running into an issue with JavaLoader, which I wanted to share because my Google searches for the related error yielded no results. As such, I thought sharing the details could help others who run into the same JavaLoader issue.
ASIDE: Why ColdFusion 2018 and not Lucee 5.3.2.77? Frankly, I use managed hosting on Hostek for my blog; and, the Support team recommended ColdFusion 2018 over Lucee as they have better support for it on Windows servers. And, I don't know enough about server management to argue with them, which is why I use "managed hosting" in the first place. I love Lucee, and I hope to be on it eventually; however, as a first step, I just wanted to get my server upgraded to a version of ColdFusion that had active support.
So, I installed ColdFusion 2018, installed the MySQL JDBC Connector, created my datasource, configured my wsconfig
connector, and then attempted to boot-up my site. At this point, I was greeted with a Java error that made no sense to me:
Unable to make public void jdk.internal.loader.BuiltinClassLoader.loadModule(java.lang.module.ModuleReference) accessible: module java.base does not "exports jdk.internal.loader" to unnamed module @6c9e74f3
From the stacktrace, I could see that ColdFusion was failing somewhere in the JavaLoader code:
JavaLoader-1.2/javaloader/JavaProxy.cfc:34
JavaLoader-1.2/javaloader/JavaLoader.cfc:448
JavaLoader-1.2/javaloader/JavaLoader.cfc:252
JavaLoader-1.2/javaloader/JavaLoader.cfc:50
After having no luck Googling for the error, I started looking through the ColdFusion 2018 Administrator with the hunch that this was somehow security related. And that's when I found the server setting, Disable access to internal ColdFusion Java components:
Since JavaLoader's whole reason-for-being relates to creating Java objects, I went ahead and unchecked that ColdFusion Server Settings box and reloaded my site. And, much to my satisfaction, it started working. So, clearly, the JavaLoader project needs access to the internal ColdFusion Java components in order to do its job.
To make sure this wasn't a coincidence, I re-checked the security box and attempted to reload my site. Once again, it failed to load; however, this time, it failed with a different error message - one that was much more user-friendly:
Permission denied for creating Java object: coldfusion.runtime.java.JavaProxy.
Access to Java objects in the ColdFusion package has been disabled by the administrator.
So clearly, this ColdFusion 2018 Server Setting was the issue. I have no idea why the error message was different on server start vs. server setting update. But, I'm happy to have it working now. And, hopefully the above error messages will help others that run into the same issue.
Reader Comments
Just wanted to let you know I recently updated from CF10 to CF2018 and this post fixed some of the errors we were getting on production and saved me what could have been a long debugging session.
@Isaac,
Ha, that's awesome!! And that's why I bother documenting this kind of stuff. Thanks for letting me know this was helpful :D
I had a requirement that access to internal coldfusion objects had to be disabled.
After a lot of reserach I found a alternative solution but it still require a change in the Coldfusion administrator
In the JAVA and JVM setting in the JVM arguments text box add the following
--add-exports=java.base/jdk.internal.loader=ALL-UNAMED
@Mark,
Oh, that's interesting. Most of the JVM stuff goes over my head (this included). So, I'll just take your word for it :D
When you changed this, did you see the checkbox in the Admin update to reflect these changes? Or, does this seem to be working via a different mechanism?
First quick correction missed a letter (should be UNNAMED not UNAMED) in my original post the line should be
--add-exports=java.base/jdk.internal.loader=ALL-UNNAMED
This is a different mechanic. Access to internal Coldfusion java components will still not be allowed. I did test this to confirm.
I could not find any information about this error specifically to coldfusion but once I realize when I changed Coldfusion version I also changed from JAVA 8 to JAVA 9 I took a different tactics and started looking at issues people had transitioning from JAVA 8 to JAVA 9 and there a ton of information out there.
First quick background about JAVA 9, it introduced the concepts of modules. Since JAVA 8 did not have the concept of modules any JAR files compiled without module information are considered UNNAMED modules by JAVA 9.
A quick over view of Unnamed Modules I found at this website
https://www.logicbig.com/tutorials/core-java-tutorial/modules/unnamed-modules.html
Taking this information and the error message coldfusion gave I figured there must be a dependency that it cant get access too.
After further research I found this website
https://blog.codefx.org/java/five-command-line-options-hack-java-module-system/
which is how I came up with that command line that worked.
It will give jdk.internal.loader.BuiltinClassLoader.loadModule access to all the packages it need at compile but not run time.
Therefore you still can not run any internal java components at runtime when the boxed is checked. Instead JAVA Loader takes care of that by using a different class paths then the coldfusion internal one.
@Mark,
:mind-blown: That's some fascinating stuff. Mostly over my head, but I appreciate the in-depth description, especially for anyone else who comes this way.
@Ben Thanks for sharing! This was super helpful and fixed my issue.
@Rachel,
That's awesome! So happy I could help.
This saved my bacon on a CF2018 update from Java 8 from Java 11.
@Gavin,
Ha ha, small world :D
Ben you have helped me with so much, please illumiate me on HOW DO I INSTALL Javaloader?
Apparenty it's not as easy as copying all CFCs into the dedicated & mapped CFC folder, then copying all JAR files into EACH AND EVERY 'lib' directory I could find, I still get "Could not find the ColdFusion component or interface javaloader.JavaLoader." in the provided test examples.
Coldfusion 9. Thank you in advance, I am desperate.
As always Ben, you are awesome. I'm finally upgrading from CF 2016 to 2021 and was having weird issues with your POI spreadsheet utility. This saved the day💥!
@Mike,
Wooot! Glad to have helped make the transition easier :D
@Steve,
Did you ever figure it out? You shouldn't have to copy the JAR files into lots of different folders. The whole point of the JavaLoader library is that you can point it directly at JAR file paths; so, your JAR files can live wherever you want.
That said, if you can't even find the JavaLoader interface, that's a problem. Usually, what I do is create a mapping in my
Application.cfc
that points to the JavaLoader folder. Like:And then, I can instantiate it like:
Something like that. It's been a while since I've started a "fresh" application - been working in the same code for like a decade 🤪 so, I get a bit rusty on the low-level instantiation details.
I plugged my error message into Google without much hope of a quick solution, fully ready to dig through pages and pages of not-quite-applicable suggestions.
Imagine my surprise when this came up first in the results, with exactly the right info!
Thanks, Ben!
By the way, I ran into this after running the CF2021 Auto-lockdown tool. So it seems that checking that box is part of the lockdown script.
@David,
I'm not a security expert by any means, so I wouldn't immediately understand why having access to the Java layer would pose an additional threat to the application. After all, much of what ColdFusion offers is just an abstraction of the Java layer anyway. But, I suppose they have valid reasons.
That said, I'm glad this helped 💪