Everytime Sun introduces new Java keywords - let it be "assert" in Java 1.4 or "enum" in Java 1.5 - there are zillions of Java projects stopping to compile. To address that issue Sun was that enlightened to give javac this nice "-source" command line switch. Unfortunatly it is not use that often. It is my strong believe that the transition to new Java versions would be much more pleasant, if maintainers of Java projects would be forced to explicitly express the Java dialect the project targets. To start embracing this good practice, Ant could make the source attribute of it's javac task mandatory. Surly this will put some burden on the shoulders of few project maintainers whoms projects to not compile anymore and who have to incooperate build.xml patches adding this tiny switch. But in return it takes the burden from much the larger group of users of those packages, who fiddle with the build.xml files manually. If you don't see this problem as an issue, just as a random maintainer of an OS distributing prebuilt Java packages.
I know this is a problem with building third party libraries, and I'm not happy with it either. But we cannot just switch on target= and source= things without breaking so many build files out there it wouldnt be funny. So this leaves us two other options 1. select a fixed language version (say java1.4), which is the default unless something else is asked for. 2. add a back door property like ant._internal.javac.source which can be set to a source to fix those build files that dont otherwise build on java1.5
Guess this ant._internal.javac.source property could work to get arround all those broken packages. As I understand this breaking apps issue: What about issuing a warning, if "source" is not set? Don't care that much about "target" as it is implied by "source".
The source attribute is documented with this (bolded) warning: Note that the default value depends on the JVM that is running Ant. We highly recommend to always specify this attribute. If users choose to ignore this warning in the documentation, I don't know that I can see the point of noising up builds in addition. :| I would be -0 on such a runtime warning.
A simple <presetdef> or <presetdef> with <import> (if you do not want to modify original build file) can solve this issue. All conversation about internal secret properties is about emulating <presetdef> with property files. I think it is useful - it would be externally configurable, but a solution is already available.
aah, but <presetdef> changes the type of teh return of project.createTask("javac"), which could toast any custom task that assumed it was castable. A property would let us fix everything on gump that is broken
>aah, but <presetdef> changes the type of teh return of >project.createTask("javac"), which could toast any custom task that assumed it >was castable. It is <presetdef> problem (or feature) that can be fixed. There is no reason for <presetdef> to change task implementation class, instead project.createTask() should set default values (maybe set by external properties or <presetdef>).
ant.build.javac.source and ant.build.javac.target are now there
I agree with Mathias on this. Wouldn't it be preferable to make the source attrs semimandatory, warning if unset? Maybe you will get a lot of warnings from Gump - good. To me that just means that we are informing a lot of projects built on Gump that they forgot to do something important - set this attr, according to the actual source level of the project being built. Using "1.4" for a 1.5 project is obviously impossible, and using "1.5" for a 1.4 project is in some cases possible but not reliably - it may turn reasonably common code like Enumeration enum = loader.getResources("foo.properties"); from a warning into an error. To Matt re. adding verbosity to builds for users who "choose to ignore the documentation's boldface warning" - I doubt most people ever read the manual very carefully (or at all). They see someone using <javac> somewhere, they copy it, it seems to work, done. I can't imagine any case where you would intentionally omit the 'source' attr except out of pure laziness.
(In reply to comment #8) > To Matt re. adding verbosity to builds for users who "choose to ignore the > documentation's boldface warning" - I doubt most people ever read the manual > very carefully (or at all). They see someone using <javac> somewhere, they copy > it, it seems to work, done. I can't imagine any case where you would > intentionally omit the 'source' attr except out of pure laziness. Guilty. ;)