Should we rename the function JavaNew? The name was chosen because it is following the same pattern as the only other Java function “JavaCast”, a name like JavaProxy would be more precise but more confusing than helpful for most users, but because this function does not produce Java objects we should not use the word “object”. So the best solution in my opinion is JavaNew because it is consistent with JavaCast, but also Fir example entityNew
From the perspective of the underlying implementation, they might not be Java objects, but from the perspective of code being written by a CFML developer who is calling javaNew() to create [something], it’s a Java object.
javaNew() makes no sense. That implies it returns a new Java. Whatever that might be.
I’m not sure we’re gaining by “namespacing” this function (eg: drawing a parallel between javaNew() and javaCast()), because I don’t think the same parallel is there as with stuff like structNew(), structAppend(); arraySort(), arrayMin() etc, as the yoda-speak has been done there because there is a sense of namespace with all the struct functions, array functions, file functions, etc. I don’t think that parallel extends to javaCast() and javaNew().
To that end, I’d actually go with createJavaObject(), but I suspect that won’t wash.
Perhaps start abandoning headless functions altogether and have something like:
myObj = new JavaProxy() // look, I even said proxy there ;-)
Where JavaProxy is a factory class which returns Java proxy objects. I kinda made that up as I was typing… what I was more thinking about is an example of not using headless functions.
I’d like to think that ultimately all headless functions would be deprecated (in the “not recommnded any more” sense of that word), and with the advent of methods being implemented for common types in Railo 4, now’s perhaps a good time to start moving in that direction more emphatically.
I am not sure what @adam_cameron means by “headless functions” , but I do like the new JavaProxy().
The documentation is then correct, for example:
“If you want to access java objects, Lucee creates a proxy that helps you access them in a safe way. Using the format:
new JavaProxy(“System.out”) you can get a Lucee object that behaves (by proxying) the same as the underlying java object”
Headless functions == current BIFs. As opposed to, say, class constructors, or static member methods of a class. Perhaps with Lucee 5’s static methods - it could be something like
import scl.util.Java;
// return the constructed string buffer object/proxy/whatever
stringBuffer = Java::instance("java.lang.StringBuilder", ["initial string"]);
// or
// return the unconstructed proxy, that you can later call init on, same way createObject("java",...) does now...
sbProxy = Java::proxy("java.lang.StringBuilder");
2 Likes
Yeah, sorry… when I say “headless functions” I mean “build in functions that aren’t a method of an object or class”. So arrayAppend(myArray, newElement) is a headless function, whereas myArray.append(newElement) is method on an array object.
I really like that syntax suggestion, Jesse.
We could do a component for this like for example the Query component we have. But we still need a function to provide this feature, I would love to discuss a general approach from moving away from BIFs, but let’s do this in a separate topic.
We should also discuss a more native way to call Java classes, so something like the following
new java.lang.String("123");String::valueOf(123);
In that case Lucee could first check for Lucee class and if not found for a Java class. But again another topic.