0

I have an ANT task defined like so:

<javac source="1.5" target="1.5" srcdir="${src.dir}" destdir="${classes.dir}" deprecation="on" debug="on" classpathref="classpath" fork="true" memoryMaximumSize="512m" encoding="UTF-8">
        <include name="${app.directory}/**/*.java"/>
    </javac>

This works fine, but when I have classes with special characters in their names it gives me the following error:

[iosession]     Compiling 131 source files to /C24/PUB/io-stds/trunk/standards/GSIT/build/test/deployment/build/classes
[iosession]     javac: file not found: /C24/PUB/io-stds/trunk/standards/GSIT/build/test/deployment/src/java/biz/c24/io/minos/AléaChiffréClass.java
[iosession]     Usage: javac <options> <source files>
[iosession]     use -help for a list of possible options
[iosession] Target compile finished
[iosession] 
[iosession] Building unsuccessful 2 seconds

When I remove the "fork=true" it works, but then it ignores the "memoryMaximumSize" setting. I also tried the nested approach, but to no avail.

Any ideas?

Mossie
  • 66
  • 5
  • The problem here is that with fork=true, the file names need to get passed through the operating system to the called `javac` process as command line arguments. This means one conversion from strings to bytes in the ant VM, and another one in the javac VM. I suppose that these two are somehow using different encodings. (Both of them are using the default encoding, and have no way of indicating the encoding, though.) I don't really have a solution here, though. – Paŭlo Ebermann Oct 14 '11 at 15:11
  • I have no idea about how this happens, but as Ebermann said, it's the encoding problem with two java process. So I think you can try this: 1. use exec task with the nested to execute the javac. 2. Also you can try to write a custom task, using ProcessBuilder to call javac, which also allows to set the env. ||||| I have the experience with the second method when writing a svninfo task calling the native svn client. – Dante WWWW Oct 17 '11 at 07:32

2 Answers2

1

It's perhaps not the answer you expect but my advice would be to remove all non-ascii letters from the names of methods and classes. I'm French-speaking too, and I've never seen any company, even in France and using French as its development language, accept accented letters in class names and methods. It's just not good practice, simply because it would be very hard for a non French developer, without accents on his keyboard, to use these classes and methods.

If you use a good IDE, it should allow you to refactor your code easily.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • I wish I could, but the Class gets generated by an application, so the name can't be changed :-) – Mossie Oct 14 '11 at 13:44
  • @Ed Staub - Our own Java application. – Mossie Oct 14 '11 at 13:59
  • Then change this Java application. – JB Nizet Oct 14 '11 at 14:04
  • @JB Nizet - Can't do that either, since the Classnames are specified by users. Special characters are allowed in Java, so it should work. – Mossie Oct 14 '11 at 14:17
  • Just because it is allowed doesn't mean it's a good idea. I would still change the application to forbid such class names. It's just a validation UI problem. Anyway, if it works without fork and you need more memory, have you tried just increasing the memory of the JVM used to run Ant? – JB Nizet Oct 14 '11 at 14:20
  • I suppose that providing more memory a different way might do the trick. I have reported a [bug](https://issues.apache.org/bugzilla/show_bug.cgi?id=52030) with apache, so will see what they say. – Mossie Oct 14 '11 at 14:41
0

Apache did confirm that the encoding attribute only applies to the file contents and not file names. I reverted back to using fork only when needed and kept encoding="UTF-8".

Mossie
  • 66
  • 5