Problem building web application on Linux using java 5

[ramprasad madathil]

Hi,

I have a web application that's compiled and deployed by an ant build
The code has java 1.5 api calls and a couple of enhanced for-loops in some classes. As I said, it compiles and works correctly on my machine (running ona Windows platform).
However when the same code is deployed on the client machine running on linux, things begin to go haywire.

For one, the java 1.5 specific code doesnt compile at all. An error was thrown for the enhanced for loops and some other 1.5 specific apis.
I ran the command java -version, which java and which javac and all pointed to version java version 5.

Is there an ant setting somewhere that I have missed ?

The following is the ant javac command

<path id="project.classpath">
        <fileset dir="${TOMCAT_HOME}/common/lib">
        <include name = "*.jar"/>
        </fileset>       
        <fileset dir="${APP_HOME}/WEB-INF/lib">
        <include name = "*.jar"/>
        </fileset>
</path>
 
<target name="compile">
<javac srcdir="${SRC}" destdir="${APP_HOME}/WEB-INF/classes">
   <classpath refid="project.classpath"/>
   </javac>
</target>

Short of ideas and pretty desperate, I then changed my code to make it 1.4 compatible as it was throwing compile errors at 1.5 features.
Again the code compiled and worked on my machine.
And again I got bizzare compilation errors running the build on the linux box.

Here's the relevant part .......

I have an interface

package com.wex.healthcheck.task;
//import declarations

public interface ParserTask extends Runnable {
    /**
     * Parse functionality which will be implemented by concrete ParserTask classes. 
     * The implementation would vary upon the kind of log file that the class is assigned to parse. 
     * @param file
     * @throws HealthCheckException
     */
    public void parse(File file) throws HealthCheckException;
    //other methods
}

And an abstract class implementing it

package com.wex.healthcheck.task;
//import declarations

public abstract class AbstractParserTask implements ParserTask {

    //other code
    
    public void run() {
        //other code
        parse(newFile);//call subclass specific implementation
        //.........
    }
}

And a concrete subclass

package com.wex.healthcheck.task;
//import declarations

public class AuthExtractParser extends AbstractParserTask {
    
    //implement the abstract method
    public void parse(File file) throws HealthCheckException{...implementation.......}
    //other methods

}

Here's the output

 [javac] Compiling 39 source files to /usr/local/src/healthcheck-build/healthcheck/WEB-INF/classes
    [javac] /usr/local/src/healthcheck-build/healthcheck/src/com/wex/healthcheck/task/AuthExtractParser.java:34: error: Invalid checked exception class `com.wex.healthcheck.exception.HealthCheckException' in `throws' clause. The exception must be a subclass of an exception thrown by `com.wex.healthcheck.task.AbstractParserTask.parse(java.io.File)' from class `com.wex.healthcheck.task.AbstractParserTask'.
    [javac]        public void parse(File file) throws HealthCheckException {
    [javac]                    ^
             ^
    [javac] 1 error

Basically it was not allowing me to implement the abstract method (from the interface) with the exception signature.
I then, went into the abstract class and added the abstract method from the interface and voila, it worked.

Changed abstract class

package com.wex.healthcheck.task;
//import declarations

public abstract class AbstractParserTask implements ParserTask {

    //other code
    public abstract void parse(File file) throws HealthCheckException;
    
    public void run() {
        //other code
        parse(newFile);//call subclass specific implementation
        //.........
    }
}

Do I have to do this ? If a class implements an interface, arent the methods in the interface, available as abstract by default in the implementation class?

Does the abstract class necessarily have to define the method to be abstract?

I would think not, since it works for me in windows. But then why do I get the error running it on linux against a jdk1.5 compiler?
It cannot be a bug in the compiler because such elementary things would surely have been well tested?

Thanks,
Ram.

[Ben Souther]

Some things I would check.

From the command prompt type:

which java
which javac
which ant
echo $JAVA_HOME

to make sure you are indeed using the versions that you expect.
When I installed FedoraCore it already had GNU's JRE on there.
It also had ANT but I'm not sure which one.
I never tested any of this out.
As soon as the box was running, I installed Sun's JDK and the latest version of ANT.

This is sounding less and less 'servlet specific' and I'm guessing that you would get some better help in another forum, either Unix/Linux or in Java In General.
Say the word and I'll move it for you.

[ramprasad madathil]

Thanks for the reply, Ben.

I did run the which java and which javac command.

from my previous post
---------------------
I ran the command java -version, which java and which javac and all pointed to version java version 5.

Apparently, though ant was picking up the jdk 1.4 which was why I was getting the compile errors for 1.5 specific features.

As I said in my other post, I altered the code to be 1.4 compatible and the errors I got were bizzare (see the later section of my previous post). Still banging my head against that though I have got a workaround (also posted).

OK, if you think this post fits better in other forums, please move it over. I posted here because the jsp/servlets forum is the one I know most regulars

Thanks,
Ram.

[Ben Souther]

Did you try pointing your JAVA_HOME environment variable to your JDK1.5 installation and running Ant again?

[ramprasad madathil]

Yes, I did that too
I have now set up a linux environment (FedoraCore) and shall install jdk 1.5, tomcat 5.5.9 and ant 1.6.5 and then try and replicate it on this machine, though I am betting that I wouldnt have this issue even then. Its been one hell of a debugging week trying to narrow down the problem with little luck.
Even after using 1.4 compatible code, I wasnt able to compile a hirearchy of classes - an interface + abstract class implementing interface + concrete sub class. The compile went through only when I specifically declared an interface method to be abstract in the abstract super class. Otherwise it kept throwing an error saying that the exception clause was incompatible.

Thanks,
Ram.

[Ben Souther]

The Linux/Unix forum might be better but since this is more about javac than anything else, I'll try moving this to Java In General (intermediate).
Hopefully you'll find better help there.

[Ernest Friedman-Hill]

Sounds to me as if the funky machine just has some outdated versions of your classes on it; in particular, it sounds as if the exception class may have been moved from one package to another at one time, and old pre-move .class files are somewhere on the classpath. I'd do a search-and-destroy, making sure that I'd gotten rid of all the old compiled classes, everywhere on the machine (because knowing exactly what CLASSPATH Ant is using is sometimes a black art), then do a rebuild.

[ramprasad madathil]

Thanks for the reply, Ernest.
I did think of that and deleted all class files - same result.

However even if that's the case (assuming that I hadnt deleted all), the one thing that beats me is how come it works when I forcefully declared the abstract method in the abstract super class?

When I declared the method from the interface, the method that the super class did not implement, as abstract in the super class, it did just compile fine. I got a couple of other people to look at the code - fresh set of eyes and they were equally baffled. And the worst part was, when it compiled with the 'workaround', I had to admit that the earlier code may have been faulty as I couldnt explain this to people who were not so familiar with java.

Having spent 2 days and a whole night on this, I know its difficult to guess what may be the cause. I was thinking that this may be a known issue or there may be a setting somewhere in ant that I may have missed. Thanks a lot for the help.

Thanks,
Ram.