Re: Release Plans

[Philip Nienhuis]

Mike Miller wrote:
> On Mon, Apr 22, 2013 at 5:13 PM, PhilipNienhuis wrote:
> > John W. Eaton wrote
> > > <snip>
> > >    * Release with Java enabled by default.  The JVM is not loaded
> > >      unless it is needed, so having Java enabled by default should not
> > >      cause trouble for users unless they actually want to try using
> > >      some Java functions.  The only exception is that the dialog
> > >      functions attempt to use Java if the Qt versions are not
> > >      available, but I think that will be a tiny minority of users.
> >
> > What trouble do you refer to? Loading of the JVM?
> > By supplying a java.opts file with carefully chosen values (sufficiently low
> > amount of initial memory, say 16 MB) this issue can be mitigated. Java has a
> > sophisticated garbage collector so if methods and objects are unloaded
> > properly, JVM memory shouldn't be an issue.
>
> There have been at least three bugs in Octave code not related to Java
> that have cropped up since the JVM was added to Octave. One was due to
> Java changing the FPU precision and others have been due to changes in
> the memory constraints. I don't think it would be a stretch to say
> that there may be more that we haven't seen yet.

Yes you're right, I remember the FPU flags issue. But was that an Octave 
bug (not properly preserving & resetting those flags) or a Java bug?
It's a bit hard to believe that other SW developers never hit this 
issue, as Java is so immensely widely used.

As to the others I have to read up on those.

> For the Java experts: Octave currently compiles in the JAVA_HOME path
> at build time. This means a user of a binary Octave package has to
> have the same version of Java installed in the same directory as the
> maintainer who built it, right?

(I'm not a Java expert, but anyway:)
AFAIK, no.
The MinGW and MSVC binaries are shipped with precompiled packages that 
run on every Windows (except 8, and older versions than 2000) having 
about any Java JRE > 1.6 installed. (Note: only a JRE is needed to run 
Java but a JDK will also work.)

As Michael Goffioul mentioned, on Windows JAVA_HOME etc. is obtained 
from the registry. I don't know how it works on Linux and *nix, but I 
suppose there's some configuration in /etc. Furthermore on Linux the 
various Java executables are in the PATH (not so on Windows).

The key may be in octave.jar, __java__.oct (especially as that routine 
starts the JVM) and their sources.

> Is it possible to compile against the
> JNI and load any JRE at run time from JAVA_HOME and test it for
> features? In other words, would it be possible to build Octave with
> JAVA_HOME=/usr/local/java-1.6.0 and run the resulting Octave binary on
> another system with JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-amd64?

I suppose so, provided 32 & 64 bits aren't mixed up; but I'm not even 
sure that will be a problem.
There's a fairly monolithic Linux setup on my dev boxes (only Mageia 2) 
so I can't test heterogeneous Linux Java installations.
I could zip an Octave hierarchy (/usr/local/<Octave> stuff) and put it 
up on Dropbox or so, so other people could test on e.g., Ubuntu. How 
that goes with glibx versions etc and other dependency libs in /usr/lib 
is anyone's guess.

> If this is possible I think this would be a big win for binary
> packagers, especially for Windows users who could have a JRE or JDK
> installed anywhere, right?

As I wrote above, on Windows that problem doesn't exist (yet - once 
again I'm unsure about 32 vs. 64 bit).

Philip