octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

usejava function


From: PhilipNienhuis
Subject: usejava function
Date: Fri, 3 Feb 2012 15:29:06 -0800 (PST)

In 3.6.0 NEWS I see the function "usejava" mentioned w/o much explication.
AFAICS it was added largely "under the radar".

Inspection of the source reveals that is merely a stub which always returns
0 (false), provided that valid input is given, otherwise it returns an
error. A return value of 1 (true) is never provided.

Now, if the Java package is loaded, most of the "Sun Java features"
mentioned in usejava.m are available, BTW also with OpenJDK (at least on
Linux). "desktop" obviously is not (ML's desktop (=GUI) is written in Java.)
So IMO the usejava function as it stands is a bit rough and may actually
return deceiving info.

There are a few options to solve this:

(1) One way would be having a core Octave usejava.m with a few try-catch
constructs around Java invocations, along the lines of:

retval = 0;
switch feature
  case "awt"
    try
      ## The next call might succeed with a loaded octave-forge Java package
      myFrame = javaObject ("java.awt.Frame");
      retval = 1;
    catch
      ## Do nothing and leave retval as it is: 0
    end_try_catch
:
:
<etc>

This way it would be independent of future Java package implementations and
the actual usejava.m that presently may return faulty info would be fixed.
(FYI "javaObject()" is a ML call to create a Java object and -I suppose-
needs to be present regardless of the way any Octave<-> Java interface is
implemented.)


(2) Another way would be to include a "usejava.m" function file in the Java
package that:
- shadows the core octave usejava.m
- obviously invokes similar try-catch constructs as above

...but this might provoke a false alarm with unwary users due to a start-up
warning: "usejava.m shadows a core function".
If ever another Java<->Octave bridge becomes available, it needs a similar
usejava.m to shadow the core function.


Of course, while the primary goal of usejava.m is to allow script
libraries/packages to decide how to proceed depending on availability of
Java features, smooth execution of scripts originally meant to run in ML
still cannot be guaranteed even if e.g., 'usejava ("<feature>")' returns 1.
E.g., in Matlab one can create Java objects out of nothing directly like:
  today = java.util.Date
while in Octave, with the octave-forge Java package, a call to javaObject()
or java_new() is needed in such cases.
OTOH, such script libraries/packages can also fail because of other
ML<->Octave incompatibilities that have nothing to do with Java.

Nevertheless, usejava.m's current output doesn't fit the bill either, IMO.


Thoughts?

(I'd prefer to fix the core usejava.m script over adding a usejava.m to
octave-forge. The first seems a bit more robust to me.)

Philip


--
View this message in context: 
http://octave.1599824.n4.nabble.com/usejava-function-tp4356108p4356108.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]