bugGNU Octave - Bugs: bug #39063, java: restriction on jvm arguments


bug #39063: java: restriction on jvm arguments

Submitted by:  None
Submitted on:  Fri 24 May 2013 03:19:53 PM UTC  
Category: LibrariesSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Feature Request
Status: FixedAssigned to: None
Originator Name: Ernst ReissnerOriginator Email: -unavailable-
Open/Closed: ClosedRelease: dev
Operating System: Any

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Thu 26 Nov 2015 06:10:47 PM UTC, comment #11:

I made Octave less restrictive about the arguments it accepts for the Java jvm in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/a972a2dc2735). It still requires that the line begin with '-' which is enough to distinguish between possible options and comments that users may have put in the java.opts file. This will be a part of Octave 4.2.

Rik <rik5>
Project Administrator
Thu 04 Jun 2015 01:57:20 AM UTC, comment #10:

Still present in the development version of Octave. Seems easy enough to fix, probably forgotten about. Updating bug status and release info.

Mike Miller <mtmiller>
Project Member
Tue 28 May 2013 02:22:34 PM UTC, comment #9:

I fully agree on this.
Typically i would expect that one wants to run with the same arguments as standalone.
But if this is not possible from within octave,
for some reason (i can hardly figure out)
the options can be modified accordingly.

To use nonstandard options is always as bad for compatibility with JVM kinds,
whether using within octave or standlone.
Thus treatment shall be the same.

Maybe one can place a note in the docu advising to restrict to standard.

Maybe more helpful: ask the user to post if a certain option does not work with octave.

Ernst Reissner <ernstreissner>
Tue 28 May 2013 02:12:37 PM UTC, comment #8:

I don't see any big issue in relaxing the constraint about the JVM arguments. I think it's reasonable to accept anything that starts with a '-', but I wouldn't try to validate them in octave, as it can be quite JVM implementation dependent.

Arguments should be passed verbatim to the JVM, if they are not recognized or invalid, I would assume JVM initialization fails and the error is reported at octave level.

Michael Goffioul <goffioul>
Project Member
Sun 26 May 2013 10:31:48 PM UTC, comment #7:

because of the unboxing problem i went back to old java-1.2.9
For this, i checked options -ea and -esa.
Implicitly also -da and -dsa and it worked well.

I am not sure whether you are interested in a check for java-1.2.9.
If not, i wait until the (un)boxing problem disappears.
I read the tests and am willing to contribute.

I am also not sure whether you like my fix:
For now I just removed any check.
I think, one should be allowed to use all possible for the JVM.
Since there is an option file java.opts dedicated for octave integration,
one can put into this file the options appropriate for octave.
These may differ from options for standalone java applications.
I think one has to place a remark on the danger in the docu
but let the user experiment and give feed back.
It seems to be no good to just ignore options.

But if you want, we can also test on standard options
and -X-options.
But there are lots and as i said before:
-X... is nonstandard (except -X alone) and -XX... is even unstable

What do you think?

Ernst Reissner <ernstreissner>
Sun 26 May 2013 08:55:27 PM UTC, comment #6:

java.opts ?
Put it in the location where the other java .m files live: in Octave do a

and it'll probably tell you something like /usr/local/share/octave/3.7.5/m/java/ (-javaclasspath.m)

You can also put it in the directory where you start Octave from. I think in ov-java.cc there are some comments on this.
It has been mentioned in the maintainers list as well, perhaps even initiated by myself.

If your options work OK, can you prepare a patch (Mercurial changeset)? Hopefully including a test? (there are a few tests in ov_java.cc for javaMethod and javaObject, perhaps you can use those as template)

Philip Nienhuis <philipnienhuis>
Project Member
Sun 26 May 2013 10:45:43 AM UTC, comment #5:

Ah, i have another problem: since 3.7.5 is so new,
there is still no documentation.
Where shall i put my option file for JVM?

Ernst Reissner <ernstreissner>
Sun 26 May 2013 10:44:14 AM UTC, comment #4:

now i tried to reinstall octave with new version 3.7.5.
Have still several problems (see other bug reports).
Mostly accessing fields via octave_get.
I will inform you when i can go on with this.

Ernst Reissner <ernstreissner>
Sat 25 May 2013 03:26:47 PM UTC, comment #3:

Did you already try to patch the java package (see my previous comment), reinstall the patched package and then run it with your desired Java flags?

It would help the devs a lot of you could test the required fix yourself, especially a fix as simple as the one you seem to need. It it works OK it can easily be ported to core Octave. (Remember, this is OSS; the best way to get features & fixes added is to do as much preparatory work as you can do yourself.)

In that Mathworks web page http://www.mathworks.de/support/solutions/en/data/1-18I2C/?solution=1-18I2C you can read that -xm256m is only valid for Java 1.1.8 (i.e., from before the -X flags). TTBOMK Octave (OF and core) needs Java >= 1.5

