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

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

Alan W. Irwin writes:
 > Geoffrey, would you be willing to trim off the plplot/examples and plplot/core
 > from the internal names and see if the above CLASSPATH then works for you?

Alan, I think this is a bit more involved than you realize.  I don't
currently believe there is anything wrong with the code.  The
pathspecs you refer to are just a result of using packages in the Java
language, and there is nothing suspicious in that.  Java has used
packages since the very beginning.

I think what is at issue, is learning how to interract with the Java
run time environment for each version of Java.  Java has a very
stylized approach to software development, which I find very
frustrating to work with, and I did not choose to exactly emulate
typical Java software development systems in the way I set up the Java
plplot stuff.  With judicious use of javac -d, and reading the man
page, I got it to work with JDK 1.3, but the problems with JDK 1.1.x
are probably related to this, rather than to the appearance of
package-delimited name qualifiers in the .java source files.

I will admit to being a serious Java neophyte here, and I think you
are too.  So lets proceed methodically, rather than just trying things
willy nilly.

Typical java projects that I have to look at, do something like this:

dir x
subdir y
file   z.java

CLASSPATH points to x/..
z.java contains "package x.y;"
compilation occurs in x/y, using "javac z.java", resulting in x/y/z.class.

Then you would run this (from anywhere) via "java x/y/z".

I think you should be able to do things like that with simple java
code in your jdk 118 without trouble.

What I'm doing in PLplot, is softlinking all the source files to
plplot/tmp, and then attempting to use the -d flag to put the
compilation products in the expected place.  I think I've shown this
is working okay for JDK 13, but JDK 11x must not be so facile.

Rather than changing the code, I think what we may have to do to
support such systems, is investigate changign the /layout/ of the code
on disk, and futzing with the precise settings of CLASSPATH and what
not. 

We may also have to ultimately figure out how to product .jar files
from our compilation products.  I'm betting that if we produced a .jar
file from what we have now, and then you fixed CLASSPATH to reference
this .jar file, it would work fine even now.  But I can't quickly test
this theory because I don't know how to make well-formed .jar files.

The bottom line is I'm a java newbie, and I think you are too.  So
rather than thrashing over all the ways we could rewrite the code,
eliminating packages and all that, I think we should instead focus on
developing or acquiring the necessary sophistication with programming
the java envirionment, and figure out what changes are needed from
that.

Recruiting a java specialist through SF might be one way to go about
this.  

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