It's not too late for access control

[Jochen Theodorou]

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