I wouldn't say that there's no need to check for invalid options. The Matlab GUI used to be written in Java - I've found it is easy to crash the entire ML GUI when experimenting with Java from within ML.
Octave may be more robust but the Java stuff has only recently been absorbed in core Octave and hasn't received much testing.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 25 May 2013 10:04:13 AM UTC, comment #2:

Hello Philip,
I know there is a java-package in octave forge created by Michael Gouffioul.
He told me that this package is part of octave now.

That is what he mailed me:

> On Fri, May 24, 2013 at 11:59 AM, ernst <rei3ner@arcor.de> wrote:
> Hi Michael,
> outch! so, i cannot activate assertions at all.
> Well. What do you think about allowing, e.g. all standard java switches?
> I suppose constraints could be relaxed a bit. As the code is now part of octave, please make a bug report about it.
> Michael.

That makes the impression as if the package is no longer supported, right?
So i decided to follow Michaels advice and file to octave directly.

Whether Matlab supports further options, i cannot say and also not prove because i have no license.
I can point you only to
which makes the impression that -mx256m is also a valid option.
Possibly, matlab does not check validity at all.
If this turns out true, i would say, octave must not check either.

As you say: Octave is often a kind of extension of matlab.
E.g. not equals can be written != and ~= in octave,
to be conform either with C or with Matlab.
Octave is a clone of Matlab insofar as each matlab source should run on octave but not the other way round, except backward compatibility is wanted.
Also Michaels package has some functions
working with octave (java_new) only and other working for both,
matlab and octave (javaObject).

This means that octave shall support a superset of what matlab supports.

To your third item, yes, it is a valuable aim to allow options only valid for "all" JVMs.
As said in
-X option is non-standard already,
except if used alone (the standard is that it displays the nonstandard options). -XX is even unstable.

Here is a list of standard options:

Those should i think be supported. Maybe no more no less.

At least Michael himself, who most probably introduced the restriction seems to see no good reason for sticking to that the restriction (see above). But maybe one should enter in discussion with him.

Next item: rebuild octave and look for crashes.
I did not do that yet, but the internal of a JVM process
invoking methods and so has, besides data transport
only the influence that exceptions and errors are thrown.
Of course, -ea can cause such an exception (thats the reason for enabling assertions;-) ) but octave handles exceptins and errors from java smoothly.
At least for standard options i see no negative impact.
But maybe this must be tried with a greater community.

Last point: If i pass options to the jvm in a standalone application, then it is because i need them.
If i pass options to the jvm in octave it is the same.
Thats why just ignoring options is bad thing.

In my case, -ea it is important for bugfixing.
It is even more important, to see whether the java kernel does not work or the integration in octave makes the problems.
Ignoring -ea obscures this distinction.

You are right, it is conceivable that different options are needed for some reason. But then, still passing all options would be fine, because i can place one set of options standalone and another set for running within octave.
I think the point is to have good control.

Hope that convinces you. ;)


Ernst Reissner <ernstreissner>
Fri 24 May 2013 08:52:22 PM UTC, comment #1:

Don't mix up (the Java package in) Octave-Forge and the newly built-in Java support in core Octave.

Would you have any idea whether Matlab also allows other options than -D and -X ? Reading up a bit in e.g., "Undocumented Matlab" (see google) I see no mention of other flags than -X and -D (save vfprint and abort)
Which is not to say that Octave should be limited to only what ML can, of course :-)

Note that there may be good reasons that only -X and -D flags are accepted. One I can think of is that Octave's Java (OF package or built-in) should run with many JRE (read: JVM) versions which simply may not all accept the same set of flags; -X and -D seem to constitute the most common subset.
Have you tried to comment out the "offending" lines, rebuild Octave (or reinstall the patched Java package) and see if -ea and -esa etc. work OK w/o crashing Octave sooner or later?

BTW Can you explain exactly why stand-alone Java programs and Java stuff run from within Octave should behave identically?
I obviously have some intuitive notion of the underlying principle, but presently I fail to see practical benefits.

("category" adapted to "libraries" as OF Java will probably not receive much more maintenance)

Philip Nienhuis <philipnienhuis>
Project Member
Fri 24 May 2013 03:19:53 PM UTC, original submission:

As shown in
the java package allows as jvm argument only those starting -X or -D.
This is too much restricted.

To make standalone application in java and integrated version in octave behave the same,
standard options should be supported.

I think most important would be
-ea and -esa enabling assertions
(and -da and -dsa for disabling).

Thanks and greetings,




(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by goffioul (Posted a comment)
  • -unavailable- added by ernstreissner (Posted a comment)
  • -unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 26 Nov 2015 06:10:47 PM UTCrik5StatusConfirmed=>Fixed
    Thu 04 Jun 2015 01:57:20 AM UTCmtmillerItem GroupNone=>Feature Request
      StatusNeed Info=>Confirmed
    Fri 24 May 2013 08:52:22 PM UTCphilipnienhuisCategoryOctave Forge Package=>Libraries
      StatusNone=>Need Info

    Back to the top

    Powered by Savane 3.1-cleanup