Re: Java support in MXE build

[PhilipNienhuis]

Michael Goffioul wrote
> On Wed, Jul 3, 2013 at 5:55 PM, PhilipNienhuis <

> pr.nienhuis@

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

What about octave.jar?
Isn't it so that some JDK stuff is needed to build it, i.e. javac and jar
executables, plus all of the implicit dependencies they need? 
If so, 
- presence of a JDK on a build system may be conceived as a "tool" in the
sense JWE mentioned above;
- there's no need to worry about where to get jni.h as any JDK contains it.

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Java-support-in-MXE-build-tp4652996p4655188.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.