ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cortexebusiness.com.au>
Subject RE: Ant Incorrectly Determining Java Version
Date Wed, 26 Sep 2001 02:51:49 GMT
Before we go into the tests, Can you please run Ant with the -debug flag.
Have a look through this for anything interesting. If the relevant stuff is
not too big, you can zip it and send to the list. If it is a bit larger,
please open up a bug report on bugzilla and attach the output to the bug
report.

Conor


> -----Original Message-----
> From: Will Wallace [mailto:willscottwallace@yahoo.com]
> Sent: Wednesday, 26 September 2001 12:40 PM
> To: ant-dev@jakarta.apache.org
> Subject: Ant Incorrectly Determining Java Version
>
>
> I'm running into problems compiling a project using
> JDK1.3.1 on Debian Linux and I think its because Ant
> doesn't properly recognize the Java version.  Here's
> the error message (and the source code that generated
> it is below):
>
> "compile:
>     [javac] Modern compiler is not available - using
> classic compiler
>     [javac] Compiling 342 source files to
> /home/dev/jakarta-jetspeed/bin/classes
>
> BUILD FAILED
>
> /home/dev/jakarta-jetspeed/build/build.xml:175: Cannot
> use classic compiler, as it is not available A common
> solution is to set the environment variable JAVA_HOME
> to your jdk directory."
>
> And BTW, yes I did set JAVA_HOME to no avail.
>
> Okay, so I've traced this back to the Project.java
> file and here's where it decides which Java version
> you've got.  One question I have is why does it do so
> in such a round about way -- why not just go with the
> java.version property?
>
> "static {
>
>         // Determine the Java version by looking at
> available classes
>         // java.lang.StrictMath was introduced in JDK
> 1.3
>         // java.lang.ThreadLocal was introduced in JDK
> 1.2
>         // java.lang.Void was introduced in JDK 1.1
>         // Count up version until a
> NoClassDefFoundError ends the try
>
>         try {
>             javaVersion = JAVA_1_0;
>             Class.forName("java.lang.Void");
>             javaVersion = JAVA_1_1;
>             Class.forName("java.lang.ThreadLocal");
>             javaVersion = JAVA_1_2;
>             Class.forName("java.lang.StrictMath");
>             javaVersion = JAVA_1_3;
>             Class.forName("java.lang.CharSequence");
>             javaVersion = JAVA_1_4;
>         } catch (ClassNotFoundException cnfe) {
>             // swallow as we've hit the max class
> version that
>             // we have
>         }"
>
> Okay, now in CompilerAdapterFactory it uses this
> information, but it does yet another wierd check.
> Again I'm wondering why not just accept the value of
> java.version?
>
> " if ( compilerType.equalsIgnoreCase("modern") ||
>
> compilerType.equalsIgnoreCase("javac1.3") ||
>
> compilerType.equalsIgnoreCase("javac1.4")) {
>                 // does the modern compiler exist?
>                 try {
>
> Class.forName("com.sun.tools.javac.Main");
>                 } catch (ClassNotFoundException cnfe)
> {
>                     task.log("Modern compiler is not
> available - using "
>                             + "classic compiler",
> Project.MSG_WARN);
>                     return new Javac12();
>                 }
>                 return new Javac13();"
>
> Can someone provide insight as to why these checks are
> so convoluted?  I imagine there's a logical reason, I
> just don't know the history.  Does anyone know how I
> can overcome this problem?
>
> Will
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo!
> Messenger. http://im.yahoo.com
>


Mime
View raw message