This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 201691

Summary: Decompiler SPI
Product: java Reporter: Jesse Glick <jglick>
Component: ClassfileAssignee: Tomas Zezula <tzezula>
Status: NEW ---    
Severity: normal CC: asbachb, cezariusz, spao001, terje7601
Priority: P3 Keywords: API
Version: 7.1   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:

Description Jesse Glick 2011-09-06 14:24:13 UTC
Currently when a request is made to open a source file for a class file which has no known source association, a class signature is opened with exceptions for method bodies. Obviously this is not very useful for understanding what the class does.

A decompiler would be more useful. Since these vary widely in capabilities and license terms, an SPI is needed so they can be supplied in plugins. The simplest possible interface would be:

/** @see ServiceProvider */
public interface Decompiler {
  /**
   * @param root the binary root of the class, e.g. {@code jar:file:/x.jar!/}
   * @param clazz a binary top-level class name in that root
   * @return the body of the decompiled source file
   * @throws IOException in case of problems reading the class file(s), invoking external tools, etc.
   * @throws UnsupportedOperationException if this decompiler cannot handle this root or class but another might be able to
   */
  String decompile(URL root, String clazz) throws IOException, UnsupportedOperationException;
}

The fallback implementation could be the current one - showing the class signature with dummy method bodies and initializers. Other implementations could include:

- show class signature with a placeholder exception for a method body but also including disassembly using javap
- show other method calls made within a method body, but in no defined order and with no variables etc. (just so you can Ctrl-B to them)
- a real decompiler that attempts to reconstruct original sources, such as JD

Other potentially useful additions:

- a binary classpath (not sure if any decompiler needs to know information about libraries in the classpath?)
- a display name, in case a GUI selector is needed (?)
- an ID so that gensrc dirs can keep track of which decompiler produced a given cached source file (but Lookup.Item.id might suffice)
Comment 1 Tomas Zezula 2011-09-06 14:40:10 UTC
We already have internal BinaryElementOpen having:
public boolean open(ClasspathInfo cpInfo, ElementHandle<? extends Element> toOpen);
But it's quite low level as the implementor needs handle file opening and setting the correct attributes on the generated FileObject to enable "Attach Sources...".
Making a SPI called from the BinaryElementOpen impl will be good.
Comment 2 Tomas Zezula 2012-03-21 16:46:59 UTC
*** Bug 209883 has been marked as a duplicate of this bug. ***