Re: javaclasspath

[Philip Nienhuis]

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.

> > Anyway, a long time ago I peeked at how Martin Hepperle implemented the
> > javarmpath() function; AFAIR it looked quite a bit more involved than just
> > swapping getProperty for setProperty. But then I may be wrong.
> This is true.  It looks like we can implement 'javaclasspath (dpath)' in a
> straightforward, but braindead way, by looping over every path in the
> current classpath and calling javarmpath on it it and then looping over
> every path in dpath and calling javaaddpath on it.  Dumb, but performance
> is not an issue here.

Unless there are many class paths involved and then it can take a long 
time (as the code underlying javaclasspath() checks the requested path).

For the time being the dumb way could do. Maybe in the future a better 
way is found.

Philip