Bug 201691 - Decompiler SPI
Decompiler SPI
Status: NEW
Product: java
Classification: Unclassified
Component: Classfile
7.1
All All
: P3 with 6 votes (vote)
: 7.1
Assigned To: Tomas Zezula
issues@java
: API
: 209883 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-06 14:24 UTC by Jesse Glick
Modified: 2015-07-22 22:11 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo