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

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

Alan W. Irwin writes:
 > On Tue, 23 Oct 2001, Geoffrey Furnish wrote:
 > > [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.  

Well, a perusal of plplot.h shows the depressing amount of work left
to be done.  PLplot has a /lot/ of API calls.

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

That would be great, thanks for offering.  If you would Java-ize the
remaining unimplemented C examples, perhaps just leaving the
unimplemented PLplot calls commented out, and check them in, then I
could just focus on implementing the needed API functions, uncomment
one or two lines, and see the examples fully implemented.  That would
definitely be a big help.

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

I'll try to do this soon.

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

Great.

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

Agree.

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

I have also been frustrated by the lack of Java rpms in the major
distros, although I haven't actually studied the licensing correlation
factor.  

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

Great, thanks for the feedback, and offer of help with implementing
the rest of the examples.

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