GMaven
  1. GMaven
  2. GMAVEN-100

Escaped backslashes in groovy code are un-escaped in java stubs

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.5
    • Component/s: stub generation
    • Labels:
      None
    • Environment:
      Maven 2.2.1, compiler plugin 2.5.1, Sun JDK 1.6
    • Number of attachments :
      0

      Description

      Strings like this one in a Groovy file:

      public static final SOME_STRING = "c:\\path\\to
      somewhere"

      end up like this in the java stub file:

      public static final java.lang.String SOME_STRING = "c:\path\to\somewhere"

      Needless to say, this breaks Java compilation, since "\p" and "\s" are illegal escape characters.

        Activity

        Hide
        Keegan Witt added a comment -

        I'm still tracking down what changed, but this doesn't seem to happen in 1.3.

        Show
        Keegan Witt added a comment - I'm still tracking down what changed, but this doesn't seem to happen in 1.3.
        Hide
        Ethan Larson added a comment -

        I can confirm that I'm also not seeing the problem in 1.3.

        Show
        Ethan Larson added a comment - I can confirm that I'm also not seeing the problem in 1.3.
        Hide
        Keegan Witt added a comment -

        It also works with 1.6.9 and 1.7.10 in 1.4, but not 1.8 and 2.0. I'm still trying to figure out what's going on here.

        Show
        Keegan Witt added a comment - It also works with 1.6.9 and 1.7.10 in 1.4, but not 1.8 and 2.0. I'm still trying to figure out what's going on here.
        Hide
        Keegan Witt added a comment -

        It also seems to be happening in stub generation, but not normal compilation.

        Show
        Keegan Witt added a comment - It also seems to be happening in stub generation, but not normal compilation.
        Hide
        Keegan Witt added a comment - - edited

        Actually, this has nothing to do with 1.3 vs 1.4, it has to do with the fact Groovy versions > 1.8.4 don't work. I just thought it was working in 1.3 because I used 1.7.10 when testing 1.3 because the 1.8 provider wasn't available in 1.3. Here's the change that seems to have broken this: https://github.com/groovy/groovy-core/commit/2e8e92c39a76bf795ffac6bfacaad9f066bbb6c7. I'm still thinking about how to deal with this.

        Show
        Keegan Witt added a comment - - edited Actually, this has nothing to do with 1.3 vs 1.4, it has to do with the fact Groovy versions > 1.8.4 don't work. I just thought it was working in 1.3 because I used 1.7.10 when testing 1.3 because the 1.8 provider wasn't available in 1.3. Here's the change that seems to have broken this: https://github.com/groovy/groovy-core/commit/2e8e92c39a76bf795ffac6bfacaad9f066bbb6c7 . I'm still thinking about how to deal with this.
        Hide
        Keegan Witt added a comment - - edited

        Reverting back to the old behavior seems to work, but I'm thinking I'd like to make the stub look like the groovy file to make debugging easier. The downside of either approach is since the breaking change is in a private method (printField), I can't change this with an anonymous class extending the original, I'll have to fork the class internally.

        Show
        Keegan Witt added a comment - - edited Reverting back to the old behavior seems to work, but I'm thinking I'd like to make the stub look like the groovy file to make debugging easier. The downside of either approach is since the breaking change is in a private method (printField), I can't change this with an anonymous class extending the original, I'll have to fork the class internally.

          People

          • Assignee:
            Keegan Witt
            Reporter:
            Ethan Larson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: