Hi Andrew,
On Sun, 2006-02-19 at 11:03 -0500, Andrew Overholt wrote:
> In the meantime, however, I found an issue with libcj and ant.java.version.
>
> ant.java.version is the property that the Eclipse uses to determine what
> JVM/JDK is being used. It is implemented like this [1]:
>
> Class.forName("java.lang.Readable");
> javaVersion = JAVA_1_5;
Ugh, that is kind of a lame test. It is a feature test that is used to
set a global version. sigh. If you need a global version checking
System.getProperty("java.version") seems more appropriate.
We have the Readable, Closeable, Flushable interfaces since they don't
require any new 1.5 language or runtime features. If you would test like
the above a much better marker class would be java.lang.Enum since that
does need 1.5 language and runtime features being present.
I would propose either pushing a version check based on
System.getProperty("java.version"), or if upstream insists on class
loading based checks to change Readable to Enum.
> Is there a way we can get around this without patching ant or removing the
> 1.5 class library stuff from libgcj?
There might be an evil hack possible if you can force loading the ant
JavaEnvUtil class with a custom ClassLoader that overrides loadClass()
to explicitly disallow loading java.lang.Readable. That is extremely
ugly though and depends on finding the correct point in your application
that loads this specific ant task. It seems ant.java.version is set way
too early for such a hack to work easily though.
Does your application really need the ${ant.java.version}?
Can't it use ${java.version}?
Cheers,
Mark
Attachment:
signature.asc
Description: This is a digitally signed message part
