allow different mapping for reflection

[LogicFan]

It's configured using json file. I've included one for sponge vanilla.

[LogicFan]

Should be fixed now.

[Zidane]

@gabizou @zml2008

Any changes? Looks straightforward to me.

[LogicFan]

fixed.

[zml2008]

This looks like a fairly straightforward implementation -- but it doesn't capture the situation of using a SpongeForge/SpongeFabric jar in a dev environment with different mappings. Forge has an (iirc) INameMappingService, fabric loader has some mapping API as well to convert from SRG/intermediary strings into the appropriate dev-time mappings. Could you look into exposing that, probably through Launch as well?

[LogicFan]

Could you look into exposing that, probably through Launch as well?

I looked at the fabric part. So, to remap a method, it also needs to also pass a descriptor. I also don't want this API to be restricted to method only. It might be necessary to use reflection on class name or field one day. I think it will be a little bit tricky to design an API that could facilitate potential future use & quite clean right now.

I think I will need to look at the forge part too to have a better understanding of what will be the best way.

[LogicFan]

Hi, @zml2008 , do you think this new approach works better? or is it overkill?

[zml2008]

This is a step in the right direction -- however, taking a look at Fabric's Mapping resolver API, this API would fail when used in development environments, particularly if a user depended on your fabric implementation from a Yarn-based workspace (since Sponge will at most know about official names and intermediary). You'd have a mismatch between the class literals (remapped by TR), and the method names (string constants), unless you were in a prod environment using intermediary class names.

[LogicFan]

You'd have a mismatch between the class literals (remapped by TR), and the method names (string constants)

As you can see in the fabric mapping resolver, there is a unmap method, which can be used for this situation. If a user runs things on yarn environment and the jar is in an intermediary, then the process will be

owner (class literal) -> getName (yarn name) -> unmap (intermediary name)
desc (class literals) -> similar to above
method (mojname) -> some how make it intermediary name -> map (with the intermediary owner and desc described above) -> yarn name

[zml2008]

Ah I see that, thanks for clairfying -- it's a touch non-traditional, but the class literal-based API is less error prone. I'm fine with that, but would be even better to see a class literal-based API exposed directly upstream in loader.

[LogicFan]

styles fixed.

[LogicFan]

Since SpongeForge is developed using forge-loom (which also uses tiny-remapper IIRC), FabricMC/tiny-remapper#70 might be a better solution than this PR.