Hi, Thanks to feedback from Jochen and significant help and suggestions from Eric, I have found a solution to the problem I was experiencing.
It is nothing to do with Groovy but everything to do with Intellij. It would appear that Intellij invokes the RootLoader in some way when you invoke these processes from within the IDE. If, instead, you create a jar using the Intellij Artifact mechanism, and then run these jars in separate command windows using the standard command line prompt >java -jar file.jar then the processes run correctly. From Eric it was also shown that the same codes created using Eclipse would run as expected from within the IDE. I now have to find a way of stopping Intellij from loading the RootLoader but that is altogether a different problem and nothing to do with Groovy. My apologies for having asked an inappropriate question of fellow Groovy developers Jon Jon Kerridge PhD FBCS FHEA CITP CEng Emeritus Professor of Computing School of Computing Edinburgh Napier University Merchiston Campus 10 Colinton Road Edinburgh EH10 5DT j.kerri...@napier.ac.uk<mailto:j.kerri...@napier.ac.uk> From: Kerridge, Jon <j.kerri...@napier.ac.uk> Sent: 12 November 2019 10:59 To: dev@groovy.apache.org Subject: Problem with org.codehaus.groovy.tools.RootLoader CAUTION: This email originated from outside Edinburgh Napier University. Do not follow links or open attachments if you doubt the authenticity of the sender or the content. Hi, I have come across a problem that I am finding very confusing. I have a parallel library that is reliable, mounted on jcenter() called jcsp – CSP for Java. I have been wanting to update the library for Java9+ and to use it with Groovy 3. But first discovered a problem that first manifest itself earlier this year when teaching a parallel processing module. Prior to this year I had used Eclipse and its Groovy plugin from SpringSource. With no problems. The code was compiled for Java 1.8 and Groovy2.4 I have created a Groovy version and a Java version of the same setup respectively: https://github.com/JonKerridge/GroovyDCL https://github.com/JonKerridge/JavaDCL The problem is that the pure Java version does not create the error and runs as expected. The ReadMe in GroovyDCL gives more detail. There is also a ReadMe in JavaDCL The problem is that the Groovy version when run as three separate processes creates the error org.codehaus.groovy.tools.RootLoader cannot be cast to jcsp.net2.mobile.DynamicClassLoader. This error comes from deep in the jcsp library. DynamicClassLoader uses the Java(8) SystemClassLoader. The code is derived from a part of jcsp which deals with class loading in a parallel system run on multiple nodes on separate workstations. The idea, which works, is that if a node discovers that it does not have the required class it can go back down the chain of nodes looking for the class file which will be automatically transferred to the node, if it is found. I know that class loaders have changed in Java9+ and was expecting to just make the change to the jcsp library from SystemClassLoader (8) to PlatformClassLoader (9+). I used the standard Intellij built-in Groovy 2.3.11 with Java 8 to keep the build as simple as possible. I have tried the same code for all later versions of groovy with Java 8 and Java 12 and get the same error. Needless to say, the actual example that showed this problem was far more complex! I therefore created the two versions referred to above as being the simplest means of demonstrating the problem. Any help or advice very gratefully received. Jon Jon Kerridge PhD FBCS FHEA CITP CEng Emeritus Professor of Computing School of Computing Edinburgh Napier University Merchiston Campus 10 Colinton Road Edinburgh EH10 5DT j.kerri...@napier.ac.uk<mailto:j.kerri...@napier.ac.uk> This message and its attachment(s) are intended for the addressee(s) only and should not be read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s) without the permission of the sender. If you are not the intended addressee you must not take any action based on this message and its attachment(s) nor must you copy or show them to anyone. Please respond to the sender and ensure that this message and its attachment(s) are deleted. It is your responsibility to ensure that this message and its attachment(s) are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this message or its attachment(s), or for errors or omissions arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier University's system are subject to routine monitoring and filtering by Edinburgh Napier University. Edinburgh Napier University is a registered Scottish charity. Registration number SC018373 This message and its attachment(s) are intended for the addressee(s) only and should not be read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s) without the permission of the sender. If you are not the intended addressee you must not take any action based on this message and its attachment(s) nor must you copy or show them to anyone. Please respond to the sender and ensure that this message and its attachment(s) are deleted. It is your responsibility to ensure that this message and its attachment(s) are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this message or its attachment(s), or for errors or omissions arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier University's system are subject to routine monitoring and filtering by Edinburgh Napier University. Edinburgh Napier University is a registered Scottish charity. Registration number SC018373
