I’ve been experimenting with the new Java integration in Lucee 6.2.1 and appreciate the direction it’s heading. However, I’ve encountered several issues that have made it challenging to continue development using this feature:
- Error Messages Lack CFML Line Numbers
When exceptions occur within type="java" functions, the error messages don’t indicate the specific line number in the .cfm file where the error happened. This omission makes debugging difficult, as I often have to guess the source of the problem.
- Use of
var Keyword Causes Errors
Attempting to use var for local variable declarations within type="java" functions results in the following error:
Local variable type inference NYI; Failed in C:\lucee\tomcat\webapps\ROOT\java_test.cfm:3
(java 11 support var Local Variable Type Inference)
- Type Casting Parameters Fails
Passing parameters of certain types to Java functions leads to casting errors. This issue was also discussed in this thread.
- Calling Other
type="java" Functions
It’s unclear how to invoke other type="java" functions or standard Lucee functions from within a type="java" function.
- Declaring Custom Java Classes
Unlike Adobe ColdFusion’s <cfjava> tag, Lucee doesn’t seem to offer a straightforward way to declare and use custom Java classes directly. For reference, here’s the Adobe documentation on <cfjava>.
Thank you again for the ongoing work on Lucee. I’m looking forward to seeing how the Java integration continues to evolve, and I’d really appreciate any advice or clarification on the points above.
thanks for the feedback.
When using type="java" if you aren’t running a jdk, Lucee falls back on the jamino compiler, which has some limitations. (docs updated to reflect that)
With a JDK, the error I’m getting back does have the correct context (yes it’s 7, but the 6 throws the same exception)
We have extended the Java support in Lucee 7 further, the upcoming 6.2.2 RC already has solved some issues, with a few more outstanding.
https://luceeserver.atlassian.net/jira/software/c/projects/LDEV/boards/53?label=java&sprints=110&useStoredSettings=true
@micstriit is going to add some move examples for this integration
2 Likes
I’d like to highlight an issue I’ve encountered with type="java" functions: when runtime errors occur, the error messages often lack specific line numbers in the .cfm file, making debugging challenging.
For example:
<cfscript>
java.math.BigDecimal function getBigNumberAdd(string A, string B) type="java" {
java.math.BigDecimal a = new java.math.BigDecimal(A);
java.math.BigDecimal b = new java.math.BigDecimal(B);
return a.add(b);
}
echo(getBigNumberAdd("", ""));
</cfscript>
<cfscript>
all_travelers=queryExecute("select * from travelers",{},{datasource="lucee"});
japen=queryExecute("select * from all_travelers where county='japen'",{},{dbtype="query"});
korea=queryExecute("select * from all_travelers where county='korea'",{},{dbtype="query"});
echo(getBigNumberAdd(japen.count,korea.count));
</cfscript>
java_test_cfm$cf$getBigNumberAddb: line 25 but code less then 25 line
If A or B is empty strings, the BigDecimal constructor throws a NumberFormatException. However, the error message doesn’t indicate the exact line in the .cfm file where the error occurred… Even if it doesn’t indicate the exact line, having a reference point a few lines before or after the problematic code would greatly aid in debugging.
Is there a way to enhance error reporting in such scenarios, perhaps by ensuring a JDK is present or through other configurations? Improved error messages with precise line numbers would greatly aid in debugging.
Thank you for your continued efforts in improving Lucee.
1 Like
TBH the experience with type=“java” will never be quite as nice as with native cfml as we have more control over the bytecode for lucee and java is way stricter than cfml
<cfscript>
echo(server.lucee.version &"<br>");
echo("java: " & server.java.version &"<br>");
dump(server.java);
b = new component {
import java.math.BigDecimal;
function getBigNumberAdd(string A, string B) {
var a = new BigDecimal(A);
var b = new BigDecimal(B);
return a.add(b);
}
};
echo(b.getBigNumberAdd(2, 3));
flush;
echo(b.getBigNumberAdd("", ""));
</cfscript>
there’s a different bug relating to inline components coming into play here
https://luceeserver.atlassian.net/browse/LDEV-5605
moving that inline component into a cfc, however, produces
1 Like
