Re: Java support in MXE build

[John W. Eaton]

On 07/03/2013 03:51 PM, PhilipNienhuis wrote:
> John W. Eaton wrote
>>
> > I think the right thing to do is to not check for the JVM.  We just need
> > enough "java" to be able to compile.  I think that's really just jni.h.
> >    We load the JVM at run time, so that's when Octave should be checking
> > for it and complaining if it doesn't exist.
> >
> > My question is really about where should we be getting the jni.h file?
> > It could probably come from the build system, but I don't think that is
> > the right solution.  Instead, I think we should be downloading some
> > package that provides it and installing it along with other dependencies
> > in the build tree.
> >
> > So, what package should we be using to get jni.h?
>
> To download a complete JDK just to get jni.h seems overkill.

So, is there some smaller package that provides just the minimal set of 
files necessary to compile an application that uses jni.h?

> Why not be practical and rely on the build system's Java JDK, perhaps just
> as fall-back or temporary solution, until maybe a better solution comes up?
>
> An -admittedly cursory-  perusal on my box through the files
>
> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.25.i386/include/jni.h   (Linux
> version)
>
> and
>
> /mnt/winxp/Programs/Java/jdk1.6.0_33/include/jni.h   (Windows version)
>
> doesn't show any difference apart from the header (comprising only comment
> lines) and some formatting (indentation).

It seems strange to me to have to tell the cross compiler that we build, 
which is supposed to be compiling things for MinGW, to look outside of 
the mxe-octave build tree to find some files.  Does that happen 
automatically?  I don't think it should.

How is the mxe-octave user supposed to know which packages to install in 
order to get an appropriate jni.h?

If we do decide that this is the best route, then it means that there is 
an additional dependency that the mxe-octave user must provide apart 
from running Make.  I know that we already require some tools in this 
way, but they are tools, not header files for the compiler.

Although the two versions of the jni.h file that you found were 
apparently the same, are there possible differences with different 
versions?  If so, that means we have less control over what is being 
built (we are just relying on whatever happens to be on the system where 
mxe-octave is being used).

jwe