RE: [Plplot-devel] Java examples work with jdk-1.2.2, but still one problem

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > I purged 1.1.8 from my Debian woody system and downloaded a private copy
 > of jdk 1.2.2 from Blackdown.
 > 
 > Following Geoffrey's recipe for working from plplot/tmp, I got further, but
 > ran into problems finding the plplot library. If I set up some symlinks from
 > files with the wrong name (libplplot.so, etc.,) to the existing files with
 > the correct name (libplplotd.so, etc.), I overcame this problem (at least to
 > the point of getting a menu to choose from.  I didn't pursue it further
 > because I immediately recognized it probably would work if I configured
 > without my usual --with-double). So I used single-precision next, and indeed
 > that worked, i.e., I got good results with java plplot/examples/x01, etc.
 > 
 > Geoffrey, have you implemented double precision?  If so, then this problem I
 > have found may simply be a forgotten LIB_TAG problem so that with double
 > configured, the libname is incorrectly referred to as libplplot rather than
 > the correct libplplot.  However, if you have an old single-precision
 > libplplot kicking around, everything will look rosy. To replicate the
 > double-precision name trouble I have found (if that is what it is) you have
 > to start with a clean slate.

Mmm, wow, thanks for uncovering this.  I certainly did not know about
this problem yet.

I haven't been configuring with --with-double, so I guess I haven't
gone through the issues of setting up the configure support for mixing
double with java.  However, I don't really see exactly how to do what
we need.  The reference to "libplplot" is found in PLStream.java, line
235:

// Static code block to get the PLplot dynamic library loaded in.
    static {
        System.loadLibrary( "plplot" );
    }

which would need to be, I guess, plplotd, for the double case.  What I
don't know, is how we're gonna make this configure-time change
accessible to the code.  Java doesn't have header files,
preprocessors, anything like CPP, etc.  I don't really like the idea
of making PLStream.java into PLStream.java.in, to be converted to
PLStream.java by configure, because it's a substantial heavyweight
source file, which I am actively editing, now, and will continue to be
in flux for some time to come (see below).

Maybe we can split the System.loadLibrary call out to another small
.java file which only does this one thing, and then have that one be
sed'd by configure.  I guess we should add this task to "the list".

 > I was most impressed with the substantial fraction of the single-precision
 > examples that have been implemented. Geoffrey, do you have the full PLplot
 > API accessible from java so the rest of the examples mimicking the x??c
 > examples would be straightforward to do? I can probably find the time to
 > fill out the remaining examples if the API is available.

Thanks.  

What's done (speaking of the API), can be seen in PLStream.java.  All
the decls that say "public native void xyz(...);" are the API entry
points that are implemented.  You can see with a quick perusal, that
this set is far short of the full set.  On the other hand, the ones
that are implemented, are mostly done in duplicate for float and
double, where there are FP arguments.  (Looks like I mised poin on
double[], gotta go back and do that at some point.)

There are many many PLplot api calls that haven't been implemented
yet.  Basically what I've been doing is implementing the examples, one
by one.  I pull in the x??c.c code to x??.java, comment it all out,
and then go through it line by line, converting the C code to Java,
leaving the plplot api calls still commented out.  Once I think I have
the data for the plot computed properly, then I go through and
uncomment the PLplot calls.  At this point most of the calls for
setting up the plots are done, so you can at least get the labels,
viewports, etc, showing.  Then I go through and implement the api's
for the drawing functions, one by one, until the whole demo is
displaying.  Then I check that in, and move to the next plot.

As time allows.

So, there's lots still left to do.  It's mostly make work.  You can
read javabind.c and see that the most of the wrapper functions are
trivially constructed.  The only really tricky part, is the business
of setting up the function names, which you have to get by putting the
decls in PLStream.java, and then running javah, and pasting the output
from that into javabind.c.  And javah sometimes lies, producing
function names with funny octal codes (I guess) burried in them, which
the JVM does /not/ use when it references the names through JNI.  So I
had to learn to chop out the bizarre octal chars, leaving the parts of
the name that look vaguely like C++ mangled linker function names.

It's dirty work, but sombody's gotta do it :-).

 > The only other issue I can see is how far back we support java.  It would be
 > nice for Debian users (who I suspect are some of our keenest users due to
 > Rafael's packaging efforts) if we could support back to jdk-1.1.8, but that
 > depends on how difficult it is to drop the current requirement (incompatible
 > with jdk-1.1.8) that we must have a partial path as part of the class name.
 > If that is a simple change, Geoffrey, then I strongly encourage you to make
 > it, but if for some unknown reason it is complicated, then I am willing to
 > say we just support jdk-1.2.2 and above.

Here's my take on it, feedback desired.

1.  I think the structure of this langauge binding is pretty good.  I
like the package structure, plplot.core and plplot.examples.  I think
it makes sense, presents the right "package interface" to the
stylistic Java user.  I think PLStream "just feels right".

2.  I think the overloading of float and double args in the Java api
is good.  People can write Java code with either float or double
types, and the plots will "just work", whichever way they configured
plplot when they built it.  That is, they can use float and float[],
and still plot to a double plplot config, and vice versa.  I think
that's good.  It decouples the client's .java source files from the
config time issue of the PLplot build.

3.  I think the under-the-hood implementation of the JNI wrappers is
good.  We are efficient when the user type maps to PLFLT, and we incur
only reasonable overhead when conversions have to be performed.  I
think this style can be extended to cover the as yet unimplemented
APIs. 

4.  I think configure support is still poor.  I didn't even know about
the float/double library config bug that Alan discovered.  There's
probably other issues neither of us knows about.  Some issues I do
know about, relate to the difficulty of mapping PLplot's "flat tmpdir"
build paradigm, to Java, and comparatively lame implemenation of the
install target (for Java components).  There's a lot of issues here.
Idiomatic Java usage seems to couple package structure to disk
hierarchy inseparably.  I've rigged the plplot build system with javac
invocation well enoguh to work for JDK 1.3, but it seems clear there
are issue with other JDK's and other vendor implementations.  Users
aren't gonna like the way the install works right now.  We should be
building a JAR for the install.  plplot-config needs to be expanded to
cover coughing up java classpaths for clients, etc.

5.  Timelines are totally unclear.  I cannot commit to specific
functionality by any particular date.  

6. I think we should regard the current java suport as alpha or early
beta level stuff, and advertise it only as functional with JDK 1.3.  

7. I remain willing, in principle, to attempt to support older JDK's,
but I can't commit to investigate this prior to an imminent release.
If Alan wants to do a release soon, which I support, then I think we
should leave --enable-java off by default, and only represent it as
working with JDK 1.3.  

8.  The pathway to supporting older JDK's, seems to me to involve
better understanding of how to set up source structures for older
javac's, and learning how to build/use JAR's, etc.  I could forsee
that this might ultimately mean substantially reworking the way
configure sets up softlinks, but I am optimisitic that it would not
change the way the Java package structure of the PLplot classes, is
presented. 

9.  I could be wrong in 8. above.  If it is conclusively determined
that the current package structure won't work in old JDK's, I suppose
more deep thinking will be required.

-- 
Geoffrey Furnish         fu...@ga...