On 16.07.2016 10:02, Alan Bateman wrote: [...]
Separately, is @Grab partly to workaround issues with @CS methods? The issue with JDBC using @CS methods is one that you brought up on another thread and there is work in progress to fix that long standing issue.
The JDBC issue is one problem. But the usage is more general: to have a script with only Groovy as dependency and loading other libraries at runtime, without using module path or classpath.
With a script in source there should be no problem. But if the script is precompiled, then we may have no classloader we can use to add the paths to. So instead of just being able to distribute a small jar with just your application classes in it and having a dependency on the minimal groovy runtime, you are now forced to choose between
(a) requiring a groovy installation, unpacking the jar, having the entry point in source and the user using the groovy command to start the application. (b) have the entry script load another entry script, loaded in a new URLClassloader loader and hope the setup will be done right
both ways are inconvenient. (a) for the user of the application, (b) for the writer of the application... plus of course the risk of a wrong class loader setup. The solution will probably be a helper method to load the second class, which does the class loader setup. This is still no good solution, since it still has more error sources than it was the case before, but I have no idea so far for a better one
The point is, that the mentioned failure will continue being a failure and old code depending on this "hack" will no longer work. And we cannot solve it by just changing things in our code, we will have to depend on the users of Groovy to fix this. Which for us means a breaking change.
bye Jochen
