Thanks for pointing me to that - I think I looked at it a long time ago, but at that point it didn't matter (since compilation was overshadowed by the loading time for other resources - the compilation is done in parallel, btw, so as long as it takes less time than image/sound loading, how long it takes literally doesn't matter). And then I promptly forgot about it. But now that there are more scripts, even in vanilla compilation can take longer than resource loading - although that probably depends on the hard drive speed.
Gave it a whirl just now, seems good, though there were a few potential pitfalls. For example, multiple mods overriding the same plugin would mean there's a cached version of the file, and the mod with the latest timestamp on the .java file would win out, *even if disabled*. Ended up creating separate cache directories for each mod to get around that.
One other potential issue is that the initial startup now takes a bit longer. (Because it's writing all those files to disk, presumably? Or the caching compiler simply takes longer.). Subsequent starts are faster, though, as expected.
I'm curious - if you don't have a solid state drive, could you let me know if the compilation step in vanilla is actually exceeding the length of the other resource loading? The way to tell would be if it hangs with the loading bar at 100% for a while, and if you're tailing the log, you'll see entries about scripts being loaded flying by when it's at 100%.
The reason I'm asking mentioned SSD vs not is because that's going to speed up the loading of the images and sounds drastically, while script compilation likely isn't IO-bound. In a non-SSD use case, which is more common/makes more sense to optimize for, there's a better chance for script compilation to be a non-consideration (due to being done in parallel and having more time due to slower image/sound loading), in which case the hit to the initial startup time wouldn't be worth it.
