groovy

CLONE -Class reloading does not work with multi-level dependencies

Details

  • Type: Sub-task Sub-task
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1-beta-2
  • Fix Version/s: 1.7-beta-1
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows XP, Java 1.4.2_13
  • Testcase included:
    yes
  • Number of attachments :
    0

Description

Java class A calls Groovy script B which uses Groovy class C. Changes to C do not always get picked up by the recompile. See the attached source files.

A: TestReload.java
B: test/Foo.groovy
C: test/Bar.groovy

Issue Links

relates to

Sub-task - The sub-task of the issue GROOVY-2674 GroovyScriptEngine does not properly handle dependencies

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Claudio Rossetto added a comment -

I have the same problem and looking for a solution I've found this issue. I've tried the testcase and it doesn't work. I tried with groovy 1.5.3 and jdk both 1.4.2_12 and jdk 1.5.0_06

Show
Claudio Rossetto added a comment - I have the same problem and looking for a solution I've found this issue. I've tried the testcase and it doesn't work. I tried with groovy 1.5.3 and jdk both 1.4.2_12 and jdk 1.5.0_06
Hide
Permalink
Claudio Rossetto added a comment -

I'm referring issue 2063
http://jira.codehaus.org/browse/GROOVY-2063

Show
Claudio Rossetto added a comment - I'm referring issue 2063 http://jira.codehaus.org/browse/GROOVY-2063
Hide
Permalink
Paul King added a comment -

Please post more details including your classpath and directory structure. Here are my details indicating that it is working for me:

> ls
TestReload.java  test

> javac TestReload.java

> java TestReload
hello world 10
hello world 10
hello world 10
hello world 20                  <-- Bar changed here
hello world 20
hello world 20
hello world 20
hello world 30                  <--- both Foo and Bar changed here
done
hello world 30
done
hello world 30
done
hello world 30
done

> dir test
 Volume in drive C has no label.
 Volume Serial Number is 0CD9-5C93

 Directory of C:\Downloads\groovy.codehaus.org\svntrunk-groovy\groovy-core\src\temp\groovy2063\test

09/02/2008  09:17 AM    <DIR>          .
09/02/2008  09:17 AM    <DIR>          ..
09/02/2008  09:21 AM                81 Bar.groovy
09/02/2008  09:21 AM                59 Foo.groovy
               2 File(s)            140 bytes
               2 Dir(s)  11,239,411,712 bytes free

> set classpath
CLASSPATH=.;C:\Progra~1\Groovy\Groovy-1.5.4\embeddable\groovy-all-1.5.4.jar
Show
Paul King added a comment - Please post more details including your classpath and directory structure. Here are my details indicating that it is working for me: > ls TestReload.java test > javac TestReload.java > java TestReload hello world 10 hello world 10 hello world 10 hello world 20 <-- Bar changed here hello world 20 hello world 20 hello world 20 hello world 30 <--- both Foo and Bar changed here done hello world 30 done hello world 30 done hello world 30 done > dir test Volume in drive C has no label. Volume Serial Number is 0CD9-5C93 Directory of C:\Downloads\groovy.codehaus.org\svntrunk-groovy\groovy-core\src\temp\groovy2063\test 09/02/2008 09:17 AM <DIR> . 09/02/2008 09:17 AM <DIR> .. 09/02/2008 09:21 AM 81 Bar.groovy 09/02/2008 09:21 AM 59 Foo.groovy 2 File(s) 140 bytes 2 Dir(s) 11,239,411,712 bytes free > set classpath CLASSPATH=.;C:\Progra~1\Groovy\Groovy-1.5.4\embeddable\groovy-all-1.5.4.jar
Hide
Permalink
Claudio Rossetto added a comment -

I've tried on a different machine (still Win XP SP2) but with groovy 1.5.4. Here's the log:

d:\java\prj\groovy2063>dir
Il volume nell'unità D è Dati
Numero di serie del volume: AC19-9A14

Directory di d:\java\prj\groovy2063

11/02/2008 11.32 <DIR> .
11/02/2008 11.32 <DIR> ..
11/02/2008 11.28 <DIR> test
15/08/2007 23.53 388 TestReload.java
1 File 388 byte
3 Directory 51.310.034.944 byte disponibili

d:\java\prj\groovy2063>dir test
Il volume nell'unità D è Dati
Numero di serie del volume: AC19-9A14

Directory di d:\java\prj\groovy2063\test

11/02/2008 11.28 <DIR> .
11/02/2008 11.28 <DIR> ..
11/02/2008 11.28 81 Bar.groovy
11/02/2008 11.28 44 Foo.groovy
2 File 125 byte
2 Directory 51.310.034.944 byte disponibili

d:\java\prj\groovy2063>echo %CLASSPATH%
.;c:\java\thirdParty\groovy-1.5.4\embeddable\groovy-all-1.5.4.jar

d:\java\prj\groovy2063>c:\java\jdk1.5.0_09\bin\javac TestReload.java

d:\java\prj\groovy2063>c:\java\jdk1.5.0_09\bin\java TestReload
hello world 10
hello world 10
hello world 10
hello world 10
hello world 20 <-- Bar changed here (OK, taken)
hello world 20
hello world 20
hello world 20
hello world 20 <-- Foo changed here (OK, taken)
done
hello world 20
done
hello world 20
done
hello world 20 <-- Bar changed here (nothing happens!)
done
hello world 20
done
hello world 20
done
... <-- waited some times
hello world 20
done
hello world 20
done
hello world 30 <-- Foo changed here (now the changes of Bar have been taken)
done!
hello world 30
done!
hello world 30
done!

This behaviour is different from what I obtained before opening the issue, when even the first change of Bar was not taken, and I can't figure out why, but I will try again.
Paul, could you please do the test as I did?
Thank you

Show
Claudio Rossetto added a comment - I've tried on a different machine (still Win XP SP2) but with groovy 1.5.4. Here's the log: d:\java\prj\groovy2063>dir Il volume nell'unità D è Dati Numero di serie del volume: AC19-9A14 Directory di d:\java\prj\groovy2063 11/02/2008 11.32 <DIR> . 11/02/2008 11.32 <DIR> .. 11/02/2008 11.28 <DIR> test 15/08/2007 23.53 388 TestReload.java 1 File 388 byte 3 Directory 51.310.034.944 byte disponibili d:\java\prj\groovy2063>dir test Il volume nell'unità D è Dati Numero di serie del volume: AC19-9A14 Directory di d:\java\prj\groovy2063\test 11/02/2008 11.28 <DIR> . 11/02/2008 11.28 <DIR> .. 11/02/2008 11.28 81 Bar.groovy 11/02/2008 11.28 44 Foo.groovy 2 File 125 byte 2 Directory 51.310.034.944 byte disponibili d:\java\prj\groovy2063>echo %CLASSPATH% .;c:\java\thirdParty\groovy-1.5.4\embeddable\groovy-all-1.5.4.jar d:\java\prj\groovy2063>c:\java\jdk1.5.0_09\bin\javac TestReload.java d:\java\prj\groovy2063>c:\java\jdk1.5.0_09\bin\java TestReload hello world 10 hello world 10 hello world 10 hello world 10 hello world 20 <-- Bar changed here (OK, taken) hello world 20 hello world 20 hello world 20 hello world 20 <-- Foo changed here (OK, taken) done hello world 20 done hello world 20 done hello world 20 <-- Bar changed here (nothing happens!) done hello world 20 done hello world 20 done ... <-- waited some times hello world 20 done hello world 20 done hello world 30 <-- Foo changed here (now the changes of Bar have been taken) done! hello world 30 done! hello world 30 done! This behaviour is different from what I obtained before opening the issue, when even the first change of Bar was not taken, and I can't figure out why, but I will try again. Paul, could you please do the test as I did? Thank you
Hide
Permalink
Paul King added a comment -

