Virtual mappings
- Dominant language
- Java
- Stars
- 7.4k
- Forks
- 538
- PR merge metrics
- No merged PRs in 30d
Description
## 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`.
Contributor guide
Assessment
This issue has not been assessed yet.