Re: javaclasspath

[Rik]

On 12/20/2012 11:58 AM, Philip Nienhuis wrote:
> Rik wrote:
>> On 12/15/2012 02:30 PM, address@hidden wrote:
>>> Message: 7
>>> Date: Sat, 15 Dec 2012 14:30:28 -0800 (PST)
>>> From: Philip Nienhuis<address@hidden>
>>> To: address@hidden
>>> Subject: Re: Opportunities for core work on Java
>>> Message-ID:<address@hidden>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Rik-4 wrote
>>>>> 12/14/12
>>>>> <snip>
>>>>> 1) javaclasspath.m needs to be able to set the classpath.
>>>>>
>>>>> Currently the Octave version of javaclasspath only reads the current
>>>>> classpath variable.  For compatibility, and because it makes sense, we
>>>>> should be able to call javaclasspath (dpath) and directly set the
>>>>> value of
>>>>> the classpath.  The functionality we are trying to match is here
>>>>> (http://www.mathworks.com/help/matlab/ref/javaclasspath.html).  The
>>>>> change
>>>>> is pretty simple as well, call javaMethod with a "setProperty" method
>>>>> instead of a "getProperty" method.  Watch out that the path to
>>>>> octave.jar
>>>>> should always remain as the first element of the classpath.
>>> Is that really true?
>>> IIRC octave.jar is implicitly in the path (i.e., in the static classpath).
>>> > From what I understand of the ML docs, javaclasspath() is supposed to
>>> only
>>> be able to change the dynamic classpath (while yes, it can query both the
>>> dynamic and static classpaths).
>>> The static classpath is supposed to be just that: static. (It can be
>>> set in
>>> the "classpath.txt" file which is processed at startup of the JVM.)
>> I was misled by some comments in the m-file.  It is true, as you say, that
>> the static class path is set just once.  The reference behavior to match is
>> http://www.mathworks.com/help/matlab/matlab_external/bringing-java-classes-and-methods-into-matlab-workspace.html.
>>
>>
>> The static path is set by the file "javaclasspath.txt".  I made a change to
>> search for that file as well as "classpath.txt" here
>> (http://hg.savannah.gnu.org/hgweb/octave/rev/492893b98eef).  I made another
>> change here (http://hg.savannah.gnu.org/hgweb/octave/rev/ac9e34f83522) to
>> allow valid one-character paths like '/'.
>>
>> Is there a good reason to hide octave.jar on the static classpath?  We are
>> doing that in javaclasspath.m but this seems unnecessary and misleading.
>
> I don't know. Being exposed is one thing but it shouldn't be vulnerable
> for messing around with it.
> octave.jar contains the very basic 'low level' Java handling that is
> essential for Octave. As in this respect it has a sort of 'super-static'
> properties (without it Java doesn't work at all in Octave) I see no
> pressing need to expose it.
>
>> Do you have access to Matlab to try some experiments?  It seems that the
>> current working directory may be included by default in the dynamic path.
>> But, given that the paths in the classpath are absolute I think this must
>> mean the startup directory from which Matlab was launched.  Could you open
>> a brand new instance of Matlab and run 'javaclasspath' and report the
>> output.
>>
>> Also, the documentation seems to imply that every time the dynamic path is
>> modified ALL java objects are cleared.  Can you test that?
>>
>> Sample Code:
>> clear all
>> x = javaObject ('java.lang.StringBuffer', 'Hello World')
>> whos
>> javaaddpath ('/tmp')
>> whos
>
> r2012a:
>
> >> clear all
> >> x = javaObject ('java.lang.StringBuffer', 'Hello World')
>
> x =
>
> Hello World
>
> >> whos
>   Name      Size            Bytes  Class                     Attributes
>
>   x         1x1                    java.lang.StringBuffer
>
> >> javaaddpath ('c:\temp')
> >> whos
>   Name      Size            Bytes  Class                     Attributes
>
>   x         1x1                    java.lang.StringBuffer
>
> >>
>
> so javaadpath leaves Java objects untouched.
> Which IMO is entirely reasonable. I really can't see why adding something
> to a PATH would clear objects.
Straight quote from the documentation,

"The functions javaaddpath and javaclasspath(dpath) add entries to the
dynamic class path. To avoid the possibility that the new path contains a
class or package with the same name as an existing class or package, MATLAB
clears all existing global variables and variables in the workspace."

And from javaaddpath,
"MATLAB calls the clear java command whenever you change the dynamic path."

So, it's possible that they don't mean what they say.  Or maybe the example
I gave was somehow too simple.  I guess we won't bother with compatibility
in this case.

--Rik