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 > http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#JAR%20Manifest. > 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 completely: http://marc.theaimsgroup.com/?l=turbine-maven-dev&m=111870499228817&w=2 > > 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? :) Agreed! 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. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
