[Clirr-devel] BCEL abstraction API (was: comments on recent commits)

[<lak...@t-...>]

Simon Kitching wrote:

>On Mon, 2004-06-21 at 17:50, Lars Kühne wrote:
>  
>
>>Simon Kitching wrote:
>>
>>    
>>
>>>On Mon, 2004-06-21 at 05:13, Lars Kühne wrote:
>>> 
>>>
>>>
>>>So I would be quite keen for clirr to move to ASM sooner or later. BCEL
>>>is working for now, so there's no urgency, but I think it would be a
>>>good idea in the long run. Building a "wrapper" that allows BCEL or ASM
>>>to be "plugged in" is an option, but it would be significant work and I
>>>don't really see any benefits over simply using ASM directly.
>>>
>>> 
>>>
>>>      
>>>
>>    * It would minimize our external dependencies, check implementations
>>      would only reference our own stuff.
>>    * Some IDEs provide their own API for accessing the class info we
>>      need, at least for the current version of the code that is
>>      checked. For example I know that IDEA provides a ProgramStructure
>>      interface (PSI) to access the source code. PSI isn't based on
>>      class files, but it provides all info required for clirr, like
>>      inheritance hierarchy, method signature, etc. Typically the IDE
>>      caches that information, minimizing disk activity. If clirr is
>>      used interactively from an IDE plugin, using PSI instead of
>>      accessing class files could make a real difference in terms of
>>      performance.
>>    
>>
>
>The PSI stuff is a good point.
>
>If IDEA have gone to the effort of designing a nice API for accessing
>class structure, then can we use *that* as our API too? ie write
>adaptors from PSI->BCEL, PSI->ASM, PSI->PSI? It seems silly to invent
>our own API...and presumably APIs are in the public domain (unlike
>implementations).
>  
>

The IDEA license does not allow redistribution of the psi classes (at 
least not in IDEA 3, which is what I have), because they are bundled 
with the idea implementation classes (one jar file).

The Eclipse JDT probably has something similar, but I'm not sure we 
really want to develop against such an API: It's too detailled. I don't 
know much about JDT, but the IDEA psi API gives you access to the actual 
source code of a method, the source file, etc. Clirr does not need all 
that, and it would be really hard to write an adapter that maps BCEL to 
PSI because of all the stuff you have to implement.

In fact I think the API we need would not be very large, it would 
basically consist of the following interfaces:

JavaClass
+ Method[] getMethods()
+ String getName()
+ JavaClass[] getSuperClasses()
+ JavaClass[] getImplementedInterfaces()

Method
+ String getName()
+ String getSignature() // would return sth. like "public void blah()"
+ JavaClass[] getParameterTypes()
+ JavaClass[] getDeclaredExceptions()

Field
+ String getName()
+ JavaClass getType()
+ Object getConstantValue()

Some parts are missing (like access scope), but I think you get the 
idea: It's not very complicated (quite similar to the reflection API), 
it's trivial to implement with BCEL, and I guess it would be trivial to 
implement with ASM, IDEA psi, Eclipse JDT or whatever...

But like you said, I don't think such a refactoring is important near 
term - let's reconsider it when an IDE plugin appears on the horizon...

Lars