Package org.benf.cfr.reader.api

# Interface ClassFileSource

public interface ClassFileSource
Implementing your own `ClassFileSource` allows you to override CFR's sourcing of byte code. You could even generate bytecode on the fly and provide it to CFR. If you wish to delegate to a 'normal' `ClassFileSource`, you may get one from `ClassFileSource.Factory` Note that implementations of this object that provide more than one class are likely to have to be mutable, as they need to keep track of the relationship between classes and directories.

- ## Nested Class Summary

  Nested Classes
  Modifier and Type
  Interface
  Description
  `static class`
  `ClassFileSource.Factory`
  Helper to construct "Standard" `ClassFileSource`, which may be useful for delegating to.

- ## Method Summary

  Modifier and Type
  Method
  Description
  `Collection<String>`
  `addJar(String jarPath)`
  CFR would like to know about all classes contained within the jar at `jarPath`
  `org.benf.cfr.reader.bytecode.analysis.parse.utils.Pair<byte[],String>`
  `getClassFileContent(String path)`
  Given a path to a class file, return a pair of * the content, as a byte array.
  `String`
  `getPossiblyRenamedPath(String path)`
  It's possible that an obfuscator might have generated a bizarre and magic file inside a jar such that it's path is too big to read.
  `void`
  `informAnalysisRelativePathDetail(String usePath, String classFilePath)`
  CFR has loaded your class, and it has decided that if it were in the correct location, it would instead be at `classFilePath`.

- ## Method Details

  - ### informAnalysisRelativePathDetail

    void informAnalysisRelativePathDetail(String usePath, String classFilePath)
    CFR has loaded your class, and it has decided that if it were in the correct location, it would instead be at `classFilePath`. This information should be taken into account when loading any inner classes, or other classes that CFR tries to load in order to improve decompilation. Why do you care? Let's say you have a class in a top level outside its normal structure, Bob.class. It should be found at org/person/Bob.class. Implementors of this will be called back with "", and "org/person", telling you that org.person are implicit in your path. CFR may later ask you to load "org/person/Bob$1.class". You should adjust this path to match where Bob$1 actually is. This will also be called with null, null to reset.
    Parameters:
      `usePath` - the path that was used to load a class file.
      `classFilePath` - the path that CFR actually suspects it should have been, based on package name.

  - ### addJar

    Collection<String> addJar(String jarPath)
    CFR would like to know about all classes contained within the jar at `jarPath`
    Parameters:
      `jarPath` - path to a jar.
    Returns:
      paths (inside jar) of all classes.

  - ### getPossiblyRenamedPath

    String getPossiblyRenamedPath(String path)
    It's possible that an obfuscator might have generated a bizarre and magic file inside a jar such that it's path is too big to read. Or it's invalid. This allows you to remap paths.
    Parameters:
      `path` - Path CFR would like to use
    Returns:
      Remapped path.

  - ### getClassFileContent

    org.benf.cfr.reader.bytecode.analysis.parse.utils.Pair<byte[],String> getClassFileContent(String path) throws IOException
    Given a path to a class file, return a pair of * the content, as a byte array. * the path where you found this.
    Parameters:
      `path` - relative path of class we wish to load.
    Returns:
      Pair<byte[], String> of class file content, and file location.
    Throws:
      `IOException` - if you can't find the class.