Stack traces

Once classes and members are renamed, a stack trace from a protected jar names a.b.c instead of your classes. The mapping file records every renaming of a run so you can translate those names back.

Export the mapping

Set mappingOutput to the path of the file to write:

{
  "options": {
    "profile": "High",
    "mappingOutput": "build/mapping.json"
  }
}

The file is written at the end of the run, with its parent folders created if needed. Nothing is written when renaming is off.

What it contains

The mapping is a JSON object with up to three sections:

Section	Content
renamed	Every old name and its new name: classes, fields and methods. Class names use the JVM’s internal form, with slashes.
kept	The input classes that kept their name, each with the exclusion rule responsible for it.
generated	Helper classes that HashGuard generated under random names, so you can recognise them while debugging.

An abridged example:

{
  "renamed": {
    "com/example/Main": "com/example/protected/a"
  },
  "kept": {
    "com/example/api/Client": "rename:com.example.api.**"
  }
}

The kept section also explains, after the fact, why a class was not renamed.

Decode a trace

Look up each obfuscated class and member of the trace in renamed, from new name back to old. The mapping is plain JSON, so profilers such as JProfiler and your own tooling can read it to show the original names.

Generated names can change from one build to the next, so always decode a trace with the mapping of the build that produced it. Store the mapping next to each release.

Keep it private

The mapping undoes the renaming. Never ship it with the jar or publish it: keep it as a private artifact of your build, see Continuous integration.