Bug 39183 - Make source attribute of javac mandatory
Make source attribute of javac mandatory
Status: RESOLVED FIXED
Product: Ant
Classification: Unclassified
Component: Core
1.6.5
Other other
: P2 normal (vote)
: 1.7.0
Assigned To: Ant Notifications List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-04-02 18:39 UTC by Mathias Hasselmann
Modified: 2008-02-22 12:18 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathias Hasselmann 2006-04-02 18:39:29 UTC
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.
Comment 1 Steve Loughran 2006-04-02 20:47:05 UTC
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
Comment 2 Mathias Hasselmann 2006-04-03 08:35:50 UTC
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".
Comment 3 Matt Benson 2006-04-03 15:22:56 UTC
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.
Comment 4 Alexey Solofnenko 2006-04-03 15:34:55 UTC
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.
Comment 5 Steve Loughran 2006-04-03 21:24:03 UTC
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
Comment 6 Alexey Solofnenko 2006-04-03 21:43:02 UTC
>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>).
Comment 7 Stefan Bodewig 2006-04-11 19:20:23 UTC
ant.build.javac.source and ant.build.javac.target are now there
Comment 8 Jesse Glick 2006-04-18 23:26:54 UTC
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.
Comment 9 Matt Benson 2006-04-19 13:57:09 UTC
(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.  ;)