1. Won't matter.  The generic import affects the compile only.
2. This could matter, especially if it's an authority issue.
3. Won't matter; that's the beautiful thing about Java.
4. Definitely a possibility.
5. Won't matter (*).

(*) As long as your classpath is set correctly.  Classpath setting is
tricky.  I suggest having a simple program on hand that does nothing else
but print the classpath.  That way you can test it using your various launch
methods to get the hang of it.

I find using the QSH command to execute "java -cp myclasspath myclass" as
the easiest way to run things because it's so similar to what you do in a
DOS/Unix environment.  In CL I build a long character variable starting with
"java -cp" and add my classpath (and any other Java switched such as setting
the JVM version), then the class I'm going to run and then finally any
parameters.  I then execute that string using STRQSH.  It works great.


> From: Kelly Cookson
> Special thanks to Kristen for the help on Saturday!
> I finally got the program to run. I'm not sure which of these changes made
> the difference, but they did the trick:
> (1) I imported the specific classes instead of using a wildcard.
> Instead of
>       import*;
> I coded the following:
>       import;
>       import;
>       import;
>       import;
> (2) I put both my source file ( and the jt400Native.jar file
> in a custom directory of the IFS (/Dot/iConnect). I had been using the
> /QIBM/ProdData/Java400 directory.
> (3) I compiled the in the IFS using qsh. I had been dragging
> a compiled class in from the Eclipse IDE on my desktop.
> (4) I set the classpath in qsh using:
>       export -s CLASSPATH=/Dot/iConnect:/Dot/iConnect/jt400Native.jar
> I had been using the WRKENVVAR from a command line of the classpath parm
> of the CL JAVA command.
> (5) I then ran the program in qsh using the java command. I had been using
> the CL JAVA command.
> Thanks again to all for the help!
> Kelly

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page