groovy
  1. groovy
  2. GROOVY-4102

remove timestamp fields for better hotswap

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.1
    • Fix Version/s: 2.4.0-beta-4
    • Component/s: bytecode
    • Labels:
      None
    • Number of attachments :
      1

      Description

      While debugging I try to hot swap a groovy class.
      It always fails with messages "Schema change not implemented. Operation not supported by VM".

      With Java classes there is no such problem - hot swap works as long as I don't add/remove any field or method or change a method signature.

      I had hoped to gradually convert my Java app to groovy, but this made me refrain from using groovy for anything more complex than "java" beans.

      Looking at the bytecode with javap, it is obvious where the problem is:
      There is an artifical field that changes its name on each compilation.
      Initial:
      public static java.lang.Long _timeStamp_239_neverHappen1268432715287;
      After recompilation:
      public static java.lang.Long _timeStamp_239_neverHappen1268433121889;

      What is this field used for? Can't we get rid of it?
      All other fields/methods look the same after recompilation, so I am pretty sure that hot swap will work without this field change.

      1. timestamp.patch
        5 kB
        blackdrag blackdrag

        Issue Links

          Activity

          Hide
          Andy Clement added a comment -

          Groovy-Eclipse no longer produces the timestamp fields (to facilitate hotswap), but I would like to see a change in groovy to remove them (or make their creation optional) so that I didn't need a private change in groovy-eclipse.

          Stephen - although you will then be able to replace them without seeing the schema changed error, you are unlikely to get the experience you expect.

          Due to call site caching you won't usually pickup any changes you make to the methods that are invoked (you'll need to use something like the agent described here to get these changes picked up: http://andrewclement.blogspot.com/2010/03/groovy-eclipse-groovy-hotswap-support.html )

          Also, due to local variable assignments becoming constants that get set in the static initializer (see GROOVY-4152), you won't see any changes you make to those local variables after a hotswap.

          Show
          Andy Clement added a comment - Groovy-Eclipse no longer produces the timestamp fields (to facilitate hotswap), but I would like to see a change in groovy to remove them (or make their creation optional) so that I didn't need a private change in groovy-eclipse. Stephen - although you will then be able to replace them without seeing the schema changed error, you are unlikely to get the experience you expect. Due to call site caching you won't usually pickup any changes you make to the methods that are invoked (you'll need to use something like the agent described here to get these changes picked up: http://andrewclement.blogspot.com/2010/03/groovy-eclipse-groovy-hotswap-support.html ) Also, due to local variable assignments becoming constants that get set in the static initializer (see GROOVY-4152 ), you won't see any changes you make to those local variables after a hotswap.
          Hide
          Stephen Friedrich added a comment -

          Thanks, I am already a happy user of the IntelliJ IDEA plugin that integrates that agent into the IDE.

          Show
          Stephen Friedrich added a comment - Thanks, I am already a happy user of the IntelliJ IDEA plugin that integrates that agent into the IDE.
          Hide
          blackdrag blackdrag added a comment -

          Since GROOVY-4152 is closed and since an agent was mentioned... is this issue still to be kept open?

          Show
          blackdrag blackdrag added a comment - Since GROOVY-4152 is closed and since an agent was mentioned... is this issue still to be kept open?
          Hide
          Andy Clement added a comment -

          I'd probably still vote for removing the timestamps unless there is a very good reason to keep them.

          My agent was updated to call the method outlined in 4152 (download link in comments here: http://andrewclement.blogspot.com/2010/03/groovy-eclipse-groovy-hotswap-support.html). I think we're going to always have to use something like that (an agent) in order for hotswapping to work reasonably for groovy code.

          Show
          Andy Clement added a comment - I'd probably still vote for removing the timestamps unless there is a very good reason to keep them. My agent was updated to call the method outlined in 4152 (download link in comments here: http://andrewclement.blogspot.com/2010/03/groovy-eclipse-groovy-hotswap-support.html ). I think we're going to always have to use something like that (an agent) in order for hotswapping to work reasonably for groovy code.
          Hide
          blackdrag blackdrag added a comment -

          An solution idea is to let Groovy, defined by an option, for the command line compiler generated classes with equal timestamps. This way hotswapping would have no problem with changed values and changed field names. If eclipse uses the same configuration option. I think it would not limit the eclipse usage.

          The patch I am attaching is not a solution, because it does strangely not pass all tests.

          Show
          blackdrag blackdrag added a comment - An solution idea is to let Groovy, defined by an option, for the command line compiler generated classes with equal timestamps. This way hotswapping would have no problem with changed values and changed field names. If eclipse uses the same configuration option. I think it would not limit the eclipse usage. The patch I am attaching is not a solution, because it does strangely not pass all tests.
          Hide
          Pascal Schumacher added a comment -
          Show
          Pascal Schumacher added a comment - Can this be closed due to GROOVY-6990: Do not add timestamp fields if possible ?
          Hide
          Pascal Schumacher added a comment -

          Cédric removed the generation of timestamp fields with GROOVY-6990: Do not add timestamp fields if possible, so I'm resolving this issue.

          Show
          Pascal Schumacher added a comment - Cédric removed the generation of timestamp fields with GROOVY-6990: Do not add timestamp fields if possible , so I'm resolving this issue.

            People

            • Assignee:
              Cdric Champeau
              Reporter:
              Stephen Friedrich
            • Votes:
              3 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: