What we do is that we compile against the runtime jars (rt.jar and
friends) of the target Java version, using bootclasspath. You can
include those jars into version control with the project, or for
example as an Ivy dependency.

One minor potential problem that remains is that javac 1.6+ allows
@Override in more places than javac 1.5 does, even with -source 1.5.
(This seems to have been a deliberate decision on the grounds that
javac 1.5 is considered somewhat broken with regard to @Override.)
As a consequence, some code may compile that wouldn't compile under
JDK 1.5. Note that this is purely a compile-time issue, and only a
problem when source code compatibility with JDK 1.5 is a requirement.
It doesn't cause any problems at runtime.

-- Niklas Matthies


On Tue 2011-02-15 at 18:32h, Toomey, Kevin H (CTO Org) wrote on user:
> Might not be the same but I remember one where a new BigDecimal(int i)
> caused a problem. That constructor doesn't exist in JDK 1.4 but the
> compiler would convert it to BigDecimal(double d) under the covers.
> 
> Java 1.6 does allow the BigDecimal(int i) so it left it alone and
> compiled it as is. 
> 
> The 1.4 JRE was not pleased.
> 
> It's always something....
> 
> Thanks,
> Kevin 
> 
> -----Original Message-----
> From: Scot P. Floess [mailto:sflo...@nc.rr.com] 
> Sent: Tuesday, February 15, 2011 5:00 PM
> To: Ant Users List
> Subject: RE: Dual Java Compilers/Replacement for antcontrib
> 
> 
> 
> > Here's an altogether different approach, but if your developers' goal 
> > is to control what version of byte code is created, have them utilize 
> > the -source and -target attributes of the <javac> task.  I have my 
> > developers do that and it allows me to use the latest JDK for all 
> > builds (400+ development streams) while they're able to build 
> > components and applications executing in JVMs from 1.4 --> 1.6
> >
> 
> Its been awhile...but if memory serves, I had a situation at work where
> we were using a newer JDK and compiling for an older VM.  Some method
> that existed in the new JDK didn't exist in the old - and targeting for
> the older VM didn't complain about the method not being there.
> Honestly, I cannot rememebr the exact scenario - its been over a year.
> 
> However, just be aware in case that happens to you :)
> 
> 
> ---
> Scot P. Floess
> 
> 
> RHCT  (Certificate Number 605010084735240)
> 
> Chief Architect FlossWare  http://sourceforge.net/projects/flossware
>                             http://flossware.sourceforge.net
>                             https://github.com/organizations/FlossWare
> 
> Chief Architect JPlate     http://sourceforge.net/projects/jplate
> Chief Architect JavaPIM    http://sourceforge.net/projects/javapim
> Chief Architect Keros      http://sourceforge.net/projects/keros
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> For additional commands, e-mail: user-h...@ant.apache.org
> 
> ************************************************************
> This communication, including attachments, is for the exclusive use of 
> addressee and may contain proprietary, confidential and/or privileged 
> information.  If you are not the intended recipient, any use, copying, 
> disclosure, dissemination or distribution is strictly prohibited.  If you are 
> not the intended recipient, please notify the sender immediately by return 
> e-mail, delete this communication and destroy all copies.
> ************************************************************
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> For additional commands, e-mail: user-h...@ant.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org

Reply via email to