clirr-devel — Discussion about the source code of Clirr

[Clirr-devel] About to commit new project structure

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

Hi guys,

I'm about to commit the multiproject changes we have been discussing. 
The current status has been tagged BEFORE_GOING_MULTIPROJECT.

There are a few things left to work out (web site structure, release 
process, etc.), but I guess it will be easier to solve if you have the 
new tree available, so I'll commit now and we can dicuss/change later.

Prepare for CVS flooding your inbox.

Lars

RE: [Clirr-devel] maven plugin

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Lars K=FChne
> Sent: lundi 5 juillet 2004 23:23
> To: cli...@li...
> Subject: Re: [Clirr-devel] maven plugin
>=20
> Vincent Massol wrote:
>=20
> >>Vincent, you can start moving core to it's sub-module and add the =
maven
> >>plugin. Do you need help or is it easier for you if you do it alone?
> >>
> >>
> >
> >I'll let you do the 'core' move and once it's done I'll create a top
> level
> >maven directory and work in there.
> >
> >
>=20
> FYI, I've been working on moving core this evening - good progress so =
far.
>=20
> I'm a bit short on time, but I think it should be possible to complete
> this work during the next few days.

No problem at all.

Thanks
-Vincent

RE: [Clirr-devel] maven plugin

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Simon Kitching
> Sent: mardi 6 juillet 2004 00:31
> To: cli...@li...
> Subject: RE: [Clirr-devel] maven plugin
> 
> On Mon, 2004-07-05 at 22:15, Vincent Massol wrote:
> > the core build is at the top level. We need a separation between the
> > core build and the maven plugin build. Hence the need for a separate
> > directory structure for core/maven.
> 
> Ok, I think I start to understand.
> 
> I presumed you were talking about a *java package* restructure, but what
> you actually need for maven is just a *directory tree* restructure? And
> the java classes could keep their original package declarations?

Yes, exactly.

> 
> As it happens, I'm quite happy to go with a minor java package
> restructure anyway; moving event/framework/check packages into a parent
> "n.s.c.core" package seems a good idea.

I also believe it's a good move.

> 
> Well, I'll just watch for whatever changes turn up, and go with them.
> 
> Cheers,
> 
> Simon

Thanks
-Vincent

RE: [Clirr-devel] maven plugin

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Lars K=FChne
> Sent: lundi 5 juillet 2004 19:22
> To: cli...@li...
> Subject: Re: [Clirr-devel] maven plugin
>=20

[snip]

>=20
> I mean toplevel modules in a Maven multiproject setup. This is =
basically
> the toplevel directory structure when you CVS-checkout clirr. Each
> module (core and maven) have a toplevel project.xml.
>=20
> Basically the multiproject plugin will search for subdirectories with
> project.xml files, cd into each of those, and build it (plus I think =
it
> will also build a couple of other things, like a wrapper website).
>=20
> Most of the current content of the root directory will be moved into =
the
> 'core' module/subdir, Vincent will fill the maven module.
>=20
> If I understand things correctly, the multiproject plugin is _the_ way
> to make Maven build multiple artifacts (jars) in one combined build.

Not quite. The Maven multiproject plugin does 2 things:
- it can call a given maven goal on a set of subprojects
- it can generate automatically a wrapper website for all subprojects
- it can generate a dependency convergence report (i.e. it lists all
dependencies - For example
http://jakarta.apache.org/turbine/turbine-2.4/dependency-convergence-repo=
rt.
html).

[snip]

> Yes, that is the basic java package structure. The core multiproject
> module (Vincent, please correct my terminology if necessary)=20

There are 2 things:
- plugins. They offer all the goals you can call (the goals listed when =
you
type "maven -g")
- projects. They are directories with a project.xml file and possibly a
maven.xml (for custom build code) and a project.properties =
(configuration of
the Maven plugins)

> will
> contain the above three Java top-level packages. Because each module

It's called a "project" :-)

> corresponds to one jar, this will lead to a combined jar that is easy =
to
> use, just like what we have now.

You'll need to use the Maven uberjar plugin for this (the multiproject =
has
nothing to do with this). See
http://maven.apache.org/reference/plugins/uberjar/

-Vincent

Re: [Clirr-devel] Java doesn't appear to do runtime checks for class/method access rights

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

On Tue, 2004-07-06 at 06:06, Lars K=FChne wrote:
> Simon Kitching wrote:
> >Attached is an archive which contains some java code that appears to
> >demonstrate that the Java JVM/runtime does not check for class or meth=
od
> >access rights.
> >
> >The java lang spec document seems clear that this *should* throw an
> >IllegalAccessError, but it doesn't. I would like someone to confirm th=
at
> >I am not having hallucinations here before I add a note about this to
> >the message description document.
> >
> I can confirm your results:
>=20
> access> java Main
> public method f1 of package scope class Foo called!
> private method f2 of package scope class Foo called!
>=20
> Wow!!
>=20
> This is scary, but on the other hand it's quite logical. Try to=20
> disassemble the code of Main:
[...]
> It seems the bytecode for both method calls is the same. The Main class=
=20
> simply seems to have no record whether the called methods are private o=
r=20
> public, so the VM can't check anything... ?

