Virtual mappings

[Col-E]

Mostly for brainstorming, the feature is complex and not likely to actually be implemented unless a REALLY good solution is put forward

UI components:

• Workspace tree
• Class tab tiles
• Class views & all associated components

Logical components:

• Decompilers
  • Need to target the virtual mappings, NOT the real existing code
    • Pre-processors can handle that
• Assembler / Disassembler
  • Need to target the virtual mappings, NOT the real existing code
    • This one is a bit of a doozy...
• Inheritance graph
  • Need to target the virtual mappings, NOT the real existing code
    • Need to make getSuperClass() yield the virtual mapped name, or handle it explicitly here.
    • More API changes for solution work mentioned below.
• Call graph
  • Need to target the virtual mappings, NOT the real existing code
    • Should be operating off virtually mapped bytecode, shouldn't be too hard to manage.
    • Lookups by name need to resolve as virtual mapped names.
• Mapping
  • Need to target the virtual mappings, NOT the real existing code
    Example: If XYZ is virtually Dog what should be done in the given circumstances?
    • Map XYZ to ABC: Nothing since XYZ virtually does not exist.
    • Map Dog to ABC: Apply the mapping.

Potential solutions:

• Currently we have getBytecode() for JVM classes.
  • Instead offer getOriginalBytecode() and getVirtualMappedBytecode() (Names not final, but to drive the point across)
  • The VirtualMappedBytecode is mutable data, which is dynamically updated across the workspace whenever virtual mapping are modified. They are thus always kept up-to-date.
    • Would be useful to optimize the update process so unaffected classes per a change are easily determined, so the mapping process only applies to relevent classes.
  • The usage of getOriginalBytecode() is very limited, and instead most calls are to getVirtualMappedBytecode().
  • The remaining issue is maintaining access by virtual name.
    • Can potentially change the Workspace#findClass(String) to assume the input is the virtual mapped name?
      • Would need to ensure all ClassInfo lookups use the find operations, and not directly from the ClassMap.

[Janmm14]

Using a bijective function for identifier renaming and renaming all identifiers makes virtual mapped bytecode not experience more mutations than regular bytecode..
The target identifier could add prefix for field/class/method differenciation, every char not allowed in identifiers and underscores are replaced by _ + unicode hex of the char + same for desc

Every feature except mappings would use the virtual mapped bytecode and "only" for displaying to the user or exporting identifiers would be mapped back.
Maybe there'd be no need to even keep non-mapped bytecode in memory.