You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Cédric Champeau <ce...@gmail.com> on 2017/12/27 09:04:44 UTC
A reminder about how things are compiled
Hi fellow Groovy contributors!
Given the recent question from Jochen about how to only execute tests from
the "core" project when you "know you only modified core" triggering
re-execution of tests for all modules, let me explain why this is like this.
Groovy is partially written in Groovy. It means that we have source code
written in Java, and source code written in Groovy. The code written in
Java is mostly, but not limited to, the "minimal compiler infrastructure".
This means that if you only compile the Java sources of the Groovy
codebase, what you obtain is something that is capable of compiling Groovy
code (and a bit more).
For this reason, we have decided, a few years back, to compile Groovy
sources using this "minimal compiler", that we call the "bootstrap
compiler". Said differently, not only Groovy is partially written in
Groovy, but we also compile the Groovy sources using the compiler generated
by the _current sources_.
Some other projects choose a different strategy: they compile, say, Java,
with version N-1 of Java. Groovy compiles itself with the _same_ version.
This has several advantages, like the fact that if Groovy N-1 produces
wrong bytecode, for some reason, we can immediately fix it. Similarly, the
generated bytecode is consistent with the bytecode that users will have
when using Groovy. Eventually, it also "accidentally" increases our test
coverage as a bug in the compiler is very likely to fail our build.
The consequence, however, is that any change to a Java class in Groovy core
is going to produce a different compiler. For Gradle, which is aware of
inputs/outputs, it means that the compiler has changed, and that it needs
to recompile downstream consumers (subprojects) and, of course, re-execute
their tests. This is the _correct behavior_. Gradle is right to do so,
because the compiler has changed, so the bytecode generated might be
different, but also since Groovy provides a runtime, it also needs to
re-execute the tests because the runtime has changed.
What I explain is also true of the other tasks we use, like groovydoc, or
docgenerator. Now, let me explain why changing the strategy to use compiler
N-1 is not necessarily a good idea for us: as I explained, Groovy also
comes with a runtime. Say that in Groovy 3, we decide to get rid of call
site caching, to only use invokedynamic. Then it means that the runtime of
Groovy 3 will no longer include call site caching. However, the Groovy
classes of the compiler would have been compiled with call site caching, so
a _consumer_ of the compiler would fail, because those classes would no
longer be there at runtime!
Of course one might say "then you can use the invokedynamic version" of
Groovy to compile Groovy 3, which leads to the last bit of complexity of
our build. Some would have noticed that we now have a "testAll" task for
each project. This task executes tests with the "indy" version of the
compiler. Which means that in practice, we produce 2 versions of the
compiler, not just one. This was the main reason for the complexity of the
previous build, that I recently got rid of by using a different strategy
and leveraging the Gradle build cache. So, instead of using the same
outputs for both compilers, they are now separate, and we can run the tests
in 2 flavors. The consequence is that tests are executed twice (one for
`test`, the other for `testWithIndy`), but the outcome is much cleaner.
I hope this clarifies things a bit. Now for daily development, you can use:
./gradlew :test : will only execute the call site caching version of tests
for the "core" project
./gradlew :testWithIndy : will only execute the indy version of tests for
the "core" project
./gradlew :testAll : will execute both flavors of tests (indy and non indy)
for the "core" project
And of course you can do the same for any subproject:
./gradlew :groovy-xml:test
You can also choose precisely which test to execute by adding `--tests
*MyTest*` to the command line.
Cheers,
Cédric
Re: A reminder about how things are compiled
Posted by Cédric Champeau <ce...@gmail.com>.
Yes.
2017-12-27 14:24 GMT+01:00 Jochen Theodorou <bl...@gmx.org>:
> On 27.12.2017 13:59, Cédric Champeau wrote:
>
>> Actually I just tested with the native IntelliJ import, that is to say
>> _without_ calling "gradle idea", and it just works out of the box (but
>> there seem to be a weird delay after the execution of a test).
>>
>
> you mean the intellij gradle import? Otherwise I do not get modules
>
> bye Jochen
>
Re: A reminder about how things are compiled
Posted by Jochen Theodorou <bl...@gmx.org>.
On 27.12.2017 13:59, Cédric Champeau wrote:
> Actually I just tested with the native IntelliJ import, that is to say
> _without_ calling "gradle idea", and it just works out of the box (but
> there seem to be a weird delay after the execution of a test).
you mean the intellij gradle import? Otherwise I do not get modules
bye Jochen
Re: A reminder about how things are compiled
Posted by Cédric Champeau <ce...@gmail.com>.
Actually I just tested with the native IntelliJ import, that is to say
_without_ calling "gradle idea", and it just works out of the box (but
there seem to be a weird delay after the execution of a test).
2017-12-27 13:29 GMT+01:00 Cédric Champeau <ce...@gmail.com>:
> I think the IDE setup can be improved. I didn't take at shot at this yet.
>
> 2017-12-27 13:22 GMT+01:00 Jochen Theodorou <bl...@gmx.org>:
>
>> On 27.12.2017 10:04, Cédric Champeau wrote:
>> [...]
>>
>>> The consequence, however, is that any change to a Java class in Groovy
>>> core is going to produce a different compiler.
>>>
>>
>> This is fine in the IDE, as long as I do not have to bootstrap
>> immediately... which I do not have to.
>>
>> But I must say the IDEA setup is still annoying as hell. I freshly
>> generated the modules and ended up with a project I cannot compile, because
>> of the examples. I then switched to build, but ignore errors, which
>> resulted in my main (FileSystemCompiler, GroovyMain) classes not being
>> found, because they have not been compiled and I did not add the Groovy
>> global lib. Then I added the bootstrap and while the main classes now have
>> been found, they have been of course from the bootstrap, not the source. I
>> will always have to have a really, really, really good look at things to
>> see if I am using bootstrap or not. I mean imagine you remove a class and
>> then run from the IDE to see if your test still works. And it will, because
>> the damn class is still in the bootstrap jar, which of course you did not
>> create a new one. I easily lost more than half a day just trying to setup
>> things again. Together with the installation and fixing of intellij
>> itself... that was no fun day at all and lost time for Groovy development.
>>
>> For Gradle, which is aware of inputs/outputs, it means that the compiler
>>> has changed, and that it needs to recompile downstream consumers
>>> (subprojects) and, of course, re-execute their tests. This is the _correct
>>> behavior_. Gradle is right to do so, because the compiler has changed, so
>>> the bytecode generated might be different, but also since Groovy provides a
>>> runtime, it also needs to re-execute the tests because the runtime has
>>> changed.
>>>
>>> What I explain is also true of the other tasks we use, like groovydoc,
>>> or docgenerator.
>>>
>>
>> that part is perfectly fine.
>>
>> Now, let me explain why changing the strategy to use compiler N-1 is not
>>> necessarily a good idea for us: as I explained, Groovy also comes with a
>>> runtime. Say that in Groovy 3, we decide to get rid of call site caching,
>>> to only use invokedynamic. Then it means that the runtime of Groovy 3 will
>>> no longer include call site caching. However, the Groovy classes of the
>>> compiler would have been compiled with call site caching, so a _consumer_
>>> of the compiler would fail, because those classes would no longer be there
>>> at runtime!
>>>
>>> Of course one might say "then you can use the invokedynamic version" of
>>> Groovy to compile Groovy 3, which leads to the last bit of complexity of
>>> our build.
>>>
>>
>> What you normally do is compiler with N-1 to get a compiler for N' and
>> then use that compiler to get the real N. Very common strategy. Of course
>> that means in a build where we would depend on an older release (N-1), we
>> not be able to use features in the new version (N') before we have created
>> N', which can actually compile the new features. And only then N could be
>> compiled using the new features from N'. Using Java is kind of like saying
>> we stay with N'. So there are pros and cons to this approach, it surely
>> does not make things more easy from the build side. It would make the
>> program code more easy and would be better in terms of "eat you own dog
>> food".
>>
>> what me really prevents from doing something like this is that the static
>> compiler has to many fallbacks to dynamic code where I do not want them.
>>
>> Some would have noticed that we now have a "testAll" task for each
>>> project. This task executes tests with the "indy" version of the compiler.
>>> Which means that in practice, we produce 2 versions of the compiler, not
>>> just one. This was the main reason for the complexity of the previous
>>> build, that I recently got rid of by using a different strategy and
>>> leveraging the Gradle build cache. So, instead of using the same outputs
>>> for both compilers, they are now separate, and we can run the tests in 2
>>> flavors. The consequence is that tests are executed twice (one for `test`,
>>> the other for `testWithIndy`), but the outcome is much cleaner.
>>>
>>> I hope this clarifies things a bit. Now for daily development, you can
>>> use:
>>>
>>> ./gradlew :test : will only execute the call site caching version of
>>> tests for the "core" project
>>> ./gradlew :testWithIndy : will only execute the indy version of tests
>>> for the "core" project
>>> ./gradlew :testAll : will execute both flavors of tests (indy and non
>>> indy) for the "core" project
>>>
>>> And of course you can do the same for any subproject:
>>>
>>> ./gradlew :groovy-xml:test
>>>
>>> You can also choose precisely which test to execute by adding `--tests
>>> *MyTest*` to the command line.
>>>
>>
>> testAll and testWithIndy I did not realize,thanks.
>>
>> bye Jcohen
>>
>
>
Re: A reminder about how things are compiled
Posted by Cédric Champeau <ce...@gmail.com>.
I think the IDE setup can be improved. I didn't take at shot at this yet.
2017-12-27 13:22 GMT+01:00 Jochen Theodorou <bl...@gmx.org>:
> On 27.12.2017 10:04, Cédric Champeau wrote:
> [...]
>
>> The consequence, however, is that any change to a Java class in Groovy
>> core is going to produce a different compiler.
>>
>
> This is fine in the IDE, as long as I do not have to bootstrap
> immediately... which I do not have to.
>
> But I must say the IDEA setup is still annoying as hell. I freshly
> generated the modules and ended up with a project I cannot compile, because
> of the examples. I then switched to build, but ignore errors, which
> resulted in my main (FileSystemCompiler, GroovyMain) classes not being
> found, because they have not been compiled and I did not add the Groovy
> global lib. Then I added the bootstrap and while the main classes now have
> been found, they have been of course from the bootstrap, not the source. I
> will always have to have a really, really, really good look at things to
> see if I am using bootstrap or not. I mean imagine you remove a class and
> then run from the IDE to see if your test still works. And it will, because
> the damn class is still in the bootstrap jar, which of course you did not
> create a new one. I easily lost more than half a day just trying to setup
> things again. Together with the installation and fixing of intellij
> itself... that was no fun day at all and lost time for Groovy development.
>
> For Gradle, which is aware of inputs/outputs, it means that the compiler
>> has changed, and that it needs to recompile downstream consumers
>> (subprojects) and, of course, re-execute their tests. This is the _correct
>> behavior_. Gradle is right to do so, because the compiler has changed, so
>> the bytecode generated might be different, but also since Groovy provides a
>> runtime, it also needs to re-execute the tests because the runtime has
>> changed.
>>
>> What I explain is also true of the other tasks we use, like groovydoc, or
>> docgenerator.
>>
>
> that part is perfectly fine.
>
> Now, let me explain why changing the strategy to use compiler N-1 is not
>> necessarily a good idea for us: as I explained, Groovy also comes with a
>> runtime. Say that in Groovy 3, we decide to get rid of call site caching,
>> to only use invokedynamic. Then it means that the runtime of Groovy 3 will
>> no longer include call site caching. However, the Groovy classes of the
>> compiler would have been compiled with call site caching, so a _consumer_
>> of the compiler would fail, because those classes would no longer be there
>> at runtime!
>>
>> Of course one might say "then you can use the invokedynamic version" of
>> Groovy to compile Groovy 3, which leads to the last bit of complexity of
>> our build.
>>
>
> What you normally do is compiler with N-1 to get a compiler for N' and
> then use that compiler to get the real N. Very common strategy. Of course
> that means in a build where we would depend on an older release (N-1), we
> not be able to use features in the new version (N') before we have created
> N', which can actually compile the new features. And only then N could be
> compiled using the new features from N'. Using Java is kind of like saying
> we stay with N'. So there are pros and cons to this approach, it surely
> does not make things more easy from the build side. It would make the
> program code more easy and would be better in terms of "eat you own dog
> food".
>
> what me really prevents from doing something like this is that the static
> compiler has to many fallbacks to dynamic code where I do not want them.
>
> Some would have noticed that we now have a "testAll" task for each
>> project. This task executes tests with the "indy" version of the compiler.
>> Which means that in practice, we produce 2 versions of the compiler, not
>> just one. This was the main reason for the complexity of the previous
>> build, that I recently got rid of by using a different strategy and
>> leveraging the Gradle build cache. So, instead of using the same outputs
>> for both compilers, they are now separate, and we can run the tests in 2
>> flavors. The consequence is that tests are executed twice (one for `test`,
>> the other for `testWithIndy`), but the outcome is much cleaner.
>>
>> I hope this clarifies things a bit. Now for daily development, you can
>> use:
>>
>> ./gradlew :test : will only execute the call site caching version of
>> tests for the "core" project
>> ./gradlew :testWithIndy : will only execute the indy version of tests for
>> the "core" project
>> ./gradlew :testAll : will execute both flavors of tests (indy and non
>> indy) for the "core" project
>>
>> And of course you can do the same for any subproject:
>>
>> ./gradlew :groovy-xml:test
>>
>> You can also choose precisely which test to execute by adding `--tests
>> *MyTest*` to the command line.
>>
>
> testAll and testWithIndy I did not realize,thanks.
>
> bye Jcohen
>
Re: A reminder about how things are compiled
Posted by Jochen Theodorou <bl...@gmx.org>.
On 27.12.2017 10:04, Cédric Champeau wrote:
[...]
> The consequence, however, is that any change to a Java class in Groovy
> core is going to produce a different compiler.
This is fine in the IDE, as long as I do not have to bootstrap
immediately... which I do not have to.
But I must say the IDEA setup is still annoying as hell. I freshly
generated the modules and ended up with a project I cannot compile,
because of the examples. I then switched to build, but ignore errors,
which resulted in my main (FileSystemCompiler, GroovyMain) classes not
being found, because they have not been compiled and I did not add the
Groovy global lib. Then I added the bootstrap and while the main classes
now have been found, they have been of course from the bootstrap, not
the source. I will always have to have a really, really, really good
look at things to see if I am using bootstrap or not. I mean imagine you
remove a class and then run from the IDE to see if your test still
works. And it will, because the damn class is still in the bootstrap
jar, which of course you did not create a new one. I easily lost more
than half a day just trying to setup things again. Together with the
installation and fixing of intellij itself... that was no fun day at all
and lost time for Groovy development.
> For Gradle, which is
> aware of inputs/outputs, it means that the compiler has changed, and
> that it needs to recompile downstream consumers (subprojects) and, of
> course, re-execute their tests. This is the _correct behavior_. Gradle
> is right to do so, because the compiler has changed, so the bytecode
> generated might be different, but also since Groovy provides a runtime,
> it also needs to re-execute the tests because the runtime has changed.
>
> What I explain is also true of the other tasks we use, like groovydoc,
> or docgenerator.
that part is perfectly fine.
> Now, let me explain why changing the strategy to use
> compiler N-1 is not necessarily a good idea for us: as I explained,
> Groovy also comes with a runtime. Say that in Groovy 3, we decide to get
> rid of call site caching, to only use invokedynamic. Then it means that
> the runtime of Groovy 3 will no longer include call site caching.
> However, the Groovy classes of the compiler would have been compiled
> with call site caching, so a _consumer_ of the compiler would fail,
> because those classes would no longer be there at runtime!
>
> Of course one might say "then you can use the invokedynamic version" of
> Groovy to compile Groovy 3, which leads to the last bit of complexity of
> our build.
What you normally do is compiler with N-1 to get a compiler for N' and
then use that compiler to get the real N. Very common strategy. Of
course that means in a build where we would depend on an older release
(N-1), we not be able to use features in the new version (N') before we
have created N', which can actually compile the new features. And only
then N could be compiled using the new features from N'. Using Java is
kind of like saying we stay with N'. So there are pros and cons to this
approach, it surely does not make things more easy from the build side.
It would make the program code more easy and would be better in terms of
"eat you own dog food".
what me really prevents from doing something like this is that the
static compiler has to many fallbacks to dynamic code where I do not
want them.
> Some would have noticed that we now have a "testAll" task for
> each project. This task executes tests with the "indy" version of the
> compiler. Which means that in practice, we produce 2 versions of the
> compiler, not just one. This was the main reason for the complexity of
> the previous build, that I recently got rid of by using a different
> strategy and leveraging the Gradle build cache. So, instead of using the
> same outputs for both compilers, they are now separate, and we can run
> the tests in 2 flavors. The consequence is that tests are executed twice
> (one for `test`, the other for `testWithIndy`), but the outcome is much
> cleaner.
>
> I hope this clarifies things a bit. Now for daily development, you can use:
>
> ./gradlew :test : will only execute the call site caching version of
> tests for the "core" project
> ./gradlew :testWithIndy : will only execute the indy version of tests
> for the "core" project
> ./gradlew :testAll : will execute both flavors of tests (indy and non
> indy) for the "core" project
>
> And of course you can do the same for any subproject:
>
> ./gradlew :groovy-xml:test
>
> You can also choose precisely which test to execute by adding `--tests
> *MyTest*` to the command line.
testAll and testWithIndy I did not realize,thanks.
bye Jcohen
Re: A reminder about how things are compiled
Posted by Daniel Sun <re...@hotmail.com>.
OK. Thanks.
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: A reminder about how things are compiled
Posted by Cédric Champeau <ce...@gmail.com>.
Nope, but I see you're using JDK 9. Maybe that's the reason.
2017-12-28 17:21 GMT+01:00 Daniel Sun <re...@hotmail.com>:
> Hi Cédric,
>
> I imported Groovy project into IntelliJ IDEA via opening
> build.gradle,
> but failed to run single test via click the "Run" button.
>
> Here are the error message:
>
> Information:javac 9.0.1 was used to compile java sources
> Information:2017/12/29 0:06 - Compilation completed with 9 errors and 32
> warnings in 1m 31s 502ms
> Error:Groovyc: While compiling groovy_main: java.lang.RuntimeException:
> java.lang.NoClassDefFoundError: Unable to load class
> org.codehaus.groovy.runtime.DateGroovyMethods due to missing dependency
> java/sql/Date
>
> Have you ever encountered some compilation issue like this?
>
> Cheers,
> Daniel.Sun
> -----------------------------------------------
> Information:javac 9.0.1 was used to compile java sources
> Information:2017/12/29 0:06 - Compilation completed with 9 errors and 32
> warnings in 1m 31s 502ms
> Error:Groovyc: While compiling groovy_main: java.lang.RuntimeException:
> java.lang.NoClassDefFoundError: Unable to load class
> org.codehaus.groovy.runtime.DateGroovyMethods due to missing dependency
> java/sql/Date
> at
> org.codehaus.groovy.control.CompilationUnit.convertUncaughtExceptionToComp
> ilationError(CompilationUnit.java:1123)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(
> CompilationUnit.java:1101)
> at
> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(
> CompilationUnit.java:631)
> at
> org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(
> CompilationUnit.java:609)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(
> CompilationUnit.java:586)
> at
> org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.
> compile(GroovyCompilerWrapper.java:62)
> at
> org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(
> DependentGroovycRunner.java:115)
> 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:564)
> at
> org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(
> GroovycRunner.java:136)
> 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:564)
> at
> org.jetbrains.jps.incremental.groovy.InProcessGroovyc.
> runGroovycInThisProcess(InProcessGroovyc.java:158)
> at
> org.jetbrains.jps.incremental.groovy.InProcessGroovyc.lambda$runGroovyc$0(
> InProcessGroovyc.java:88)
> at java.base/java.util.concurrent.FutureTask.run(
> FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.
> runWorker(ThreadPoolExecutor.java:1167)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$
> Worker.run(ThreadPoolExecutor.java:641)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: java.lang.NoClassDefFoundError: Unable to load class
> org.codehaus.groovy.runtime.DateGroovyMethods due to missing dependency
> java/sql/Date
> at org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(
> Java5.java:400)
> at org.codehaus.groovy.ast.ClassNode.lazyClassInit(
> ClassNode.java:283)
> at org.codehaus.groovy.ast.ClassNode.getMethods(
> ClassNode.java:408)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache.scanClassesForDGMMethods(StaticTypeCheckingSupport.
> java:2242)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache.getDGMMethods(StaticTypeCheckingSupport.java:2233)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache.access$100(StaticTypeCheckingSupport.java:2164)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache$1.provide(StaticTypeCheckingSupport.java:2192)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache$1.provide(StaticTypeCheckingSupport.java:2170)
> at
> org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(
> ConcurrentCommonCache.java:138)
> at
> org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(
> ConcurrentCommonCache.java:113)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$
> ExtensionMethodCache.getExtensionMethods(StaticTypeCheckingSupport.
> java:2168)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.
> findDGMMethodsForClassNode(StaticTypeCheckingSupport.java:306)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.
> findDGMMethodsForClassNode(StaticTypeCheckingSupport.java:292)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.
> findDGMMethodsByNameAndArguments(StaticTypeCheckingSupport.java:1005)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.findMethod(
> StaticTypeCheckingVisitor.java:4184)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.
> visitConstructorCallExpression(StaticTypeCheckingVisitor.java:2056)
> at
> org.codehaus.groovy.transform.sc.StaticCompilationVisitor.
> visitConstructorCallExpression(StaticCompilationVisitor.java:413)
> at
> org.codehaus.groovy.ast.expr.ConstructorCallExpression.visit(
> ConstructorCallExpression.java:46)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.
> visitBinaryExpression(StaticTypeCheckingVisitor.java:713)
> at
> org.codehaus.groovy.ast.expr.BinaryExpression.visit(
> BinaryExpression.java:60)
> at
> org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(
> CodeVisitorSupport.java:122)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(
> ClassCodeVisitorSupport.java:197)
> at
> org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(
> ExpressionStatement.java:42)
> at
> org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(
> CodeVisitorSupport.java:88)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(
> ClassCodeVisitorSupport.java:106)
> at
> org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(
> ClassCodeVisitorSupport.java:110)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(
> ClassCodeVisitorSupport.java:121)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.
> visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1962)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(
> ClassCodeVisitorSupport.java:132)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.
> startMethodInference(StaticTypeCheckingVisitor.java:2317)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(
> StaticTypeCheckingVisitor.java:2276)
> at
> org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethod(
> StaticCompilationVisitor.java:224)
> at org.codehaus.groovy.ast.ClassNode.visitContents(
> ClassNode.java:1095)
> at
> org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(
> ClassCodeVisitorSupport.java:54)
> at
> org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(
> StaticTypeCheckingVisitor.java:378)
> at
> org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitClass(
> StaticCompilationVisitor.java:182)
> at
> org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(
> StaticCompileTransformation.java:67)
> at
> org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(
> ASTTransformationVisitor.java:152)
> at
> org.codehaus.groovy.transform.ASTTransformationVisitor$2.
> call(ASTTransformationVisitor.java:196)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(
> CompilationUnit.java:1087)
> ... 20 more
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: A reminder about how things are compiled
Posted by Daniel Sun <re...@hotmail.com>.
Hi Cédric,
I imported Groovy project into IntelliJ IDEA via opening build.gradle,
but failed to run single test via click the "Run" button.
Here are the error message:
Information:javac 9.0.1 was used to compile java sources
Information:2017/12/29 0:06 - Compilation completed with 9 errors and 32
warnings in 1m 31s 502ms
Error:Groovyc: While compiling groovy_main: java.lang.RuntimeException:
java.lang.NoClassDefFoundError: Unable to load class
org.codehaus.groovy.runtime.DateGroovyMethods due to missing dependency
java/sql/Date
Have you ever encountered some compilation issue like this?
Cheers,
Daniel.Sun
-----------------------------------------------
Information:javac 9.0.1 was used to compile java sources
Information:2017/12/29 0:06 - Compilation completed with 9 errors and 32
warnings in 1m 31s 502ms
Error:Groovyc: While compiling groovy_main: java.lang.RuntimeException:
java.lang.NoClassDefFoundError: Unable to load class
org.codehaus.groovy.runtime.DateGroovyMethods due to missing dependency
java/sql/Date
at
org.codehaus.groovy.control.CompilationUnit.convertUncaughtExceptionToCompilationError(CompilationUnit.java:1123)
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1101)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:631)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:609)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:586)
at
org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:62)
at
org.jetbrains.groovy.compiler.rt.DependentGroovycRunner.runGroovyc(DependentGroovycRunner.java:115)
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:564)
at
org.jetbrains.groovy.compiler.rt.GroovycRunner.intMain2(GroovycRunner.java:136)
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:564)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.runGroovycInThisProcess(InProcessGroovyc.java:158)
at
org.jetbrains.jps.incremental.groovy.InProcessGroovyc.lambda$runGroovyc$0(InProcessGroovyc.java:88)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.NoClassDefFoundError: Unable to load class
org.codehaus.groovy.runtime.DateGroovyMethods due to missing dependency
java/sql/Date
at org.codehaus.groovy.vmplugin.v5.Java5.configureClassNode(Java5.java:400)
at org.codehaus.groovy.ast.ClassNode.lazyClassInit(ClassNode.java:283)
at org.codehaus.groovy.ast.ClassNode.getMethods(ClassNode.java:408)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$ExtensionMethodCache.scanClassesForDGMMethods(StaticTypeCheckingSupport.java:2242)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$ExtensionMethodCache.getDGMMethods(StaticTypeCheckingSupport.java:2233)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$ExtensionMethodCache.access$100(StaticTypeCheckingSupport.java:2164)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$ExtensionMethodCache$1.provide(StaticTypeCheckingSupport.java:2192)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$ExtensionMethodCache$1.provide(StaticTypeCheckingSupport.java:2170)
at
org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:138)
at
org.codehaus.groovy.runtime.memoize.ConcurrentCommonCache.getAndPut(ConcurrentCommonCache.java:113)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$ExtensionMethodCache.getExtensionMethods(StaticTypeCheckingSupport.java:2168)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.findDGMMethodsForClassNode(StaticTypeCheckingSupport.java:306)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.findDGMMethodsForClassNode(StaticTypeCheckingSupport.java:292)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.findDGMMethodsByNameAndArguments(StaticTypeCheckingSupport.java:1005)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.findMethod(StaticTypeCheckingVisitor.java:4184)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorCallExpression(StaticTypeCheckingVisitor.java:2056)
at
org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitConstructorCallExpression(StaticCompilationVisitor.java:413)
at
org.codehaus.groovy.ast.expr.ConstructorCallExpression.visit(ConstructorCallExpression.java:46)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitBinaryExpression(StaticTypeCheckingVisitor.java:713)
at
org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:60)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:122)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:197)
at
org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
at
org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:88)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:106)
at
org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:110)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:121)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1962)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:132)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.startMethodInference(StaticTypeCheckingVisitor.java:2317)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(StaticTypeCheckingVisitor.java:2276)
at
org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethod(StaticCompilationVisitor.java:224)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1095)
at
org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:54)
at
org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(StaticTypeCheckingVisitor.java:378)
at
org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitClass(StaticCompilationVisitor.java:182)
at
org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:67)
at
org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:152)
at
org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:196)
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1087)
... 20 more
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html