Re: Java and autotools

[Daniel J Sebald]

On 11/27/2012 09:51 AM, John W. Eaton wrote:
> On 25-Nov-2012, Rik wrote:
>
> | Would it be helpful to borrow some of the Java-related macros from the
> | Autoconf Archive rather than rolling our own?  See
> | http://www.gnu.org/software/autoconf-archive/The-Macros.html#The-Macros and
> | search for the word java.  There are several that I think could be useful.
> | Currently, I'm not able to build on kubuntu 10.04 with OpenJDK6.  The build
> | can't find jni.h which I think could be fixed by using the
> | ax_jni_include_dir macro.  I don't mind volunteering to try and get these
> | to work, but I won't push forward if you think it is the wrong way to go.
>
> Yeah, I'd like to improve the way we check for Java.
>
> I just grabbed the section from the java package configure script that
> appeared to do the job.  I assumed, apparently incorrectly, that it
> would work given that it had been in the java package for a long time.
> I'm busy with another project this week, but if I have some free time
> I'll try to take a look.  But if someone else wants to look at
> improving it, then that would be great.  I also plan to change the way
> that __java__.oct finds octave.jar.  It should be looking in the
> location determined at compile time, or by using some environment
> variable, not by searching the load path for the __java__.oct file as
> that seems unreliable.
>
> jwe

Also think of whether the JAVA_HOME variable should be used within the 
executables and scripts.  I can see its use as part of building Octave, 
but to reference JAVA_HOME doesn't feel right.  Here is the rule for 
accessing the Java compiler:

   We try the Java compilers in the following order:
     1. getenv ("JAVAC"), because the user must be able to override our
        preferences,
     2. "gcj -C", because it is a completely free compiler,
     3. "javac", because it is a standard compiler,
     4. "jikes", comes last because it has some deviating interpretation
        of the Java Language Specification and because it requires a
        CLASSPATH environment variable.

which makes sense.  But near the above comments (javacomp.c and 
javaexec.c) is also some strange code whereby JAVA_HOME is disabled:

  /* Unset the JAVA_HOME environment variable.  */
  old_JAVA_HOME = getenv ("JAVA_HOME");
  if (old_JAVA_HOME != NULL)
    {
      old_JAVA_HOME = xstrdup (old_JAVA_HOME);
      unsetenv ("JAVA_HOME");
    }

It's just that the use of JAVA_HOME once Octave is compiled isn't so 
clear to me.

In dlgtest.m is a conditional that will break if environment variable 
JAVA_HOME isn't defined.  But the JAVA_HOME variable isn't used anywhere.

Dan