On Mon, 03 Dec 2001 Diane Holt wrote : > > > > +1 to include -legacy flag > > > > +1 on throwing BuildException when -legacy is not > used. > > How does this move us toward being able to remove > deprecated stuff?
It promotes deprecated 'warnings' to DeprecatedException. The APIs will still exist, but will fail at runtime. For an example of where such tactics is being used, try using java.lang.System.getenv(String) in Java 1.0, 1.1..1.4. javac provides a warning at compile time. At runtime, getenv fails. Throwing an exception at runtime is practically the same as removing it, but it has certain advantages: 1) When user uses build.xml with say Javadoc2, Ant *recognizes* it as a deprecated task before throwing an 'unsupported' exception. It does not simply say it doesn't know what this task is. Politically, we don't forget out histories ;-) 2) It guides the user to use alternative non-deprecated APIs/tasks - say for example, user downloads Ant 1.5 and the site also has Ant 1.5 in its docs. User is supplied with a 'legacy' build.xml. How does the user know whether Javadoc2 is a deprecated task or some custom task somebody wrote? Summarizing, introduction of BuildException upon use of deprecated tasks *is* practically removal of the feature. The -legacy switch is just for lazy bones ;-) Magesh -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
