portal entry

select a category, or use search below
(searches all categories and all time range)
Title:

Union and diff of arrays

| View in Portal
January 21, 2019 08:26:22 PM GMT
8 Comments
<p>Union and diff of arrays in CFML using underlying Java methods</p>
<p>The post <a rel="nofollow" href="https://coldfusion.adobe.com/2019/01/union-diff-arrays/">Union and diff of arrays</a> appeared first on <a rel="nofollow" href="https://coldfusion.adobe.com">ColdFusion</a>.</p>
Labels: Blog, ColdFusion, Modern CFML, 2016, blog, modern cfml

Comments:

Let me make sure I understand. Arrays are getting passed into the function. Array have member functions above and beyond the ones that Adobe lists. Are there other Java member functions that may be useful? How would I find them?
Comment by James Mohler
1570 | January 22, 2019 04:57:38 PM GMT
Regarding finding available Java methods: In order to find this, we need to get the Java class that is being used with the given data type/object we're working with. From there it's just a matter of calling that class' getMethods() function and iterating over the results; which is an array of Java Method classes. Here's an example: <code></code> exampleArray = []; methods = exampleArray.getClass().getMethods(); // If you want to see the raw result // writeDump(methods); arrayEach(methods, function(method) { writeOutput("#method.getName()#"); });  
Comment by Tony Junkes
1572 | January 23, 2019 02:42:56 PM GMT
How does the Java clone() function compare to ColdFusion's duplicate() function?
Comment by Carl Von Stetten
1571 | January 23, 2019 05:51:17 PM GMT
Sorry about the formatting - I don't seem to be able to fix it!Arrays are based on java.util.AbstractList. You can find the super class by doing:---exampleArray = [];writeDump(exampleArray.getClass().getSuperClass().getSuperClass().getName());writeDump(exampleArray.getClass().getSuperClass().getSuperClass().getSuperClass().getName());---In ACF (2018) that’ll give you:---java.util.ArrayListjava.util.AbstractList---In Lucee (5) that’ll give you:---lucee.runtime.type.util.ArraySupportjava.util.AbstractList---You can then look up the methods of java.util.AbstractList
Comment by aliaspooryorik
1575 | January 24, 2019 09:20:22 AM GMT
To be honest - I don't know. I'd imagine that <code>duplicate</code> is using <code>clone</code> under the hood. If you use either you get back the same java datatype.
Comment by aliaspooryorik
1574 | January 24, 2019 09:26:42 AM GMT
Here is a link to the JavaDocs for AbstractList: <a href="https://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html" rel="nofollow">https://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html</a>  
Comment by Peter Freitag
1578 | January 24, 2019 02:57:02 PM GMT
Whatever you do, put these calls to the underlying java methods in wrapper so that you never call it but one spot in your code base so that whenever Adobe breaks it in a future version cause it's "undocumented" you won't have to fight with your codebase for 6 months.
Comment by Justin Treher
1663 | February 11, 2019 07:17:23 PM GMT
@Justin Thanks for the comment. In the past I would have agreed with you, these days I think taking advantage of the Java methods is a reasonable thing. These methods are undocumented in CFML land, but they are documented in Java land. So I take your point that Adobe may change the Java datatype they use for say a ColdFusion array but it is highly unlikely. Lucee and ColdFusion use a slightly different inheritance tree, but these methods still work on both engines. It is of course possible (although unlikely) that Adobe changes the underlying datatype.  However you should have unit tests, so you will know as soon as you update ColdFusion that there is an issue and the change will be the same throughout your code base. If you don't have code coverage then any change to ColdFusion or the JVM version is a bit of a risk.
Comment by aliaspooryorik
1662 | February 11, 2019 08:58:55 PM GMT