The information must be in the class file somewhere, because in BCEL we
can ask:
   somemethod.isPrivate() etc.
Also, when compiling source with javac against a library the compiler
can report attempted calls to inaccessable methods.

>=20
> I couldn't find the IllegalAccessError requirement you mentioned, but i=
n=20
> $13.4.6 the JLS says:
>=20
> "Changing the declared access of a member or constructor to permit less=
=20
> access may break compatibility with pre-existing binaries, causing a=20
> linkage error to be thrown when these binaries are resolved.
>=20
> Less access is permitted if the access modifier is changed from default=
=20
> access to |private| access; from |protected| access to default or=20
> |private| access; or from |public| access to |protected|, default, or=20
> |private| access"
>=20
> Not quite sure what to make of this, to me the spec is quite confusing =
-=20
> aren't those two sentences contradicting each other?

The sentence beginning "Less access" *is* poorly worded, but correct.=20

To rephrase:=20
  "<em>Less</em> access is permitted if ..."
or:
  "The access permissions are defined to be 'less' if the access =20
   modifier is changed from...."=20

The sentence starting "Changing..." says what happens if a change
resulting in "less access" is made: a linkage error is thrown.

Hmm..I can't find the bit that specifies "IllegalAccessError" either,
though I'm sure this *is* the exception that should be thrown.

>=20
> Still surprised,

Me too. And I think that clirr still should report an ERROR here,
because this change is a violation of the spec, even if it isn't
currently enforced by either Sun or IBM JVMs. What do you think?

Cheers,

Simon

RE: [Clirr-devel] Maven plugin: filtering error messages

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

On Mon, 2004-07-05 at 19:37, Vincent Massol wrote:
> > -----Original Message-----
> > From: cli...@li... [mailto:clirr-devel-
> > ad...@li...] On Behalf Of Simon Kitching
> > Sent: lundi 5 juillet 2004 09:19
> > To: cli...@li...
> > Subject: RE: [Clirr-devel] Maven plugin: filtering error messages
> > 
> > On Mon, 2004-07-05 at 19:03, Vincent Massol wrote:
> > > > On Fri, 2004-07-02 at 15:09, Simon Kitching wrote:
> > > >
> > > > > One thing that should now be fairly easy to support if you wish to
> > is
> > > > > adding some stuff to the Ant task to allow users to selectively
> > ignore
> > > > > certain messages. Because each message has a unique id, it should be
> > > > > simple to support tags in the ant file like:
> > > > >
> > > > >   <ignore-error class="com.acme.widget" message-id="7001"/>
> > > > >
> > > > > When a build "clirrs" (in your suggested terminology :-), but the
> > user
> > > > > doesn't care about that particular problem, they could add a tag
> > like
> > > > > this to suppress the error-counting for that problem. And it will
> > work
> > > > > for any locale, because the message-ids don't change by locale.
> > > > >
> > > > > Just a thought....
> > >
> > > I completely agree that we need a way to tell Clirr to ignore some
> > checks.
> > > However, I'd prefer that this ignore list be specified with the name of
> > the
> > > check (check id) instead of the message id. But I could live with both
> > > solutions.
> > 
> > Salut Vincent!
> > 
> > You mean give the user the option to ignore "all method-related errors"
> > for a class or set of classes?
> 
> No I meant more fine-grained than this. For example "Method signature
> change", "Method return type changed", "Class changed to interface", etc
> 
> Look at the way Checkstyle works. Each check has a name. For example:
> NoWhitespaceBefore. The good thing is that the classes implementing these
> checks have this same name. And excluding a check actually boils down to
> excluding a class.

But clirr's check classes aren't as fine-grained as that. Each check
class can detect up to a dozen different sorts of problems. And I doubt
a serious refactoring of the check classes into one-message-per-class is
going to happen, or is even possible.

Filtering on "message ids" would give exactly the level of control that
filtering on CheckStyle check classes gives. The only difference is that
the identifier to filter on is a number instead of a classname.

Regards,

Simon

Re: [Clirr-devel] MethodSetCheck: changing argument count

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

On Tue, 2004-07-06 at 07:05, Lars K=FChne wrote:
> Maybe it would be a bit easier to implement if we'd only apply the=20
> heuristic if the original method does not override anything? That would=
=20
> result in
>=20
> (1)
>   ERROR: Changed X(a) to X(b,c)
> (2)
>   INFO: Removed method X(a), method now in superclass/interface
>   INFO: Added method X(b,c)
>=20
> I think in the "non-override" case the message is much better than=20
> "removed, added", and I'd like to keep it if possible with reasonable=20
> implementation efforts.

I agree with that. I'll try to change the code so that we check for
"overriding" before attempting to use the similarity table. If the
changed method used to override a method we go for remove/add else we
use the existing code.

>=20
> >I was browsing through the clirr bugtracker, and found this issue from
> >Stephen Colebourne which is about just this problem:
> >
> >http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D967288&gr=
oup_id=3D89627&atid=3D590802
> >
> >In this case, he definitely wanted to see "added + removed" rather tha=
n
> >"changed".=20
> > =20
> >
>=20
> Yes. Unfortunately I can't find the request/email that led me to=20
> implementing the heuristic... :-(

I hate it when that happens :-)


