The problem is not the performance of the test, it's the performance of _compiling_ the test. @CompileStatic wouldn't help there.
Le ven. 25 mai 2018 à 14:24, Thibault Kruse <tibokr...@googlemail.com> a écrit : > Would the test performance be improved if @CompileStatic were used? I > think gradle uses Spock, and last time I checked Spock could not be > used with @CompileStatic. But Spock could also be removed with some > effort... > > On Fri, May 25, 2018 at 8:52 PM, Jochen Theodorou <blackd...@gmx.org> > wrote: > > > > > > Am 25.05.2018 um 12:51 schrieb Daniel.Sun: > >> > >> Hi Cédric, > >> > >> I am not going to cache ClassNode instance(just cache class names, > >> which are `String`), but I want to add a check whether the name of the > >> ClassNode being resolved is possibly in the default imported packages, > >> e.g. > >> If a ClassNode instance's name is `Foobar`(apparently it could not be in > >> any > >> default imported packages), then we can `return false` immediately and > the > >> further resolving can be eliminated. > > > > > > but this means we will have to manually update the list for java.lang, > > java.util, java.io and java.net > > > > Take for example Module. It is new in Java 9 and is in java.lang. If we > had > > this logic already in say Groovy 2.0 I am pretty sure the last versions > till > > Groovy 2.3 would not be able to resolve this class anymore then. > > > > I think there would be no problem with Java10, but think of Java 11... > we do > > not know yet. > > > > bye Jochen >
