consider how we use Compiler in a concurrent environment

[RobAustin]

We should reconsider how we use Java-Runtime-Compiler in a concurrent environment and write a version which is suited to be used during code generation. As Java-Runtime-Compiler has had issues in the past when run concurrently.

The following ( and above ) comments were from @glukos

• When compilation is requested, CachedCompiler triggers compilation of all classes that were ever compiled and loaded with the current classloader. Perhaps it's a feature: user may compile code that depends on a previously compiled class. But it also makes compilation slower with every CachedCompiler#loadFromJava call: e.g. on 100th MethodReader creation (assuming that proxied interfaces are unique), we'll compile 100 classes.
• Aforementioned CME with CachedCompiler#javaFileObjects map
• Compilation results are consumed by MyJavaFileManager, which is a singleton for a classloader and not properly synchronized. Bytecode is saved in MyJavaFileManager#buffers and almost anything can happen: buffers may be re-initialized by concurrent compilation, we may attempt to define class with a partially written (or empty) buffer and so on.
• Linkage error "attempted duplicate class definition" is possible: we are not protected from defining the same class twice in case of concurrent compilation.

[minborg]

I think we should provide an alternate means of providing performant code. Generating code dynamically prevents AOT compilation and is initially slow, for example. We could use an annotation processor or we could perhaps change the way method handlers are used.

[peter-lawrey]

Compilation should be incremental and not recompile everything each time. This may require moving compiled classes to the .class instead of retaining the .java

[RobAustin]

This issue is high level, if this is still required, then we should replace this issue with more targetted issues.