Am 17.12.2015 um 03:59 schrieb Goo Mail: [...]
Whatever manipulation is going on there was apparently not intended to performed on shared objects, but I was able to make it work by serializing all calls to the Groovy parser until at least one good parse has been completed. After the first good parse, the types in the ImportCustomizer seem to be fully resolved and I can again parse scripts on multiple thread simultaneously with the shared ImportCustomizer.
ResolveVisitor will resolve only unresolved class objects, so that strategy should work. Even better of course would be to be able to add imports using resolved classes
With all of that having been written: is sharing the same ImportCustomizer across different classloaders and parse sessions still a good idea?
if you can ensure everything is resolved and if you are aware, that you are sharing an object concurrently, that is not written for that (even with just reading you can get into safe publication problems). So you may have to ensure memory barriers are passed
I like the performance improvement that sharing the ImportCustomizer provides, but the mutability aspect seems like more of an inadvertent feature and/or issue that might not have been intended by the Groovy designers.
every part of the Groovy AST is basically mutable and not intended for multithreaded use.
bye Jochen
