Re: [jdt-core-dev] Re: Dynamically generating source for IClassFile ...

["Philippe Mulet/SNZ/OTI" <Philippe_Mulet@xxxxxxx>]

Vladimir,

I could imagine situations where I am not interested by a disassembled 
source, but simply by bytecodes (like the output of javap -c).
How would you envisage to have both views interact ? Is this a truly 
separate problem ? Would you support parameters ?

Philippe





"Vladimir Grishchenko" <vladgri@xxxxxxxxxxx>
Sent by: jdt-core-dev-admin@xxxxxxxxxxx
11/26/2001 06:09 PM
Please respond to jdt-core-dev

 
        To:     <jdt-core-dev@xxxxxxxxxxx>
        cc: 
        Subject:        [jdt-core-dev] Re: Dynamically generating source for IClassFile ...

That's pretty much it. The simple logic I follow is to try to getSource()
on ClassFile, if it's null I extract local file system coordinates from
ClassFile (getParent().getParent()...) and decompile it, then do
something like BufferManager.getDefault().openBuffer(char[],...).

The extension point would probably rely on simple interface like

public interface ISourceLocator
{
    public String locateSource(IClassFile cFile);
}

which would be consulted if an attempt to retrieve source for a class file
failed using normal mechanisms. You could even include a default
decompiler which just extracts class name and methods stubs

--Vladimir.
--------------------------------

Hello Vladimir,

Unfortunately there isn't currently a way to plug your tool inside JDT
cleanly. We should indeed introduce an extension point for you to succeed.
We currently handle source attachments internally (through indications
associated with the classpath), but what you're suggesting is that this
could be bundled separately, right (if no source is available, then
decompile ?).





"Vladimir Grishchenko" <vladgri@xxxxxxxxxxx>
Sent by: jdt-core-dev-admin@xxxxxxxxxxx
11/26/2001 12:39 AM
Please respond to jdt-core-dev


        To:     <jdt-core-dev@xxxxxxxxxxx>
        cc:
        Subject:        [jdt-core-dev] Dynamically generating source for
IClassFile - advice
needed...

Hello all,

I'm trying to create a plugin that will allow automatic decompilation of
class files with no source code available
(http://sourceforge.net/projects/jadclipse). Whether or not it's legal to
decompile is a separate discussion... I need an advice on how I could
accompilsh this without using dirty code calling internal methods and at
the
same time have it integrated with JDT. I have a beta version functional
but
it relies on internal classes:

 org.eclipse.jdt.internal.ui.javaeditor.IClassFileEditorInput
 org.eclipse.jdt.internal.core.BufferManager

Not surprisingly, the plugin breaks whenever there's a change in relevant
intrenal API. I tried to create my own class file editor and use
org.eclipse.ui.editors EP, but I get an instance of
org.eclipse.jdt.internal.ui.javaeditor.InternalClassFileEditorInput in
init() method, which is internal again. Is there a "clean" way to do it?
Does anyone think that org.eclipse.jdt.SourceLocators extension point
would
make sense for such application if it existed?

Thanks,
Vlad.

_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev