Using cfml from Java? (the opposite of createobject("java")

language
1

I’ve got the current Lucee 5.3 java source from github able to build with ant and the patch works when I run it in a real server. Thank you very much for making it easy for us to participate with the Java on all the recent Lucee 5 versions.

I was hoping for a little internal knowledge about the current github Lucee 5.3 branch.

Is there a hidden way to allow me to execute the loader Main.java class or some other class directly in the eclipse or intellij run configuration? In older versions of Lucee, there was a way to do this. When I open .project, it seems to be a broken environment in eclipse in both 5.0.x and 5.3. Maybe you guys gave up on having a way to execute and debug the java, but that seems like it would be more time consuming to develop that way. IntelliJ seems way more efficient to work with compared to eclipse. At the moment, it seems best to use ant and IntelliJ to modify Lucee if I can’t get better information about an eclipse project that already works perhaps.

Additionally, I was curious if it is possible to directly access CFML data types from the Java and call CFML objects via some class in the Java project? I wanted to make lex extensions for Lucee language (which looks easy), and also have Java make direct changes to the application scope and other things potentially (which is undocumented but probably doable with just reading the Java).

I was also curious if Lucee could be made to function without servlet technology, and just run as a CLI application or integrated with a different server method like AKKA HTTP, etc. I was thinking of exploring other ways of request pooling to see how that scales under load and trying other libraries for things. It looked like only a few hundred references to javax servlet are in the code, so it’s kind of a medium difficult change I could do perhaps.

I already look beyond the Adobe product by implementing Lucee exclusive features for years. I’d like to take more ownership of how we use the language in the future. I’ll probably open source some things that may help others in CFML community.

My first project is related to asynchronous queries and my security approach where I treat unescaped sql literals as exceptions. I may do the same for http after that. I already made a simple protoype in CFML for the new CFML BIFs, but I want pure Java speed with a hikaricp connection pool that is separate from Lucee’s to give even more control to CFML for managing concurrency. I was able to get it working pretty quick on both CFML and Java, so it seems like it will happen in another week or two if I focus on this. Plugging the result back into native CFML object is the next step I was going to explore, I’d appreciate any guidance in this area.

2

I figured out how to do all this and got it working really well.

3

Can you share?

4

BTW, I somehow missed this topic when you originally posted it or I would have added a couple thoughts then. You can use CFML from the CLI right now. The easiest method is probably CommandBox Task Runners.

CommandBox> task create --open
CommandBox> task run

Those two lines will have you a command line task scaffolded out and running with no web server and it comes with ANSI formatting, interactive libraries for collecting input, and a modular architecture for loading 3rd party libs in .

Now, as far as running CFML from inside of a Java app, I would recommend looking at Lucee’s JSR-233 implementation. In fact, that’s exactly what CommandBox uses under the hood to load Lucee up and execute CFML. Here you can see the Java code that CommandBox uses to load Lucee and execute just enough CFML code to create a CF Mapping and then CFIncluded the CommandBox Bootstrap.cfm that loads the rest of the console app.

5

Brad,

I am getting really deep into optimizing and customizing how I use Lucee.

You might not realize that the code you pasted actually has to trigger the java servlet request flow in order to do that instead of it allowing you to run CFML without the concept of a web server. My goal was to eliminate servlet and be able to debug lucee core changes in the IDE faster. But more then that, I wanted to change how my code executes so that my request path actually starts with a pure Java implementation instead of calling CFML that then calls Java. This will let me optimize and preload the core engine of my application with things that are closer to the hardware in their performance. In particular, I’m treating hash maps and blocking I/O as the enemy with this new code I’m writing.

I ended up finding a way to operate directly against CFC methods and objects from the Java side. With this approach, there would be no servlet overhead, and it allows you to implement CFML with a totally different server / socket implementation.

Here is the specific Java code, plus I made a customization to PageContextImpl to allow me to get access to more scopes then i guess Lucee/Coldfusion care to share in the new thread.
PageContextImpl pc2 = ThreadUtil.createPageContext(
pc.getConfig(),
DevNullOutputStream.DEV_NULL_OUTPUT_STREAM,
“lucee”,
“”,
“”,
CreatePageContext.toCookies(new StructImpl()),
CreatePageContext.toPair(new StructImpl(), true),
null,
CreatePageContext.toPair(new StructImpl(), true),
CreatePageContext.castValuesToString(new StructImpl()), true, -1);
Collection.Key k=new KeyImpl(cfcMethod);
Object[] args=new Object[]{ lqResult, asyncId };
cfcObject.call(pc2, k, args);

I’m trying to allow a non-servlet approach to my flow that is based on java nio socket and custom parsing that is super optimized to my specific application and linux stack.

However, some of my Lucee extension work could be super useful to other cfml developers like I have a much more efficient non-blocking and memory efficient alternative to cfquery and I’m looking into doing more like that.

I’m inspired by the concurrency and parallel approach of things like node.js, akka/play framework, nginx, go language. I want to bring that to Lucee CFML.

Does anyone else using Lucee have an interest in what I’m doing?

1 Like
6

Very interesting stuff. I’d like to see you document some more of that. Regarding the servlets-- I’m aware of how JSR-223 works to a fair degree and while it “pretends” to be in a servlet, to be clear, there is no servlet container at all, it’s just spoofed behind the scenes. The original Railo/Lucee CLI before JSR-223 did the same basic thing. I’ve always thought the overhead of the fake servlet context and request context was negligible and I don’t have to deal with any of it since I simply pass a bit of CFML directly to CFML and I get the output back.

But overall, I think the ability to easily run CFML from Java apps is something big that can help Java devs pick up CFML in the same way that Java shops pick up Kotlin, Clojure, or Scala right now as a natural extension of their current apps. I would be interested to see what measurable performance benefits you have from your method as opposed to the JSR-223 implementation. I’m curious about this for another reason as well since I’d like for a persistent CLI process to be able to power requests (possibly via Websockets?) from, say, an Electron app without the need to spin up a full server.

1 Like