Convert Lucee component to Java class?

I’m entertaining the idea of converting a Lucee component into a Java class and then turn it into war file and have Tomcat to serve it. Doable? Or too much hassles like Java dependencies etc.
If doable, it might be a useful learning experience. Thoughts?

you’re pretty much describing what Lucee already does out of the box

if you want a learning exercise with java and lucee, why not start by picking a open bug/enhancement request and fixing it :slight_smile:

Can you clarify that?

And let me add this, a java.class file may be directly used by an Java native application.
So, one question is, how would Java interact with a relational database, say, MS SQL Server?
via jdbc?
Or would I be better off googling for this?

Deploying a separate war is going to put you in a different Tomcat class loader. Which means your java.class can’t use ANY Lucee objects - datasources, mail services, utility functions, etc. Considering CFML is loosely-typed, anything accessing a variable goes through a helper function. Things like scopes (variable/request/session/etc) and core language features are going to be in that code. None of that will work outside that classloader.

At that point you might as well just write java servlets or jsps and use Tomcat native services, resource management etc for JNDI/JDBC resources.

Deploying a java class, i.e. in a jar or in the classpath, inside the same webapp as Lucee has always been doable. See java settings in the Application.cfc.

Just because Lucee is Java, and some other app is Java, doesn’t mean your class is going to work correctly in both. Every Java app is going to be based on libraries and APIs and the other objects within your class loader. So, sure, a Java class might use native JDBC. A Java class designed to work with Lucee or ACF might pull the datasource service and get the JDBC Driver or Datasource object corresponding to a Lucee managed resource. (I’ve done this. In fact I have a spring app running in the same web.xml as Adobe CF, sharing session variables and JDBC pools. I don’t recommend it. It’s unnecessary and dangerous when things like microservices are usually a better fit for a polyglot implementation.) A Java class running outside Lucee’s classloader won’t be able to do any of that.

What Zac is alluding to is that all CFML gets compiled to Java bytecode under the hood. But it’s Java bytecode using Lucee native classes, functions and features. If you just want a bean that you can use instead of a cfc - that’s a lot of work considering the compilation overhead is so low. If you want something you can write in Lucee, compile to Java and dump in another webapp entirely - that’s just not going to happen - there’s no reason for Lucee to support transpiling to Java. The best you could do is take the java source Lucee compiles (if possible, if not you’d have to decompile the class files) and then remove the Lucee specific bits to make it run in Java.

All of that is likely more trouble than it’s worth.

And yes, I’ve done this thought experiment multiple times in the past. It is possible to transpile CFML (or really any language) to any other language. Consider Wasabi: https://www.joelonsoftware.com/2006/09/01/wasabi/

You’d need a parser, or you’d have to reuse one (i.e. Lucee’s or ACF’s), and then you’d need to write your own code to generate the language of your choice. Generally I consider this when it comes time to pay for our licensing. Wouldn’t it be great if I didn’t need ACF and I was just running native Java… But it’s impractical. Even switching to another engine like moving ACF to Lucee is going to have compatibility issues and tooling differences. It’s going to be 10 times worse switching to another language with completely different infrastructure.

What DOES make sense… Personally I like the idea of strictly typed beans using Java classes, and serializing with Jackson or GSON directly, to circumvent all the issues with CF based JSON serialization. You can write the bean in Java. (long and tedious and repetitive). Or you can write it in Groovy (really easy), or you can write it in Kotlin (one liner data class). As long as you compile it to a class file and include any dependent libraries, you’re good to go.

Without a better idea of what you’re trying to accomplish we can’t really recommend a better option for you.

1 Like

Very informative, much appreciated.

Especially love the following insight.

A thought to myself was, consider to turn some component into a Java class and make it work outside Lucee realm as a way to learn Java (not necessarily as a Java programmer but be able to read Java code effectively). Btw, I just looked up db connection with Java, it requires several libraries among others, no wonder people say programming in Java would take twice amount of time compared to Lucee.

Just “wrote” my virgin .Java file with 2 classes, one as sort of wrapper, another, setting up db connection ( via jdbc ) & subsequently runs a query to fetch some data. With the wrapper calling the other’s method to return data.

And since we have a Java jdk comes with Lucee already, I thought why not use its
javac utility to compile it and see what happens. Oh boy, 3 errors.
May I post the java “code” here?
I’d appreciate a helping hand.

4 posts were split to a new topic: Getting error message: “coldfusion/runtime/UDFMethod” and Type: “java.lang.NoClassDefFoundError”