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

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

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

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

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

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.

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.

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.

Yeah but GroovyScriptEngine doesn't reload dependents either.

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