Cheers,

Simon

RE: [Clirr-devel] maven plugin

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

On Mon, 2004-07-05 at 22:15, Vincent Massol wrote:
> the core build is at the top level. We need a separation between the
> core build and the maven plugin build. Hence the need for a separate
> directory structure for core/maven.

Ok, I think I start to understand.

I presumed you were talking about a *java package* restructure, but what
you actually need for maven is just a *directory tree* restructure? And
the java classes could keep their original package declarations?

As it happens, I'm quite happy to go with a minor java package
restructure anyway; moving event/framework/check packages into a parent
"n.s.c.core" package seems a good idea.

Well, I'll just watch for whatever changes turn up, and go with them.

Cheers,

Simon

Re: [Clirr-devel] maven plugin

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

Vincent Massol wrote:

>>Vincent, you can start moving core to it's sub-module and add the maven
>>plugin. Do you need help or is it easier for you if you do it alone?
>>    
>>
>
>I'll let you do the 'core' move and once it's done I'll create a top level
>maven directory and work in there.
>  
>

FYI, I've been working on moving core this evening - good progress so far.

I'm a bit short on time, but I think it should be possible to complete 
this work during the next few days.

Lars

Re: [Clirr-devel] MethodSetCheck: changing argument count

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

Simon Kitching wrote:

>On Mon, 2004-07-05 at 18:39, Simon Kitching wrote:
>  
>
>>On Mon, 2004-07-05 at 18:04, Lars Kühne wrote:
>>    
>>
>>>>And what do we report if the old version of Foo was overriding an
>>>>inherited method, and the new version is not?
>>>>
>>>>        
>>>>
>>>I agree the algorithm it's not perfect. Not sure if this is reason 
>>>enough to remove it completely, maybe it's not that difficult to improve it?
>>>      
>>>
>>I see this as requiring AI to do properly. Does the user "perceive"
>>these methods as being the same method or not?
>>
>>    
>>
>>>I'd suggest leaving it in there, release 0.4 and wait for user feedback.
>>>      
>>>
>>How do we handle the case where the old version of Foo was overriding an
>>inherited method, and the new version is not?
>>
>>Below, (1) is the case where the original method was not overriding an
>>inherited implementation, and (2) where it was.
>>
>>Right now, we have this:
>>(1)
>>  ERROR: Changed X(a) to X(b,c)
>>(2)
>>  ERROR: Changed X(a) to X(b,c)
>>when (2) really isn't an error, because an inherited implementation is
>>available.
>>
>>By removing the "argcount changed" code, we would have this
>>automatically:
>>(1)
>>  ERROR: Removed method X(a)
>>  INFO:  Added method X(b,c)
>>(2)
>>  INFO: Removed method X(a), method now in superclass/interface
>>  INFO: Added method X(b,c)
>>
>>    
>>

I see your point, and like I said, the algorithm is not perfect.

>>With the "argcount changed" code, we *could* implement this:
>>(1)
>>  ERROR: Changed X(a) to X(b,c)
>>(2) [suggested]
>>  INFO: Changed X(a) to X(b,c). This method no 
>>  longer overrides inherited method X(a).
>>
>>
>>I guess I could live with the last option above. But I still think the
>>simplest option (no "guessing") is better..
>>    
>>
>
>  
>

Maybe it would be a bit easier to implement if we'd only apply the 
heuristic if the original method does not override anything? That would 
result in

(1)
  ERROR: Changed X(a) to X(b,c)
(2)
  INFO: Removed method X(a), method now in superclass/interface
  INFO: Added method X(b,c)

I think in the "non-override" case the message is much better than 
"removed, added", and I'd like to keep it if possible with reasonable 
implementation efforts.

>I was browsing through the clirr bugtracker, and found this issue from
>Stephen Colebourne which is about just this problem:
>
>http://sourceforge.net/tracker/index.php?func=detail&aid=967288&group_id=89627&atid=590802
>
>In this case, he definitely wanted to see "added + removed" rather than
>"changed". 
>  
>

Yes. Unfortunately I can't find the request/email that led me to 
implementing the heuristic... :-(

Lars

Re: [Clirr-devel] MethodSetCheck: changing argument count

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

Simon Kitching wrote:

>On Mon, 2004-07-05 at 18:04, Lars Kühne wrote:
>  
>
>>Hi Simon,
>>
>>sorry for the late answer.
>>    
>>
>
>Euro 2004 football finals are over, right? :-)
>
>  
>

Yes, now I'm preparing for my summer vacation in Croatia :-) And man, do 
I need some sun - where I live we haven't had anything but cold and wet 
days this "summer"

>And what a surprise result...I think it's great to see Greece take the
>cup away.
>
>  
>

Yes, it's good to see the "little guys" win once in a while. I think 
Greece really played phantastic - not very attractice to watch, but very 
good tactics, and they it's very hard to score against them...

>That's a nice leadup to the Olympics.
>
>  
>

Oh, I see, this summer Clirr will get nowhere ;-)

