[groovy-user] Netbeans complains about Groovy attempts to access default package
Yegor Bryukhov
attempts to access default package. Nb 5.5 prints warnings and
Nb6beta2 prints stack traces (which is slow).
As far as I understand it can be turned off in Netbeans but may be
there is a way to fix it on Groovy side?
The most typical example when this happens is when you access a
variable from a binding in a template (either using ${} or <% %>),
Netbeans 6 beta2 prints something like:
java.lang.IllegalStateException: You are trying to access file:
result.groovy from the default package. Please see
http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/classpath.html#default_package
at org.netbeans.ProxyClassLoader.printDefaultPackageWarning(ProxyClassLoader.java:500)
at org.netbeans.ProxyClassLoader.getResource(ProxyClassLoader.java:280)
at java.lang.ClassLoader.getResource(ClassLoader.java:972)
at groovy.lang.GroovyClassLoader.getSourceFile(GroovyClassLoader.java:763)
at groovy.lang.GroovyClassLoader.access$100(GroovyClassLoader.java:75)
at groovy.lang.GroovyClassLoader$1$1.run(GroovyClassLoader.java:91)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.GroovyClassLoader$1.loadGroovySource(GroovyClassLoader.java:89)
at org.codehaus.groovy.control.ResolveVisitor.resolveToScript(ResolveVisitor.java:226)
at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:162)
at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:130)
at org.codehaus.groovy.control.ResolveVisitor.transformVariableExpression(ResolveVisitor.java:565)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:440)
at org.codehaus.groovy.control.ResolveVisitor.transformMethodCallExpression(ResolveVisitor.java:637)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:448)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:148)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:53)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:129)
at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:755)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:52)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:73)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:80)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:53)
at org.codehaus.groovy.control.ResolveVisitor.visitConstructorOrMethod(ResolveVisitor.java:96)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:88)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:851)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:48)
at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:734)
at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:71)
at org.codehaus.groovy.control.CompilationUnit$5.call(CompilationUnit.java:527)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:772)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:438)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:289)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:488)
at groovy.lang.GroovyShell.parse(GroovyShell.java:500)
at groovy.lang.GroovyShell.parse(GroovyShell.java:480)
at groovy.lang.GroovyShell.parse(GroovyShell.java:519)
at groovy.text.SimpleTemplateEngine.createTemplate(SimpleTemplateEngine.java:74)
at groovy.text.TemplateEngine.createTemplate(TemplateEngine.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:56)
at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:538)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:803)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:643)
at org.codehaus.groovy.runtime.Invoker.invokePojoMethod(Invoker.java:87)
at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:75)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:69)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:170)
Or when you coerce a map to a class:
java.lang.IllegalStateException: You are trying to access file:
AbstractAction_groovyProxyBeanInfo.groovy from the default package.
Please see http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/classpath.html#default_package
at org.netbeans.ProxyClassLoader.printDefaultPackageWarning(ProxyClassLoader.java:500)
at org.netbeans.ProxyClassLoader.getResource(ProxyClassLoader.java:280)
at java.lang.ClassLoader.getResource(ClassLoader.java:972)
at groovy.lang.GroovyClassLoader.getSourceFile(GroovyClassLoader.java:763)
at groovy.lang.GroovyClassLoader.access$100(GroovyClassLoader.java:75)
at groovy.lang.GroovyClassLoader$1$1.run(GroovyClassLoader.java:91)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.GroovyClassLoader$1.loadGroovySource(GroovyClassLoader.java:89)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:667)
at groovy.lang.GroovyClassLoader$InnerLoader.loadClass(GroovyClassLoader.java:385)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:723)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.beans.Introspector.instantiate(Introspector.java:1438)
at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:410)
at java.beans.Introspector.<init>(Introspector.java:359)
at java.beans.Introspector.getBeanInfo(Introspector.java:159)
at groovy.lang.MetaClassImpl$6.run(MetaClassImpl.java:2310)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2308)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2299)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:160)
at org.codehaus.groovy.runtime.Invoker.invokeConstructorOf(Invoker.java:125)
at org.codehaus.groovy.runtime.InvokerHelper.invokeConstructorOf(InvokerHelper.java:98)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeNewN(ScriptBytecodeAdapter.java:245)
at Script1.run(Script1.groovy:9)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:459)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:434)
at groovy.util.ProxyGenerator.instantiateAggregate(ProxyGenerator.java:172)
at groovy.util.ProxyGenerator.instantiateAggregateFromBaseClass(ProxyGenerator.java:47)
at groovy.util.ProxyGenerator.instantiateAggregateFromBaseClass(ProxyGenerator.java:43)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.asType(DefaultGroovyMethods.java:2894)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:56)
at org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:54)
at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:538)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:803)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:643)
at org.codehaus.groovy.runtime.Invoker.invokePojoMethod(Invoker.java:87)
at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:75)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:69)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:170)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.asType(ScriptBytecodeAdapter.java:641)
--
Best regards,
Yegor
__________________________________________________________
Yegor Bryukhov,
Research Associate
Center for Algorithms and Interactive Scientific Software
City College of New York
---------------------------------------------------------------------
To unsubscribe from this list please visit:
Jochen Theodorou
> Certain dynamic features of Groovy cause Netbeans to complain about
> attempts to access default package. Nb 5.5 prints warnings and
> Nb6beta2 prints stack traces (which is slow).
oh my, that is strange... So they set a classloader explicitly to enable
throwing this exception? It might be that the JLS suggests not to use
the default package, but that is no requirement. And for sure there is
no reason to enforce this at runtime.
Groovy tries to access the default package in several cases:
1) a variable needs to be resolved which is not local and no import does
fit.
2) a class in the deafult package is created
3) eval is called with a String (a version of case 2)
4) a class in the default package is referenced
The cases 1 und 2 happen only during compilation and precompiled groovy
code would help avoinding this. But Groovy is a dynamic language in many
cases and this includes creating classes at runtime. and it happens
often, that Groovy creates additional classes in the default package. As
soon as a MetaClass for this is created Groovy will also look for a
BeanInfo class, which of course would be in the default packge too if it
exists.
The trace is not long enough to see how you start Groovy in your IDE,
but if it is from a plugin I would suggest that the plugin people do
handle this case on their side, for example by adding a classloader in
between. Or, if you run GroovyMain directly, that you write a wrapper.
> As far as I understand it can be turned off in Netbeans but may be
> there is a way to fix it on Groovy side?
no easy fix. Groovy behaves here completely as we specified, but
Netbeans' classloader does not behave as we expect from a classloader.
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
Yegor Bryukhov
> Yegor Bryukhov schrieb:
> > Certain dynamic features of Groovy cause Netbeans to complain about
> > attempts to access default package. Nb 5.5 prints warnings and
> > Nb6beta2 prints stack traces (which is slow).
>
> oh my, that is strange... So they set a classloader explicitly to enable
> throwing this exception? It might be that the JLS suggests not to use
> the default package, but that is no requirement. And for sure there is
> no reason to enforce this at runtime.
It turns out, they don't throw the exception, they just create it and
pass to logger.
I know that throwing an exception is expensive, but I'm not sure how
expensive its creation, if it involves collection of the whole stack
trace.
Do you think it might noticeably affect Groovy code performance?
It's just that my application seems a bit less responsive on NB6 vs NB5.5 ...
In my case some user actions result in _creation_ of 5-10 such exceptions.
> The trace is not long enough to see how you start Groovy in your IDE,
> but if it is from a plugin I would suggest that the plugin people do
> handle this case on their side, for example by adding a classloader in
> between. Or, if you run GroovyMain directly, that you write a wrapper.
>
I don't start Groovy, I compile my groovy code into a Netbeans module
(package basically) which is later loaded when I start my application.
What kind of wrapper are you suggesting to write?
Another classloader somewhere between Netbeans' ProxyClassLoader and
Groovy classloader?
I don't think it's a good idea to dump Netbeans' loader completely (if
it is possible) because it would cripple their module architecture.
What should it do?
>
> no easy fix. Groovy behaves here completely as we specified, but
> Netbeans' classloader does not behave as we expect from a classloader.
>
Why specifying Groovy which package to use instead of default package
won't work?
Is it because there are too many place in code to change or is there a
deeper problem?
--
Best regards,
Yegor
__________________________________________________________
Yegor Bryukhov,
Research Associate
Center for Algorithms and Interactive Scientific Software
City College of New York
---------------------------------------------------------------------
Jochen Theodorou
> On Nov 18, 2007 2:20 PM, Jochen Theodorou <blac...@gmx.org> wrote:
>> Yegor Bryukhov schrieb:
>>> Certain dynamic features of Groovy cause Netbeans to complain about
>>> attempts to access default package. Nb 5.5 prints warnings and
>>> Nb6beta2 prints stack traces (which is slow).
>> oh my, that is strange... So they set a classloader explicitly to enable
>> throwing this exception? It might be that the JLS suggests not to use
>> the default package, but that is no requirement. And for sure there is
>> no reason to enforce this at runtime.
>
> It turns out, they don't throw the exception, they just create it and
> pass to logger.
ah, ok, that's much better. But still unneeded.
> I know that throwing an exception is expensive, but I'm not sure how
> expensive its creation, if it involves collection of the whole stack
> trace.
> Do you think it might noticeably affect Groovy code performance?
only during the compilation process. After that it will be ok. But
depending on the sice of your scripts you will get a huge amount of
output. And some operations may trigger new lookups too.
[...]
>> The trace is not long enough to see how you start Groovy in your IDE,
>> but if it is from a plugin I would suggest that the plugin people do
>> handle this case on their side, for example by adding a classloader in
>> between. Or, if you run GroovyMain directly, that you write a wrapper.
>
> I don't start Groovy, I compile my groovy code into a Netbeans module
> (package basically) which is later loaded when I start my application.
I see.
> What kind of wrapper are you suggesting to write?
one with a classloader in between, that blocks queries for classes in
the standard package.
> Another classloader somewhere between Netbeans' ProxyClassLoader and
> Groovy classloader?
ah, there you are saying it ;)
> I don't think it's a good idea to dump Netbeans' loader completely (if
> it is possible) because it would cripple their module architecture.
> What should it do?
frankly I would prefer to tell that stupid loader to not to do such
things. Maybe we should try to contact some Netbeans guys and ask them
why this is needed in their eyes.
>> no easy fix. Groovy behaves here completely as we specified, but
>> Netbeans' classloader does not behave as we expect from a classloader.
>
> Why specifying Groovy which package to use instead of default package
> won't work?
> Is it because there are too many place in code to change or is there a
> deeper problem?
the issue a default package brings up, the naming problem, which is
probably the reason they made this loader, isn't resolved by that. Well
ok, enough of that part. The problem is that we can't use the normal
compilation for an eval anymore, because we need to add a package
information, that is not originally there. It is just, that this is a
bigger thing, because it changes the semantics at some places and we
would have to first test what is affected and what not. Then there is of
course no central part for creating these classes, as these creation
places are normally not connected.. well only by the compiler. But for
example asType has nothing to do with evaluate, but both may create
additional classes.
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
---------------------------------------------------------------------
Yegor Bryukhov
> > expensive its creation, if it involves collection of the whole stack
> > trace.
> > Do you think it might noticeably affect Groovy code performance?
>
> only during the compilation process. After that it will be ok. But
> depending on the sice of your scripts you will get a huge amount of
> output. And some operations may trigger new lookups too.
>
But when I load a template using SimpleTemplateEngine it involves
runtime compilation, right?
BTW, is there a way to move this compilation to the build phase of my
application while still keeping templates as nice separate files (vs
having them in """ """ inside a groovy file and using string
interpolation ${...}) ?
> the issue a default package brings up, the naming problem, which is
> probably the reason they made this loader, isn't resolved by that. Well
> ok, enough of that part. The problem is that we can't use the normal
> compilation for an eval anymore, because we need to add a package
> information, that is not originally there. It is just, that this is a
> bigger thing, because it changes the semantics at some places and we
> would have to first test what is affected and what not. Then there is of
> course no central part for creating these classes, as these creation
> places are normally not connected.. well only by the compiler. But for
> example asType has nothing to do with evaluate, but both may create
> additional classes.
>
I see, it is too of a massive change both semantically and "geographically".
--
Best regards,
Yegor
__________________________________________________________
Yegor Bryukhov,
Research Associate
Center for Algorithms and Interactive Scientific Software
City College of New York
---------------------------------------------------------------------
Jochen Theodorou
>>> I know that throwing an exception is expensive, but I'm not sure how
>>> expensive its creation, if it involves collection of the whole stack
>>> trace.
>>> Do you think it might noticeably affect Groovy code performance?
>> only during the compilation process. After that it will be ok. But
>> depending on the sice of your scripts you will get a huge amount of
>> output. And some operations may trigger new lookups too.
>
> But when I load a template using SimpleTemplateEngine it involves
> runtime compilation, right?
yes
> BTW, is there a way to move this compilation to the build phase of my
> application while still keeping templates as nice separate files (vs
> having them in """ """ inside a groovy file and using string
> interpolation ${...}) ?
hmm... that is kinda like having precompiled JSPs
>> the issue a default package brings up, the naming problem, which is
>> probably the reason they made this loader, isn't resolved by that. Well
>> ok, enough of that part. The problem is that we can't use the normal
>> compilation for an eval anymore, because we need to add a package
>> information, that is not originally there. It is just, that this is a
>> bigger thing, because it changes the semantics at some places and we
>> would have to first test what is affected and what not. Then there is of
>> course no central part for creating these classes, as these creation
>> places are normally not connected.. well only by the compiler. But for
>> example asType has nothing to do with evaluate, but both may create
>> additional classes.
>
> I see, it is too of a massive change both semantically and "geographically".
I am not so concerned about the many places that need a changes as more
of the semantics of such a change. There are maybe 5-6 places, that is
not that much
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
---------------------------------------------------------------------