Package statement recognized by code coverage tools

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Package statement recognized by code coverage tools

David Witherspoon
Hi,

So I've just gone through the process of updating our groovy-eclipse compiler version.  Now we're using:
  • maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
  • groovy-eclipse-compiler: 2.7.0-01
  • groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
Now we've got some new behavior.  We're using cobertura (2.5.2), and it's now complaining that the package statement in one of our classes is an uncovered line.  As I understand it, compilers are supposed to flag these lines in generated bytecode as not executable.

But I guess that's not happening now.

Any ideas?
 
~~~~~~~~~~~~~~~~
"The problem with internet quotes is that you cannot verify their authenticity."  - Abraham Lincoln
Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

Andrew Eisenberg
Why would a package statement be an uncovered line?  The compiler must
have placed some code in the class file at line 1 (or wherever the
package statement is).

You can share the class file with me (privately if you like) and I can
see if there's anything in the bytecode.

On Tue, Jun 25, 2013 at 2:36 PM, David Witherspoon <[hidden email]> wrote:

> Hi,
>
> So I've just gone through the process of updating our groovy-eclipse
> compiler version.  Now we're using:
>
> maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
> groovy-eclipse-compiler: 2.7.0-01
> groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
>
> Now we've got some new behavior.  We're using cobertura (2.5.2), and it's
> now complaining that the package statement in one of our classes is an
> uncovered line.  As I understand it, compilers are supposed to flag these
> lines in generated bytecode as not executable.
>
> But I guess that's not happening now.
>
> Any ideas?
>
> ~~~~~~~~~~~~~~~~
> "The problem with internet quotes is that you cannot verify their
> authenticity."  - Abraham Lincoln

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

David Witherspoon
Hi Andrew,

It's just that it's completely new behavior.  As soon as I worked through the issues I had yesterday with the groovy-batch-compiler, a number of our files started showing lower code coverage numbers.

The file is not very interesting, so I've attached the .class file.

- David

From: Andrew Eisenberg <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Tuesday, June 25, 2013 6:49 PM
Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by code coverage tools

Why would a package statement be an uncovered line?  The compiler must
have placed some code in the class file at line 1 (or wherever the
package statement is).

You can share the class file with me (privately if you like) and I can
see if there's anything in the bytecode.

On Tue, Jun 25, 2013 at 2:36 PM, David Witherspoon <[hidden email]> wrote:

> Hi,
>
> So I've just gone through the process of updating our groovy-eclipse
> compiler version.  Now we're using:
>
> maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
> groovy-eclipse-compiler: 2.7.0-01
> groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
>
> Now we've got some new behavior.  We're using cobertura (2.5.2), and it's
> now complaining that the package statement in one of our classes is an
> uncovered line.  As I understand it, compilers are supposed to flag these
> lines in generated bytecode as not executable.
>
> But I guess that's not happening now.
>
> Any ideas?
>
> ~~~~~~~~~~~~~~~~
> "The problem with internet quotes is that you cannot verify their
> authenticity."  - Abraham Lincoln

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

LocalDateDeserializer.class (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

David Witherspoon
A little more on this...after the builds overnight have run, code coverage is broken in half of our projects now.

I have dropped back to using javac for all projects without groovy, and using the new config for just those few projects with groovy source.

I think the new configuration is marking more lines as executable when they are not.  After rebuilding with javac, coverage numbers are where they were before.
 
- David

From: David Witherspoon <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Wednesday, June 26, 2013 7:26 AM
Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by code coverage tools

Hi Andrew,

It's just that it's completely new behavior.  As soon as I worked through the issues I had yesterday with the groovy-batch-compiler, a number of our files started showing lower code coverage numbers.

The file is not very interesting, so I've attached the .class file.

- David

From: Andrew Eisenberg <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Tuesday, June 25, 2013 6:49 PM
Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by code coverage tools

Why would a package statement be an uncovered line?  The compiler must
have placed some code in the class file at line 1 (or wherever the
package statement is).

You can share the class file with me (privately if you like) and I can
see if there's anything in the bytecode.

On Tue, Jun 25, 2013 at 2:36 PM, David Witherspoon <[hidden email]> wrote:

> Hi,
>
> So I've just gone through the process of updating our groovy-eclipse
> compiler version.  Now we're using:
>
> maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
> groovy-eclipse-compiler: 2.7.0-01
> groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
>
> Now we've got some new behavior.  We're using cobertura (2.5.2), and it's
> now complaining that the package statement in one of our classes is an
> uncovered line.  As I understand it, compilers are supposed to flag these
> lines in generated bytecode as not executable.
>
> But I guess that's not happening now.
>
> Any ideas?
>
> ~~~~~~~~~~~~~~~~
> "The problem with internet quotes is that you cannot verify their
> authenticity."  - Abraham Lincoln

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email






Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

Andrew Eisenberg
In the class file that you sent me, the deserialize() method is marked
as having code at line 1.  This is the reason why cobertura is looking
at that line.  Is the deserialize method generated or is it in the
source?  What line is it on?  Is the deserialize method tested
anywhere?

There is nothing that I am aware of that would have caused this change
with the new artifacts that were just relesaed.

On Wed, Jun 26, 2013 at 7:59 AM, David Witherspoon <[hidden email]> wrote:

> A little more on this...after the builds overnight have run, code coverage
> is broken in half of our projects now.
>
> I have dropped back to using javac for all projects without groovy, and
> using the new config for just those few projects with groovy source.
>
> I think the new configuration is marking more lines as executable when they
> are not.  After rebuilding with javac, coverage numbers are where they were
> before.
>
> - David
> ________________________________
> From: David Witherspoon <[hidden email]>
> To: "[hidden email]"
> <[hidden email]>
> Sent: Wednesday, June 26, 2013 7:26 AM
>
> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
> code coverage tools
>
> Hi Andrew,
>
> It's just that it's completely new behavior.  As soon as I worked through
> the issues I had yesterday with the groovy-batch-compiler, a number of our
> files started showing lower code coverage numbers.
>
> The file is not very interesting, so I've attached the .class file.
>
> - David
>
> From: Andrew Eisenberg <[hidden email]>
> To: "[hidden email]"
> <[hidden email]>
> Sent: Tuesday, June 25, 2013 6:49 PM
> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
> code coverage tools
>
> Why would a package statement be an uncovered line?  The compiler must
> have placed some code in the class file at line 1 (or wherever the
> package statement is).
>
> You can share the class file with me (privately if you like) and I can
> see if there's anything in the bytecode.
>
> On Tue, Jun 25, 2013 at 2:36 PM, David Witherspoon <[hidden email]>
> wrote:
>> Hi,
>>
>> So I've just gone through the process of updating our groovy-eclipse
>> compiler version.  Now we're using:
>>
>> maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
>> groovy-eclipse-compiler: 2.7.0-01
>> groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
>>
>> Now we've got some new behavior.  We're using cobertura (2.5.2), and it's
>> now complaining that the package statement in one of our classes is an
>> uncovered line.  As I understand it, compilers are supposed to flag these
>> lines in generated bytecode as not executable.
>>
>> But I guess that's not happening now.
>>
>> Any ideas?
>>
>> ~~~~~~~~~~~~~~~~
>> "The problem with internet quotes is that you cannot verify their
>> authenticity."  - Abraham Lincoln
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

David Witherspoon
Well, the inner-workings of byte code is beyond me.  Line 1 is a package statement, nothing more.

The deserialize method is not generated...it's a regular old method that looks like this:
   @Override
   public LocalDate deserialize(final JsonParser parser, final DeserializationContext context) throws IOException {
      String dateAsString = parser.getText();
      return LocalDate.parse(dateAsString);
   }

That one method is exercised via a unit test.

I can tell you that once we dropped back to javac, our test coverage problems all went away.

Please find attached two screenshots.  One is the Cobertura output screen using javac as the compiler (notice the 80% coverage), and the other is compiling with the groovy-eclipse-compiler using this configuration:

         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>2.3.2</version>
            <configuration>
               <compilerId>groovy-eclipse-compiler</compilerId>
               <source>1.6</source>
               <target>1.6</target>
               <extensions>true</extensions>
               <verbose>true</verbose>
            </configuration>
            <dependencies>
               <dependency>
                  <groupId>org.codehaus.groovy</groupId>
                  <artifactId>groovy-eclipse-compiler</artifactId>
                  <version>2.7.0-01</version>
                  <exclusions>
                     <exclusion>
                        <groupId>org.codehaus.groovy</groupId>
                        <artifactId>groovy-eclipse-batch</artifactId>
                     </exclusion>
                  </exclusions>
               </dependency>
               <dependency>
                  <groupId>org.codehaus.groovy</groupId>
                  <artifactId>groovy-eclipse-batch</artifactId>
                  <version>2.1.3-01</version>
               </dependency>
            </dependencies>
        </plugin>



From: Andrew Eisenberg <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Wednesday, June 26, 2013 1:13 PM
Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by code coverage tools

In the class file that you sent me, the deserialize() method is marked
as having code at line 1.  This is the reason why cobertura is looking
at that line.  Is the deserialize method generated or is it in the
source?  What line is it on?  Is the deserialize method tested
anywhere?

There is nothing that I am aware of that would have caused this change
with the new artifacts that were just relesaed.

On Wed, Jun 26, 2013 at 7:59 AM, David Witherspoon <[hidden email]> wrote:

> A little more on this...after the builds overnight have run, code coverage
> is broken in half of our projects now.
>
> I have dropped back to using javac for all projects without groovy, and
> using the new config for just those few projects with groovy source.
>
> I think the new configuration is marking more lines as executable when they
> are not.  After rebuilding with javac, coverage numbers are where they were
> before.
>
> - David
> ________________________________
> From: David Witherspoon <[hidden email]>
> To: "[hidden email]"
> <[hidden email]>
> Sent: Wednesday, June 26, 2013 7:26 AM
>
> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
> code coverage tools
>
> Hi Andrew,
>
> It's just that it's completely new behavior.  As soon as I worked through
> the issues I had yesterday with the groovy-batch-compiler, a number of our
> files started showing lower code coverage numbers.
>
> The file is not very interesting, so I've attached the .class file.
>
> - David
>
> From: Andrew Eisenberg <[hidden email]>
> To: "[hidden email]"
> <[hidden email]>
> Sent: Tuesday, June 25, 2013 6:49 PM
> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
> code coverage tools
>
> Why would a package statement be an uncovered line?  The compiler must
> have placed some code in the class file at line 1 (or wherever the
> package statement is).
>
> You can share the class file with me (privately if you like) and I can
> see if there's anything in the bytecode.
>
> On Tue, Jun 25, 2013 at 2:36 PM, David Witherspoon <[hidden email]>
> wrote:
>> Hi,
>>
>> So I've just gone through the process of updating our groovy-eclipse
>> compiler version.  Now we're using:
>>
>> maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
>> groovy-eclipse-compiler: 2.7.0-01
>> groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
>>
>> Now we've got some new behavior.  We're using cobertura (2.5.2), and it's
>> now complaining that the package statement in one of our classes is an
>> uncovered line.  As I understand it, compilers are supposed to flag these
>> lines in generated bytecode as not executable.
>>
>> But I guess that's not happening now.
>>
>> Any ideas?
>>
>> ~~~~~~~~~~~~~~~~
>> "The problem with internet quotes is that you cannot verify their
>> authenticity."  - Abraham Lincoln
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

CoberturaReport-groovy-eclipse-compiler.png (60K) Download Attachment
CoberturaReport-javac.png (61K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

Andrew Eisenberg
The javac screenshot also shows that there is a missing tested line at
line 1 where the package statement is.  Am I right?

The difference is in the numbers for the lines that are hit. Javac has
4/2/2 and GEC has 2/1/1.  I'm not sure what these numbers mean and why
javac has 4/5 lines covered and GEC has 3/4 lines covered.

Can you send over the class file for the javac-generated class?

On Wed, Jun 26, 2013 at 10:40 AM, David Witherspoon
<[hidden email]> wrote:

> Well, the inner-workings of byte code is beyond me.  Line 1 is a package
> statement, nothing more.
>
> The deserialize method is not generated...it's a regular old method that
> looks like this:
>    @Override
>    public LocalDate deserialize(final JsonParser parser, final
> DeserializationContext context) throws IOException {
>       String dateAsString = parser.getText();
>       return LocalDate.parse(dateAsString);
>    }
>
> That one method is exercised via a unit test.
>
> I can tell you that once we dropped back to javac, our test coverage
> problems all went away.
>
> Please find attached two screenshots.  One is the Cobertura output screen
> using javac as the compiler (notice the 80% coverage), and the other is
> compiling with the groovy-eclipse-compiler using this configuration:
>
>          <plugin>
>             <groupId>org.apache.maven.plugins</groupId>
>             <artifactId>maven-compiler-plugin</artifactId>
>             <version>2.3.2</version>
>             <configuration>
>                <compilerId>groovy-eclipse-compiler</compilerId>
>                <source>1.6</source>
>                <target>1.6</target>
>                <extensions>true</extensions>
>                <verbose>true</verbose>
>             </configuration>
>             <dependencies>
>                <dependency>
>                   <groupId>org.codehaus.groovy</groupId>
>                   <artifactId>groovy-eclipse-compiler</artifactId>
>                   <version>2.7.0-01</version>
>                   <exclusions>
>                      <exclusion>
>                         <groupId>org.codehaus.groovy</groupId>
>                         <artifactId>groovy-eclipse-batch</artifactId>
>                      </exclusion>
>                   </exclusions>
>                </dependency>
>                <dependency>
>                   <groupId>org.codehaus.groovy</groupId>
>                   <artifactId>groovy-eclipse-batch</artifactId>
>                   <version>2.1.3-01</version>
>                </dependency>
>             </dependencies>
>         </plugin>
>
>
> ________________________________
> From: Andrew Eisenberg <[hidden email]>
> To: "[hidden email]"
> <[hidden email]>
> Sent: Wednesday, June 26, 2013 1:13 PM
>
> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
> code coverage tools
>
> In the class file that you sent me, the deserialize() method is marked
> as having code at line 1.  This is the reason why cobertura is looking
> at that line.  Is the deserialize method generated or is it in the
> source?  What line is it on?  Is the deserialize method tested
> anywhere?
>
> There is nothing that I am aware of that would have caused this change
> with the new artifacts that were just relesaed.
>
> On Wed, Jun 26, 2013 at 7:59 AM, David Witherspoon <[hidden email]>
> wrote:
>> A little more on this...after the builds overnight have run, code coverage
>> is broken in half of our projects now.
>>
>> I have dropped back to using javac for all projects without groovy, and
>> using the new config for just those few projects with groovy source.
>>
>> I think the new configuration is marking more lines as executable when
>> they
>> are not.  After rebuilding with javac, coverage numbers are where they
>> were
>> before.
>>
>> - David
>> ________________________________
>> From: David Witherspoon <[hidden email]>
>> To: "[hidden email]"
>> <[hidden email]>
>> Sent: Wednesday, June 26, 2013 7:26 AM
>>
>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>> code coverage tools
>>
>> Hi Andrew,
>>
>> It's just that it's completely new behavior.  As soon as I worked through
>> the issues I had yesterday with the groovy-batch-compiler, a number of our
>> files started showing lower code coverage numbers.
>>
>> The file is not very interesting, so I've attached the .class file.
>>
>> - David
>>
>> From: Andrew Eisenberg <[hidden email]>
>> To: "[hidden email]"
>> <[hidden email]>
>> Sent: Tuesday, June 25, 2013 6:49 PM
>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>> code coverage tools
>>
>> Why would a package statement be an uncovered line?  The compiler must
>> have placed some code in the class file at line 1 (or wherever the
>> package statement is).
>>
>> You can share the class file with me (privately if you like) and I can
>> see if there's anything in the bytecode.
>>
>> On Tue, Jun 25, 2013 at 2:36 PM, David Witherspoon <[hidden email]>
>> wrote:
>>> Hi,
>>>
>>> So I've just gone through the process of updating our groovy-eclipse
>>> compiler version.  Now we're using:
>>>
>>> maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
>>> groovy-eclipse-compiler: 2.7.0-01
>>> groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
>>>
>>> Now we've got some new behavior.  We're using cobertura (2.5.2), and it's
>>> now complaining that the package statement in one of our classes is an
>>> uncovered line.  As I understand it, compilers are supposed to flag these
>>> lines in generated bytecode as not executable.
>>>
>>> But I guess that's not happening now.
>>>
>>> Any ideas?
>>>
>>> ~~~~~~~~~~~~~~~~
>>> "The problem with internet quotes is that you cannot verify their
>>> authenticity."  - Abraham Lincoln
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

David Witherspoon
Several attachments for you. The source.java, the unit test source.java, the javac.class file, the gec.class file.

Hopefully that will provide enough info to help you see what's going on.  Thanks very much for looking into this!

- David



From: Andrew Eisenberg <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Wednesday, June 26, 2013 1:58 PM
Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by code coverage tools

The javac screenshot also shows that there is a missing tested line at
line 1 where the package statement is.  Am I right?

The difference is in the numbers for the lines that are hit. Javac has
4/2/2 and GEC has 2/1/1.  I'm not sure what these numbers mean and why
javac has 4/5 lines covered and GEC has 3/4 lines covered.

Can you send over the class file for the javac-generated class?

On Wed, Jun 26, 2013 at 10:40 AM, David Witherspoon
<[hidden email]> wrote:

> Well, the inner-workings of byte code is beyond me.  Line 1 is a package
> statement, nothing more.
>
> The deserialize method is not generated...it's a regular old method that
> looks like this:
>    @Override
>    public LocalDate deserialize(final JsonParser parser, final
> DeserializationContext context) throws IOException {
>      String dateAsString = parser.getText();
>      return LocalDate.parse(dateAsString);
>    }
>
> That one method is exercised via a unit test.
>
> I can tell you that once we dropped back to javac, our test coverage
> problems all went away.
>
> Please find attached two screenshots.  One is the Cobertura output screen
> using javac as the compiler (notice the 80% coverage), and the other is
> compiling with the groovy-eclipse-compiler using this configuration:
>
>          <plugin>
>            <groupId>org.apache.maven.plugins</groupId>
>            <artifactId>maven-compiler-plugin</artifactId>
>            <version>2.3.2</version>
>            <configuration>
>                <compilerId>groovy-eclipse-compiler</compilerId>
>                <source>1.6</source>
>                <target>1.6</target>
>                <extensions>true</extensions>
>                <verbose>true</verbose>
>            </configuration>
>            <dependencies>
>                <dependency>
>                  <groupId>org.codehaus.groovy</groupId>
>                  <artifactId>groovy-eclipse-compiler</artifactId>
>                  <version>2.7.0-01</version>
>                  <exclusions>
>                      <exclusion>
>                        <groupId>org.codehaus.groovy</groupId>
>                        <artifactId>groovy-eclipse-batch</artifactId>
>                      </exclusion>
>                  </exclusions>
>                </dependency>
>                <dependency>
>                  <groupId>org.codehaus.groovy</groupId>
>                  <artifactId>groovy-eclipse-batch</artifactId>
>                  <version>2.1.3-01</version>
>                </dependency>
>            </dependencies>
>        </plugin>
>
>
> ________________________________
> From: Andrew Eisenberg <[hidden email]>
> To: "[hidden email]"
> <[hidden email]>
> Sent: Wednesday, June 26, 2013 1:13 PM
>
> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
> code coverage tools
>
> In the class file that you sent me, the deserialize() method is marked
> as having code at line 1.  This is the reason why cobertura is looking
> at that line.  Is the deserialize method generated or is it in the
> source?  What line is it on?  Is the deserialize method tested
> anywhere?
>
> There is nothing that I am aware of that would have caused this change
> with the new artifacts that were just relesaed.
>
> On Wed, Jun 26, 2013 at 7:59 AM, David Witherspoon <[hidden email]>
> wrote:
>> A little more on this...after the builds overnight have run, code coverage
>> is broken in half of our projects now.
>>
>> I have dropped back to using javac for all projects without groovy, and
>> using the new config for just those few projects with groovy source.
>>
>> I think the new configuration is marking more lines as executable when
>> they
>> are not.  After rebuilding with javac, coverage numbers are where they
>> were
>> before.
>>
>> - David
>> ________________________________
>> From: David Witherspoon <[hidden email]>
>> To: "[hidden email]"
>> <[hidden email]>
>> Sent: Wednesday, June 26, 2013 7:26 AM
>>
>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>> code coverage tools
>>
>> Hi Andrew,
>>
>> It's just that it's completely new behavior.  As soon as I worked through
>> the issues I had yesterday with the groovy-batch-compiler, a number of our
>> files started showing lower code coverage numbers.
>>
>> The file is not very interesting, so I've attached the .class file.
>>
>> - David
>>
>> From: Andrew Eisenberg <[hidden email]>
>> To: "[hidden email]"
>> <[hidden email]>
>> Sent: Tuesday, June 25, 2013 6:49 PM
>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>> code coverage tools
>>
>> Why would a package statement be an uncovered line?  The compiler must
>> have placed some code in the class file at line 1 (or wherever the
>> package statement is).
>>
>> You can share the class file with me (privately if you like) and I can
>> see if there's anything in the bytecode.
>>
>> On Tue, Jun 25, 2013 at 2:36 PM, David Witherspoon <[hidden email]>
>> wrote:
>>> Hi,
>>>
>>> So I've just gone through the process of updating our groovy-eclipse
>>> compiler version.  Now we're using:
>>>
>>> maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
>>> groovy-eclipse-compiler: 2.7.0-01
>>> groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
>>>
>>> Now we've got some new behavior.  We're using cobertura (2.5.2), and it's
>>> now complaining that the package statement in one of our classes is an
>>> uncovered line.  As I understand it, compilers are supposed to flag these
>>> lines in generated bytecode as not executable.
>>>
>>> But I guess that's not happening now.
>>>
>>> Any ideas?
>>>
>>> ~~~~~~~~~~~~~~~~
>>> "The problem with internet quotes is that you cannot verify their
>>> authenticity."  - Abraham Lincoln
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

LocalDateDeserializer.java (770 bytes) Download Attachment
LocalDateDeseralizerTest.java (1K) Download Attachment
LocalDateDeserializer.javac.class (1K) Download Attachment
LocalDateDeserializer.gec.class (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

Andrew Eisenberg
Hi David,

Thanks for the attachments.  I've confirmed that there is a difference
between the javac and JDT compilers (ie- this is not groovy-eclipse
specific).  Because the return type of deserialize is covariant (ie-
the super class has a type parameter for the return type), there is a
bridge method created for deserialize.  In javac, this bridge method
gets a line number of 10 (ie- the class declaration line number), but
JDT gives it a line number of 1.  The class declaration line number is
also the line number used for the default constructor.

What this is saying that your bridge method is never executed. In
javac, this is hidden because the default constructor and the bridge
method have the same line numbers.  And so calling the constructor
makes it look like the bridge method is also invoked.

I checked this in Eclipse 3.8 and 4.3, so this is not a regression in
JDT.  I'm not even sure if this is a "bug" (I'd have to look at the
Java spec for that).

One thing that is a bit surprising is that cobertura isn't picking
this up.  I would think that it should be able to ignore synthetic
methods.


On Wed, Jun 26, 2013 at 11:31 AM, David Witherspoon
<[hidden email]> wrote:

> Several attachments for you. The source.java, the unit test source.java, the
> javac.class file, the gec.class file.
>
> Hopefully that will provide enough info to help you see what's going on.
> Thanks very much for looking into this!
>
> - David
>
>
> ________________________________
> From: Andrew Eisenberg <[hidden email]>
> To: "[hidden email]"
> <[hidden email]>
> Sent: Wednesday, June 26, 2013 1:58 PM
>
> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
> code coverage tools
>
> The javac screenshot also shows that there is a missing tested line at
> line 1 where the package statement is.  Am I right?
>
> The difference is in the numbers for the lines that are hit. Javac has
> 4/2/2 and GEC has 2/1/1.  I'm not sure what these numbers mean and why
> javac has 4/5 lines covered and GEC has 3/4 lines covered.
>
> Can you send over the class file for the javac-generated class?
>
> On Wed, Jun 26, 2013 at 10:40 AM, David Witherspoon
> <[hidden email]> wrote:
>> Well, the inner-workings of byte code is beyond me.  Line 1 is a package
>> statement, nothing more.
>>
>> The deserialize method is not generated...it's a regular old method that
>> looks like this:
>>    @Override
>>    public LocalDate deserialize(final JsonParser parser, final
>> DeserializationContext context) throws IOException {
>>      String dateAsString = parser.getText();
>>      return LocalDate.parse(dateAsString);
>>    }
>>
>> That one method is exercised via a unit test.
>>
>> I can tell you that once we dropped back to javac, our test coverage
>> problems all went away.
>>
>> Please find attached two screenshots.  One is the Cobertura output screen
>> using javac as the compiler (notice the 80% coverage), and the other is
>> compiling with the groovy-eclipse-compiler using this configuration:
>>
>>          <plugin>
>>            <groupId>org.apache.maven.plugins</groupId>
>>            <artifactId>maven-compiler-plugin</artifactId>
>>            <version>2.3.2</version>
>>            <configuration>
>>                <compilerId>groovy-eclipse-compiler</compilerId>
>>                <source>1.6</source>
>>                <target>1.6</target>
>>                <extensions>true</extensions>
>>                <verbose>true</verbose>
>>            </configuration>
>>            <dependencies>
>>                <dependency>
>>                  <groupId>org.codehaus.groovy</groupId>
>>                  <artifactId>groovy-eclipse-compiler</artifactId>
>>                  <version>2.7.0-01</version>
>>                  <exclusions>
>>                      <exclusion>
>>                        <groupId>org.codehaus.groovy</groupId>
>>                        <artifactId>groovy-eclipse-batch</artifactId>
>>                      </exclusion>
>>                  </exclusions>
>>                </dependency>
>>                <dependency>
>>                  <groupId>org.codehaus.groovy</groupId>
>>                  <artifactId>groovy-eclipse-batch</artifactId>
>>                  <version>2.1.3-01</version>
>>                </dependency>
>>            </dependencies>
>>        </plugin>
>>
>>
>> ________________________________
>> From: Andrew Eisenberg <[hidden email]>
>> To: "[hidden email]"
>> <[hidden email]>
>> Sent: Wednesday, June 26, 2013 1:13 PM
>>
>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>> code coverage tools
>>
>> In the class file that you sent me, the deserialize() method is marked
>> as having code at line 1.  This is the reason why cobertura is looking
>> at that line.  Is the deserialize method generated or is it in the
>> source?  What line is it on?  Is the deserialize method tested
>> anywhere?
>>
>> There is nothing that I am aware of that would have caused this change
>> with the new artifacts that were just relesaed.
>>
>> On Wed, Jun 26, 2013 at 7:59 AM, David Witherspoon <[hidden email]>
>> wrote:
>>> A little more on this...after the builds overnight have run, code
>>> coverage
>>> is broken in half of our projects now.
>>>
>>> I have dropped back to using javac for all projects without groovy, and
>>> using the new config for just those few projects with groovy source.
>>>
>>> I think the new configuration is marking more lines as executable when
>>> they
>>> are not.  After rebuilding with javac, coverage numbers are where they
>>> were
>>> before.
>>>
>>> - David
>>> ________________________________
>>> From: David Witherspoon <[hidden email]>
>>> To: "[hidden email]"
>>> <[hidden email]>
>>> Sent: Wednesday, June 26, 2013 7:26 AM
>>>
>>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>>> code coverage tools
>>>
>>> Hi Andrew,
>>>
>>> It's just that it's completely new behavior.  As soon as I worked through
>>> the issues I had yesterday with the groovy-batch-compiler, a number of
>>> our
>>> files started showing lower code coverage numbers.
>>>
>>> The file is not very interesting, so I've attached the .class file.
>>>
>>> - David
>>>
>>> From: Andrew Eisenberg <[hidden email]>
>>> To: "[hidden email]"
>>> <[hidden email]>
>>> Sent: Tuesday, June 25, 2013 6:49 PM
>>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>>> code coverage tools
>>>
>>> Why would a package statement be an uncovered line?  The compiler must
>>> have placed some code in the class file at line 1 (or wherever the
>>> package statement is).
>>>
>>> You can share the class file with me (privately if you like) and I can
>>> see if there's anything in the bytecode.
>>>
>>> On Tue, Jun 25, 2013 at 2:36 PM, David Witherspoon <[hidden email]>
>>> wrote:
>>>> Hi,
>>>>
>>>> So I've just gone through the process of updating our groovy-eclipse
>>>> compiler version.  Now we're using:
>>>>
>>>> maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
>>>> groovy-eclipse-compiler: 2.7.0-01
>>>> groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
>>>>
>>>> Now we've got some new behavior.  We're using cobertura (2.5.2), and
>>>> it's
>>>> now complaining that the package statement in one of our classes is an
>>>> uncovered line.  As I understand it, compilers are supposed to flag
>>>> these
>>>> lines in generated bytecode as not executable.
>>>>
>>>> But I guess that's not happening now.
>>>>
>>>> Any ideas?
>>>>
>>>> ~~~~~~~~~~~~~~~~
>>>> "The problem with internet quotes is that you cannot verify their
>>>> authenticity."  - Abraham Lincoln
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

Andrew Eisenberg
I see there is an open cobertura bug for this and a patch:
http://sourceforge.net/p/cobertura/patches/97/

Another question that I have is, what setup were you using before you
saw this problem?  Since this is not a new change in JDT, were you
using something very old?

On Wed, Jun 26, 2013 at 1:57 PM, Andrew Eisenberg <[hidden email]> wrote:

> Hi David,
>
> Thanks for the attachments.  I've confirmed that there is a difference
> between the javac and JDT compilers (ie- this is not groovy-eclipse
> specific).  Because the return type of deserialize is covariant (ie-
> the super class has a type parameter for the return type), there is a
> bridge method created for deserialize.  In javac, this bridge method
> gets a line number of 10 (ie- the class declaration line number), but
> JDT gives it a line number of 1.  The class declaration line number is
> also the line number used for the default constructor.
>
> What this is saying that your bridge method is never executed. In
> javac, this is hidden because the default constructor and the bridge
> method have the same line numbers.  And so calling the constructor
> makes it look like the bridge method is also invoked.
>
> I checked this in Eclipse 3.8 and 4.3, so this is not a regression in
> JDT.  I'm not even sure if this is a "bug" (I'd have to look at the
> Java spec for that).
>
> One thing that is a bit surprising is that cobertura isn't picking
> this up.  I would think that it should be able to ignore synthetic
> methods.
>
>
> On Wed, Jun 26, 2013 at 11:31 AM, David Witherspoon
> <[hidden email]> wrote:
>> Several attachments for you. The source.java, the unit test source.java, the
>> javac.class file, the gec.class file.
>>
>> Hopefully that will provide enough info to help you see what's going on.
>> Thanks very much for looking into this!
>>
>> - David
>>
>>
>> ________________________________
>> From: Andrew Eisenberg <[hidden email]>
>> To: "[hidden email]"
>> <[hidden email]>
>> Sent: Wednesday, June 26, 2013 1:58 PM
>>
>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>> code coverage tools
>>
>> The javac screenshot also shows that there is a missing tested line at
>> line 1 where the package statement is.  Am I right?
>>
>> The difference is in the numbers for the lines that are hit. Javac has
>> 4/2/2 and GEC has 2/1/1.  I'm not sure what these numbers mean and why
>> javac has 4/5 lines covered and GEC has 3/4 lines covered.
>>
>> Can you send over the class file for the javac-generated class?
>>
>> On Wed, Jun 26, 2013 at 10:40 AM, David Witherspoon
>> <[hidden email]> wrote:
>>> Well, the inner-workings of byte code is beyond me.  Line 1 is a package
>>> statement, nothing more.
>>>
>>> The deserialize method is not generated...it's a regular old method that
>>> looks like this:
>>>    @Override
>>>    public LocalDate deserialize(final JsonParser parser, final
>>> DeserializationContext context) throws IOException {
>>>      String dateAsString = parser.getText();
>>>      return LocalDate.parse(dateAsString);
>>>    }
>>>
>>> That one method is exercised via a unit test.
>>>
>>> I can tell you that once we dropped back to javac, our test coverage
>>> problems all went away.
>>>
>>> Please find attached two screenshots.  One is the Cobertura output screen
>>> using javac as the compiler (notice the 80% coverage), and the other is
>>> compiling with the groovy-eclipse-compiler using this configuration:
>>>
>>>          <plugin>
>>>            <groupId>org.apache.maven.plugins</groupId>
>>>            <artifactId>maven-compiler-plugin</artifactId>
>>>            <version>2.3.2</version>
>>>            <configuration>
>>>                <compilerId>groovy-eclipse-compiler</compilerId>
>>>                <source>1.6</source>
>>>                <target>1.6</target>
>>>                <extensions>true</extensions>
>>>                <verbose>true</verbose>
>>>            </configuration>
>>>            <dependencies>
>>>                <dependency>
>>>                  <groupId>org.codehaus.groovy</groupId>
>>>                  <artifactId>groovy-eclipse-compiler</artifactId>
>>>                  <version>2.7.0-01</version>
>>>                  <exclusions>
>>>                      <exclusion>
>>>                        <groupId>org.codehaus.groovy</groupId>
>>>                        <artifactId>groovy-eclipse-batch</artifactId>
>>>                      </exclusion>
>>>                  </exclusions>
>>>                </dependency>
>>>                <dependency>
>>>                  <groupId>org.codehaus.groovy</groupId>
>>>                  <artifactId>groovy-eclipse-batch</artifactId>
>>>                  <version>2.1.3-01</version>
>>>                </dependency>
>>>            </dependencies>
>>>        </plugin>
>>>
>>>
>>> ________________________________
>>> From: Andrew Eisenberg <[hidden email]>
>>> To: "[hidden email]"
>>> <[hidden email]>
>>> Sent: Wednesday, June 26, 2013 1:13 PM
>>>
>>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>>> code coverage tools
>>>
>>> In the class file that you sent me, the deserialize() method is marked
>>> as having code at line 1.  This is the reason why cobertura is looking
>>> at that line.  Is the deserialize method generated or is it in the
>>> source?  What line is it on?  Is the deserialize method tested
>>> anywhere?
>>>
>>> There is nothing that I am aware of that would have caused this change
>>> with the new artifacts that were just relesaed.
>>>
>>> On Wed, Jun 26, 2013 at 7:59 AM, David Witherspoon <[hidden email]>
>>> wrote:
>>>> A little more on this...after the builds overnight have run, code
>>>> coverage
>>>> is broken in half of our projects now.
>>>>
>>>> I have dropped back to using javac for all projects without groovy, and
>>>> using the new config for just those few projects with groovy source.
>>>>
>>>> I think the new configuration is marking more lines as executable when
>>>> they
>>>> are not.  After rebuilding with javac, coverage numbers are where they
>>>> were
>>>> before.
>>>>
>>>> - David
>>>> ________________________________
>>>> From: David Witherspoon <[hidden email]>
>>>> To: "[hidden email]"
>>>> <[hidden email]>
>>>> Sent: Wednesday, June 26, 2013 7:26 AM
>>>>
>>>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>>>> code coverage tools
>>>>
>>>> Hi Andrew,
>>>>
>>>> It's just that it's completely new behavior.  As soon as I worked through
>>>> the issues I had yesterday with the groovy-batch-compiler, a number of
>>>> our
>>>> files started showing lower code coverage numbers.
>>>>
>>>> The file is not very interesting, so I've attached the .class file.
>>>>
>>>> - David
>>>>
>>>> From: Andrew Eisenberg <[hidden email]>
>>>> To: "[hidden email]"
>>>> <[hidden email]>
>>>> Sent: Tuesday, June 25, 2013 6:49 PM
>>>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>>>> code coverage tools
>>>>
>>>> Why would a package statement be an uncovered line?  The compiler must
>>>> have placed some code in the class file at line 1 (or wherever the
>>>> package statement is).
>>>>
>>>> You can share the class file with me (privately if you like) and I can
>>>> see if there's anything in the bytecode.
>>>>
>>>> On Tue, Jun 25, 2013 at 2:36 PM, David Witherspoon <[hidden email]>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> So I've just gone through the process of updating our groovy-eclipse
>>>>> compiler version.  Now we're using:
>>>>>
>>>>> maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
>>>>> groovy-eclipse-compiler: 2.7.0-01
>>>>> groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
>>>>>
>>>>> Now we've got some new behavior.  We're using cobertura (2.5.2), and
>>>>> it's
>>>>> now complaining that the package statement in one of our classes is an
>>>>> uncovered line.  As I understand it, compilers are supposed to flag
>>>>> these
>>>>> lines in generated bytecode as not executable.
>>>>>
>>>>> But I guess that's not happening now.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> ~~~~~~~~~~~~~~~~
>>>>> "The problem with internet quotes is that you cannot verify their
>>>>> authenticity."  - Abraham Lincoln
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

David Witherspoon
After every release, we advance versions of all third party tools and maven plugins.  So while we are almost never on the latest stuff out there, we are usually within 6 months of the latest.

The version of Cobertura we're using now is 2.5.2.  The patch you mention is from 2010...seems like this would have been fixed by now.  I wonder if that patch is still relevant against 2.5.2.

Remember that the only change I made was when I had to advance the version of groovy-eclipse-batch. Nothing else changed.
 
Thanks again!


From: Andrew Eisenberg <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Wednesday, June 26, 2013 4:59 PM
Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by code coverage tools

I see there is an open cobertura bug for this and a patch:
http://sourceforge.net/p/cobertura/patches/97/

Another question that I have is, what setup were you using before you
saw this problem?  Since this is not a new change in JDT, were you
using something very old?

On Wed, Jun 26, 2013 at 1:57 PM, Andrew Eisenberg <[hidden email]> wrote:

> Hi David,
>
> Thanks for the attachments.  I've confirmed that there is a difference
> between the javac and JDT compilers (ie- this is not groovy-eclipse
> specific).  Because the return type of deserialize is covariant (ie-
> the super class has a type parameter for the return type), there is a
> bridge method created for deserialize.  In javac, this bridge method
> gets a line number of 10 (ie- the class declaration line number), but
> JDT gives it a line number of 1.  The class declaration line number is
> also the line number used for the default constructor.
>
> What this is saying that your bridge method is never executed. In
> javac, this is hidden because the default constructor and the bridge
> method have the same line numbers.  And so calling the constructor
> makes it look like the bridge method is also invoked.
>
> I checked this in Eclipse 3.8 and 4.3, so this is not a regression in
> JDT.  I'm not even sure if this is a "bug" (I'd have to look at the
> Java spec for that).
>
> One thing that is a bit surprising is that cobertura isn't picking
> this up.  I would think that it should be able to ignore synthetic
> methods.
>
>
> On Wed, Jun 26, 2013 at 11:31 AM, David Witherspoon
> <[hidden email]> wrote:
>> Several attachments for you. The source.java, the unit test source.java, the
>> javac.class file, the gec.class file.
>>
>> Hopefully that will provide enough info to help you see what's going on.
>> Thanks very much for looking into this!
>>
>> - David
>>
>>
>> ________________________________
>> From: Andrew Eisenberg <[hidden email]>
>> To: "[hidden email]"
>> <[hidden email]>
>> Sent: Wednesday, June 26, 2013 1:58 PM
>>
>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>> code coverage tools
>>
>> The javac screenshot also shows that there is a missing tested line at
>> line 1 where the package statement is.  Am I right?
>>
>> The difference is in the numbers for the lines that are hit. Javac has
>> 4/2/2 and GEC has 2/1/1.  I'm not sure what these numbers mean and why
>> javac has 4/5 lines covered and GEC has 3/4 lines covered.
>>
>> Can you send over the class file for the javac-generated class?
>>
>> On Wed, Jun 26, 2013 at 10:40 AM, David Witherspoon
>> <[hidden email]> wrote:
>>> Well, the inner-workings of byte code is beyond me.  Line 1 is a package
>>> statement, nothing more.
>>>
>>> The deserialize method is not generated...it's a regular old method that
>>> looks like this:
>>>    @Override
>>>    public LocalDate deserialize(final JsonParser parser, final
>>> DeserializationContext context) throws IOException {
>>>      String dateAsString = parser.getText();
>>>      return LocalDate.parse(dateAsString);
>>>    }
>>>
>>> That one method is exercised via a unit test.
>>>
>>> I can tell you that once we dropped back to javac, our test coverage
>>> problems all went away.
>>>
>>> Please find attached two screenshots.  One is the Cobertura output screen
>>> using javac as the compiler (notice the 80% coverage), and the other is
>>> compiling with the groovy-eclipse-compiler using this configuration:
>>>
>>>          <plugin>
>>>            <groupId>org.apache.maven.plugins</groupId>
>>>            <artifactId>maven-compiler-plugin</artifactId>
>>>            <version>2.3.2</version>
>>>            <configuration>
>>>                <compilerId>groovy-eclipse-compiler</compilerId>
>>>                <source>1.6</source>
>>>                <target>1.6</target>
>>>                <extensions>true</extensions>
>>>                <verbose>true</verbose>
>>>            </configuration>
>>>            <dependencies>
>>>                <dependency>
>>>                  <groupId>org.codehaus.groovy</groupId>
>>>                  <artifactId>groovy-eclipse-compiler</artifactId>
>>>                  <version>2.7.0-01</version>
>>>                  <exclusions>
>>>                      <exclusion>
>>>                        <groupId>org.codehaus.groovy</groupId>
>>>                        <artifactId>groovy-eclipse-batch</artifactId>
>>>                      </exclusion>
>>>                  </exclusions>
>>>                </dependency>
>>>                <dependency>
>>>                  <groupId>org.codehaus.groovy</groupId>
>>>                  <artifactId>groovy-eclipse-batch</artifactId>
>>>                  <version>2.1.3-01</version>
>>>                </dependency>
>>>            </dependencies>
>>>        </plugin>
>>>
>>>
>>> ________________________________
>>> From: Andrew Eisenberg <[hidden email]>
>>> To: "[hidden email]"
>>> <[hidden email]>
>>> Sent: Wednesday, June 26, 2013 1:13 PM
>>>
>>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>>> code coverage tools
>>>
>>> In the class file that you sent me, the deserialize() method is marked
>>> as having code at line 1.  This is the reason why cobertura is looking
>>> at that line.  Is the deserialize method generated or is it in the
>>> source?  What line is it on?  Is the deserialize method tested
>>> anywhere?
>>>
>>> There is nothing that I am aware of that would have caused this change
>>> with the new artifacts that were just relesaed.
>>>
>>> On Wed, Jun 26, 2013 at 7:59 AM, David Witherspoon <[hidden email]>
>>> wrote:
>>>> A little more on this...after the builds overnight have run, code
>>>> coverage
>>>> is broken in half of our projects now.
>>>>
>>>> I have dropped back to using javac for all projects without groovy, and
>>>> using the new config for just those few projects with groovy source.
>>>>
>>>> I think the new configuration is marking more lines as executable when
>>>> they
>>>> are not.  After rebuilding with javac, coverage numbers are where they
>>>> were
>>>> before.
>>>>
>>>> - David
>>>> ________________________________
>>>> From: David Witherspoon <[hidden email]>
>>>> To: "[hidden email]"
>>>> <[hidden email]>
>>>> Sent: Wednesday, June 26, 2013 7:26 AM
>>>>
>>>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>>>> code coverage tools
>>>>
>>>> Hi Andrew,
>>>>
>>>> It's just that it's completely new behavior.  As soon as I worked through
>>>> the issues I had yesterday with the groovy-batch-compiler, a number of
>>>> our
>>>> files started showing lower code coverage numbers.
>>>>
>>>> The file is not very interesting, so I've attached the .class file.
>>>>
>>>> - David
>>>>
>>>> From: Andrew Eisenberg <[hidden email]>
>>>> To: "[hidden email]"
>>>> <[hidden email]>
>>>> Sent: Tuesday, June 25, 2013 6:49 PM
>>>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>>>> code coverage tools
>>>>
>>>> Why would a package statement be an uncovered line?  The compiler must
>>>> have placed some code in the class file at line 1 (or wherever the
>>>> package statement is).
>>>>
>>>> You can share the class file with me (privately if you like) and I can
>>>> see if there's anything in the bytecode.
>>>>
>>>> On Tue, Jun 25, 2013 at 2:36 PM, David Witherspoon <[hidden email]>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> So I've just gone through the process of updating our groovy-eclipse
>>>>> compiler version.  Now we're using:
>>>>>
>>>>> maven-compiler-plugin: 2.3.2 (3.0 would not compile some projects)
>>>>> groovy-eclipse-compiler: 2.7.0-01
>>>>> groovy-eclipse-batch: 2.1.3-01 (other versions also tested)
>>>>>
>>>>> Now we've got some new behavior.  We're using cobertura (2.5.2), and
>>>>> it's
>>>>> now complaining that the package statement in one of our classes is an
>>>>> uncovered line.  As I understand it, compilers are supposed to flag
>>>>> these
>>>>> lines in generated bytecode as not executable.
>>>>>
>>>>> But I guess that's not happening now.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> ~~~~~~~~~~~~~~~~
>>>>> "The problem with internet quotes is that you cannot verify their
>>>>> authenticity."  - Abraham Lincoln
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

