[Octave-bug-tracker] [bug #39063] java: restriction on jvm arguments

[Ernst Reissner]

Follow-up Comment #2, bug #39063 (project octave):

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 <address@hidden> 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 
http://www.mathworks.de/support/solutions/en/data/1-18I2C/?solution=1-18I2C 
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 
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.htmlhttp://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
-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: 
http://javaeesupportpatterns.blogspot.de/2011/08/jvm-options-hotspot-vm-standard-options.html

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

Greetings, 
Ernst 





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?39063>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/