Is it possible to decouple the code indexing capabilities of Eclipse?

岁酱吖の 提交于 2019-12-03 15:24:42

Walking the byte code is not hard at all and is not slow either. We have performed static analysis of large Java code projects at interactive speeds. Since, you are short on time I would suggest that you modify something like a call graph viewer plugin[1] in eclipse. Also, Eclipse code is hard to comprehend, you are better off writing your own plugin that uses as much of Eclipse's undocumented API's as possible.

[1] http://www.eclipseplugincentral.com/Web_Links-index-req-viewlink-cid-1326.html

zvikico

The operation you are looking for is not exactly indexing. Indexing is done to provide full text search. Finding the super-class of a given class is hardly text search.

You want to write an Eclipse plugin (rather simple, may be just a couple of classes) which uses JDT. You will need to write an AST (Abstract Syntax Tree) Visitor which will be used to analyze your code. You will then be able to resolve types and easily traverse the class hierarchy using the JDT facilities.

Check out my answer to this question.

I would go for a solution based on ASM, it will do the hard work, resolving hierarchy. Here is a simple analyser, that println the call hierarchy of Class given :

public class Analyzer {
    public static void main(String[] args) throws IOException {
        ClassReader classReader;
        ClassNode classNode;
        String fullyQualifiedClassName = args[0];
        String callHierarchy = "";
        while (null != fullyQualifiedClassName) {
            callHierarchy = " > " + fullyQualifiedClassName + callHierarchy;
            classReader = new ClassReader(fullyQualifiedClassName);
            classNode = new ClassNode();
            classReader.accept(classNode, 0);
            if (null != classNode.superName) {
                fullyQualifiedClassName = classNode.superName.replace('/', '.');
            } else {
                fullyQualifiedClassName = null;
            }
        }
        System.out.println(callHierarchy);
    }
}

Given java.util.TreeMap as argument, it prints

> java.lang.Object > java.util.AbstractMap > java.util.TreeMap

I know this is bytecode analysis, but to be honest, ASM is lightning fast and if all you need is Call Hierarchy, scanning won't take much time (nothing noticeable imo).

Hope this help :)

Have a look at IBM's WALA framework. Among other things, you can generate the Call Graph (CG) for your code base. In fact, pretty much everything in WALA starts with building the CG. You can modify their examples and replace the test data with your own.

This is a GUI plugin to Eclipse that gives a visual representation of the call hierarchy. It's not a list, but it's a help.

http://www.certiv.net/projects/callgraph.html

kdgregory

I would ignore Eclipse entirely: it's just going to distract you.

If you're performing static analysis, you'll almost certainly want to analyze bytecode. To find the call hierarchy, you look for the invokeinstance, invokestatic, and invokespecial bytecodes (see the JVM spec). These reference a fully qualified class/methodname, and you can build your call hierarchy using a Map<FuncRef,Set<FuncRef>>, where FuncRef is a class you define to hold the method call information.

BCEL can help you with bytecode scanning.

However, you're going to have to do more work than that, particularly with invokeinstance, since you don't know what the real instance might be. Sometimes you can look backwards in the code to find an assignment, but more likely you're going to be guessing -- this is the Achilles heel of static analysis.

Have you looked at ecj? It's the compiler portion of eclipse, factored out into a separate project.

Or you can use the JDT portion of eclipse: http://www.eclipse.org/jdt/core/index.php

Eclipse plugins really aren't that hard; they take a little getting used to, but not too long.

Think about adding whatever functionality you want to the eclipse IDE. You can leverage other plugin functionality (such as JDT, which includes the search functionality you're looking for).

You can then provide your plugins for all eclipse users to use, rather than develop another standalone tool.

I suspect you will find that it's easier to write the plugin - for which Eclipse is designed and documented - than to extract the bits that are meant to be internal and build something else out of them.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!