Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.8-rc-2, 1.9-beta-1
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      1

      Activity

      Hide
      Peter Niederwieser added a comment -

      Here is a patch for trunk, very similar but not identical to Paul's (now reverted) commit. Solves all problems that I'm aware of.

      Show
      Peter Niederwieser added a comment - Here is a patch for trunk, very similar but not identical to Paul's (now reverted) commit. Solves all problems that I'm aware of.
      Hide
      Peter Niederwieser added a comment -

      With my patch, adding the evil "foo" method posted by Guillaume on the mailing list...

         public static Integer foo(Integer self) {
              Collection c = new ArrayList();
              Number x = inject(c, (Integer) 3, new Closure<BigInteger>(c) {
                  void doCall() {
                  }
              });
              return self;
          }
      

      ...still produces a compile error, but this error can now be avoided by casting to Number instead of Integer. I don't know why the compiler needs this assistance, but I think the patch is nevertheless safe and should go in.

      Show
      Peter Niederwieser added a comment - With my patch, adding the evil "foo" method posted by Guillaume on the mailing list... public static Integer foo( Integer self) { Collection c = new ArrayList(); Number x = inject(c, ( Integer ) 3, new Closure<BigInteger>(c) { void doCall() { } }); return self; } ...still produces a compile error, but this error can now be avoided by casting to Number instead of Integer. I don't know why the compiler needs this assistance, but I think the patch is nevertheless safe and should go in.
      Hide
      Paul King added a comment -

      Peter, as per your email I originally tried something very close to your patch. The only difference was that I removed the two casts to (T) as Intellij was saying they were redundant but then it didn't compile. Hence my earlier variation. But with the two casts, it compiles fine and seems to be the correct way to go. I'll apply the patch.

      Show
      Paul King added a comment - Peter, as per your email I originally tried something very close to your patch. The only difference was that I removed the two casts to (T) as Intellij was saying they were redundant but then it didn't compile. Hence my earlier variation. But with the two casts, it compiles fine and seems to be the correct way to go. I'll apply the patch.
      Hide
      Peter Niederwieser added a comment -

      The other difference is in the signature: Closure<V> vs. Closure<? extends T>. For some reason I don't understand, only with the former signature can the evil foo method be made to compile by casting to Number instead of Integer.

      I've seen quite a few cases where IDEA is wrong about generics. Eclipse does a much better job in this regard.

      Show
      Peter Niederwieser added a comment - The other difference is in the signature: Closure<V> vs. Closure<? extends T>. For some reason I don't understand, only with the former signature can the evil foo method be made to compile by casting to Number instead of Integer. I've seen quite a few cases where IDEA is wrong about generics. Eclipse does a much better job in this regard.
      Hide
      Paul King added a comment -

      I think the lesson here is that Java generics leaves much to be desired (but we all knew that). The added Java integration test looks like this:

      Collection<Integer> c = Arrays.asList(2, 4, 5, 20);
      Number initial = BigDecimal.ZERO;
      Closure<? extends Number> closure = new Closure<BigDecimal>(c) {
          BigDecimal doCall(BigDecimal total, Integer next) {
              return total.add(BigDecimal.ONE.divide(new BigDecimal(next)));
          }
      };
      assertTrue(DefaultTypeTransformation.compareEqual(BigDecimal.ONE, inject(c, initial, closure)));
      

      Several bits of this you would think are possible to simplify but currently you can't or the Java compiler gets upset. Nonetheless, this example illustrates the recommended way of using the current API.

      Show
      Paul King added a comment - I think the lesson here is that Java generics leaves much to be desired (but we all knew that). The added Java integration test looks like this: Collection< Integer > c = Arrays.asList(2, 4, 5, 20); Number initial = BigDecimal.ZERO; Closure<? extends Number > closure = new Closure<BigDecimal>(c) { BigDecimal doCall(BigDecimal total, Integer next) { return total.add(BigDecimal.ONE.divide( new BigDecimal(next))); } }; assertTrue(DefaultTypeTransformation.compareEqual(BigDecimal.ONE, inject(c, initial, closure))); Several bits of this you would think are possible to simplify but currently you can't or the Java compiler gets upset. Nonetheless, this example illustrates the recommended way of using the current API.

        People

        • Assignee:
          Paul King
          Reporter:
          Paul King
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved: