Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2001-10-21 01:48:59
|
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.)
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
.
.
.
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.
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
setenv CLASSPATH java/plplot/examples
java x03
Error loading class x03: Wrong name
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?
Alan
email: ir...@be...
phone: 250-727-2902 FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________
Linux-powered astrophysics
__________________________
|
|
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...
|
|
From: Alan W. I. <ir...@be...> - 2001-10-22 19:04:47
|
On Mon, 22 Oct 2001, Geoffrey Furnish wrote: > 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? It is there. > Anyway, try JDK 1.3, if you don't mind, and we'll take it from there. I am willing to do that as a test, but we should also think hard about compatibility with older jdk versions. Our Debian users are not going to be able to use your package (without a special download and possibly conflicts between that download and the supported jdk-1.1.8 version). I guess I can live with that because it might be a special case. Also, I personally don't have a problem with a conflict because I don't use any other Debian packages that are related to jdk-1.1.8. But to ensure we don't make things too impossible for our users, we should look at what other distributions do as well. Does anybody here know what jdk version is officially supported by Redhat 7.1? (or 7.2 which is just out today?) Same question for SuSe and Mandrake (latest versions only, please). If they all tend to be 1.2.x (or even 1.1.8), I think we should support that version if at all possible. Note this might be quite easy to do. There was no trouble compiling any of the applications under 1.1.8. So there may be no fundamental inconsistency between your work and jdk-1.1.8. The symptoms I am getting are consistent with the mental model that everything will work if the java invocation is done without any path to the file name. That is you just use "java x01" rather than "java plplot/examples/x01". If that model is true, then the only additional thing required to make it work is to change all internal references to trim off plplot/examples and plplot/core from the names. (I noticed with the strings command that there were such internal references.) Then, if my model of what is going on is correct, then setenv CLASSPATH java/plplot/examples:java/plplot/core should work regardless of jdk version. 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? Thanks. Alan |
|
From: Geoffrey F. <fu...@ga...> - 2001-10-22 20:21:51
|
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... |
|
From: Alan W. I. <ir...@be...> - 2001-10-23 00:11:21
|
Geoffrey, you may have misunderstood me since you talk about eliminating packages which is a phrase I certainly did not use. I am actually asking for something quite simple. > 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. > That was one of my points. I did such experiments with my hello_world programme and it empirically appears that you cannot have slashes in the name of the class file you invoke in java 1.1.8. For that version it appears you *must* setenv CLASSPATH x/y; java z rather than setenv CLASSPATH .; java x/y/z. Why can't we set things up so our examples are invoked the first way (which is also the way I have seen all classic java demo programmes invoked). That is all I am asking. Alan |
|
From: Geoffrey F. <fu...@ga...> - 2001-10-23 16:24:55
|
Alan W. Irwin writes: > Geoffrey, you may have misunderstood me since you talk about eliminating > packages which is a phrase I certainly did not use. I am actually asking > for something quite simple. > > > 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. > > > > That was one of my points. I did such experiments with my hello_world > programme and it empirically appears that you cannot have slashes in the > name of the class file you invoke in java 1.1.8. For that version it appears > you *must* > > setenv CLASSPATH x/y; java z > > rather than > > setenv CLASSPATH .; java x/y/z. > > Why can't we set things up so our examples are invoked the first way (which > is also the way I have seen all classic java demo programmes invoked). > > That is all I am asking. My point is that I believe your request is synonymous with eliminating packages. Perhaps I am mistaken, but I don't have information to persuade me otherwise at this time. CLASSPATH is supposed to point to the /root/ of your java package system. If a Java class file lives in package x.y, then you point CLASSPATH to the parent of x, and reference the class as x/y/z. If you want to eliminate the string "x/y/z", I believe this effectively means eliminating the package structure. I admit the conceivability that I may be wrong. But I haven't seen the evidence yet. I realize you've done some tests, but I'm saying they don't convince me, at least not yet. The package system has been in Java since the beginning. My active Java programming status has been only for two months, using JDK 1.3. So yes, it is possible that my assumptions about how Java used to work may be wrong. It is also possible that there are some nuances of precise techniques for working with older JDK's, that both you and me, don't know. Before I agree to some substantial restructuring of the code, which I believe is well structured now, I want to be certain that I understand the true and complete semantics of class usage in older JDK's. Right now I don't have this clear understanding. Right now the only thing I feel I know clearly, is that "it don't work". But I don't feel we've identified /why/ it doesn't work, or /how/ things do work in the old JDK's. I want to get through that clearly, rather than just initating reactive efforts at restructuring the PLplot code. In other words, I'd rather do the experiments with HelloWorld class things, than with PLplot. |
|
From: Alan W. I. <ir...@be...> - 2001-10-23 18:18:17
|
On Tue, 23 Oct 2001, Geoffrey Furnish wrote: > Alan W. Irwin writes: > > Geoffrey, you may have misunderstood me since you talk about eliminating > > packages which is a phrase I certainly did not use. > > My point is that I believe your request is synonymous with eliminating > packages. Perhaps I am mistaken, but I don't have information to > persuade me otherwise at this time. > > CLASSPATH is supposed to point to the /root/ of your java package > system. If a Java class file lives in package x.y, then you point > CLASSPATH to the parent of x, and reference the class as x/y/z. If > you want to eliminate the string "x/y/z", I believe this effectively > means eliminating the package structure. Thanks for that clarification. I had no clue what you meant by packages before, and I have to confess I interpreted the phrase "eliminating packages" as something to do with eliminating software packages. But now I understand what you are talking about, 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 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. 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. Alan |
|
From: Geoffrey F. <fu...@ga...> - 2001-10-24 00:06:26
|
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... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X