Of course, the peculiarity is not limited to those interactions with ITIM - it's just that ITIM returns Process IDs in java.lang.Long format. All handling of java.lang.Long objects should be treated suspiciously.
Take for example the following logic:
var myString = "6746449726097972618";
var myLong = new java.lang.Long(myString);
task.logmsg("INFO", "STRING is: " + myString);
task.logmsg("INFO", "LONG is: " + myLong.longValue);
One might reasonably assume that the resulting log file will display the long number 6746449726097972618 twice. But you would be wrong. In fact, the log will look a lot like this:
08:51:23,047 INFO - CTGDIS087I Iterating.
08:51:23,047 INFO - CTGDIS086I No iterator in AssemblyLine, will run single pass only.
08:51:23,047 INFO - CTGDIS092I Using runtime provided entry as working entry (first pass only).
08:51:23,057 INFO - STRING is: 6746449726097972618
08:51:23,057 INFO - LONG is: 674644972609797222408:51:23,057 INFO - CTGDIS088I Finished iterating.
08:51:23,057 INFO - CTGDIS100I Printing the Connector statistics.
08:51:23,057 INFO - [EmptyScript] Calls: 1
08:51:23,057 INFO - CTGDIS104I Total: Not used.
08:51:23,057 INFO - CTGDIS101I Finished printing the Connector statistics.
08:51:23,057 INFO - CTGDIS080I Terminated successfully (0 errors).
So why the lack of precision when we try to display our Long object? A clue to what is going on here can be found by adding the following line of code:
Now, our log file looks like this:
08:51:29,237 INFO - STRING is: 6746449726097972618
08:51:29,237 INFO - LONG is: 6746449726097972224
08:51:29,237 INFO - 6746449726097972618
So, we have now been able to display our Long object correctly. But the only difference was that I passed my Long object as a long object type rather than as a string. ("LONG is: " + myLong.longValue will convert myLong.longValue to a string prior to appending it to the string "LONG is: ")
The reason, is that we are calling a proper Java method at that point and Java is more than capable of handling java.lang.Long objects (as you might expect).
If you really must play with java.lang.Long objects within your script nodes in TDI and you want to write the object to any target, you'll probably be better to have a think about performing a true Java conversion of the object in order to retain precision, like so...
var myConvertedString = new java.lang.String.valueOf(myLong.longValue);
myConvertedString will now contain 6746449726097972618, as expected, and can be displayed quite happily as a result of calling the task.logmsg() method regardless of how you construct the arguments to the method.