Re: Ant 1.7 release
Stefan Bodewig wrote: Say there is a method void doSomething(Object o); in a class inside the Java class library of JDK 1.3 and a new overload void doSomething(String s); was added in JDK 1.4. Any call to doSomething() compiled on JDK 1.4 and above will pick the String signature and fail with a NoSuchMethodError (or IncompatibleClassChange, not sure) when run on JDK 1.3. NSME. There are several examples of changes like this in the JDK Annoyingly, StringBuffer.append(StringBuffer) added in JDK 1.4: StringBuffer b1, b2; // ... b1.append(b2); when compiled against JDK 1.4's rt.jar will yield code which does not run on JDK 1.3 - even though the same code compiles on JDK 1.3 and runs fine on either JDK! You need to write b1.append((Object) b2); or b1.append(b2.toString()); to ensure that the code can be safely compiled and run on either JDK. so you can't be sure it works just bbbe setting the correct target. Correct. Java 5 adds a completely new sort of problems with APIs retrofitted to support generics. Since Comparable is now ComparableT the BigInteger class used to have a method int compareTo(Object) and now has a int compareTo(BigInteger) and no Object signature alternative. Not true. Check javap; both signatures exist in the bytecode. javac -source 1.5 automatically creates the cT(Object) overload which delegates to cT(BI) after a cast. This is necessary for compatibility with 1.4-based client code. -J. -- [EMAIL PROTECTED] x22801 netbeans.org ant.apache.org http://google.com/search?q=e%5E%28pi*i%29%2B1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Kev Jackson wrote: I can build all the ant-* jars except ant-starteam and ant-weblogic I've contacted borland regarding getting access to starteam sdk without having to sign up to some ridiculous trial/download nonsense. [...] Note that we could set up separate source roots containing phony classes and interfaces matching what we need for these kinds of JARs. If you had the real thing available it would use it; else it would compile against the stubs. -J. -- [EMAIL PROTECTED] x22801 netbeans.org ant.apache.org http://google.com/search?q=e%5E%28pi*i%29%2B1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On Sat, 10 Jun 2006, Jesse Glick [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: Java 5 adds a completely new sort of problems with APIs retrofitted to support generics. Since Comparable is now ComparableT the BigInteger class used to have a method int compareTo(Object) and now has a int compareTo(BigInteger) and no Object signature alternative. Not true. Check javap; both signatures exist in the bytecode. OK, so that means that JDK 1.4 compiled code should work in Java 5, but not the other way around. Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Antoine Levy-Lambert wrote: Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? I'm tempted to do it but can't as I am three chapters out from finishing the text of the book, then its all the other stuff with updating it. not only would being the release manager add extra workload, it'd lead to conflict of interest (i'd be against anything inconsistent with the book text, see) I should be able to pull some work time to help with functioanl testing on odd platforms, as its interesting enough to qualify as a bit of research. I have a vmware image of win98 that we could put java1.2 on, and could set up on another vmware system (linux, probably), luntbuild to do continuous integration on the release branch. This would be an interesting exercise in the runup to release. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On 5 Jun 2006, at 03:08, Steve Loughran wrote: Antoine Levy-Lambert wrote: Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? I'm tempted to do it but can't as I am three chapters out from finishing the text of the book, then its all the other stuff with updating it. not only would being the release manager add extra workload, it'd lead to conflict of interest (i'd be against anything inconsistent with the book text, see) I'm starting to feel confident enough to do it except for the potential amount of extra work it may include (hope that nothing happens at work to suddenly bog me down) I should be able to pull some work time to help with functioanl testing on odd platforms, as its interesting enough to qualify as a bit of research. I have a vmware image of win98 that we could put java1.2 on, and could set up on another vmware system (linux, probably), luntbuild to do continuous integration on the release branch. This would be an interesting exercise in the runup to release. Having a vmware image setup for the testing would be a great contribution - I doubt anyone would willingly work on win98 with jdk1.2, so I think your vmware image is the only way that combination will be tested :) thanks Kev -- All governments are in equal measure good and evil. The best ideal is anarchy. - Leo Tolstoy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Kev Jackson wrote: On 1 Jun 2006, at 10:02, Antoine Levy-Lambert wrote: Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? I'd be happy to help, but before I offer myself as the 'release manager', what would I have to do and what are the requirements (system/src/libs etc) before I commit to something which I'd be unable to fulfill Just to note that I am happy to be a fall back if you run into problems Kev. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
A quick update regarding my situation trying to build a test release dist. I can now bootstrap everything except starteam and weblogic. I'm also having a strange issue with Echo not compiling in eclipse (but works fine from command line). ie, I can build all the ant-* jars except ant-starteam and ant-weblogic I've contacted borland regarding getting access to starteam sdk without having to sign up to some ridiculous trial/download nonsense. I'll see if they get back to me. Regarding weblogic, if anyone has a jar file for that I'll probably need it as I doubt bea will supply me with one without again registering. Thanks Kev -- It is through disobedience that progress has been made, through disobedience and through rebellion - Oscar Wilde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Hi, I am going to make these jars available to Kevin. Regards, Antoine Kev Jackson wrote: A quick update regarding my situation trying to build a test release dist. I can now bootstrap everything except starteam and weblogic. I'm also having a strange issue with Echo not compiling in eclipse (but works fine from command line). ie, I can build all the ant-* jars except ant-starteam and ant-weblogic I've contacted borland regarding getting access to starteam sdk without having to sign up to some ridiculous trial/download nonsense. I'll see if they get back to me. Regarding weblogic, if anyone has a jar file for that I'll probably need it as I doubt bea will supply me with one without again registering. Thanks Kev -- It is through disobedience that progress has been made, through disobedience and through rebellion - Oscar Wilde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
We simply can't. Leaving the generics/erasure problem aside, there is a way to ensure you don't compile against methods that are too new, but it is painful: start building with JDK 1.2, compile what hasn't been compiled by building with JDK 1.3, repeat with JDK 1.4 and 1.5. What about cross-compiling against older JDK's by tweaking the bootclasspath/extdirs on Javac's command line? We'd just need to keep older rt.jar files. Anyone tried that before? (I vaguely recall discussions around this). --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Ant 1.7 release
Hi Dominique, I think it is worth a try to build ant with Java 1.5 in one shot, and run tests on 1.2, 1.3, 1.4 and see how it behaves. We could also change ProxyDiagnostics and call the 1.5 APIs which are in there using reflection/introspection. There is also one test class which requires 1.5 to compile I think, so we could change it too. In this case we could build Ant 1.7 in one shot using JDK 1.4 like 1.6. We must find a solution which is simple for the release manager. We also need to automate other steps of the release process such as PGP signing the build artifacts. Regards, Antoine Original-Nachricht Datum: Fri, 2 Jun 2006 09:22:43 -0500 Von: Dominique Devienne [EMAIL PROTECTED] An: Ant Developers List dev@ant.apache.org Betreff: Re: Ant 1.7 release We simply can't. Leaving the generics/erasure problem aside, there is a way to ensure you don't compile against methods that are too new, but it is painful: start building with JDK 1.2, compile what hasn't been compiled by building with JDK 1.3, repeat with JDK 1.4 and 1.5. What about cross-compiling against older JDK's by tweaking the bootclasspath/extdirs on Javac's command line? We'd just need to keep older rt.jar files. Anyone tried that before? (I vaguely recall discussions around this). --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Kev Jackson wrote: On 1 Jun 2006, at 10:02, Antoine Levy-Lambert wrote: Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? I'd be happy to help, but before I offer myself as the 'release manager', what would I have to do and what are the requirements (system/src/libs etc) before I commit to something which I'd be unable to fulfill Thanks Kev -- In vain you tell me that Artificial Government is good, but that I fall out with the Abuse. The Thing! The Thing itself is the Abuse! - Edmund Burke Hello Kev, you need the libs for all the optional tasks described in the section installing ant of the manual. the way to check that you have all the libs is to make a full build and check that all the ant-* jar files have built and are not manifest only. the only lib which belongs to a product without an open source license is weblogic. I can help you regarding this one if you like. Concerning the system, any operating system is good. I built Ant 1.6 under Windows 2000 with a Sun JDK 1.4, all in one go. It looks like that Ant 1.7 has classes which require to be built under JDK 1.5. Not sure if we can build Ant 1.7 under JDK 1.5 also all in one go and still produce jars which can run under 1.2. Concerning the sources, you need the head revision from SVN obviously. Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Ant 1.7 release
Not sure if we can build Ant 1.7 under JDK 1.5 also all in one go and still produce jars which can run under 1.2. Should be possible (but I would do a test after the build...) http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html -target version Generate class files that will work on VMs with the specified version. The default is to generate class files to be compatible with the JDK 5 VM. When the -source 1.4 or lower option is used, the default target is 1.4. The versions supported by javac are: cldc1.0 Generate class files suitable for use on VMs in Connected Limited Device Configuration (CLDC) version 1.0 and later. The compiler generates stack maps making the use of the preverifier unnecessary. 1.1 Generate class files that will run on VMs in JDK 1.1 and later. 1.2 Generate class files that will run on VMs in JDK 1.2 and later, but will not run on 1.1 VMs. 1.3 Generate class files that will run on VMs in JDK 1.3 and later, but will not run on 1.1 or 1.2 VMs. 1.4 Generate class files that will run on VMs in JDK 1.4 and later, but will not run on 1.1, 1.2 or 1.3 VMs. 1.5 Generate class files that are compatible only with JDK 5 VMs. 5 Synonym for 1.5 So a -target 1.2 should work the job - which is the default behaviour in our buildfile (property javac.target). Could only produce troubles if there is use of Java5 language stuff in the JDK5-only classes (e.g. enum, generic). Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Ant 1.7 release
Original-Nachricht Datum: Thu, 1 Jun 2006 16:36:11 +0200 Von: [EMAIL PROTECTED] An: dev@ant.apache.org Betreff: AW: Ant 1.7 release Not sure if we can build Ant 1.7 under JDK 1.5 also all in one go and still produce jars which can run under 1.2. Should be possible (but I would do a test after the build...) So a -target 1.2 should work the job - which is the default behaviour in our buildfile (property javac.target). Could only produce troubles if there is use of Java5 language stuff in the JDK5-only classes (e.g. enum, generic). This is not the case. There is one class called ProxyDiagnostics under util/java15, it uses JDK 1.5 APIs but no generics or enum. So in principle, it should be possible to build Ant 1.7 in one shot under JDK 1.5 Jan Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
Hi all, I'm not confirming yet to be release manager, but I'm preparing a build environment with all libs etc - so I'm edging my hat into the ring you need the libs for all the optional tasks described in the section installing ant of the manual. I have all the latest libs as described in this section, but I still can't get a completely clean compile of the following (from within eclipse) org.apache.tools.ant.taskdefs.optional.XalanLiason org.apache.tools.ant.taskdefs.optional.junit.Xalan1Executor packages: org.apache.tools.ant.taskdefs.optional.ejb org.apache.tools.ant.taskdefs.optional.starteam org.apache.tools.ant.taskdefs.optional.scm the way to check that you have all the libs is to make a full build and check that all the ant-* jar files have built and are not manifest only. the only lib which belongs to a product without an open source license is weblogic. Which tasks require this weblogic.jar? I'm getting quite a clean build here without it and I can't see where it's required. I can help you regarding this one if you like. Concerning the system, any operating system is good. Well my main (currently only personal) machine is an ageing G4 powerbook - OSX 10.4 with Java5 (apple supplied, also have JDK1.3/1.4 available). I have a nice OpenBSD3.9 box in the office here and obviously I have access to WindowsXP sp2 machines too, so I can potentially test a build on 3 envs, although realistically I'd only build it under my main machine as the others are not setup as dev boxes. I built Ant 1.6 under Windows 2000 with a Sun JDK 1.4, all in one go. It looks like that Ant 1.7 has classes which require to be built under JDK 1.5. Well I can certainly build a test release on my main machine if I can get all the required jars - my plan is to create a release-test build/ dist today and upload to my apache space if all goes well. Thanks for the info so far Kev -- I call it the State where everyone, good or bad, is a poison- drinker: the State where universal slow suicide is called - life - Friedrich Nietzsche - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On Thu, 1 Jun 2006, Jan Materne [EMAIL PROTECTED] wrote: Not sure if we can build Ant 1.7 under JDK 1.5 also all in one go and still produce jars which can run under 1.2. Should be possible (but I would do a test after the build...) http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html -target version Generate class files that will work on VMs with the specified version. That's only one part of the problem. The other one is that you might be using methods introduced in later versions of the class library by accident. Say there is a method void doSomething(Object o); in a class inside the Java class library of JDK 1.3 and a new overload void doSomething(String s); was added in JDK 1.4. Any call to doSomething() compiled on JDK 1.4 and above will pick the String signature and fail with a NoSuchMethodError (or IncompatibleClassChange, not sure) when run on JDK 1.3. There are several examples of changes like this in the JDK so you can't be sure it works just bbbe setting the correct target. Java 5 adds a completely new sort of problems with APIs retrofitted to support generics. Since Comparable is now ComparableT the BigInteger class used to have a method int compareTo(Object) and now has a int compareTo(BigInteger) and no Object signature alternative. It is impossible to compile code on JDK 1.5 that uses the method and still works on JDK 1.4 - but the opposite is also true. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On 2 Jun 2006, at 11:16, Stefan Bodewig wrote: Object signature alternative. It is impossible to compile code on JDK 1.5 that uses the method and still works on JDK 1.4 - but the opposite is also true This leaves us in a pickle unless we can guarantee that the every line of code will both compile and run correctly on all JVMs released since 1.2. I'm not sure that we can guarantee to this level of surety. Do you have any advice for building/testing a release to avoid a 'working' release for one jdk which breaks on a different jdk? I was seriously considering the release manager role for 1.7 until this email :) Kev -- In vain you tell me that Artificial Government is good, but that I fall out with the Abuse. The Thing! The Thing itself is the Abuse! - Edmund Burke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On Fri, 2 Jun 2006, Kev Jackson [EMAIL PROTECTED] wrote: On 2 Jun 2006, at 11:16, Stefan Bodewig wrote: Object signature alternative. It is impossible to compile code on JDK 1.5 that uses the method and still works on JDK 1.4 - but the opposite is also true This leaves us in a pickle unless we can guarantee that the every line of code will both compile and run correctly on all JVMs released since 1.2. I'm not sure that we can guarantee to this level of surety. We simply can't. Leaving the generics/erasure problem aside, there is a way to ensure you don't compile against methods that are too new, but it is painful: start building with JDK 1.2, compile what hasn't been compiled by building with JDK 1.3, repeat with JDK 1.4 and 1.5. The pragmatic way is to assume that (1) nobody complained that Ant 1.6.5 didn't work so JDK 1.4 was fine back then and (2) the unit tests cover quite a bit of our code so running the unit test suite with JDK 1.2 is supposed to find trouble spots. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On 2 Jun 2006, at 11:37, Stefan Bodewig wrote: On Fri, 2 Jun 2006, Kev Jackson [EMAIL PROTECTED] wrote: On 2 Jun 2006, at 11:16, Stefan Bodewig wrote: Object signature alternative. It is impossible to compile code on JDK 1.5 that uses the method and still works on JDK 1.4 - but the opposite is also true This leaves us in a pickle unless we can guarantee that the every line of code will both compile and run correctly on all JVMs released since 1.2. I'm not sure that we can guarantee to this level of surety. We simply can't. Leaving the generics/erasure problem aside, there is a way to ensure you don't compile against methods that are too new, but it is painful: start building with JDK 1.2, compile what hasn't been compiled by building with JDK 1.3, repeat with JDK 1.4 and 1.5. Well that's physically impossible for my main machine as there isn't a JDK 1.2 for OSX (earliest is 1.3.1 I believe). The pragmatic way is to assume that (1) nobody complained that Ant 1.6.5 didn't work so JDK 1.4 was fine back then and (2) the unit tests cover quite a bit of our code so running the unit test suite with JDK 1.2 is supposed to find trouble spots. So then the 'solution' (for want of a better description) would be simply to compile with the Java5 jdk, but set the source option as 1.4. Then run the junit tests on a 1.2 vm? As I'm assuming that other people will be testing on various os' and vms, there should be adequate coverage of the vms (but I'm also guessing that there will be a tendency for the vms to be skewed towards the newer versions (1.4 +)) Thanks Kev -- Society in every state is a blessing, but government even in its best state is but a necessary evil; in it's worst state an intolerable one - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant 1.7 release
Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 release
On 1 Jun 2006, at 10:02, Antoine Levy-Lambert wrote: Hi, I am having a look at http://wiki.apache.org/ant/Ant17/Planning We are still on the step finding a release manager Do we have any candidates ? I'd be happy to help, but before I offer myself as the 'release manager', what would I have to do and what are the requirements (system/src/libs etc) before I commit to something which I'd be unable to fulfill Thanks Kev -- In vain you tell me that Artificial Government is good, but that I fall out with the Abuse. The Thing! The Thing itself is the Abuse! - Edmund Burke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