Lars

Re: [Clirr-devel] Handling private/package-scope changes

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

Simon Kitching wrote:

>Hi Lars,
>
>In the original clirr design, all package and private classes, members &
>fields were ignored, because they were irrelevant to the goal of
>detecting "binary incompatibilities".
>
>I added the *option* to include private and package things in clirr's
>processing in order to be able to generate complete change reports.
>However this currently has the effect of reporting binary
>compatibilities for things like changing the type of a private field or
>package-scope method return type when reporting on private items is
>enabled.
>
>I would like to keep the ability to generate complete change reports,
>but restore the original behaviour of reporting ERROR and WARNING stuff
>only for public/protected things, ie stuff that is intended to be
>visible to "users" of the package.
>
>What I have done is added the following methods to AbstractDiffReporter:
>  public Severity getSeverity(JavaClass clazz, Severity s);
>  public Severity getSeverity(JavaClass clazz, Method m, Severity s);
>  public Severity getSeverity(JavaClass clazz, Field f, Severity s);
>
>These methods are called from just about anywhere an ApiDifference is
>reported from, and they "reduce" the severity from ERROR/WARN to info if
>the specified class, method, or field is package or private scope.
>
>Is this change ok by you?
>
>  
>

yes

>Regards,
>
>Simon
>
>  
>

Re: [Clirr-devel] Java doesn't appear to do runtime checks for class/method access rights

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

Simon Kitching wrote:

>Hi Lars,
>
>Could you please check that I haven't gone completely mad?
>
>Attached is an archive which contains some java code that appears to
>demonstrate that the Java JVM/runtime does not check for class or method
>access rights.
>
>Try:
>* cd v1; javac Foo.java
>* cd v2; javac Foo.java
>* cd ..
>* cp v1/Foo.class pkg
>* javac Main.java
>* java Main
>--> so far, all as expected.
>
>But now:
>* cp v2/Foo.class pkg
>* java Main
>--> the main class successfully invokes a private method on
>    the package-scope Foo class!
>
>The java lang spec document seems clear that this *should* throw an
>IllegalAccessError, but it doesn't. I would like someone to confirm that
>I am not having hallucinations here before I add a note about this to
>the message description document.
>
>I've tried this with:
>* sun java 1.3 on AIX
>* sun java 1.4 on linux 
>* sun java 1.5 on linux
>* IBM java 1.4 on AIX
>* IBM java 1.4 on linux
>and they all give the same result.
>
>Regards,
>
>Simon
>  
>


I can confirm your results:

access> java Main
public method f1 of package scope class Foo called!
private method f2 of package scope class Foo called!

Wow!!

This is scary, but on the other hand it's quite logical. Try to 
disassemble the code of Main:

access> javap -private -c Main

Compiled from "Main.java"
public class Main extends java.lang.Object{
public Main();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public static void main(java.lang.String[]);
  Code:
   0:   new     #2; //class pkg/Foo
   3:   dup
   4:   invokespecial   #3; //Method pkg/Foo."<init>":()V
   7:   astore_1
   8:   aload_1
   9:   invokevirtual   #4; //Method pkg/Foo.f1:()V
   12:  aload_1
   13:  invokevirtual   #5; //Method pkg/Foo.f2:()V
   16:  return

}

It seems the bytecode for both method calls is the same. The Main class 
simply seems to have no record whether the called methods are private or 
public, so the VM can't check anything... ?

I couldn't find the IllegalAccessError requirement you mentioned, but in 
$13.4.6 the JLS says:

"Changing the declared access of a member or constructor to permit less 
access may break compatibility with pre-existing binaries, causing a 
linkage error to be thrown when these binaries are resolved.

Less access is permitted if the access modifier is changed from default 
access to |private| access; from |protected| access to default or 
|private| access; or from |public| access to |protected|, default, or 
|private| access"

Not quite sure what to make of this, to me the spec is quite confusing - 
aren't those two sentences contradicting each other?

Still surprised,
Lars

Re: [Clirr-devel] maven plugin

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

Simon Kitching wrote:

>On Mon, 2004-07-05 at 17:47, Lars Kühne wrote:
>  
>
>>Simon Kitching wrote:
>>    
>>
>>OK, so the plan is to have two top level modules, core and maven.
>>
>>The top level package structure is not affected by that move, I don't 
>>think Maven requires the module name to occur as a package name. This 
>>means we can have:
>>
>>clirr-core.jar
>>+ n.s.c.core (includes only Checker)
>>+ n.s.c.core.event
>>+ n.s.c.core.internal.framework (not to be used by integration frontends)
>>+ n.s.c.core.internal.checks (dito)
>>+ n.s.c.cli
>>+ n.s.c.ant
>>
>>    
>>
>
>Sorry, what do you mean by "module"?
>
>  
>

I mean toplevel modules in a Maven multiproject setup. This is basically 
the toplevel directory structure when you CVS-checkout clirr. Each 
module (core and maven) have a toplevel project.xml.

Basically the multiproject plugin will search for subdirectories with 
project.xml files, cd into each of those, and build it (plus I think it 
will also build a couple of other things, like a wrapper website).

