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

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

On Tue, 23 Oct 2001, Geoffrey Furnish wrote:

> 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".

That sounds like a reasonable solution to me.  Another alternative, of
course, would be to read (at run time) the library name from a special
one-line file.

> [Referring to implementing the remainder of the plplot API]
> It's dirty work, but sombody's gotta do it :-).

Thanks for doing so much already.  With nine demos implemented, you probably
already have a large majority of the API implemented so you might be closer
to the end than you think.  The easiest thing would probably be just for you
to carry on with your present work style (API and examples simultaneously)
as you have time.  Often, it is counterproductive to throw in new resources
near the end of a project. However, I would be willing to do the grunt work
on the examples side (but not on the API side since I don't feel competent
there) if that would be a help.

> ....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".

OK.  I have already posted on this question, and you have recently replied.
You also pointed out in your replay that I had more of a C stylistic
perspective, but that probably flatters me.  More likely its a Fortran
stylistic perspective....;-) Obviously I am less comfortable with java
package style for the examples than you are. However, I respect "just feels
right". Anybody else?

> 4.  I think configure support is still poor.

Probably, but I wouldn't want overall concern for the whole configuration to
divert attention from the relatively simple task of fixing up the library
name configuration.  Even if you solve that simple issue in a temporary way,
it gives us the chance to make valuable tests of the java front end using
double precision for the first time.

>
> 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.

I agree with the alpha designation since some of the API is still missing.
All my testing so far has been with JDK-1.2.2, and the current java front
end to plplot does fine in that environment.  Thus, I would rephrase your
wording to "functional with JDK 1.2.2 and higher".

>
> 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.

With regard to supporting 1.1.8, I think that is a dead duck now or very low
priority (see below).  With regard to the potential release, if the
configuration change for the library name reveals some other double-java
problems for the examples that now work in single, I would simply note it
and not let that hold back a release. OTOH, double and java might work well
(once that library name configure issue is solved) for the limited API of
the current examples that work with single.  That would be nice to be able
to state for the new release so let's find how far we can go with just that
library name configuration change.  Same comment as previous about JDK
version.


>
> 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.

It seems to work fine for 1.2.2, and I wouldn't worry about anything older
for some time to come if ever (see dead duck comment above...;-)) I brought
up 1.1.8 originally, but as I have gotten more experience with java, my
interest in 1.1.8 has waned considerably.  We are not really penalizing
users much to demand they use 1.2.2 or above.  It looks like users tend to
download whatever jdk they want.  For example, I had a chance to look at RH
7.1 yesterday, and there is no jdk in it, and I assume that continues for RH
7.2.  I think the Sun License is essentially forcing everybody to make
individual downloads, and those downloads tend to be the latest/greatest
version.  Debian does have one old example (Blackdown jdk-1.1.8) that is
thoroughly integrated into their packaging system, but there may be a
license relaxation for such an old jdk version that allows this. My guess it
that most Debian Java users may simply ignore that old version, download the
latest JDK, and use the dummy packages to help integrate it.

So to summarize, please give the highest priority to finding at least a
temporary solution to the library name problem so I can test other aspects
of double (and perhaps brag about it in the new release if double works as
well as single does now).  1.2.2 is fine as far as I am concerned so don't
worry about 1.1.8.  Leave the java packaging of the examples as is if nobody
else complains about this additional complexity (or Java style) like I have
done....;-)

Alan