[BUG] QtJambi 6.6.0 seems to not update cache of Java resources accessible via Qt?

[sowelipililimute]

Describe the bug
When a Java resource changes (i.e. editing a QML file and recompiling/restarting the app), Qt's access to that resource seems to be stuck on the old version.

To Reproduce

1. Create a simple app to display a QML hello world
2. Compile/run it
3. See that it says "hello world"
4. Change the QML file to say "bye world"
5. Compile/run it
6. It still says "hello world"

Expected behavior
The files that Qt is seeing should update when the files in the jar change instead of seemingly being cached the first time a file from that resource path is accessed

System (please complete the following information):

• OS: Fedora 38
• Java version: OpenJDK 21 (2023-09-19)
• QtJambi version: 6.6.0
• Qt version: 6.6.0

Additional context
Being built and run w/ sbt, but this seems to be irrelevant as manual inspection of the jars being ran shows they are being updated as expected.

[omix]

Qml caches contents to directory given by QStandardPaths.writableLocation(QStandardPaths.StandardLocation.CacheLocation) + "/qmlcache".
As a workaround you could delete the directory content at program start. Does this resolve the issue?
I guess there's something wrong with file time property.

[omix]

I am not able to reproduce the issue on Windows.

[omix]

Could you please an outprint of the QML file's time attributes for both runtimes, hello and bye:

QFileInfo file = new QFileInfo(":/issue184/main.qml");
for(QFileDevice.FileTime t : QFileDevice.FileTime.values()) {
    System.out.println(t+": "+file.fileTime(t));
}

As I am not able to reproduce it on my main development environment this information could help me to exclude or confirm my attempts.
Thanks.

[sowelipililimute]

sbt:shades> [info] running (fork) Shades.Main 
[info] FileAccessTime Fri Jan 1 00:00:00 2010
[info] FileBirthTime Fri Jan 1 00:00:00 2010
[info] FileMetadataChangeTime Fri Jan 1 00:00:00 2010
[info] FileModificationTime Fri Jan 1 00:00:00 2010

Turns out that this is an issue wrt sbt resetting the timestamps to Jan 2010.