Full Changelog: https://gist.github.com/Jonathing/c3ad28b2a048ac839a7baba5417ee870
The key features are:
- ES6 language support
- Thoroughly updated ASMAPI, with full documentation
- Bug fixes (some optional for backwards-compatibility)
- Partial internal code cleanup
- Request CoreMods to not apply fix for ASMAPI.findFirstInstructionBefore by default
Related dependency bumps:
- Updated ASM to 9.7.1
- Updated Nashorn to 15.4
- Updated Log4J to 2.19.0 (included with installer)
* Fix compatibility checker task configuration
The setupCheckJarCompatibility task exists to configure the main
compatibility checker task, checkJarCompatibility, because certain
configuration steps for that task could not be done until after the
configuration phase of Gradle.
However, that setup task previously held all the configuration for the
main check task in its task action. This caused problems because the
main check task's inputs are linked to other tasks, and the previous
situation made it so its configuration (by the setup task) happened
_after_ Gradle built the task dependency model/tree.
This meant that certain tasks which the main check task depended on did
not run before that task, because Gradle was unaware of this inter-task
dependency until it was too late (when it was already executing tasks).
This fixes the issue by moving the bulk of the configuration for the
main check task from the action of the setup task to the main
buildscript, therefore allowing Gradle to know about those task
dependencies and factor them in to its process of determining what tasks
to run and in what order.
The remaining configuration step in the setup task for the main check
task is linked to the setup task, and does not affect the task's
dependencies (because it uses a configuration which it resolves
immediately), so it stays in the setup task.
* Force checker setup task to never be up-to-date
The setup task configures the main check task, so it should always run
before that task. However, because it has an input and output, the setup
task is affected by Gradle's incremental build feature, which leads to
the possibility that Gradle considers the setup task as up-to-date,
therefore not executing its action and causing errors with the main
check task down the line.