Package org.benf.cfr.reader.api

# Interface SinkReturns.LineNumberMapping

Enclosing interface:
  `SinkReturns`

public static interface SinkReturns.LineNumberMapping

- ## Method Summary

  Modifier and Type
  Method
  Description
  `NavigableMap<Integer,Integer>`
  `getClassFileMappings()`
  `NavigableMap<Integer,Integer>`
  `getMappings()`
  `String`
  `methodDescriptor()`
  `String`
  `methodName()`

- ## Method Details

  - ### methodName

    String methodName()
    Returns:
      Name of method for which these line number mappings apply.

  - ### methodDescriptor

    String methodDescriptor()
    Returns:
      Descriptor of method for which these line number mappings apply.

  - ### getMappings

    NavigableMap<Integer,Integer> getMappings()
    Returns:
      Mapping from bytecode location in contained method to line number. Note that this is indexed by bytecode location, not by line number (as is found in javap output). (multiple bytecodes may appear on the same line out of order). and only applies to the method which is described by methodDescriptor. Line numbers apply to the entire output file/text, and include all emitted comments etc.

  - ### getClassFileMappings

    NavigableMap<Integer,Integer> getClassFileMappings()
    Returns:
      Mappings from bytecode location in contained method to line number, as specified by the class file. This corresponds to the LineNumber table in the original class file. Note: These mappings are unreliable, not verified, and may contain entirely invalid data. This may be null, if the original class file did not contain line number information. Why provide this at all? Some editors (notably intellij's IDEA) don't allow decompilers to return mappings between bytecode and line numbers, just between 'original line numbers' and 'decompiled line numbers'. When correlated with `getMappings`, this is sufficient to provide that.