ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <jesse.gl...@sun.com>
Subject Re: svn commit: r743910 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Javac.java
Date Fri, 13 Feb 2009 17:38:24 GMT
Stefan Bodewig wrote:
>>>            if (!f.getName().equals("package-info.java")) {
>>>                continue;
> 
> should that test better be case-insensitive?

Should it? I don't know. It seemed to work on XP as is. Would someone really specifically
create a file PACKAGE-INFO.JAVA? Windows does at least preserve case, after all.

To Dominique - yes this should be the equivalent of compiling a package-info.java containing
only SOURCE annotations using JDK 5. (JDK 5 javac creates it as an 
ACC_INTERFACE, by the way. JDK 6 adds ACC_ABSTRACT, and -target 6 besides using the newer
bytecode version further adds ACC_SYNTHETIC, but it is otherwise the same.) The 
bytecode is loaded at runtime in case some code requests the java.lang.Package.

It would be good to get feedback on whether this trick works for the cases users have brought
up and introduces no problems. The only drawback I know about is the 
creation of an extra class file, though it is small and this only happens for a package-info.java
with no annotations, which is probably a very small proportion of 
realistic source bases.

Arguably javac itself should be changed to always generate package-info.class, which would
address the issue not just for Ant but also for Maven and any other tools which 
invoke javac for incremental builds. There is no apparent "correct" behavior - JLS 3 talks
briefly about package-info.java but the proposed changes to the JVM spec ch. 4 

for JDK 5 do not seem to mention package-info.class at all.

If the package name includes national characters, these are parsed essentially according to
what File.absolutePath reports. It would be possible to parse 
package-info.java using the declared encoding, but the placing of the package-info.class to
be written would still be at the mercy of the filesystem, so this would not 
seem to be an improvement. javac itself seems to use the declared encoding only for parsing
the text contents of files, still relying on the filesystem to locate and 
store files with possibly non-ASCII paths. For a Unicode-safe environment (such as Linux with
the normal ext3 & LC_ALL=UTF-8) this should not be an issue.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message