Opportunities for core work on Java

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Opportunities for core work on Java

Rik-4
12/14/12

All,

For anyone who is interested in doing a little core development, but has
been reluctant because it looks daunting, there are a number of bite-size
tasks that are available.

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.

 javaMethod ("getProperty", "java.lang.System", "java.class.path")
    =>
 javaMethod ("setProperty", "java.lang.System", "java.class.path", dpath)

2) javaaddpath.m needs to support prepending as well as appending a path to
the classpath variable.

Currently, javaaadpath always appends which is the equivalent of the '-end'
option.  The functionality to match is
http://www.mathworks.com/help/matlab/ref/javaaddpath.html.  Maybe wait on
this item until item #1 is done and then this will become very easy.

3) im2java.m for conversion between Octave and Java image formats.

The functionality to match is
http://www.mathworks.com/help/matlab/ref/im2java.html.  The java format to
match is that of java.awt.Image.  The Octave side has ind2rgb which will
get the image in close to the correct format.

4) Need %!demo blocks for dialog functions

There is a seperate m-file, scripts/java/dlgtest.m, which contains
demonstrations of the different dialog boxes.  This should be broken up and
the code put at the bottom of each relevant m-file such as errordlg.m or
questdlg.m.  Demo blocks begin with %!demo and begin 2 lines below
'endfunction'.  Once the demo blocks have been created dlgtest.m can be
removed.

5) %!test blocks needed for java functions

The java functions need tests written for them.  The test code is at the
end of each m-file and should begin with '%!testif HAVE_JAVA' if it uses
Java.  It can begin with '%!test' if it is an ordinary test block that
might be checking just input validation.  There are functions in
libinterp/octave-value/ov-java.cc which also need test blocks.  In the C++
code the test blocks need to be inside of block comments immediately after
the DEFUN block.  For example, a totally simple test for the isjava()
function is:

/*
%!testif HAVE_JAVA
%! jobj = javaObject ("java.lang.StringBuffer");
%! assert (isjava (jobj));
*/

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Opportunities for core work on Java

Philip Nienhuis
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.)

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.

<snip>
5) %!test blocks needed for java functions

The java functions need tests written for them.  The test code is at the
end of each m-file and should begin with '%!testif HAVE_JAVA' if it uses
Java.  It can begin with '%!test' if it is an ordinary test block that
might be checking just input validation.  There are functions in
libinterp/octave-value/ov-java.cc which also need test blocks.  In the C++
code the test blocks need to be inside of block comments immediately after
the DEFUN block.  For example, a totally simple test for the isjava()
function is:

/*
%!testif HAVE_JAVA
%! jobj = javaObject ("java.lang.StringBuffer");
%! assert (isjava (jobj));
*/
I'll have a go at javaMethod/java_invoke, javaObject/java_new in the coming days.

Philip