Most of the current content of the root directory will be moved into the 
'core' module/subdir, Vincent will fill the maven module.

If I understand things correctly, the multiproject plugin is _the_ way 
to make Maven build multiple artifacts (jars) in one combined build.

>I see *four* basic packages:
>  n.s.c.core
>  n.s.c.ant
>  n.s.c.cli
>  
>

Yes, that is the basic java package structure. The core multiproject 
module (Vincent, please correct my terminology if necessary) will 
contain the above three Java top-level packages. Because each module 
corresponds to one jar, this will lead to a combined jar that is easy to 
use, just like what we have now.

>  n.s.c.maven
>  
>

If the Maven plugin requires that (maybe it only use Jelly script?) that 
package will be hosted by the maven module.

>If the above package structure is what is proposed, I like it.
>Have I misunderstood?
>
>  
>

I hope I have clarified the difference between the multiproject 
directory structure and the java package structure, and how the latter 
is more fine-grained in our case.

>[...]
>I think the ant/maven enhancement I suggested in recent emails is
>*really important* for users. 
>
>Given the decision to issue ERROR level messages for lots of things that
>may not be a problem for users depending upon context (eg adding method
>to interface only breaks systems where users are expected to implement
>those interfaces), I think it is really important to give users the
>ability to selectively ignore certain errors being reported by clirr
>when using the ant or maven tasks.
>
>Personally, I would really like to see this (pretty simple) feature
>added before the 0.4 release....
>  
>

If you can do it quickly, that's fine by me. We can also push out 
another release quickly ("release often" style), so I don't think it's 
*that* important.

Maybe it would be better to specify those ignored errors in a separate 
file instead of using the ant file directly? The Maven plugin could then 
use it to build a web page that documents the incompatibilities that 
were ignored, and why (define an XML format that allows to specify the 
reason).

Lars

RE: [Clirr-devel] maven plugin

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Simon Kitching
> Sent: lundi 5 juillet 2004 10:41
> To: cli...@li...
> Subject: RE: [Clirr-devel] maven plugin
> 
> On Mon, 2004-07-05 at 19:20, Vincent Massol wrote:
> > >
> > > We simply need to agree on the timing of the module restructuring
> move,
> > > so the files are not moved away under our feet when Simon or I have
> > > uncommitted changes.
> > >
> > > Vincent, please tell us when you have the time to actually make that
> > > change.
> >
> > I think it's better the other way round. I'll let you stuff everything
> under
> > 'core' and I'll take care of the 'maven' part once you've done the core
> > part. I can probably find some time this week to work on this.
> 
> Umm..Vincent, what exactly is the reason for this restructuring anyway?
> Maybe you explained it earlier but I can't find it in the archives.
> 
> Is there some reason that this *must* be done in order to implement a
> Maven plugin for clirr, or is it just that you think the clirr code
> would "look nicer" if rearranged?
> 

ATM, the core build is at the top level. We need a separation between the
core build and the maven plugin build. Hence the need for a separate
directory structure for core/maven.

Thanks
-Vincent

> Regards,
> 
> Simon
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Clirr-devel mailing list
> Cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clirr-devel

Re: [Clirr-devel] MethodSetCheck: changing argument count

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

On Mon, 2004-07-05 at 18:39, Simon Kitching wrote:
> On Mon, 2004-07-05 at 18:04, Lars K=FChne wrote:
> > >And what do we report if the old version of Foo was overriding an
> > >inherited method, and the new version is not?
> > >
> >=20
> > I agree the algorithm it's not perfect. Not sure if this is reason=20
> > enough to remove it completely, maybe it's not that difficult to impr=
ove it?
>=20
> I see this as requiring AI to do properly. Does the user "perceive"
> these methods as being the same method or not?
>=20
> > I'd suggest leaving it in there, release 0.4 and wait for user feedba=
ck.
>=20
> How do we handle the case where the old version of Foo was overriding a=
n
> inherited method, and the new version is not?
>=20
> Below, (1) is the case where the original method was not overriding an
> inherited implementation, and (2) where it was.
>=20
> Right now, we have this:
> (1)
>   ERROR: Changed X(a) to X(b,c)
> (2)
>   ERROR: Changed X(a) to X(b,c)
> when (2) really isn't an error, because an inherited implementation is
> available.
>=20
> By removing the "argcount changed" code, we would have this
> automatically:
> (1)
>   ERROR: Removed method X(a)
>   INFO:  Added method X(b,c)
> (2)
>   INFO: Removed method X(a), method now in superclass/interface
>   INFO: Added method X(b,c)
>=20
> With the "argcount changed" code, we *could* implement this:
> (1)
>   ERROR: Changed X(a) to X(b,c)
> (2) [suggested]
>   INFO: Changed X(a) to X(b,c). This method no=20
>   longer overrides inherited method X(a).
>=20
>=20
> I guess I could live with the last option above. But I still think the
> simplest option (no "guessing") is better..


I was browsing through the clirr bugtracker, and found this issue from
Stephen Colebourne which is about just this problem:

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D967288&group=
_id=3D89627&atid=3D590802

