Description Maxime Daniel 2007-02-01 01:55:45 EST

Fup on bug 161996. The argument is that some users want to have ecj behave like javac when given javac compatible options. This is not always the case as of today  (see an example in bug 161996).
We need to drive an extensive review of what this could mean.

I would contend that different levels of javac behave differently, which may drive a need for a nuance here. Minimum feature would be to declare/document the compatibility with a given, well-chosen level of javac.

The latest idea that came up to my mind about the way to tell ecj to consider the command line to be in javac compatibility mode without adding an option (which would defeat the whole purpose of the feature by definition) would be to leverage the command name itself. Say have ecj be named ecj_compat or any other distinct name when it should behave in compatibility mode. This is superior to alternatives that involve black magic behind the scenes (environment variables, .rc files) in that it does not have to be global at any time (even if such techniques remain valuable to provide defaults and could be considered separately). And changing the name is already something people do when using ecj instead of javac. (Note: to remain on the safe side, ecj should be capable to associate its being called as javac to javac compatibility mode - this mapping possibly overriden at the environment level for those who would want to have ecj called as javac and behaving as ecj.)