From: Geoffrey F. <fu...@ga...> - 2001-10-22 16:45:51
|
Alan W. Irwin writes: > I tried plplot java with both the IBM jdk and Blackdown version. (Both are > version 1.1.8.) (BTW, kaffe is not a complete JDK so it is out of the > running.) Both the IBM and Blackdown versions worked with no problems > up to and including make jdemos. After that, however, no example > would work. > > Here was my environment (for the Blackdown version. The IBM version > was the same except for JAVA_HOME.) Here is what I get when I run from my dev area. This is the CVS head for plplot, configured with --prefix=/home/furnish/j2. After the build, here is what I have, and I've run x01 to show that it does work: plplot/tmp> pwd /home/furnish/devel/plplot/tmp plplot/tmp> echo $CLASSPATH ./java plplot/tmp> echo $LD_LIBRARY_PATH .:/home/furnish/j2/lib/ plplot/tmp> ls java/plplot/examples/ x01.class x01.java@ x02.class x02.java@ x03.class x03.java@ x04.class x04.java@ x05.class x05.java@ x06.class x06.java@ x07.class x07.java@ x08.class x08.java@ x09.class x09.java@ x10.class x10.java@ x11.class x11.java@ x12.class x12.java@ x13.class x13.java@ x14.class x14.java@ x15.class x15.java@ x16.class x16.java@ x17.class x17.java@ x18.class x18.java@ x19.class x19.java@ plplot/tmp> ls java/plplot/core PLStream.class PLStream.java@ plplot/tmp> java plplot/examples/x01 Plotting Options: < 1> xwin X-Window (Xlib) ... I also ran it with CLASSPATH java (instead of ./java), just to be sure nothing so trivial could be at fault, but it behaves the same (correctly) for me both ways. > pwd > /home/software/plplot_cvs/HEAD/plplot/tmp > > printenv JAVA_HOME > /usr/lib/jdk1.1/ > > printenv CLASSPATH > java > > Note I also tried this as an absolute path and it did not work. > > printenv LD_LIBRARY_PATH > /home/software/plplot_cvs/HEAD/plplot/tmp > > ls java/plplot/examples/ > x01.class* x04.java@ x08.class* x11.java@ x15.class* x18.java@ > x01.java@ x05.class* x08.java@ x12.class* x15.java@ x19.class* > x02.class* x05.java@ x09.class* x12.java@ x16.class* x19.java@ > x02.java@ x06.class* x09.java@ x13.class* x16.java@ > x03.class* x06.java@ x10.class* x13.java@ x17.class* > x03.java@ x07.class* x10.java@ x14.class* x17.java@ > x04.class* x07.java@ x11.class* x14.java@ x18.class* > > Here is the error message when I attempted to execute the first example. > > java plplot/examples/x01 > Invalid class name: plplot/examples/x01 > Usage: java [-options] class > . > . > . Well, it sure looks to me like it built correctly, and put things in the right places. Did you check that plplot/tmp/java/plplot/core has the PLStream.class file? > To test that my jdk was working, I compiled the following incredibly > complicated programme: > ************** > class HelloWorld > { > > public static void main(String args[]) > { > > System.out.println("Hello World!"); > } > > } > > javac compiled it and java ran it without problems. I also tried > appletview on several rather complicated examples such as molecule viewing, > etc. They all worked. > > Thus, I am stumped why plplot java does not work for me when I believe > I have followed Geoffrey's cookbook exactly. Yes, it looks to me also that you have done it right. > But wait.... After thinking about that last sentence I tried moving my hello > world programme around. If I execute it as java HelloWorld (i.e., no > partial path before HelloWorld and with CLASSPATH set to the *entire path*) > it works fine. But any attempt to have a partial pathname with it, e.g., > setenv CLASSPATH /home; java irwin/HelloWorld produces the same bad symptoms > as above. So for my version of java it seems no partial path can be part of > the class name when java executes a class. Armed with that knowledge, I tried Mmm, interesting. Sounds like the whole package loading thing must not work the same in JDK 1.1.x as it does now. > setenv CLASSPATH java/plplot/examples > java x03 > Error loading class x03: Wrong name Mmm. Well, just for grins you could try java plplot/examples/x03, since the x03.class file will show that its contained class x03 is in the "java package" plplot/examples. I dunno. It seems like what you've done above should've worked. I am no Java expert by any means, and I especially don't know much about how it has morphed with time and JDK (sun) version numbers. I know the 1.1.x -> 1.2.x transition was a Huge deal, at least in the minds of Sun's marketting team. The thing called "Java 2" is what was labeled JDK 1.2.0. So, you're not even using the Java 2 platform, but just the Java 1 platform, which is archaic in the Java world. > so clearly this "full CLASSPATH" strategy isn't the whole answer. > > Do you have any ideas how to overcome these CLASSPATH problems, Geoffrey? > > Does JDK-1.1.8 have a limitation that your JDK does not have? I don't know specifically, but I do know that JDK 1.1.x are way way way out of date in the Java world. I would've been frankly more worried aobut some part of my JNI coding having been tied to 1.3.x, but maybe there were even changes in package identification and loading, between 1.1.x and the 1.3.0 that we're using here: /home/furnish> java -version java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Java HotSpot(TM) Client VM (build 1.3.0, mixed mode) I saw there were packages for JDK 1.3 up at blackdown. I'd suggest, if you don't mind the labor involved, just trying it out with a vintage 1.3 jdk, and seeing how that goes. I don't have specific knowledge of anything that should be pinning us on a late model JDK, but I probably also don't know enough of the history and culture of Java to recognize it even if there were, sorry. I did look at JNI a few years ago (pre Java 2), and I have the vague impression that some things are different now, although my memory isn't clear enough to know for sure. Anyway, it wouldn't surprise me if we are tied to Java 2 because of the C coupling, but this trouble finding/loading packages does surprise me. Anyway, try JDK 1.3, if you don't mind, and we'll take it from there. -- Geoffrey Furnish fu...@ga... |