Here are some Frequently-Asked-Questions (with answers ;-) and some
common mistakes people make when trying to translate and run JR
programs. Some of
this information applies specifically to UC Davis's CS
department's CSIF systems, but it is also likely to apply to other
systems.
- Java versions:
- "... class file has wrong version 50.0, should be 49.0 ..."
The version difference suggests a setup problem: 49 is for Java
1.5, 50 is for Java 1.6. It's likely you have a non-1.6 Java in
your PATH. Make sure each of the following commands shows 1.6:
javac -version
java -version
- Simple translation problems:
- Translation (e.g., jrgo, jr, or jrc) complains about variable
JR, e.g.:
main.jr:6: cannot find symbol
symbol : variable JR
location: class main
JR.exit(0);
^
Not generating jrGen/main.java due to errors.
1 error
You've probably forgotten
import edu.ucdavis.jr.JR;
- Translation (e.g., jrgo, jr, or jrc) complains about variable
st (or other variables that would be fine in Java programs), e.g.:
main.jr:10: not a statement
ArrayList<String> st;
^
main.jr:10: ';' expected
ArrayList<String> st;
^
Not generating any jrGen files due to errors.
2 errors
st is a keyword in JR.
(So, change it in your program to something different,
e.g., symtab.)
See page 334 of the JR book for a complete list of JR keywords.
- "main.jr:6: unreported exception
java.lang.InterruptedException;
must be caught or declared to be thrown". Thread.sleep (or some
other
method that can throw the above exception) needs to be in a try/catch
block. See, e.g., p11 of the JR book. (Or, replace
Thread.sleep
via the new JR.nap, which doesn't need to be in a try/catch block.)
- Simple execution problems:
- "jr Foo
jrvm exception: java.lang.ClassNotFoundException: Foo
java.lang.ClassNotFoundException: java.lang.ClassNotFoundException: Foo"
You've probably misspelled the name of your main class "Fooo".
Suggestion: use "jrgo". You don't specify the name of the main
class to "jrgo"; instead, "jrgo" will be able to figure that out (in
most
cases).
- "Contact with a VM on pi.cs.ucdavis.edu has been lost ...
exiting". This message is normal if your program has caused a
run-time error, such as "java.lang.ClassCastException". In such a
case, the exception stack trace will appear before the above message.
- Exceptions during execution: If your JR code causes an
exception (e.g., java.lang.NullPointerException), you'll see a
stacktrace as you would for an exception during execution of a Java
program. However, this JR stacktrace is more difficult to
understand because your JR program is translated into Java code; the
stacktrace shows the trace of the generated Java code, not your
original JR code, and contains methods that you didn't include in your
code, but that the JR implementation did. In most cases, though,
the stacktrace is still useful. Here's how:
- find the first line
in the stacktrace that mentions the file X.java where you have an X.jr
file in your code.
- look at the given line in the file jrGen/X.java; that line
caused the exception. You might recognize code on that line that
looks like something that corresponds to what you have in your X.jr
code.
Here's an example:
jrvm exception: null
java.lang.NullPointerException
at Main.main(Main.java:24)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:597)
at
edu.ucdavis.jr.jrx.jrvm.startmain(jrvm.java:333)
at
edu.ucdavis.jr.jrx.jrvm.main(jrvm.java:449)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:597)
at
edu.ucdavis.jr.jrx.jrvm_wrap.startmain(jrvm_wrap.java:67)
at
edu.ucdavis.jr.jrx.jrvm_wrap.main(jrvm_wrap.java:124)
So, look at line 24 in jrGen/Main.java
for the cause of the exception. Then, locate the corresponding
line in Main.jr.
- My JR program can't create all its processes!
- I get errors like "jrvm exception: unable to create new native
thread; java.lang.OutOfMemoryError: unable to create new native thread"
- Be sure you're not trying to create too many processes,
e.g., via an infinite loop that sends to an op-method.
- How many processes is "too many"? It depends on your
system, but somewhere around 200-300 should work on most systems.
(You might find the program in vsuite/environment/maxproc/jr useful to
get an idea of what your system supports.) However, an important
detail: we've seen systems configured such that they restrict the
number of threads that can be created due to their limit on
stacksize. In particular, on one such group of systems, under
[t]csh, the stacksize limit was set to 256M ("limit"), which
effectively limits the number of threads to about 12. A more
reasonable setting is 8192K ("limit stacksize 8192") or even
4096K. And you might want to change the maxproc if it's too low;
a more than reasonable setting is 1024 ("limit maxproc 1024"). Also, if
you do change stacksize or maxproc, do so in your .cshrc so that the
change also applies to multi-VM JR programs. Note that we've seen
systems whose settings vary according to which shell you're using, so
be careful with that. (Under bash, use "ulimit" instead of
"limit" and place the commands in your .bashrc file.)
- My JR program using Swing or AWT doesn't work!
- My program seems just to terminate after it starts up.
See discussion on p309 of the JR book. Add a "sleeper process" to
your JR code or use "jr -explicit name_of_main_class".
- My program just hangs without opening up any windows on the
screen. Be sure your constructors for the class that is creating
the
window terminates.
- Make sure DISPLAY is set properly. The instructions page shows how to set
DISPLAY when you want the displays to show up on the local
console. However, if you instead want the displays to show on
your local system:
-
If you're using
VNC, you'll need to do something like "vncserver :4" and then use
"setenv DISPLAY :4.0" in your .cshrc.
-
If you're using, say, "ssh -X pc63",
then use something like "setenv DISPLAY localhost:10.0" in your
.cshrc on pc63.
To find the exact DISPLAY string, temporarily put "echo
$DISPLAY" in your .cshrc on pc63 and "ssh -X pc63"; then remove the
echo
and add the setenv to your .cshrc on pc63.
(You'll likely need to change DISPLAY each session.)
- Make sure you've executed the xhost command (see the instructions
page); if not, you'll get an ugly bunch of exceptions, but the key
symptom is the line:
Caused by: java.lang.InternalError: Can't connect to
X11 window server using ':0.0' as the value of the DISPLAY variable.
- As a good, quick test: Make sure the BnB program (in the
codeextract) runs for you.
- My multi-VM program doesn't work!
- I get errors that say something like "Cannot create
virtual machine on pc51..." or "Cannot create virtual machine on
localhost...".
- Be sure to check that the tests in Steps 4 and 5 on the instructions page work. Even if you
checked those previously and your program used to work on this
particular system, sometimes systems get upgraded, etc., which can
break the ssh setup.
- Pay special attention that CLASSPATH and DISPLAY are exactly
as specified on the instructions page.
- Try your program on a different system(s). Again,
sometime system problems or changes can break things.
- Be sure your program isn't trying to create too many
VMs. (How many you actually can create depends on system,
etc., but on CSIF I wouldn't try to create more than about 10 on a
single host.) Also, see notes on maximum
number of processes.
- My program isn't able to open files. Non-main JR VMs
execute in the home directory rather than the
current directory, which might make a difference if the JR program uses
relative pathnames for files.
- I'm getting
"edu.ucdavis.jr.jrCommunicationException: java.rmi.MarshalException:
error marshalling arguments; nested exception is:
java.io.NotSerializableException: Server
...".
You'll need to make the Server class "implements
java.io.Serializable". See p152 and p305 in the JR text.
- I'm getting a weird, ugly bunch of errors:
"java.lang.NoSuchMethodException:
MainFrame.<init>(java.lang.String)
at
java.lang.Class.getConstructor0(Class.java:2647)
at
java.lang.Class.getConstructor(Class.java:1629)
at
edu.ucdavis.jr.jrx.jrvm.innerCreateInstance(jrvm.java:163)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:585)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at
sun.rmi.transport.Transport$1.run(Transport.java:153)
at
java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at
java.lang.Thread.run(Thread.java:595)
jrvm exception: java.rmi.ServerException: RemoteException occurred in
server thread; nested exception is:
java.rmi.RemoteException:
java.lang.NoSuchMethodException:
MainFrame.<init>(java.lang.String)
edu.ucdavis.jr.jrCommunicationException:
java.rmi.ServerException:RemoteException occurred in server thread;
nested exception is:
java.rmi.RemoteException:
java.lang.NoSuchMethodException:MainFrame.<init>(java.lang.String)
at
edu.ucdavis.jr.jrx.jrvm.createInstance(jrvm.java:139)
at Start.main(Start.java:23)
...".
You probably forgot to make your remote class constructors public.
- Miscellany:
- "error: Unexpected end of file encountered while reading the
class file". You've probably exceeded your disk quota.
- "sh: Translator.out: Permission denied
expected 0, got 1 from jrc"
when running jrv. You're trying to run jrv in a directory where
you don't have write permissions. If you really want to run jrv,
then copy the vsuite to someplace where you do have write permissions
(and then use "jrv -d ." in that new directory). Do you need to
run jrv? If you're using the already installed JR implementation
in the CSIF, then no. If you've installed your own version of JR
on CSIF, then you should run jrv, but first: why do you need your own
JR when you can just use the already installed one? If you're
running JR on your home machine, then running jrv is a good idea to
check that it works.
- "An exception has occurred in the jr translator ...".
Oops, looks like you found a bug. Please send us your complete program (all .jr files and
whatever data files are needed to run your program) and
we'll try to fix it.