Functions in Java interface

[John W. Eaton]

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.

I agree.  Thanks for looking at this in detail.

| __java__ is an empty DLD_FCN; it would seem that this could be deleted
| immediately.

By now you've seen that this function has already been removed.

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

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

| java_debug, java_convert_matrix, java_unsigned_conversion control certain
| variables within __java__.cc but they are undocumented.  From looking at
| the code,
| java_debug does print out some extra information when enabled.
| java_convert_matrix controls whether return results which are of a
| complementary type to an existing Octave class (java.lang.Double -> double)
| are automatically converted.
| java_unsigned_conversion controls whether signed/unsigned results are
| returned in the automatic conversion if that is enabled.
| 
| I would say that java_convert_matrix sounds too much like a function call
| that would convert a java matrix to an Octave matrix and should probably be
| renamed.  For all of them, I think it would be nice to find names that
| indicate that these are variables rather than functions.  As an example, we
| don't have a function jit_debug.  Instead we have enable_jit_debugging()
| which handles setting the internal variable.

I agree that we should use better names for these functions.

| isjava is something simple and should be added to the core (rather than in
| scripts/java which is conditionally built).  Something simple like
| 
| retval = (arg.class_name () == "octave_java");

OK.

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

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

| java2mat seems like it is in the conversion family of routines such as
| mat2cell, etc.  However, it doesn't appear to work as I would expect when I
| used javaArray and then java2mat.  It is also undocumented and doesn't
| appear anywhere else in java.cc or in scripts/java according to grep.  Is
| there someone who can say definitively whether this function can be 
deprecated?

I don't know about this one.

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

| dlgtest is just a test function for the various dialog boxes and probably
| doesn't need to be in the user namespace.

I'd remove that in favor of adding demo blocks to the dialog functions.

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.

jwe