Compilation error

I noticed this problem on linux and create a fix for it that I expcetd will work on windows too.
It looks like it doesn't work on windows.
I removed the unicode escape from the source.
Can you try it now to so if it works?

First I did a "build clean", then a "build cd-x86-lite". Now I get the following error:

-----------------

native2ascii:
[native2ascii] Converting 1 file from C:\jnode\builder\build\src\org\jnode\jnasm
\preprocessor\gen to C:\jnode\builder\build\src\org\jnode\jnasm\preprocessor\gen

[move] Moving 1 file to C:\jnode\builder\build\src\org\jnode\jnasm\preproce
ssor\gen

BUILD FAILED
C:\jnode\all\build.xml:226: The following error occurred while executing this li
ne:
C:\jnode\all\lib\jnode.xml:69: The following error occurred while executing this
line:
C:\jnode\builder\build.xml:80: Unable to remove existing file C:\jnode\builder\b
uild\src\org\jnode\jnasm\preprocessor\gen\JNAsmPP.java

Total time: 5 minutes 44 seconds

"Unable to remove existing file C:\jnode\builder\b
uild\src\org\jnode\jnasm\preprocessor\gen\JNAsmPP.java"

Unable to remove existing file?
I wonder why... what is not OK for windows there?

Levente, that file is a generated file, right ?

Windows (at least until Windows XP. I don't know for Vista) is known to have problems with deleting files that are being used (it might also be due to file handling not properly closed ...).
Ask to the apache tomcat guys, that's a problem they know (I have seen that somewhere on their mailing lists)

So, I think that file is currently being used by your windows : close all applications, eventually close your session or if it's still doesn't work reboot windows. Ultimately, use Linux

I think i am close to a solution.

JNode ANT task didn't close file. Please update trunk.

Changes to file: \jnode\builder\src\builder\org\jnode\ant\taskdefs\Native2AsciiTask.java

    private boolean containsNonAscii(File file) throws IOException {
        final FileInputStream is = new FileInputStream(file);
        try {
            final BufferedInputStream bis = new BufferedInputStream(is);
            int v;
            while ((v = bis.read()) >= 0) {
                if ((v & 0xFF) > 128) {
			is.close();
			return true;
                }
            }
            is.close();
            return false;
        } finally {
            is.close();
        }
    }

Are you sure this is the problem?
The finally at the end should close the stream in all cases:
....
} finally {
is.close();
}

Yes I am sure. I don't think finally is executed - it make sense. Calling return is a normal executing path therefore you should clean up on your own.
A better way is to call return at the end of the method, that way finally will always get executed.

public class Test {
  public static int test() {
    try {
      return 1;
    } finally {
      System.out.println("2");
      //return 3;
    }
  }
  public static void main(String[] args) {
    System.out.println(test());
  }
}

This prints "2,1" for sun jdk 1.6 or "2,3" without the comment.

Yes, your right. So this is not the issue. Strange error.

What Levente and Peter said above corresponds to my understanding of try { ... } finally { ... }.

A 'finally' block will be executed for all execution paths that leave the statement, including:

• by completing the last statement in the 'try' block,
• by exiting the 'try' block via a 'return', 'break' or 'continue',
• via an exception thrown by the 'try' block, or propagating from something called by the 'try' block,
• by completing the last statement of a 'catch' block,
• by exiting a 'catch' block via a 'return', 'break' or 'continue', or
• via an exception thrown by a 'catch' block, or propagating from something called by a 'catch' block.

If you don't believe me/us, read what the Java Language Specification says.

AFAIK, the only cases where a 'finally' block is not executed are when execution doesn't reach it due to:

1. to an infinite loop within the 'try' block or a 'catch' block,
2. a deadlock or similar within the 'try' block or a 'catch' block,
3. the application calling 'java.lang.System.exit()', or
4. the JVM being terminated by an external event or agent.

(Actually with 3) and 4) there might be obscure scenarios where 'finally' block does get to execute; e.g. involving JVM shutdown hooks calling Thread.kill().)

I think we can mark this as fixed now ...

The method called in \jnode\builder\src\builder\org\jnode\ant\taskdefs\Native2AsciiTask.java is depricated:

getProject().copyFile(tmp, file);

Instead something like this could be used:

------
Project p = getProject();
org.apache.tools.ant.taskdefs.Copy ct = new org.apache.tools.ant.taskdefs.Copy();
ct.setProject(p);
ct.setFile(file);
ct.setTofile(tmp);
ct.execute();
------

I don't know if that is the cause of the strange error but it's proberly a good idea to use something else than the depricated method.

Bluebit: please do the work to test your suggested fix and see if it fixes the strange problem. If it does (or even if it does not) please create a proper patch and submit it.

Marking 'fixed' as per earlier comments.

Automatically closed -- issue fixed for two weeks with no activity.