I will try your example when I get a chance but just for interest, does your second Bar change happen 1 or 2 seconds after the previous change? I seem to recall some discussion about partcular operating systems not having very fine recording/reporting of file timestamps, e.g. you could change it several times in a second and it wouldn't be noticed.

Show
Paul King added a comment - I will try your example when I get a chance but just for interest, does your second Bar change happen 1 or 2 seconds after the previous change? I seem to recall some discussion about partcular operating systems not having very fine recording/reporting of file timestamps, e.g. you could change it several times in a second and it wouldn't be noticed.
Hide
Permalink
Claudio Rossetto added a comment -

I've done some other test and no matter how many seconds pass betweeen the changes of Bar, just the first one is taken. Then any other change of Bar is taken just if Foo is changed also.

Show
Claudio Rossetto added a comment - I've done some other test and no matter how many seconds pass betweeen the changes of Bar, just the first one is taken. Then any other change of Bar is taken just if Foo is changed also.
Hide
Permalink
blackdrag blackdrag added a comment - - edited

there is a general problem here... and that is that GCL does no dependency tracking. I will try to explain:

class Foo {
  Bar b;
}

when you load and initialize the class Foo, then the class Bar is loaded before the initialization of class Foo is completed. The class reloading hooks now into the loadClass calls, which means if Foo is loaded, then Bar is checked and eventually recompiled. But after this Bar is loaded and will not be requested again, unless Foo itself is reloaded. This is true for fields, for super classes and since we cache manually (java does as well before java5 and after that it does automatically) we get the cached value, the old Bar, instead of any new Bar.something else would cause an error. This means if Bar has been changed, then the only way to make this change prominent is by recompiling Foo too, even though it has not been changed.

And this is simply something GCL can not and won't try to do. For things like these we have GroovyScriptEngine and other things. the reloading feature in GCL can be used as part of a general class reloading strategy, but it is not enough to track dependencies and recompile whole sets of classes where most have not changed at all.

So this issue is not exactly a Bug, but a missing feature.. but one that can not be done with GCL alone, since you need more information. you need to find the entry points and track the whole chain of load commands to ensure that all that needs recompilation is recompiled.

Show
blackdrag blackdrag added a comment - - edited there is a general problem here... and that is that GCL does no dependency tracking. I will try to explain: class Foo { Bar b; } when you load and initialize the class Foo, then the class Bar is loaded before the initialization of class Foo is completed. The class reloading hooks now into the loadClass calls, which means if Foo is loaded, then Bar is checked and eventually recompiled. But after this Bar is loaded and will not be requested again, unless Foo itself is reloaded. This is true for fields, for super classes and since we cache manually (java does as well before java5 and after that it does automatically) we get the cached value, the old Bar, instead of any new Bar.something else would cause an error. This means if Bar has been changed, then the only way to make this change prominent is by recompiling Foo too, even though it has not been changed. And this is simply something GCL can not and won't try to do. For things like these we have GroovyScriptEngine and other things. the reloading feature in GCL can be used as part of a general class reloading strategy, but it is not enough to track dependencies and recompile whole sets of classes where most have not changed at all. So this issue is not exactly a Bug, but a missing feature.. but one that can not be done with GCL alone, since you need more information. you need to find the entry points and track the whole chain of load commands to ensure that all that needs recompilation is recompiled.
Hide
Permalink
David S added a comment -

Yeah but GroovyScriptEngine doesn't reload dependents either.

Show
David S added a comment - Yeah but GroovyScriptEngine doesn't reload dependents either.
Hide
Permalink
blackdrag blackdrag added a comment -

the new GroovyScriptEngine now looks after transitive dependencies, so this issue here will no longer happen

Show
blackdrag blackdrag added a comment - the new GroovyScriptEngine now looks after transitive dependencies, so this issue here will no longer happen

People

  • Assignee:
    blackdrag blackdrag
    Reporter:
    Claudio Rossetto
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: