RE: [Plplot-devel] Java examples don't work for me

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

Alan W. Irwin writes:
 > I agree that what I was asking for before was to eliminate the
 > package structure, but I now refine that request, see below.
 > 
 > > In other words, I'd rather do the experiments with HelloWorld class
 > > things, than with PLplot.
 > 
 > I have done those tests which I believe can be summarized as package
 > structure does not work for 1.1.8.  Nevertheless, it does work for 1.2.2 and
 > above as my further tests last night proved.  So I don't mind if you put
 > PLStream.class in its own package.  I like that because the extra
 > plplot.core helps to identify it and also eliminates name clashes, and I
 > also think it is acceptable to say we don't support anything before
 > jdk-1.2.2.
 > 
 > I guess my only remaining objection is having the examples in a package
 > structure.  To me that seems like unnecessary complexity. It gives the
 > mistaken impression to the java newbie like me that my own java code for
 > plotting must be in a complicated directory structure.  Thus, I believe you
 > should remove the package command from all the examples so the resulting
 > class files appear right in tmp and are part of no formal java
 > package.

I thought about this.  If the examples were just free standing
programs, this would make a certain amount of sense.  The C demos, for
example, are kind of like this.  Just independent programs that link
against plplot, but are otherwise independent.

In Java, I am imagining that the installation article, is a JAR file.
plplot-config --java-classpath will return something like:
	      $prefix/lib/java/plplot.jar
or some such.  With this class path, and with LD_LIBRARY_PATH set to
include $prefix/lib, they will "run" the demos via java
plplot/examples/x??.  The thing is that Java's CLASSPATH centric view
of the software world, means that all these things sort of "live in
the same space".  Speaking anthropomorphically here, but hopefully you
understand what I mean.

My feeling was that for things delivered in a JAR, leaving them at
global scope would be bad, because the class names "x01", etc, would
interfere with the ability of clients to have similar names in their
global scope.  So, because of Java's propensity for gang bundling
software, I decided that what made the most sense to me, was to bundle
the plplot java examples together, but drop them in a namespace
(woops, dropping into C++ parlance there), a Java package, that
wouldn't collide with users.  So, plplot.examples.*, gets them
delivered to the JAR that winds up in their CLASSPATH, without dumping
junk into the global scope.

I think if you want to strip the examples out of 
  package plplot.examples;
then we need to also not deliver them in the JAR file (or hierarchical
.class collection) at install time.  We could still upload them to the
install tree somewhere, but not under the same CLASSPATH as the
plplot.core goods.  They would still be able to run them, but they'd
have to cd to the java demo dir, and run them as you've shown.  That
works, I agree, but just doesn't seem as stylistically or
idiomatically java, as the choice I made.  

I guess my position can be sumarized by saying that the scheme you are
advocating looks to me very natural from a C mindset.  But the scheme
I chose seems more natural to a Java mindset.  I believe this, but I
realize I am a small sample :-).  Studying how other packaged/released
java ware is done obviously presents one way to attempt to tune into
the frequency of the Java community, but I guess I'd be wary of
relying too heavily on the example of things that date from the
pre-Java 2 days.  

 (I
 > have just done this on my own and it works fine so long as you have your
 > CLASSPATH set up as
 > 
 > echo $CLASSPATH
 > .:/home/software/plplot_cvs/HEAD/plplot/tmp/java/
 > 
 > The initial . finds any class file you have compiled into the local
 > directory wherever that may be, and the /home/etc.... finds the
 > PLStream.class.  That latter directory would be changed if PLStreams.class
 > was installed, of course.  Also note for all user examples, that at least
 > two paths will always be required of CLASSPATH unless PLStreams.class is
 > installed in a java default location.) In my view compiling into the local
 > directory will be more representative of the way that most java users will
 > be using plplot. All java examples I have seen recently (and I have seen
 > quite a few) compile their class files right into the current directory, and
 > I think that keeping things simple this way is an excellent choice for our
 > examples as well.

The extended Java framework that Lightspeed has, also has files
distributed over a hierarchy on disk, with the package assocations
matching the disk layout identically.  Then we point CLASSPATH to the
root of this tree, but also to any other Java ware that we use which
is not part of the local source set.  By just including the PLplot
classpath as one component in the classpath, we can run local code,
including local code that uses the PLplot Java API, or
the PLplot examples, without tampering with the CLASSPATH.  Others
could do the same.  This seems like a very free-playing way to go, to
me. 

 > However, that is just my $0.02 Canadian from my java newbie
 > perspective, and if you feel it is necessary to keep the package
 > complexity for the examples, I would be willing to accept that
 > (albeit somewhat reluctantly) as well.

I don't view the "package plplot.examples;" as complexity, but rather
as idiomatic Java style.  

We should consider this topic open for further discussion.

Gotta run.

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