Re: [Clirr-devel] comments on recent commits

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

On Mon, 2004-06-21 at 17:50, Lars K=FChne wrote:
> Simon Kitching wrote:
>=20
> >On Mon, 2004-06-21 at 05:13, Lars K=FChne wrote:
> > =20
> >
> >
> >So I would be quite keen for clirr to move to ASM sooner or later. BCE=
L
> >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 AS=
M
> >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.
> >
> > =20
> >
>=20
>     * It would minimize our external dependencies, check implementation=
s
>       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).

>=20
>=20
> >And one last issue: java 1.4 includes the BCEL classes, because it
> >includes Xalan; try "jar tf rt.jar | grep BCEL".
> >
>=20
> No results for me (1.4.2-b28), it seems Sun has fixed it within 1.4.2 a=
s=20
> well (?). Still it's worrying. I've checked the bcel-devel archives, an=
d=20
> that's not too encouraging either...

Sorry,my mistake. I'm sure I saw it there, but can't find it now. I must
have had sun-stroke or something :-)

Bcel is in java 1.5, but isn't an issue because with 1.5 sun now make
sure any non-sun software they distribute is given a sun package prefix,
eg 1.5 contains:
  com.sun.org.apache.bcel...
  com.sun.org.apache.xerces....

This is a reasonably nice solution; they don't hide the real authors of
the code, but do allow downloads direct from apache or others to be used
without conflicting with the classes in the java std libs.


> >>>
> >>Maybe we should start an Open Source Java Profiler tool (competitor t=
o=20
> >>JProbe, Optimizeit, etc.) so we get to read "Inside the Java Virtual=20
> >>Machine" as well ;-)
> >>   =20
> >>
> >
> >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 wor=
k
> >in java 1.3.=20
> >
>=20
> That would probably be in scope for clirr, but I'm not sure it's=20
> feasible: Things like reflection and casting may turn out to be=20
> significant road blocks to detect these problems reliably. But maybe we=
=20
> could start by checking that the class file format version of each clas=
s=20
> has stayed the same?

Yes, there could be gotchas.=20

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

I'm +1 on reporting compile-time incompatibilities too.=20

I agree that changing the declared exceptions should be reported; a
WARNING seems most appropriate to me. What do you think?


Regards,

Simon