In this case, he definitely wanted to see "added + removed" rather than
"changed".=20

Regards,

Simon

RE: [Clirr-devel] maven plugin

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

On Mon, 2004-07-05 at 19:20, Vincent Massol wrote:
> > 
> > We simply need to agree on the timing of the module restructuring move,
> > so the files are not moved away under our feet when Simon or I have
> > uncommitted changes.
> > 
> > Vincent, please tell us when you have the time to actually make that
> > change.
> 
> I think it's better the other way round. I'll let you stuff everything under
> 'core' and I'll take care of the 'maven' part once you've done the core
> part. I can probably find some time this week to work on this.

Umm..Vincent, what exactly is the reason for this restructuring anyway?
Maybe you explained it earlier but I can't find it in the archives.

Is there some reason that this *must* be done in order to implement a
Maven plugin for clirr, or is it just that you think the clirr code
would "look nicer" if rearranged?

Regards,

Simon

RE: [Clirr-devel] maven plugin

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Lars K=FChne
> Sent: lundi 5 juillet 2004 07:47
> To: cli...@li...
> Subject: Re: [Clirr-devel] maven plugin
>=20

[snip]
=20
> Vincent, you can start moving core to it's sub-module and add the =
maven
> plugin. Do you need help or is it easier for you if you do it alone?

I'll let you do the 'core' move and once it's done I'll create a top =
level
maven directory and work in there.

[snip]

Thanks
-Vincent

[Clirr-devel] Java doesn't appear to do runtime checks for class/method access rights

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

Hi Lars,

Could you please check that I haven't gone completely mad?

Attached is an archive which contains some java code that appears to
demonstrate that the Java JVM/runtime does not check for class or method
access rights.

Try:
* cd v1; javac Foo.java
* cd v2; javac Foo.java
* cd ..
* cp v1/Foo.class pkg
* javac Main.java
* java Main
--> so far, all as expected.

But now:
* cp v2/Foo.class pkg
* java Main
--> the main class successfully invokes a private method on
    the package-scope Foo class!

The java lang spec document seems clear that this *should* throw an
IllegalAccessError, but it doesn't. I would like someone to confirm that
I am not having hallucinations here before I add a note about this to
the message description document.

I've tried this with:
* sun java 1.3 on AIX
* sun java 1.4 on linux 
* sun java 1.5 on linux
* IBM java 1.4 on AIX
* IBM java 1.4 on linux
and they all give the same result.

Regards,

Simon

RE: [Clirr-devel] Maven plugin: filtering error messages

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Simon Kitching
> Sent: lundi 5 juillet 2004 09:19
> To: cli...@li...
> Subject: RE: [Clirr-devel] Maven plugin: filtering error messages
> 
> On Mon, 2004-07-05 at 19:03, Vincent Massol wrote:
> > > On Fri, 2004-07-02 at 15:09, Simon Kitching wrote:
> > >
> > > > One thing that should now be fairly easy to support if you wish to
> is
> > > > adding some stuff to the Ant task to allow users to selectively
> ignore
> > > > certain messages. Because each message has a unique id, it should be
> > > > simple to support tags in the ant file like:
> > > >
> > > >   <ignore-error class="com.acme.widget" message-id="7001"/>
> > > >
> > > > When a build "clirrs" (in your suggested terminology :-), but the
> user
> > > > doesn't care about that particular problem, they could add a tag
> like
> > > > this to suppress the error-counting for that problem. And it will
> work
> > > > for any locale, because the message-ids don't change by locale.
> > > >
> > > > Just a thought....
> >
> > I completely agree that we need a way to tell Clirr to ignore some
> checks.
> > However, I'd prefer that this ignore list be specified with the name of
> the
> > check (check id) instead of the message id. But I could live with both
> > solutions.
> 
> Salut Vincent!
> 
> You mean give the user the option to ignore "all method-related errors"
> for a class or set of classes?

No I meant more fine-grained than this. For example "Method signature
change", "Method return type changed", "Class changed to interface", etc

Look at the way Checkstyle works. Each check has a name. For example:
NoWhitespaceBefore. The good thing is that the classes implementing these
checks have this same name. And excluding a check actually boils down to
excluding a class.

Doing something like this for Clirr would be nice.

> 
> That's much more coarse-grained than having the user say "ignore all
> occurrences of error#7012", ie cases where a method has been added to an
> interface.
> 
> I *believe* (without any evidence at all :-) that the latter is more
> useful than the former.
> 
> But *both* would be useful. I could certainly live with a 0.4 release
> that only provides disabling of "all checks for method-related errors".
> It would at least provide users with a way to continue using clirr when
> it reports errors they wish to ignore - though possibly at the cost of
> accidentally ignoring some errors they did *not* intend to ignore.
> 
> On an implementation note, however, it is far *simpler* to exclude
> errors with certain message codes from the "core" point of view.
> Implementing the "exclude all method-related errors" would probably best
> be implemented by excluding all messages in the range 7000-7999. But
> given that, why not expose the finer control to the user?
> 
> Regards,
> 
> Simon
> 

-Vincent

