Re: [Clirr-devel] comments on recent commits

[Simon K. <si...@ec...>]

On Mon, 2004-06-21 at 05:13, Lars K=FChne wrote:
> BTW, if we wrote our own BCEL adaptor I mentioned on IRC, this would be=
=20
> one of the methods for a class, so we'd have a more OO API to work with=
.=20
> No big deal however, and the work involved in such an abstraction would=
=20
> 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.

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.

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

>=20
> >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 o=
n
> >clirr!
> >
> > =20
> >
>=20
> Maybe we should start an Open Source Java Profiler tool (competitor to=20
> JProbe, Optimizeit, etc.) so we get to read "Inside the Java Virtual=20
> 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.=20

This should be pretty simple to implement:=20
(a)=20
get a list of all accessable classes, methods,fields in release X of
java
(b)=20
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.

Regards,

Simon