@subbuss and @enebo will have to comment, but I assumed it was so we could configure the passes that run at runtime and potentially include new passes without modifying any code.

I'm guessing you're asking about this because it causes problems for the substrate build? There will certainly be other places we load code reflectively.

Yeah - Substrate or any other hypothetical AOT tool people might want to run in the future.

I'm going through and substituting all the places that use reflection or class loaders. I can work around most of them - such as those in Joda and JCodings. Some stuff I'm just disabling for now, like requiring class files or converting Ruby objects to Java objects.

IR compiler phases could be simply switched to factory methods so that I don't have to do anything with them. We could then add a factory method that does use reflection if that's needed. This would allow the IR interpreter to be used in Substrate, and if someone ever wrote a Graal backend for IR, or a byte code interpreter in Truffle, that would work as well.

I'm happy to do the work.

Yeah this was done to make passes pluggable without being in source. I think jruby-visualizer might? have one. We can make a factory for the builtin ones and lookup based on name from that factory so we can remove reflection for builtin passes. We should probably be doing that anyways.

Closing as @donv has a better workaround which will achieve the same goal for me.