#1 would not be backwardly compatible ! I am not too sure about #2. In the ant build file we had to deal with this issue for a while, it may be as well to get other project 1.5 aware. Also new projects would have to set things so that 1.5 (and higher) would work.
Peter On 3/23/06, Steve Loughran <[EMAIL PROTECTED]> wrote: > > Dominique Devienne wrote: > >> Specifically, it appears to be defaulting to source=1.5 > >> [...] > >> I checked out the source in CVS; they are not saying source="1.5"; they > >> are not saying anything about the source version. Yet javac has > switched > >> to java1.5. This is breaking backwards compatibility for builds. > > > > It was always my understanding that <javac>, just like SUN's compiler, > > always defaults to the current Java source level for the JDK. > > > > Wrong assumption? The fact that the Java language evolves, making > > older sources incompatible with it, is not really pointing to a BC > > issue for <javac> IMHO. > > > > Gump moving to 1.5 has got to have consequences, it can't be > > transparent, when new keywords and classes are added to the platform > > (even new classes can break the source, when it's using import foo.*). > > --DD > > Gump didnt want to move to java1.5; junit forced their hand. Now old > code, code that built and worked happily, has broken. The usual cause is > that enum is now reserved. > > Now, when <rmic>'s dependency logic broke moving up to 1.5, I fixed it > by forcing the proxy generation to be downwards compatible, so > everything behaved as on a 1.3 or 1.4 box. > > Here are some options > (1) tweak javac to build at 1.4 or below unless stated. > > (2) provide a back door switch to let gump control the jvm version. that > way old code can be built under a new compiler. > > #2 has appeal. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
