clirr-devel

[Clirr-devel] about to commit changes to support a SPI

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

Hi,

if nobody objects within the next few days, I will commit changes to 
clirr-core that introduce an SPI for providing the Java code structure. 
I think I discussed the idea with Simon a while ago, the basic idea is 
to let the checks work against a the interfaces /JavaType,/ /Field/ and 
/Method/ instead of working directly against the BCEL classes.

This change has three major objectives:

    * decouple our core logic from external dependencies (in this case BCEL)
    * allow replacing BCEL with a faster/smaller/more-full-featured
      (think Java5) byte code lib. ASM would be one of the candidates
    * allow Clirr IDE plugins to use their IDE's internal code
      representation, so compilation to class files is not required. It
      should be possible to write a plugin that lets users detect
      incompatible changes while they are typing the code.

All existing tests still pass, but this change could cause problems for 
some corner cases that are currently untested.

Let me know what you think.

Cheers,
Lars

RE: [Clirr-devel] about to commit changes to support a SPI

[Vincent M. <vm...@pi...>]

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Lars K=FChne
> Sent: lundi 22 ao=FBt 2005 21:05
> To: cli...@li...
> Subject: [Clirr-devel] about to commit changes to support a SPI
>=20
> Hi,
>=20
> if nobody objects within the next few days, I will commit changes to
> clirr-core that introduce an SPI for providing the Java code =
structure.
> I think I discussed the idea with Simon a while ago, the basic idea is
> to let the checks work against a the interfaces /JavaType,/ /Field/ =
and
> /Method/ instead of working directly against the BCEL classes.
>=20
> This change has three major objectives:
>=20
>     * decouple our core logic from external dependencies (in this case
> BCEL)
>     * allow replacing BCEL with a faster/smaller/more-full-featured
>       (think Java5) byte code lib. ASM would be one of the candidates
>     * allow Clirr IDE plugins to use their IDE's internal code
>       representation, so compilation to class files is not required. =
It
>       should be possible to write a plugin that lets users detect
>       incompatible changes while they are typing the code.
>=20
> All existing tests still pass, but this change could cause problems =
for
> some corner cases that are currently untested.
>=20
> Let me know what you think.

Sounds good to me.

-Vincent

Re: [Clirr-devel] about to commit changes to support a SPI

[Simon K. <ski...@ap...>]

On Mon, 2005-08-22 at 21:05 +0200, Lars Kühne wrote:
> Hi,
> 
> if nobody objects within the next few days, I will commit changes to 
> clirr-core that introduce an SPI for providing the Java code structure. 
> I think I discussed the idea with Simon a while ago, the basic idea is 
> to let the checks work against a the interfaces /JavaType,/ /Field/ and 
> /Method/ instead of working directly against the BCEL classes.
> 
> This change has three major objectives:
> 
>     * decouple our core logic from external dependencies (in this case BCEL)
>     * allow replacing BCEL with a faster/smaller/more-full-featured
>       (think Java5) byte code lib. ASM would be one of the candidates
>     * allow Clirr IDE plugins to use their IDE's internal code
>       representation, so compilation to class files is not required. It
>       should be possible to write a plugin that lets users detect
>       incompatible changes while they are typing the code.
> 
> All existing tests still pass, but this change could cause problems for 
> some corner cases that are currently untested.
> 
> Let me know what you think.

Sounds fine - though I would also be happy with just swapping to use ASM
directly.

I've been wondering whether we should look at restructuring the code to
work more like an asm "visitor" or how checkstyle works than the current
layout, because last I looked the method tests were getting rather
complex. But of course last time I looked was quite a while ago! I
presume your new code will still essentially encapsulate an in-memory
"model" of classes that the checks then inspect rather that try to be
more ASM-ish??

Cheers,

Simon

Re: [Clirr-devel] about to commit changes to support a SPI

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

Simon Kitching wrote:

>On Mon, 2005-08-22 at 21:05 +0200, Lars Kühne wrote:
>  
>
>>Hi,
>>
>>if nobody objects within the next few days, I will commit changes to 
>>clirr-core that introduce an SPI for providing the Java code structure. 
>>[...]
>>
>Sounds fine
>

OK, done.

> - though I would also be happy with just swapping to use ASM
>directly.
>
>  
>

You mean implementing our checks directly against ASM? I considered 
that, but I think an IDE plugin would provide real value. I'm not sure 
that the interface design is ideal, though - this is only a first shot.

>I've been wondering whether we should look at restructuring the code to
>work more like an asm "visitor" or how checkstyle works than the current
>layout, because last I looked the method tests were getting rather
>complex.
>

Yes, they are too complex.

> But of course last time I looked was quite a while ago! I
>presume your new code will still essentially encapsulate an in-memory
>"model" of classes that the checks then inspect rather that try to be
>more ASM-ish??
>
>  
>

Currently yes, but now that we have our own interfaces we are no longer 
limited by BCEL and can easily add an accept() method to them.

Not sure that the visitor pattern is ideal, though. The checks are 
dependent on each other in the sense that some checks are not executed 
if other checks detect a "higher level" problem. Visitor doesn't cover 
this well, to me this sounds like we should organize our checks as a 
chain of responsibility. Haven't thought this through completely however...

Thanks for your feedback,
Lars