Skip to main content
Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.

JavaLoader Needs Access To Internal ColdFusion Java Components In ColdFusion 2018

By Ben Nadel on
Tags: ColdFusion

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 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:

ColdFusion 2018 administrator settings for internal ColdFusion Java objects.

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:
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.

Reply to this Comment


Ha, that's awesome!! And that's why I bother documenting this kind of stuff. Thanks for letting me know this was helpful :D

Reply to this Comment

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


Reply to this Comment


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?

Reply to this Comment

First quick correction missed a letter (should be UNNAMED not UNAMED) in my original post the line should be


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

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

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.

Reply to this Comment


: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.

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Blog
Live in the Now
NEW: Some basic markdown formatting is now supported: bold, italic, blockquotes, lists, fenced code-blocks. Read more about markdown syntax »
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.