Hello,

is the problem related to the fact that you do the re-build cycle too fast? Are you able to reproduce when you do the re-build slowly, e.g. waiting for example one minute and then rebuild?

Thanks,

David

The problem seems to be that I'm making a change to a source file, and clicking on Debug or Run button (without first saving). I can make the change to source and walk away for 1/2 hour, click on Debug, and I will still get the error.

Aha, I see. This was important info (that it happens when you don't save the file). Thanks.

Thanks for the report!

Could you please try to reproduce the issue with following change in jfx-impl.xml? Thanks.

-> Replace macrodef "deploy-sign" with following:

    <macrodef name="deploy-sign">
        <sequential>
            <echo message="keystore=${javafx.signjar.keystore}" level="verbose"/>
            <echo message="storepass=${javafx.signjar.storepass}" level="verbose"/>
            <echo message="alias=${javafx.signjar.alias}" level="verbose"/>
            <echo message="keypass=${javafx.signjar.keypass}" level="verbose"/>
            <mkdir dir="${jfx.deployment.dir}/signed"/>
            <signjar keystore="${javafx.signjar.keystore}"
                     storepass="${javafx.signjar.storepass}"
                     alias="${javafx.signjar.alias}"
                     keypass="${javafx.signjar.keypass}" destdir="${jfx.deployment.dir}/signed">
                <fileset dir="${jfx.deployment.dir}">
                    <include name="${jfx.deployment.jar}"/>
                    <include name="lib${file.separator}*.jar"/>
                </fileset>
            </signjar>
            <copy todir="${jfx.deployment.dir}" overwrite="true">
                <fileset dir="${jfx.deployment.dir}/signed">
                    <include name="**/*"/>
                </fileset>
            </copy>
            <delete dir="${jfx.deployment.dir}/signed" />
        </sequential>
    </macrodef>

As you requested, I replaced macrodef "deploy-sign".

The change fixed the bug in both RC2 and DEV as far as I can tell!!!

I will check again after some sleep - it's very late in Chicago...

Personally I doubt it will help.
The <jarsign> Ant Task just executes Oracle jarsigner.
If you look at the jarsigner source http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/9f57d2774603/src/share/classes/sun/security/tools/jarsigner/Main.java line 1358 you will find that the jarsigner does the temporary file itself. So the "signed/*jar" moved to original jar has the same problem.

It's important to find out who is holding the File Handle to the jar.

1st) We need to verify that it's NetBeans,this can be done using the MS Process Monitor http://technet.microsoft.com/en-us/sysinternals/bb896645.

2nd) If so, I will write and attach an agent which will print out stack trace of the caller which opened the jar and did not close it.

Here is a modified tools.jar with debug logging https://dl.dropboxusercontent.com/u/79648505/tools.jar.
Roman can you try to reproduce the problem with it? Simply replace the ${JDK_HOME}/lib/tools.jar with it and run the the IDE on this modified JDK.
You should see output like:
Signing file: /Users/tom/NetBeansProjects/JavaFXApplication2/dist/JavaFXApplication2.jar into: /Users/tom/NetBeansProjects/JavaFXApplication2/dist/JavaFXApplication2.jar.sig
in the output window. When it fails it should print what was the reason.
Thanks!

The modified 'deploy-sign' seemed to fix the bug using the basic JavaFX FXML "Hello world" project (timing, perhaps?). I performed the test a few dozen times and it looked good...

But this morning the error returned after I had added Hibernate cfg, reveng, and eight Hibernate pojos to the project. I don't think it has anything to do with Hibernate, per se. Let me know if you need further testing.

In my previous tests, I had NOT enabled Blob signing.

Enable Blob Signing makes the problem go away, so this is the workaround, and another clue.

Anomaly also exists in Windows 8.1, just as sporadic as before.

Anomaly not present in NetBeans 7.4-patch1
Possibly fixed as a side-effect of other changes(?).
Will verify in the publicly-available patch.