command line tools fail with SecurityException on OSX

is it possible that you have the rt.jar or any other class containing a java.lang class in your classpath?

I have nothing in my classpath.

If I change the startGroovy script to set TOOLS_JAR to the empty string, then I can run the various scripts. The darwin variant for TOOLS_JAR, /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Classes/classes.jar, has many classes in java.lang.

I'm experiencing the exact same problem with groovy-1.0-jsr-06, groovy-1.0-jsr-05 works great.
OS: Windows 2000

java.lang.SecurityException: java.lang.Object - protected system package 'java.lang'
at java.lang.ClassLoader.checkClassName(ClassLoader.java:163)
at java.lang.ClassLoader.defineClass(ClassLoader.java:205)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:146)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:555)
at java.net.URLClassLoader.access$400(URLClassLoader.java:118)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:958)
at java.security.AccessController.doPrivileged(AccessController.java:270)
at java.net.URLClassLoader.findClass(URLClassLoader.java:486)
at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:143)
at java.lang.ClassLoader.loadClass(ClassLoader.java:517)
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:218)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:146)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:555)
at java.net.URLClassLoader.access$400(URLClassLoader.java:118)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:958)
at java.security.AccessController.doPrivileged(AccessController.java:270)
at java.net.URLClassLoader.findClass(URLClassLoader.java:486)
at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:143)
at java.lang.ClassLoader.loadClass(ClassLoader.java:517)
at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:121)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:160)

I encountered the same error. When I changed these lines in startGroovy

1. For Darwin, use classes.jar for TOOLS_JAR
   TOOLS_JAR="$JAVA_HOME/lib/tools.jar"
   if $darwin; then
   TOOLS_JAR="/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Classes/classes.jar"
   fi

to

TOOLS_JAR="$JAVA_HOME/lib/tools.jar"

i.e. deleted the darwin-specific part, it worked fine.

For what reason has this darwin-specific part been added? Perhaps it just can be deleted!?

Argh I am on OSX and have the same problem. I don't recall having these problems before with JSR-05

On the mailing list David Budworth suggest this - and it works:

You need to remove rt.jar from the classpath. The groovy shell script "startGroovy" has around line 158 a line that says
if $darwin; then
TOOLS_JAR="/path/to/jdk/classes.jar"
fi

just comment out those 3 lines. they don't apply to Apple's JDK 1.5 (which is what is default on new macs)

So it looks like just an issue with the startGroovy script

The issue is now, is this only an issue with JDK 1.5 on Macs, or does it apply to JDK 1.4 also? If it's only 1.5 we need to detect the 1.5 VM and only set TOOLS_JAR to a value if it is not 1.5

I would suggest this is raised to blocker as it prevents use of Groovy out of the box on Macs

it mades me think... why do we insert the tools.jar? We don't use it in the command line based groovy. And even if, the system loader should load it for us. And RootLoader needs a check to not to load classes from the rt.jar.. We could do this by looking into the jar and if there is a java.lang.Object or such, then we could remove the jar from the path... That would work. But the best approach would be to not to put so many things into the Rootlaoder and especially not to load the classpath blindly into the RootLoader. jsut asking the SystemLoader to load a class first is no option, since the system loader may have an jar we don't want to have. If you think back, that was the reason for using that class.

This does not appear to be specific to jse 5.0 on the mac.

If I change startGroovy to set TOOLS_JAR="$JAVA_HOME/../Classes/classes.jar", I get the same error regardless of whether JAVA_HOME is pointing to 1.4.2 or 1.5.0. Pointing JAVA_HOME at 1.3.1 gives me an UnsupportedClassVersionError, which is not unexpected since groovy requires jdk 1.4.

Setting TOOLS_JAR= (ie setting it to nothing) and running groovysh shows either Version: 1.0-JSR-06 JVM: 1.5.0_06-64 or Version: 1.0-JSR-06 JVM: 1.4.2-54.

Any idea when this will be fixed?

could you please try a current version? I think the problem is basically fixed

Well, I have just douwload the latest version and the problem persist. What so we do?

ok, one more try. Could someone test this new http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/src/bin/startGroovy ?

it would still not work if the rt.jar is in the classpath, but if that is not the case, then it should work now out of the box. I expect that the classes.zip is loaded automatically through the system loader without being present in the classpath

I tested and it seems to work

I close the bug as fixed, if there are still problems we will reopen the bug

I get a similar error again on Groovy Version: 1.5.7 JVM: 1.5.0_16 and Win2000.

I have a script and a WSDL that's causing the problems. How do I attach these?

what version of Groovy are you using and is it a fresh installationfrom our zip distribution?

I installed groovy-1.8.0 on mac osx 10.6.7 and get the following error when typing "groovy" in the command shell. When I type in "sudo groovy" it works fine.
Any thoughts or suggestions? Thanks!

java.lang.SecurityException: Prohibited package name: java.lang
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:480)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:626)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at org.codehaus.groovy.tools.RootLoader.oldFindClass(RootLoader.java:152)
at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:124)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at org.codehaus.groovy.tools.RootLoader.oldFindClass(RootLoader.java:152)
at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:124)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:98)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:130)

is it possible for you to find the startGroovy script and the line

TOOLS_JAR="$JAVA_HOME/lib/tools.jar"

and replace it by:

TOOLS_JAR=""

to see if that fixes the problem?