Re: Java support in MXE build

[Michael Goffioul]

On Wed, Jul 3, 2013 at 5:55 PM, PhilipNienhuis <address@hidden> wrote:

John W. Eaton wrote

> 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.

If everything was only black or white...

AFAIK there are no small packages that contain jni.h

For native builds, there is no alternative AFAICS - the JDK nowadays is
either an .msi or a helper file which downloads & installs the rest of the
JDK.

That's why I suggested to be "practical".

BTW there may be a way out: the jni.h header says:

/*
 * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.  Oracle designates this
 * particular file as subject to the "Classpath" exception as provided
 * by Oracle in the LICENSE file that accompanied this code.


so I suppose we are allowed to include it in mxe-octave ?

Alternatively, we could download them from:

http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/raw-file/tip/src/share/javavm/export/jni.h

http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/raw-file/tip/src/windows/javavm/export/jni_md.h

The last change on these files is from 3 years ago, so they don't change much :)

AFAIK, these are the only thing that you need to compile java support are those 2 headers.

Michael.