Hi Paul,
that did solve the problem, thank you - but it would be nice if an
oversight like that would not lead to a "no information" internal
compiler error for us poor no Maven/Gradle build people :-)
Besides some solvable/trivial ones, I encountered another surprising one
in StaticImportVisitor#getAccessorName (stacktrace below) - maybe coming
from the NV/NVL macro stubs, or static Table class members...
Cheers,
mg
Error:Groovyc: While compiling groovysql:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.base/java.lang.String.substring(String.java:1841)
at org.apache.groovy.util.BeanUtils.capitalize(BeanUtils.java:54)
at
org.codehaus.groovy.control.StaticImportVisitor.getAccessorName(StaticImportVisitor.java:519)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessor(StaticImportVisitor.java:528)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticPropertyAccessorGivenArgs(StaticImportVisitor.java:524)
at
org.codehaus.groovy.control.StaticImportVisitor.findStaticMethodImportFromModule(StaticImportVisitor.java:505)
at
org.codehaus.groovy.control.StaticImportVisitor.transformPropertyExpression(StaticImportVisitor.java:384)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:130)
at
org.codehaus.groovy.ast.expr.CastExpression.transformExpression(CastExpression.java:95)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:169)
at
org.codehaus.groovy.ast.expr.DeclarationExpression.transformExpression(DeclarationExpression.java:183)
at
org.codehaus.groovy.control.StaticImportVisitor.transform(StaticImportVisitor.java:169)
at
org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:108)
at
org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:86)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:164)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitTryCatchFinally(CodeVisitorSupport.java:133)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitTryCatchFinally(ClassCodeVisitorSupport.java:242)
at
org.codehaus.groovy.ast.stmt.TryCatchStatement.visit(TryCatchStatement.java:47)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:86)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:164)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:69)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:138)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:111)
at
org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:66)
at
org.codehaus.groovy.control.StaticImportVisitor.visitConstructorOrMethod(StaticImportVisitor.java:108)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:106)
at org.codehaus.groovy.ast.ClassNode.visitMethods(ClassNode.java:1099)
at
org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1092)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:52)
at
org.codehaus.groovy.control.CompilationUnit.lambda$addPhaseOperations$3(CompilationUnit.java:209)
at
org.codehaus.groovy.control.CompilationUnit$IPrimaryClassNodeOperation.doPhaseOperation(CompilationUnit.java:942)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:671)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:635)
at
org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:62)
at
org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(DependentGroovycRunner.java:107)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(GroovycRunner.java:90)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.runGroovycInThisProcess(InProcessGroovyc.java:175)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.lambda$runGroovyc$0(InProcessGroovyc.java:94)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
On 01/03/2021 23:28, Paul King wrote:
Just a complete guess but does your 3.0.7/2.5.14 global libraries
include the lib/groovy-jaxb jar and not the lib/extras-jaxb/*.jar files?
On Tue, Mar 2, 2021 at 3:41 AM MG <mg...@arscreat.com
<mailto:mg...@arscreat.com>> wrote:
Hi,
I tried to do a spike to switch the (large) IntelliJ build-based*
Groovy project I am working on to from Groovy 2.5.10 to the
current Groovy 3 release (3.0.7) today, but immediately got a
"Groovyc: Internal groovyc error: code 1" that (contrary to
previous times I encountered that error) did not go away through a
rebuild of the current module or the whole project.
The same problem then occurred with the current Groovy 2.5 release
(2.5.14).
I have now created a minimal IntelliJ Groovy project, that
contains a single test that outputs the Groovy version - and to my
surprise this still gives "Groovyc: Internal groovyc error: code
1" in the 'Builder "Groovy stub generator" requested rebuild of
module chunk "GroovyMinimal"' phase...
The minimal project builds & runs without problems when switching
back to Groovy 2.5.10.
My complete build environment is:
IntellliJ 2020.2.3
AdoptOpenJDK jdk-11.0.10.9-hotspot (same behavior when using
11.0.10.5)
Windows 10 Pro 64-bit (build 19041.804)
Groovy 2.5.10 (works) / 2.5.14 (fails) / 3.0.7 (fails) respectively
(Hardware: Intel i5 CPU, 32GB RAM, 2TB SSD)
The project consists only of the (non-global) respective Groovy
library dependency, and the following Groovy test file (for
simplicity I use the JUnit that comes with this particular
IntelliJ version in the minimal project):
package minimal.groovy
import org.junit.Ignore import org.junit.Test class MinimalTest {
@Test @Ignore void test() {
println"Grooovy: ${GroovySystem.version}" }
}
Is this a known problem ? If not, feedback from other Groovy users
would be appreciated. I am evidently trying to find a solution to
this problem, but also to discern the extent of it: E.g. does it
also occur when using Maven or Gradle as a build system (which
would surprise me, since that is what most people use) ? If your
build works fine with Groovy 2.5.14 / 3.0.7, what is your build
environment ?
Thanks, cheers,
mg
*Since the question typically pops up: The environment I work in
does not allow access to build repositories on the internet, and
it is not possible to automatically mirror repositories locally,
and we have no complicated build steps, so using Gradle (or Maven)
would have no real advantage for us, so we use the build system
that is best integrated with our IDE and has good (apart from some
minor hickups) minimal rebuild support, etc, i.e. an IntelliJ build.
