While building MappingLoom and trying it out as a local dependency to make MappingWeaver work on my MacOS, I bumped into the following issues that warrant a clear documentation in the short term, and probably a revision in the long run.
-
The code calls java.lang.System::load (in be.ugent.idlab.knows.mappingLoom.NativeUtils), which is a restricted method. At least on MacOS, I have to run the JAR with the --enable-native-access=ALL-UNNAMED option to temporarily ignore the restriction.
-
The code calls sun.misc.Unsafe::objectFieldOffset (through org.apache.pekko.util.Unsafe), which is a deprecated method. This is already solved in Pekko v2, so bumping this dependency will solve it. Until then, running the JAR with the --sun-misc-unsafe-memory-access=allow option temporarily ignores it.
-
The build uses shading, presumably to fix dependencies. This is not a good practice, however, and unless there are some truly complex issues at hand, dependencies should be resolvable with a good Maven setup.
While building MappingLoom and trying it out as a local dependency to make MappingWeaver work on my MacOS, I bumped into the following issues that warrant a clear documentation in the short term, and probably a revision in the long run.
The code calls
java.lang.System::load(inbe.ugent.idlab.knows.mappingLoom.NativeUtils), which is a restricted method. At least on MacOS, I have to run the JAR with the--enable-native-access=ALL-UNNAMEDoption to temporarily ignore the restriction.The code calls
sun.misc.Unsafe::objectFieldOffset(throughorg.apache.pekko.util.Unsafe), which is a deprecated method. This is already solved in Pekko v2, so bumping this dependency will solve it. Until then, running the JAR with the--sun-misc-unsafe-memory-access=allowoption temporarily ignores it.The build uses shading, presumably to fix dependencies. This is not a good practice, however, and unless there are some truly complex issues at hand, dependencies should be resolvable with a good Maven setup.