Andrew Eisenberg-2
The bug was created in 2010, but it is still open. It's worth omen ting on the bug to see why no one has touched it.

On Thursday, June 27, 2013, David Witherspoon wrote:
After every release, we advance versions of all third party tools and maven plugins.  So while we are almost never on the latest stuff out there, we are usually within 6 months of the latest.

The version of Cobertura we're using now is 2.5.2.  The patch you mention is from 2010...seems like this would have been fixed by now.  I wonder if that patch is still relevant against 2.5.2.

Remember that the only change I made was when I had to advance the version of groovy-eclipse-batch. Nothing else changed.
 
Thanks again!


From: Andrew Eisenberg <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;andrew@eisenberg.as&#39;);" target="_blank">andrew@...>
To: "<a href="javascript:_e({}, &#39;cvml&#39;, &#39;eclipse-plugin-user@groovy.codehaus.org&#39;);" target="_blank">eclipse-plugin-user@..." <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;eclipse-plugin-user@groovy.codehaus.org&#39;);" target="_blank">eclipse-plugin-user@...>
Sent: Wednesday, June 26, 2013 4:59 PM
Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by code coverage tools

I see there is an open cobertura bug for this and a patch:
http://sourceforge.net/p/cobertura/patches/97/

Another question that I have is, what setup were you using before you
saw this problem?  Since this is not a new change in JDT, were you
using something very old?

On Wed, Jun 26, 2013 at 1:57 PM, Andrew Eisenberg <[hidden email]> wrote:
> Hi David,
>
> Thanks for the attachments.  I've confirmed that there is a difference
> between the javac and JDT compilers (ie- this is not groovy-eclipse
> specific).  Because the return type of deserialize is covariant (ie-
> the super class has a type parameter for the return type), there is a
> bridge method created for deserialize.  In javac, this bridge method
> gets a line number of 10 (ie- the class declaration line number), but
> JDT gives it a line number of 1.  The class declaration line number is
> also the line number used for the default constructor.
>
> What this is saying that your bridge method is never executed. In
> javac, this is hidden because the default constructor and the bridge
> method have the same line numbers.  And so calling the constructor
> makes it look like the bridge method is also invoked.
>
> I checked this in Eclipse 3.8 and 4.3, so this is not a regression in
> JDT.  I'm not even sure if this is a "bug" (I'd have to look at the
> Java spec for that).
>
> One thing that is a bit surprising is that cobertura isn't picking
> this up.  I would think that it should be able to ignore synthetic
> methods.
>
>
> On Wed, Jun 26, 2013 at 11:31 AM, David Witherspoon
> <[hidden email]> wrote:
>> Several attachments for you. The source.java, the unit test source.java, the
>> javac.class file, the gec.class file.
>>
>> Hopefully that will provide enough info to help you see what's going on.
>> Thanks very much for looking into this!
>>
>> - David
>>
>>
>> ________________________________
>> From: Andrew Eisenberg <[hidden email]>
>> To: "[hidden email]"
>> <[hidden email]>
>> Sent: Wednesday, June 26, 2013 1:58 PM
>>
>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>> code coverage tools
>>
>> The javac screenshot also shows that there is a missing tested line at
>> line 1 where the package statement is.  Am I right?
>>
>> The difference is in the numbers for the lines that are hit. Javac has
>> 4/2/2 and GEC has 2/1/1.  I'm not sure what these numbers mean and why
>> javac has 4/5 lines covered and GEC has 3/4 lines covered.
>>
>> Can you send over the class file for the javac-generated class?
>>
>> On Wed, Jun 26, 2013 at 10:40 AM, David Witherspoon
>> <[hidden email]> wrote:
>>> Well, the inner-workings of byte code is beyond me.  Line 1 is a package
>>> statement, nothing more.
>>>
>>> The deserialize method is not generated...it's a regular old method that
>>> looks like this:
>>>    @Override
>>>    public LocalDate deserialize(final JsonParser parser, final
>>> DeserializationContext context) throws IOException {
>>>      String dateAsString = parser.getText();
>>>      return LocalDate.parse(dateAsString);
>>>    }
>>>
>>> That one method is exercised via a unit test.
>>>
>>> I can tell you that once we dropped back to javac, our test coverage
>>> problems all went away.
>>>
>>> Please find attached two screenshots.  One is the Cobertura output screen
>>> using javac as the compiler (notice the 80% coverage), and the other is
>>> compiling with the groovy-eclipse-compiler using this configuration:
>>>
>>>          <plugin>
>>>            <groupId


