I would say that we must assume the Lucee / CFML developer does NOT have
knowledge of underlying JAVA functions. Like you say, they are not
supported/documented and can contradict or conflict with Lucee’s
implementation or train of thought. Like me calling a JAVA delete function
and then complaining about the array start from 0 or 1 thingy.
I could only advocate that we make sure that all the basic functions for
struct and array (and more) editing are in place there so that nobody has
to go the the underlying JAVA layer. Me calling a Java delete function is
only because I couldn’t find a SPLICE function in the docs. There might be
ways around this, but I am used to Javascript and doing it these things in
one line ( not a long line though 
).
Maybe we can start a list of functions that people like to see implemented,
I think we are already way on track but there are always a couple of things
we don’t want to do in a UDF.
About they Jira ticket, I am not sure how high of a priority that would be.
I heard the dev team right now is pretty swamped. Can’t we already edit the
docs? I can propose a change when I click on the little pencil and edit on
githubOn Tuesday, 17 November 2015 19:18:26 UTC+11, Adam Cameron wrote:
On Tuesday, 17 November 2015 02:14:50 UTC, Mattijs Spierings wrote:
If I do not use javaCast, the array remove() function (which is not in
the docs by the way…?!?),
Except for here:
AbstractCollection (Java Platform SE 8 )
And here:
AbstractList (Java Platform SE 8 )
the result is a boolean False.
With the javacast, it returns the number that was removed from the array
and they seedGroup array has been reduced by one element.
Is this something that is going to be amended?
What do you perceive needs amending here? You’re calling methods on the
underlying Java implementation of Lucee’s “array”, which inherits from
java.util.AbstractList and in turn java.util.AbstractCollection.
It’s ubiquitous knowledge (innit?) that Lucee object implementations are
extensions of underlying Java classes, so if you’re calling an
“undocumented” method, then it’s likely to be one of the underlying Java
methods. Only if it’s not a method of the underlying Java
implementation would a method be “undocumented”.
That said, there’s a discussion to be had (and perhaps a separate one) as
to whether calling Java methods as opposed to “member functions” is,
strictly speaking, “supported”: it’s implementation detail that
lucee.runtime.type.ArrayImpl ultimately extends java.util.AbstractList
(etc), and indeed it’s even implementation detail that
lucee.runtime.type.ArrayImpl is “a thing” in the first place. It’s unclear
whether it’s a defined “contract” that this level of implementation is
intended to be understood by CFML developers/code, and therefore whether
one ought to be using methods like remove() in the first place. It could be
legit (if unlikely) that Lucee decides to shift away
from java.util.AbstractList, in which event your code will stop working.
Perhaps what needs to happen is for the Lucee Docs project to be augmented
to have placeholder pages for things like scopes, types, etc, so people can
document them, including what the level of officially sanctioned usage
is. It might be worth you raising a Jira ticket to get this implemented, if
you think it’s a shortcoming.