Re: Java support in MXE build

[Philip Nienhuis]

John W. Eaton wrote:
> On 05/15/2013 05:55 PM, PhilipNienhuis wrote:
> > Until now the MXE building process fails to include Java support.
> > Looking at
> > the log from a freshly checked out MXE build I see:
> >
> > configure: WARNING: JAVA_HOME environment variable not initialized.
> > configure: WARNING: Auto-detection will proceed but is unreliable.
> > checking for java... /usr/bin/java
> > /home/philip/devel/octdev/mxe-octave/tmp-octave/octave-3.7.5/configure: line
> >
> > 66352: pwd: -W: invalid option
> > pwd: usage: pwd [-LP]
> > checking for javac... /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19/bin/javac
> > checking for jar... /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19/bin/jar
> > checking for Java version... 1.7.0_19
> > checking for jvm.dll... not found
> > configure: WARNING: Library jvm.dll not found. Octave will not be able to
> > call Java methods.
> >
> > So the configure script defaults to the Linux Java system on the box
> > where
> > MXE is run.
> >
> > I then tried to configure with the Windows Java system, installed on
> > another
> > (windows 7) partition, by adding a few configure options in
> > ./mxe-octave/src/octave.mk (symlink /mnt/jhm points to /mnt/win7/Program
> > Files/Java/jdk1.7.0_21):
> >
> > :
> > JAVA_HOME="/mnt/jhm" \
> > --with-java-homedir="/mnt/jhm" \
> > --with-java-libdir="/mnt/jhm/jre/bin/server" \
> >
> > --with-java-includedir="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.19/include"
> > \
> > :
> >
> > I had to make the symlink as configure hickups on spaces in path
> > names. This
> > trick seemed to work, but then I got other errors:
> >
> > :
> > - checking for java... /usr/bin/java
> > /home/philip/devel/octdev/mxe-octave/tmp-octave/octave-3.7.5/configure: line
> >
> > 66352: pwd: -W: invalid option
> > pwd: usage: pwd [-LP]
> > checking for javac... /usr/bin/javac
> > checking for jar... /usr/bin/jar
> > checking for Java version... 1.7.0_19
> > checking for jvm.dll... /mnt/jhm/jre/bin/server
> > checking for include file<jni.h>... not found
> > configure: WARNING: Include file<jni.h> not found. Octave will not be
> > able
> > to call Java methods.
> > :
> >
> > Setting JAVA_HOME to the Java installation on the Windows partition
> > doesn't
> > help in any way.
> >
> > So it seems the configure script consistently picks up the native (Linux)
> > Java version and seems to largely ignore the --with-java-* configure
> > options. It does find the jvm.dll (that configure option works) but not
> > jni.h while the latter does live in the "java-includedir" indicated in
> > the
> > configure options.
> >
> > Obvious question: how can we proceed with getting Java support
> > included in
> > MXE builds?
>
> I think we need tools like javac and jar that can run on the build
> system. We need a jni.h file that can be compiled for MinGW. And then we
> need to be able to have a jvm.dll file that can be loaded on the Windows
> system at run time. I don't think we really even need to check for that
> when building. We just need to be able to locate one that we can use
> when Octave runs. So part of the problem is that the configure tests are
> wrong, and part of it is that we probably don't have the right jni.h on
> the build system.
>
> I don't know whether it is reasonable to attempt to cross compile our
> own jvm.dll so that we can distribute one with Octave, or whether we
> should just expect one to be installed on the Windows system where
> Octave will run.

I think we need to build:

* __java__.oct (or whatever its successor is named), do we need jni.h 
for that? If so, I think (but I might very well be wrong) that we need 
the window jni.h + gcc (cross-) to do this.
There are some differences between windows and Linux jni.h files, but 
not much. I can check that out tonight.

* The octave.jar file, we need javac & jar for that. But as .jars are 
platform-independent by default this may be done with native (Linux) tools?

* jvm.dll: I wonder if it is needed at all during the cross-compile. 
Maybe for building octave.jar, but then we might do with libjvm.so.

As usual Michael probably knows all the answers.
I was just trying out a few easy things I could oversee and immediately 
ran into configure issues I can't solve (I know too little about autotools).

Thanks,

Philip