Re: Deprecating Java functions

[Rik]

On 12/09/2012 04:25 AM, address@hidden wrote:
> Message: 2
> Date: Sat, 8 Dec 2012 14:32:11 -0800 (PST)
> From: Philip Nienhuis <address@hidden>
> To: address@hidden
> Subject: Re: Functions in Java interface
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
>> > | 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.
I recognize this point completely and is why I suggested deprecation rather
than immediately removing them.  Deprecated functions exist for two
releases before removal so all of the java functions would continue to
exist for releases 4.0 and 4.2 before being removed in 4.4.  Even in the
best of circumstances a 4.4 release would be a year away and likely longer
than that.
>> > | 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)?
For the moment, because I can't think of anything better, we'll leave
javamem alone.
>
>> > <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.
retval = sprintf ("%s\n", c{:});
retval(end) = "";   # remove final trailing newline

might be a touch clearer than the indexing solution, but I leave that
decision up to you.
When I benchmarked both code snippets the deletion method was 0.8% faster.
>
>
>> > <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?
That would be a big help.

--Rik