--
Sent while on the go.
Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

David Witherspoon
I'll do that.

I'm still not clear though.  You're saying the difference in how code is marked executable is due to the JDT compiler.  But remember, we did not change anything.  The new version of groovy-eclipse-batch broke our builds, and so to fix this, we just locked down the version of groovy-eclipse-batch. And the output .class file has the differences you mentioned.

How could that be?  Really appreciate your help...and trying to understand!

- David


From: Andrew Eisenberg <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Thursday, June 27, 2013 9:20 AM
Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by code coverage tools

The bug was created in 2010, but it is still open. It's worth omen ting on the bug to see why no one has touched it.

On Thursday, June 27, 2013, David Witherspoon wrote:
After every release, we advance versions of all third party tools and maven plugins.  So while we are almost never on the latest stuff out there, we are usually within 6 months of the latest.

The version of Cobertura we're using now is 2.5.2.  The patch you mention is from 2010...seems like this would have been fixed by now.  I wonder if that patch is still relevant against 2.5.2.

Remember that the only change I made was when I had to advance the version of groovy-eclipse-batch. Nothing else changed.
 
Thanks again!


From: Andrew Eisenberg <andrew@...>
To: "eclipse-plugin-user@..." <eclipse-plugin-user@...>
Sent: Wednesday, June 26, 2013 4:59 PM
Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by code coverage tools

I see there is an open cobertura bug for this and a patch:
http://sourceforge.net/p/cobertura/patches/97/

Another question that I have is, what setup were you using before you
saw this problem?  Since this is not a new change in JDT, were you
using something very old?

On Wed, Jun 26, 2013 at 1:57 PM, Andrew Eisenberg <andrew@...> wrote:
> Hi David,
>
> Thanks for the attachments.  I've confirmed that there is a difference
> between the javac and JDT compilers (ie- this is not groovy-eclipse
> specific).  Because the return type of deserialize is covariant (ie-
> the super class has a type parameter for the return type), there is a
> bridge method created for deserialize.  In javac, this bridge method
> gets a line number of 10 (ie- the class declaration line number), but
> JDT gives it a line number of 1.  The class declaration line number is
> also the line number used for the default constructor.
>
> What this is saying that your bridge method is never executed. In
> javac, this is hidden because the default constructor and the bridge
> method have the same line numbers.  And so calling the constructor
> makes it look like the bridge method is also invoked.
>
> I checked this in Eclipse 3.8 and 4.3, so this is not a regression in
> JDT.  I'm not even sure if this is a "bug" (I'd have to look at the
> Java spec for that).
>
> One thing that is a bit surprising is that cobertura isn't picking
> this up.  I would think that it should be able to ignore synthetic
> methods.
>
>
> On Wed, Jun 26, 2013 at 11:31 AM, David Witherspoon
> <dbw.online@...> wrote:
>> Several attachments for you. The source.java, the unit test source.java, the
>> javac.class file, the gec.class file.
>>
>> Hopefully that will provide enough info to help you see what's going on.
>> Thanks very much for looking into this!
>>
>> - David
>>
>>
>> ________________________________
>> From: Andrew Eisenberg <andrew@...>
>> To: "eclipse-plugin-user@..."
>> <eclipse-plugin-user@...>
>> Sent: Wednesday, June 26, 2013 1:58 PM
>>
>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>> code coverage tools
>>
>> The javac screenshot also shows that there is a missing tested line at
>> line 1 where the package statement is.  Am I right?
>>
>> The difference is in the numbers for the lines that are hit. Javac has
>> 4/2/2 and GEC has 2/1/1.  I'm not sure what these numbers mean and why
>> javac has 4/5 lines covered and GEC has 3/4 lines covered.
>>
>> Can you send over the class file for the javac-generated class?
>>
>> On Wed, Jun 26, 2013 at 10:40 AM, David Witherspoon
>> <dbw.online@...> wrote:
>>> Well, the inner-workings of byte code is beyond me.  Line 1 is a package
>>> statement, nothing more.
>>>
>>> The deserialize method is not generated...it's a regular old method that
>>> looks like this:
>>>    @Override
>>>    public LocalDate deserialize(final JsonParser parser, final
>>> DeserializationContext context) throws IOException {
>>>      String dateAsString = parser.getText();
>>>      return LocalDate.parse(dateAsString);
>>>    }
>>>
>>> That one method is exercised via a unit test.
>>>
>>> I can tell you that once we dropped back to javac, our test coverage
>>> problems all went away.
>>>
>>> Please find attached two screenshots.  One is the Cobertura output screen
>>> using javac as the compiler (notice the 80% coverage), and the other is
>>> compiling with the groovy-eclipse-compiler using this configuration:
>>>
>>>          <plugin>
>>>            <groupId


--
Sent while on the go.


Reply | Threaded
Open this post in threaded view
|

Re: Package statement recognized by code coverage tools

Andrew Eisenberg
I don't know why you didn't see them before.  I had asked previously
what your working configuration is as it seems like this is a
long-standing "feature" of JDT.  This latest release of
groovy-eclipse-batch is now based on Eclipse 4.3.  I only checked
against e43 and e42. I have not checked e37. If your version is old
enough, then you may be using that version and things may be different
with the JDT compiler.

On Thu, Jun 27, 2013 at 7:28 AM, David Witherspoon <[hidden email]> wrote:

> I'll do that.
>
> I'm still not clear though.  You're saying the difference in how code is
> marked executable is due to the JDT compiler.  But remember, we did not
> change anything.  The new version of groovy-eclipse-batch broke our builds,
> and so to fix this, we just locked down the version of groovy-eclipse-batch.
> And the output .class file has the differences you mentioned.
>
> How could that be?  Really appreciate your help...and trying to understand!
>
> - David
>
> ________________________________
> From: Andrew Eisenberg <[hidden email]>
> To: "[hidden email]"
> <[hidden email]>
> Sent: Thursday, June 27, 2013 9:20 AM
>
> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
> code coverage tools
>
> The bug was created in 2010, but it is still open. It's worth omen ting on
> the bug to see why no one has touched it.
>
> On Thursday, June 27, 2013, David Witherspoon wrote:
>
> After every release, we advance versions of all third party tools and maven
> plugins.  So while we are almost never on the latest stuff out there, we are
> usually within 6 months of the latest.
>
> The version of Cobertura we're using now is 2.5.2.  The patch you mention is
> from 2010...seems like this would have been fixed by now.  I wonder if that
> patch is still relevant against 2.5.2.
>
> Remember that the only change I made was when I had to advance the version
> of groovy-eclipse-batch. Nothing else changed.
>
> Thanks again!
>
> ________________________________
> From: Andrew Eisenberg <[hidden email]>
> To: "[hidden email]"
> <[hidden email]>
> Sent: Wednesday, June 26, 2013 4:59 PM
> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
> code coverage tools
>
> I see there is an open cobertura bug for this and a patch:
> http://sourceforge.net/p/cobertura/patches/97/
>
> Another question that I have is, what setup were you using before you
> saw this problem?  Since this is not a new change in JDT, were you
> using something very old?
>
> On Wed, Jun 26, 2013 at 1:57 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>> Hi David,
>>
>> Thanks for the attachments.  I've confirmed that there is a difference
>> between the javac and JDT compilers (ie- this is not groovy-eclipse
>> specific).  Because the return type of deserialize is covariant (ie-
>> the super class has a type parameter for the return type), there is a
>> bridge method created for deserialize.  In javac, this bridge method
>> gets a line number of 10 (ie- the class declaration line number), but
>> JDT gives it a line number of 1.  The class declaration line number is
>> also the line number used for the default constructor.
>>
>> What this is saying that your bridge method is never executed. In
>> javac, this is hidden because the default constructor and the bridge
>> method have the same line numbers.  And so calling the constructor
>> makes it look like the bridge method is also invoked.
>>
>> I checked this in Eclipse 3.8 and 4.3, so this is not a regression in
>> JDT.  I'm not even sure if this is a "bug" (I'd have to look at the
>> Java spec for that).
>>
>> One thing that is a bit surprising is that cobertura isn't picking
>> this up.  I would think that it should be able to ignore synthetic
>> methods.
>>
>>
>> On Wed, Jun 26, 2013 at 11:31 AM, David Witherspoon
>> <[hidden email]> wrote:
>>> Several attachments for you. The source.java, the unit test source.java,
>>> the
>>> javac.class file, the gec.class file.
>>>
>>> Hopefully that will provide enough info to help you see what's going on.
>>> Thanks very much for looking into this!
>>>
>>> - David
>>>
>>>
>>> ________________________________
>>> From: Andrew Eisenberg <[hidden email]>
>>> To: "[hidden email]"
>>> <[hidden email]>
>>> Sent: Wednesday, June 26, 2013 1:58 PM
>>>
>>> Subject: Re: [groovy-eclipse-plugin-user] Package statement recognized by
>>> code coverage tools
>>>
>>> The javac screenshot also shows that there is a missing tested line at
>>> line 1 where the package statement is.  Am I right?
>>>
>>> The difference is in the numbers for the lines that are hit. Javac has
>>> 4/2/2 and GEC has 2/1/1.  I'm not sure what these numbers mean and why
>>> javac has 4/5 lines covered and GEC has 3/4 lines covered.
>>>
>>> Can you send over the class file for the javac-generated class?
>>>
>>> On Wed, Jun 26, 2013 at 10:40 AM, David Witherspoon
>>> <[hidden email]> wrote:
>>>> Well, the inner-workings of byte code is beyond me.  Line 1 is a package
>>>> statement, nothing more.
>>>>
>>>> The deserialize method is not generated...it's a regular old method that
>>>> looks like this:
>>>>    @Override
>>>>    public LocalDate deserialize(final JsonParser parser, final
>>>> DeserializationContext context) throws IOException {
>>>>      String dateAsString = parser.getText();
>>>>      return LocalDate.parse(dateAsString);
>>>>    }
>>>>
>>>> That one method is exercised via a unit test.
>>>>
>>>> I can tell you that once we dropped back to javac, our test coverage
>>>> problems all went away.
>>>>
>>>> Please find attached two screenshots.  One is the Cobertura output
>>>> screen
>>>> using javac as the compiler (notice the 80% coverage), and the other is
>>>> compiling with the groovy-eclipse-compiler using this configuration:
>>>>
>>>>          <plugin>
>>>>            <groupId
>
>
>
> --
> Sent while on the go.
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email