RE: [Clirr-devel] maven plugin

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Lars K=FChne
> Sent: dimanche 4 juillet 2004 08:30
> To: cli...@li...
> Subject: Re: [Clirr-devel] maven plugin

[snip]

>=20
> The simplest thing is to create a module 'core' and simply move
> everything we have now (including cli and ant) into that module. You =
can
> then start committing the Maven plugin into a different module, so we
> end up with two multiproject modules, 'core' and 'maven'.
>=20
> I'm not convinced anyway that it makes sense to have cli and ant in
> different packages: the jar would basically consist of one class =
file...
> If someone disagrees we can do further split-up later.
>=20
> We simply need to agree on the timing of the module restructuring =
move,
> so the files are not moved away under our feet when Simon or I have
> uncommitted changes.
>=20
> Vincent, please tell us when you have the time to actually make that
> change.

I think it's better the other way round. I'll let you stuff everything =
under
'core' and I'll take care of the 'maven' part once you've done the core
part. I can probably find some time this week to work on this.

[snip]

Thanks
-Vincent

RE: [Clirr-devel] Maven plugin: filtering error messages

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

On Mon, 2004-07-05 at 19:03, Vincent Massol wrote:
> > On Fri, 2004-07-02 at 15:09, Simon Kitching wrote:
> > 
> > > One thing that should now be fairly easy to support if you wish to is
> > > adding some stuff to the Ant task to allow users to selectively ignore
> > > certain messages. Because each message has a unique id, it should be
> > > simple to support tags in the ant file like:
> > >
> > >   <ignore-error class="com.acme.widget" message-id="7001"/>
> > >
> > > When a build "clirrs" (in your suggested terminology :-), but the user
> > > doesn't care about that particular problem, they could add a tag like
> > > this to suppress the error-counting for that problem. And it will work
> > > for any locale, because the message-ids don't change by locale.
> > >
> > > Just a thought....
> 
> I completely agree that we need a way to tell Clirr to ignore some checks.
> However, I'd prefer that this ignore list be specified with the name of the
> check (check id) instead of the message id. But I could live with both
> solutions.

Salut Vincent!

You mean give the user the option to ignore "all method-related errors"
for a class or set of classes?

That's much more coarse-grained than having the user say "ignore all
occurrences of error#7012", ie cases where a method has been added to an
interface.

I *believe* (without any evidence at all :-) that the latter is more
useful than the former. 

But *both* would be useful. I could certainly live with a 0.4 release
that only provides disabling of "all checks for method-related errors".
It would at least provide users with a way to continue using clirr when
it reports errors they wish to ignore - though possibly at the cost of
accidentally ignoring some errors they did *not* intend to ignore.

On an implementation note, however, it is far *simpler* to exclude
errors with certain message codes from the "core" point of view.
Implementing the "exclude all method-related errors" would probably best
be implemented by excluding all messages in the range 7000-7999. But
given that, why not expose the finer control to the user?

Regards,

Simon

RE: [Clirr-devel] maven plugin

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Simon Kitching
> Sent: lundi 5 juillet 2004 01:09
> To: cli...@li...
> Subject: Re: [Clirr-devel] maven plugin
>=20
> On Sun, 2004-07-04 at 18:29, Lars K=FChne wrote:
> > Vincent Massol wrote:
> > >>>
> > >>>I've tried 3 times to garner interest in refactoring the clirr
> directory
> > >>>structure in order to support integration modules such as Ant,
> Eclipse
> > >>>plugin, Maven plugin, Cli, etc. I've even spent time showing what =
it
> > >
> [stuff removed]
>=20
> I'm also keen to see a Maven plugin, and agree Clirr is the best place
> to host it.

cool

>=20
> I have only one (minor) reservation about your original proposal. I =
did
> raise this by email, but didn't see any response. It is the matter of
> moving the "cli" stuff into a subpackage. I think the command
>   java net.sf.clirr.cli.Clirr
> is already quite long enough without moving the cli stuff into a
> subpackage :-).

Fine. This doesn't impact the directory structure.

>=20
> Still, if (for some reason) moving the cli "main" class is absolutely
> necessary to implement a Maven plugin, I could live with it.
>=20
> Apart from that, I'm all for integrating the maven code as soon as
> possible.
>=20
>=20
> > The simplest thing is to create a module 'core' and simply move
> > everything we have now (including cli and ant) into that module. You =
can
> > then start committing the Maven plugin into a different module, so =
we
> > end up with two multiproject modules, 'core' and 'maven'.
>=20
> That would make the start command for the cli into this?
>   java net.sf.clirr.core.cli.Clirr
>=20
> >
> > I'm not convinced anyway that it makes sense to have cli and ant in
> > different packages: the jar would basically consist of one class =
file...
> > If someone disagrees we can do further split-up later.
>=20
> I tend to agree.

Sure. Let's do TSTTCPW ;-)

