This primarily reduces the memory consumed by FF, now able to decompile one of the 1.18.2 snapshots with a minimum of 2GB of ram, rather than the 4+GB previously required.
There may be some performance improvements from this change as well, but the difference between this change and just #116 is pretty negligible, so it's not super useful for judging this PR.
I've also introduced a -jrt <1|current|path> option, which allows reading JDK classes from a JEP220 java runtime image, or the legacy rt/lib/*.jar and lib/*.jar format, to cover modern and pre-J9 runtimes. This means that users who want to decompile classes produced for a version of Java older than the one required for Forgeflower (now J17) can reference that runtime, without any attachment to what FF requires.
There is no change to the decompiled output from this branch.
Currently, these changes are tacked into a patch at the end of the list -- once I gather up the motivation/initial review has happened, I'll move the lazy classpath patch earlier in the sequence, so later patches can make their changes taking advantage of the lazy classpath API. I'll leave it as a draft until then.
This primarily reduces the memory consumed by FF, now able to decompile one of the 1.18.2 snapshots with a minimum of 2GB of ram, rather than the 4+GB previously required.
There may be some performance improvements from this change as well, but the difference between this change and just #116 is pretty negligible, so it's not super useful for judging this PR.
I've also introduced a
-jrt <1|current|path>option, which allows reading JDK classes from a JEP220 java runtime image, or the legacyrt/lib/*.jarandlib/*.jarformat, to cover modern and pre-J9 runtimes. This means that users who want to decompile classes produced for a version of Java older than the one required for Forgeflower (now J17) can reference that runtime, without any attachment to what FF requires.There is no change to the decompiled output from this branch.
Currently, these changes are tacked into a patch at the end of the list -- once I gather up the motivation/initial review has happened, I'll move the lazy classpath patch earlier in the sequence, so later patches can make their changes taking advantage of the lazy classpath API. I'll leave it as a draft until then.