JADE Environment Development Ideas

Change the node.createExternalProcess method parameter "args" type from StringArray to HugeStringArray

Some external process arguments require full path file locations that can be greater than 100 characters long (StringArray entry limit); Having the "args" parameter as a HugeStringArray would address this limitation.

  • Kevin Chu
  • Jul 22 2021
  • Needs review
  • Attach files
  • Kevin Chu commented
    27 Jul 03:26am

    @BeeJay Thanks for the suggestion. I did in the end use the subclass Array (specifying the new Array max length field) and it worked perfectly.

    As for the Jade 2020 upgrade, it is out of my hands as to when the system is going to be upgraded.

    I did think prior to this post that the ramification of such a change would break previous implementations of this method call and hence the reluctance to make the change I proposed.


    @John I too have just used the command string in previous uses of the method. Cheers.

  • John Porter commented
    27 Jul 02:36am

    You can also avoid the restriction by using the "command" String parameter instead of the "args" array parameter. I normally just use the command string as it's easier than breaking it all up into an array.

  • BeeJay commented
    22 Jul 04:52am

    I think there are a number of issues with this suggestion:

    • Changing the parameter type to HugeStringArray would break all existing apps which are using Node::createExternalProcess as HugeStringArray doesn't inherit from StringArray.

    • You can already pass in a variable which is an instance of your own subclass of StringArray which has a larger max length. eg: We have a StringArray500, with max length of 500 characters, which we use for some calls to Node::createExternalProcess where the default length was insufficient.

    • It may also be a moot point anyway with the JADE 2020 change to make the native StringArray variable length. Effectively you are no longer limited in the length of strings you add to a StringArray instance, removing the need to create your own subclasses of StringArray with longer max lengths.

    Note: I'm planning to review usage of our subclasses of StringArray to see if we no longer require them, at least in transient instances, as there are probably memory use advantages to using the new 'variable length' native StringArray class..