Re: Functions in Java interface

[Philip Nienhuis]

John W. Eaton wrote
> On  8-Dec-2012, Rik wrote:
> 
> | We seem to have an embarassment of riches.  The new Java interface
> brings
> | with it many more functions than the existing Matlab interface.  I think
> it
> | is desirable to pare down the list of Octave functions for greater
> | compatibility and to avoid polluting the global namespace.
> :
> <snip>
> :
> | java_init and java_exit call internal C++ initialization and termination
> | routines for the JVM.  However, calling any java routine will take care
> of
> | initialization for the user so I would vote to remove these explicit
> | functions from user space immediately.
> 
> I don't think we need the init and exit functions.  It might be nice
> to have a way to unload the JVM, but that doesn't seem to work
> properly.  If it could be made to work, then we could add a function
> to do that, but for now it seems OK to me if we just keep the JVM
> loaded once it has been initialized.

The Java garbage collector can shrink the actual JVM size very effectively,
but obviously that is dependent on user code neatly releasing Java objects
once done. I don't know if the JVM can be gracefully exited while Java
objects are still referenced, but if so, java_exit would be a nice shortcut
for cleaning up.
(Not my style of programming BTW; but remember that the whole point of the
Java subsystem is to run "code once, run anywhere" code, while unfortunately
there are tons of crappy Java programs out there that can easily hang the
JVM and in turn affect Octave itself. Libre-/OpenOffice's Java-UNO bridge is
a fine example. IMO it would be a good thing to be able to shield &
disconnect Octave from accidents happening inside the JVM)

Also, if the minimum JVM heap size has been set too high (in e.g. a
java.opts file), undue memory is kept by the JVM. java_exit can help here.

I really don't know if it is possible at all, but the init and exit function
might be useful to specify temporary arguments, like for example min and max
JVM heap size, different from the system defaults or from the settings in a
(possibly system-wide) java.opts file that are too restrictive for some user
job.

BTW where is that file "java.opts" supposed to be found by the JVM init
routines nowadays? Still in the Java .m file directory in Octave's m-file
tree?


> | java_new is a synonym for javaObject.  I like the simplicity (new
> reminds
> | me of C++ and the fact that we are calling a constructor), but do we
> really
> | need to extend the syntax here since the Matlab function already exists? 
> | It might be wise to deprecate this so that Octave java code doesn't
> diverge
> | so significantly that it becomes cumbersome to run our code on Matlab.
> | 
> | java_set and java_get can set/get data members in a class.  In both
> Octave
> | and Matlab the struct syntax is overloaded to perform this operation.
> | 
> | java_set (java_obj, "fieldname", value)
> |    is equivalent to
> | java_obj.fieldname = value.
> | 
> | Matlab manages without these so it seems like we could to.  Do people
> like
> | the extra setter/getter routines are should we start these on the road
> to
> | removal by deprecating them?
> 
> Removing the redundant functions seems OK to me.
> <snip>
> :
> | javafields and javamethods, in Matlab, are handled by overloading
> | fieldnames() and methods().  I propose that we do the same and then
> | deprecate these two functions.  The beginning of methods() is
> 
> OK.

The octave-forge Java package has existed for several years so there is an
unknown Octave-based code base still depending on those "redundant"
functions. Better wait a few stable Octave versions.


> | javamem doesn't seem to have an exact analog under Matlab.  inmem() is
> | related, but doesn't actually report how much memory is being used.  I
> | guess it can stay for now.
> 
> Seems OK to keep it, but maybe rename it __javamem__?  Also, does it
> just print the stats?  It seems like it would be better to also be
> able to get the info returned in a struct.

Its intended use was for debugging Java problems, so decorating with
underscores and maybe putting it in ./private will make Java debugging a bit
harder.
I had plans to have it echo more JVM stats then just memory heap sizes. E.g.
the JVM slot dedicated for static methods can silently overflow (happened
often to me with Matlab) giving rise to hard-to-track errors while there are
JVM arguments to adapt this that obviously make users need up-to-date info
on current settings and sizes.

It can already return info but in a cell array. I'll pick that up, yet I'll
need to have suggestions for field names:
-max size ("maxMemory")
-current size ("totalMemory")
-free size ("freeMemory")
The Java method names are between quotes, would they do (incl. camel
casing)?


> <snip>
> | cell2mlstr seems like a convenience function that should possibly be in
> | scripts/general along with cell2mat since it is not java specific. 
> | Phillip, can you comment on when this function is used and why it is
> valuable?
> 
> I don't think this function is really needed.  How is it different
> from
> 
>   sprintf ("%s\n", c{:})
> 
> ?  And the sprintf solution works if C is an array of strings, not
> just if it is a vector.

Thanks, good start.

sprintf ("%s\n", c{:})(1:end-1)

takes care of the superfluous trailing newline.


> <snip>
> Also, as we've discussed before, the dialog functions should probably
> be rewritten with Qt instead.  I don't think the JVM should be
> required to display a dialog box.

Shall I implement your sprintf trick in the dialog functions (as long as
there's no Qt replacement yet) and remove cell2mlstr?

Philip



--
View this message in context: 
http://octave.1599824.n4.nabble.com/Functions-in-Java-interface-tp4647660p4647670.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.