Community
Participate
Working Groups
3.2 javac X.java -d none produces a none/X.class file, while ecj X.java -d none produces no X.class file at all. This is documented, -d none being used to tell the compiler not to output class files at all. This breaks javac compatibility and raises a continuity issue (since none is a valid directory name, and ecj X.java -d nonz produces nonz/X.java). I would suggest that ecj generate none/X.java when called with '-d none', and that one of the following options be considered to prevent class files output: - '-d:none'; this is in line with what we do for '-warn:none', and javac simply rejects it; this might be a bit confusing on unices though, because ':' is the path separator (anyway, '-d' does not accept multiple paths); - '-d-'; would be quite a bit new in our options catalog... - '-d /dev/null'; two issues with this one: this is only familiar to unices users, and it tweaks a bit the concept anyway (since /dev/null is a file, whereas '-d' demands a directory); - use a brand new option; probably avoid -nod (looks a bit like -nowarn, but quite a bit odd?); we may loose the connection to -d here, but this could be a boon in that the current semantics of '-d none' have nothing to do with directories in some cases; for example, if src/sub1/X.java and src/sub2/Y.java exist: ecj src produces src/sub1/X.class and src/sub2/Y.class whereas ecj src -d none produces nothing; the net effect is that -d none absorbed two files that would otherwise lie into distinct directories.
Do we really want to align javac and ecj?
The continuity issue remains anyway.
Inside an ant script the "-d none" could be nested within a <compilearg> element. No plan to change this as it would break existing users relying on the current behavior. Closing as WONTFIX.
Verified for 3.6M1