>=20
> >
> > Simon, do you have uncommitted changes on your hard drive?
>=20
> There's nothing I can't modify fairly easily. Don't let this stop you
> from getting started...
>=20
> >
> > >>    * the Maven plugin should be hosted by Clirr itself, because =
that
> > >>      would improve the user experience (one-stop shopping) a lot!
> > >>
> > >>
> > >
> > >Cool. I also think so.
>=20
> Me too. If only the UN could agree so easily :-)
>=20
>=20
> > I can understand your frustration, and I think we should start using
> > multiproject next weekend (or earlier if everyone agrees - Simon, =
please
> > speak up).
>=20
> Fine by me. Don't worry about causing any problems for code I've got
> outstanding; I can deal with any problems that turn up.
>=20
> > >On a positive note, I'd really like to try using Clirr on my =
project at
> > >work. I've convinced other people that we should try it. As we're =
using
> > >Maven, I'd like to have a Maven plugin working quickly.
>=20
> I've been thinking it's about time for a 0.4 release. If you're
> interested in getting others to use clirr then it might be a good idea
> to get this new release out the door.
>=20
> > >
> > >>I suggest we meet on IRC right now or (if you
> > >>want to give Simon a chance to participate) Sunday morning, 9:30 =
AM
> CEST.
>=20
> I don't think that it's necessary to get me involved. You guys just go
> ahead.
>=20

Cool. Thanks Simon.

-Vincent

RE: [Clirr-devel] maven plugin

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

> -----Original Message-----
> From: cli...@li... [mailto:clirr-devel-
> ad...@li...] On Behalf Of Simon Kitching
> Sent: lundi 5 juillet 2004 08:02
> To: cli...@li...
> Subject: Re: [Clirr-devel] maven plugin
>=20
> On Mon, 2004-07-05 at 17:47, Lars K=FChne wrote:
> > Simon Kitching wrote:
> > >
> >
> > OK, so the plan is to have two top level modules, core and maven.
> >
> > The top level package structure is not affected by that move, I =
don't
> > think Maven requires the module name to occur as a package name. =
This
> > means we can have:
> >
> > clirr-core.jar
> > + n.s.c.core (includes only Checker)
> > + n.s.c.core.event
> > + n.s.c.core.internal.framework (not to be used by integration
> frontends)
> > + n.s.c.core.internal.checks (dito)
> > + n.s.c.cli
> > + n.s.c.ant
> >
>=20
> Sorry, what do you mean by "module"?
>=20
> I see *four* basic packages:
>   n.s.c.core
>   n.s.c.ant
>   n.s.c.cli
>   n.s.c.maven
>=20
> If the above package structure is what is proposed, I like it.
> Have I misunderstood?

Oh cool. I like it too.

>=20
> >
> > On our web site we can follow Vincent's suggestion and have a =
toplevel
> > menu entry like
> >
> > Integrations
> > + Ant
> > + Command Line
> > + Maven
>=20
> Yep, looks nice.
>=20
> > >I've been thinking it's about time for a 0.4 release. If you're
> > >interested in getting others to use clirr then it might be a good =
idea
> > >to get this new release out the door.
> > >
> > >
> > >
> >
> > Yep, let's get that Maven plugin ready and then release 0.4.
>=20
> I think the ant/maven enhancement I suggested in recent emails is
> *really important* for users.
>=20
> Given the decision to issue ERROR level messages for lots of things =
that
> may not be a problem for users depending upon context (eg adding =
method
> to interface only breaks systems where users are expected to implement
> those interfaces), I think it is really important to give users the
> ability to selectively ignore certain errors being reported by clirr
> when using the ant or maven tasks.
>=20

Agreed.

> Personally, I would really like to see this (pretty simple) feature
> added before the 0.4 release....

I'm fine with either. It can happen in 0.5 a week after 0.4 is delivered =
and
I wouldn't mind. It's up to you guys really.

Thanks
-Vincent

Re: [Clirr-devel] MethodSetCheck: changing argument count

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

On Mon, 2004-07-05 at 18:04, Lars K=FChne wrote:
> >And what do we report if the old version of Foo was overriding an
> >inherited method, and the new version is not?
> >
>=20
> I agree the algorithm it's not perfect. Not sure if this is reason=20
> enough to remove it completely, maybe it's not that difficult to improv=
e it?

I see this as requiring AI to do properly. Does the user "perceive"
these methods as being the same method or not?

> I'd suggest leaving it in there, release 0.4 and wait for user feedback.

How do we handle the case where the old version of Foo was overriding an
inherited method, and the new version is not?

Below, (1) is the case where the original method was not overriding an
inherited implementation, and (2) where it was.

Right now, we have this:
(1)
  ERROR: Changed X(a) to X(b,c)
(2)
  ERROR: Changed X(a) to X(b,c)
when (2) really isn't an error, because an inherited implementation is
available.

By removing the "argcount changed" code, we would have this
automatically:
(1)
  ERROR: Removed method X(a)
  INFO:  Added method X(b,c)
(2)
  INFO: Removed method X(a), method now in superclass/interface
  INFO: Added method X(b,c)

With the "argcount changed" code, we *could* implement this:
(1)
  ERROR: Changed X(a) to X(b,c)
(2) [suggested]
  INFO: Changed X(a) to X(b,c). This method no=20
  longer overrides inherited method X(a).


I guess I could live with the last option above. But I still think the
simplest option (no "guessing") is better..

Cheers,

Simon