Stefan Bodewig wrote:
On Thu, 16 Feb 2006, Jeffrey E. Care <[EMAIL PROTECTED]> wrote:
several examples of this in the Java class library.
There are other ways to accomplish this (and Ant itself makes use of
some of those techniques) but you can't rely on those being 100%
safe.
Such as?
>> > There are other ways to accomplish this (and Ant itself
>makes use of
>> > some of those techniques) but you can't rely on those being 100%
>> > safe.
>>
>> Such as? I'm really curious.
>
>The usual tricks, like checking for the existence of a class
>known to be introduced in a given JRE
> > There are other ways to accomplish this (and Ant itself makes use of
> > some of those techniques) but you can't rely on those being 100%
> > safe.
>
> Such as? I'm really curious.
The usual tricks, like checking for the existence of a class known to be
introduced in a given JRE version, lo
On Thu, 16 Feb 2006, Jeffrey E. Care <[EMAIL PROTECTED]> wrote:
> The only 100% safe way I know of to make sure you aren't using
> improper APIs is to make sure you are compiling against the class
> library from the *lowest common denominator* JDK version you need to
> support.
This is what happe
Your assumptions are incorrect; @target & @source have to do with language
features and class file formats, not APIs.
The only 100% safe way I know of to make sure you aren't using improper
APIs is to make sure you are compiling against the class library from the
*lowest common denominator* JDK
It was my understanding that the target/source attributes in the javac
task forced the compiled classes to be compatible with old versions.
What I also assumed was that it wouldn't let me compile something if I
was using an API that was newer than the 'target' attribute. For
example, my task
