[Plplot-devel] Cool free java results (was Build of latest....)

[Alan W. I. <ir...@be...>]

I posted this to plplot_devel a couple of days ago, but apparently this cool
free java result never made the list so here goes again (under a more
appropriate subject).

Alan

On 2004-06-14 19:20+0100 Andrew Ross wrote:

> On Mon, Jun 14, 2004 at 10:26:49AM -0700, Alan Irwin wrote:
>> [...] the gcj approach should be tried by hand to
>> make sure there are no showstopper Class Library issues.  My educated 
>> guess
>> is it will work since our java use is quite minimalist and 
>> unsophisticated.
>> I won't be able to get to this for some time, but if you are curious 
>> enough
>> to try gcj by hand before me, I would be most interested in your results.
>> 
>> To anticipate one issue there, compiled java objects should not be mixed
>> with compiled C objects in the same library (recall all the trouble I had
>> in
>> the fortran case before I split the fortran and C objects into two 
>> separate
>> wrapper libraries).  So you will need a "Java" wrapper library for the 
>> java
>> objects corresponding to the swigjavafiles list in Makefile.am and a "C"
>> wrapper library corresponding to swigcfiles = plplotjavac_wrap.c in
>> Makefile.am.
>> 
>> The example java code executables should be linked to the "Java" wrapper
>> library which in turn links to the "C" wrapper library which in turn links
>> to libplplot.
> 
> Well if you want to use gcj as a byte compiler then it more of less
> works out of the box. The only problem I encountered was the configure
> check for jni_md.h. gcj doesn't have this. I've commited some changes to
> cf/java.ac to get round this. I've also added a check in the standard
> include search path for jni.h.
> 
> With these changes java now works out of the box on debian testing with
> gcj / gij. No configure options or environment variables needed for
> compilation. Of course you still need to set CLASSPATH to run the
> examples.

That's great.

Your gcj success inspired me to try the Debian package free-java-sdk which
apparently not only provides a byte compiler (jikes in this case rather than
gcj), but also a free run-time java implementation.  (The purpose of that
package is to replace all proprietary java stuff with the free equivalents.)
To use it simply set your JAVA_HOME environment variable to /usr/lib/fjsdk
and put $JAVA_HOME/bin first in your PATH.

One problem was jni.h could not be found.  Since the above package brought
in libsablevm1 as a dependency, I installed libsablevm1-dev to solve that
problem. After that, everything built and installed without any obvious
problems.  Also, I have just now been able to run a simple test (with
CLASSPATH set to $prefix/lib/java)

software@chickadee> which java
/usr/lib/fjsdk/bin/java

software@chickadee> java plplot/examples/x10 -dev xwin

I was extremely happy to see that wonderful red square show up!

However,

software@chickadee> ./plplot-test.sh --front-end=java

reveals a few of the examples (9, 15, 16, and 22) die with the
"jni: fatal error (Local reference capacity exceeded)" error message.

I looked that up with google, and apparently (from
http://lists.debian.org/debian-java/2004/01/msg00148.html) that error
message is a result of too many (more than 16) local references.  Apparently
that small limit is in the java spec so that is what SableVM implements.  Also,
you can get such a message if you don't free things properly (which is
probably our case).

Andrew, would you be willing to look at this problem using the free-java-sdk
approach I outlined above or tell me how to free local references in java?

(Change since original post.  I am currently looking into this.  I believe
it has something to do with swig and implementing the pltr_func pltr,
PLPointer SWIG_OBJECT_DATA arguments for java [since only those functions
are affected], but progress is slow and, Andrew, if you know a quick answer,
please get in touch with me.)

Once we have that last problem fixed, then we know our java interface works
with a completely free traditional java approach, and that has lots of nice
implications including

* not having to sign any more stupid proprietary java licensing agreements!
(which is of increasing importance to me as I get older and more radical
:-))

and

* being able to package that interface under Debian.

Anyhow, such packaging is something that Rafael may wish to consider after
the above error is solved and this current release is out of the way.

> 
> I guess the next stage (if anyone is interested) is to use gcj to
> compile object files rather than just byte compiled java .class files.
> In this case Alan's comments about making a wrapper library apply.

To put this into context, this approach is quite different from the
traditional (free and otherwise) java approach we now implement. In
particular, my understanding is it does not require a run-time environment
to run.  Thus, you just build an ordinary native executable with gcj that
runs a bit faster and which you can analyze with gdb and valgrind.  Anyhow,
I am all for this idea, but setting up the simultanous support of this
approach and the (free and otherwise) traditional java approach will be a
bit complicated and should be done post-release to make Rafael's job easier.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the PLplot scientific plotting software
package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the
Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________