Re: [Clirr-devel] comments on recent commits

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

Simon Kitching wrote:

>On Mon, 2004-06-21 at 05:13, Lars Kühne wrote:
>  
>
>>BTW, if we wrote our own BCEL adaptor I mentioned on IRC, this would be 
>>one of the methods for a class, so we'd have a more OO API to work with. 
>>No big deal however, and the work involved in such an abstraction would 
>>not be justified...
>>    
>>
>
>The ASM library appears to handle this stuff automatically; see
>
>http://asm.objectweb.org/current/doc/javadoc/user/org/objectweb/asm/tree/InnerClassNode.html
>
>I also think that BCEL's OO design is odd in places. AccessFlags? Should
>a JavaClass really have an "is-a" relationship with (ie inherit from)
>"AccessFlags"? A has-a relationship seems much more sensible.
>
>  
>

Yes, I have found that the BCEL design is ... errrmmhhh ... a bit 
strange in places. You mentioned one example, the classloader/repository 
handling is another one. I've also found that bcel accessors tend to 
hand out their private data structures, e.g. JavaClass.getFields()

>And I've also subscribed to the BCEL user email list, and can report it
>is absolutely *silent*.
>
>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.


>And one last issue: java 1.4 includes the BCEL classes, because it
>includes Xalan; try "jar tf rt.jar | grep BCEL".
>

No results for me (1.4.2-b28), it seems Sun has fixed it within 1.4.2 as 
well (?). Still it's worrying. I've checked the bcel-devel archives, and 
that's not too encouraging either...

> So it is not possible
>to provide an updated BCEL distribution with clirr (classes in rt.jar
>override the user classpath, unless serious trickery is applied). Note
>that this is a problem *only* for java1.4; sun have fixed this in 1.5.
>
>  
>
>>>I'm slowly working my way through chapter 13 of the java specification
>>>(the binary compatibility bit); I presume you've been though that too.
>>>That's something I would never have done if I hadn't started working on
>>>clirr!
>>>
>>> 
>>>
>>>      
>>>
>>Maybe we should start an Open Source Java Profiler tool (competitor to 
>>JProbe, Optimizeit, etc.) so we get to read "Inside the Java Virtual 
>>Machine" as well ;-)
>>    
>>
>
>Hey, why not??
>
>I have noticed a need for a tool that determines whether code is
>invoking any methods not present in Java version XXX. A few Apache
>commons releases have accidentally gone out with code that doesn't work
>in java 1.3. 
>
>This should be pretty simple to implement: 
>(a) 
>get a list of all accessable classes, methods,fields in release X of
>java
>(b) 
>iterate over all the code in a set of jars, determining whether
>there are any references to classes/methods/fields that aren't present
>in the list from step (a).
>
>I don't know whether this is within the scope of the clirr project or
>not....it is sort of a "binary compatibility test", but this time
>testing whether program W is compatible with library X, rather than
>whether there are any differences between library X version 1 and
>version 2.
>  
>

That would probably be in scope for clirr, but I'm not sure it's 
feasible: Things like reflection and casting may turn out to be 
significant road blocks to detect these problems reliably. But maybe we 
could start by checking that the class file format version of each class 
has stayed the same?

On a related note, I have recently found out that messing around with a 
method's declared exceptions will not result in binary compatibility 
problems (surprising to me). Should we extend clirr's scope to check for 
source compatibility as well?

Cheers,
Lars