commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: maven.compile.source
Date Tue, 14 Jun 2005 07:13:16 GMT
On Tue, 2005-06-14 at 15:24 +1000, Brett Porter wrote:
> Firstly, I still believe if you've got sufficient testing, this isn't 
> really necessary, and this discussion is getting a little carried away. 

The problem is that testing is supposed to be done by the unit tests.
But the unit tests won't pick this up, even when testers download the
source onto a machine with jdk1.3 and run "maven test". 

The only way this would be picked up is if someone downloads a RC jar
file pre-built and then runs it in an application that uses the class
that has the problem. And that can't be relied upon for commons projects
with fairly small user bases.

Having problems that aren't found by the unit tests isn't good.

> There are very limited cases where this is a problem in the current JDKs 
> (theoretically there could be more, but it seems so far that 
> StringBuffer one is the primary one).

Yes, but that one problem is a nasty one. It is not at all unlikely for
code to pass a StringBuffer object to a PrintStream.

> Using compile.executable is going to be sufficient in Maven. 

Yes, I think so too. I can't think of any problems with this approach.
I certainly wouldn't like to move back to Ant builds, and don't see any
reason why that would be necessary as long as maven.compile.executable
is available.

> The other issue is what is generated in the manifest under 
> Build-jdk. Well, that's not even documented in 
> It appears to be something Ant and Maven both set, but the JAR tools 
> doesn't. It should *not* be used as an indication of what JDK it was 
> designed to run on. So I don't see this as a problem.

I agree. It's a nice-to-have but not necessary. The project
documentation should describe what JVM is supported. 

Of course if this suggestion were implemented then this would be solved

> Let's not forget the downsides of using JDK 1.3 to compile the sources. 
> That's now an EOL'd JDK. Someone has already mentioned (I have no idea 
> if it is true), that a newer javac could have less bugs and generate 
> better bytecode even when targetting an older JVM. Not to mention the 
> massive inconvenience it is to maintain a separate JDK, and to swtich to 
> it for certain builds and not others.

True, newer javac versions should be better. That's why I wanted to
avoid compiling on old systems - but I believe the StringBuffer example
proves that it's just not avoidable.

> Wouldn't it be nice if javac could utilise all those @since tags in 
> rt.jar to do this for you? :)


I've been thinking about enhancing clirr to detect exactly these sorts
of issues. The @since tags just aren't reliable enough, but it should be
possible to compare two rt.jar files with clirr and generate a list of
methods added, then flag code which calls an "added" method.

> IMO, I think compile.source|target is good enough, as long as you have 
> enough coverage and someone is testing on the JDKs you intend to target.

Unfortunately I can't agree - for commons projects at least. Maybe for
bigger projects with more thorough release cycles such as Tomcat and
Maven it can be assumed that someone out there will test a binary
download against all the supported JVMs.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message