Skip to main content
Ben Nadel at the React NYC Meetup (Oct. 2018) with: Nir Kaufman
Ben Nadel at the React NYC Meetup (Oct. 2018) with: Nir Kaufman

JavaLoader Needs Access To Internal ColdFusion Java Components In ColdFusion 2018

By
Published in Comments (16)

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:

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

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

15,848 Comments

@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

7 Comments

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

15,848 Comments

@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?

7 Comments

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.

15,848 Comments

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

1 Comments

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.

4 Comments

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💥!

15,848 Comments

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

this.mappings = {
	"/javaloader": "/path/to/my/javaloader"
};

And then, I can instantiate it like:

var my loader = new javaloader.JavaLoader();

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.

7 Comments

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.

15,848 Comments

@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 💪

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel