groovy
  1. groovy
  2. GROOVY-833

Groovy-core compile errors in eclipse with 5.0 compiler enabled

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0-JSR-2
    • Fix Version/s: 1.0-JSR-5
    • Component/s: groovy-jdk
    • Labels:
      None
    • Environment:
      Eclipse 3.1M5, JDK 5.0
    • Number of attachments :
      2

      Description

      Using eclipse with the 5.0 compiler (instead of the 1.4 compiler) causes the following ERRORs:

      org/codehaus/groovy/runtime/DefaultGroovyMethods.java (line 3355)
      The method compareTo(BigInteger) in the type BigInteger is not applicable for the arguments (BigDecimal)

      org/codehaus/groovy/runtime/WriteFile.java (line 102)
      Name clash: The method compareTo(Object) of type WritableFile has the same erasure as compareTo(T) of type Comparable<T> but does not override it

      org/codehaus/groovy/runtime/WriteFile.java (line 103)
      The method compareTo(File) in the type File is not applicable for the arguments (Object)

      1. groovy.java5.patch
        7 kB
        Marc Guillemot
      2. WritableFile.java
        3 kB
        Marc Guillemot

        Issue Links

          Activity

          Hide
          Dierk König added a comment -

          applied WritableFile.java.

          please test and close issue if ok.

          Show
          Dierk König added a comment - applied WritableFile.java. please test and close issue if ok.
          Hide
          blackdrag blackdrag added a comment -

          you people where a bit fast here...

          it is good you corrected WritableFile, because I think the compareTo method in the first patch would have produced a stack overflow when compiled with 1.4. I am not lucky about the changed tests

          +import java.math.*
          +

          public class DownUpStepTest extends GroovyTestCase {

          void testDownto() {

          • def z = 0.0
          • (10.5).downto(5.9) { z += it }
            - assert z == 10.5 + 9.5 + 8.5 + 7.5 + 6.5
            - assert z == 42.5

            + def z = []
            + (10.5).downto(5.9) { z << it }
            + assertEquals( [10.5, 9.5, 8.5, 7.5, 6.5], z)
            + }
            +
            + void testBigIntegerDowntoBigDecimal() {
            + def z = []
            + (new BigInteger("10")).downto(new BigDecimal("5.9")) { z << it }
            + assertEquals( [new BigInteger("10"), new BigInteger("9"), new BigInteger("8"),
            + new BigInteger("7"), new BigInteger("6")], z)

            }

            first... this test isn't groovy. There is no need to write new Biginteger("10"), we can write 10G. Second, why is the list used? I strongly recomend to revert the changes in testDownto(). And testBigIntegerDowntoBigDecimal could be also more groovy:

            void testBigIntegerDowntoBigDecimal() {
            def z = 0G
            10G.downto(5.9) { z += it }

            assert z == 40G
            assert z.class == BigInteger
            }

          using assertEquals(List,Object) won't work, as this merhod is not available.. then the testDownto in DefaultGroovyMethodsTest , why do we create a String here and compare that? I mean

          assertEquals("[1, 0]", DefaultGroovyMethods.toString(li));

          we could simply count how often the closure is called:

          public void testDownto() {
          final List li = new ArrayList();
          final Closure closure = new Closure(null) {
          int count = 0;
          public Object doCall(final Object params)

          { count++; return null; }

          };

          DefaultGroovyMethods.downto(new BigInteger("1"), new BigDecimal("0"), closure);
          assertEquals(closure.count, 2);

          closure.count=0;

          DefaultGroovyMethods.downto(new BigInteger("1"), new BigDecimal("0.123"), closure);
          assertEquals(closure.count,1);
          }

          btw, java.math isn't needed in groovy for BigInteger and BigDecimal in the CVS version.. so I think that's all

          Show
          blackdrag blackdrag added a comment - you people where a bit fast here... it is good you corrected WritableFile, because I think the compareTo method in the first patch would have produced a stack overflow when compiled with 1.4. I am not lucky about the changed tests +import java.math.* + public class DownUpStepTest extends GroovyTestCase { void testDownto() { def z = 0.0 (10.5).downto(5.9) { z += it } - assert z == 10.5 + 9.5 + 8.5 + 7.5 + 6.5 - assert z == 42.5 + def z = [] + (10.5).downto(5.9) { z << it } + assertEquals( [10.5, 9.5, 8.5, 7.5, 6.5] , z) + } + + void testBigIntegerDowntoBigDecimal() { + def z = [] + (new BigInteger("10")).downto(new BigDecimal("5.9")) { z << it } + assertEquals( [new BigInteger("10"), new BigInteger("9"), new BigInteger("8"), + new BigInteger("7"), new BigInteger("6")], z) } first... this test isn't groovy. There is no need to write new Biginteger("10"), we can write 10G. Second, why is the list used? I strongly recomend to revert the changes in testDownto(). And testBigIntegerDowntoBigDecimal could be also more groovy: void testBigIntegerDowntoBigDecimal() { def z = 0G 10G.downto(5.9) { z += it } assert z == 40G assert z.class == BigInteger } using assertEquals(List,Object) won't work, as this merhod is not available.. then the testDownto in DefaultGroovyMethodsTest , why do we create a String here and compare that? I mean assertEquals(" [1, 0] ", DefaultGroovyMethods.toString(li)); we could simply count how often the closure is called: public void testDownto() { final List li = new ArrayList(); final Closure closure = new Closure(null) { int count = 0; public Object doCall(final Object params) { count++; return null; } }; DefaultGroovyMethods.downto(new BigInteger("1"), new BigDecimal("0"), closure); assertEquals(closure.count, 2); closure.count=0; DefaultGroovyMethods.downto(new BigInteger("1"), new BigDecimal("0.123"), closure); assertEquals(closure.count,1); } btw, java.math isn't needed in groovy for BigInteger and BigDecimal in the CVS version.. so I think that's all
          Hide
          blackdrag blackdrag added a comment -

          sorry, the comment about assertEquals was stupid, of course you compare lists

          Show
          blackdrag blackdrag added a comment - sorry, the comment about assertEquals was stupid, of course you compare lists
          Hide
          Marc Guillemot added a comment -

          10G, 9G, ... should be used. Sorry, I'm not yet confident enough will all Groovy shortcuts.

          Otherwise the test has to compare lists because it is far more precise than comparing counts or sums (like what was previously made) and it is really more readable.

          Show
          Marc Guillemot added a comment - 10G, 9G, ... should be used. Sorry, I'm not yet confident enough will all Groovy shortcuts. Otherwise the test has to compare lists because it is far more precise than comparing counts or sums (like what was previously made) and it is really more readable.
          Hide
          blackdrag blackdrag added a comment -

          yes, I already said that my comment about assertEquals was stupid. I still don't like the thing with toString in DefaultGroovyMethodsTest, but as long as the build works I can life with it

          Show
          blackdrag blackdrag added a comment - yes, I already said that my comment about assertEquals was stupid. I still don't like the thing with toString in DefaultGroovyMethodsTest, but as long as the build works I can life with it

            People

            • Assignee:
              Dierk König
              Reporter:
              Hein Meling
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: