Ans : 

There are five common mistakes that cause your VM (java or browser) to be unable to execute your classes
1. First, did you write an applet or an application? If an applet, you must make sure that you did extend the java.applet.Applet class. Your starting code should be in the init routine. If you wrote an application, your starting code should be in a routine called main(). Don't mix applets with applications until you have a bit more experience.
2. You must declare your main class as "public". If you don't, unfortunately some systems will still run the code, while others won't. The main class is either the one with the main() method in, or in the case of an Applet, the class that extends Applet.
3. Your class name and the file name must match exactly, even letter case. If your class is HelloWorld, your source file must be HelloWorld.java and your class file will be "HelloWorld.class".
4. If an Applet, and you used ftp to transfer the classes to the server, you must ftp all the classes, and you must use BINARY transfer not ASCII.
5. Errors in setting the CLASSPATH (and/or codebase in an applet). Even seasoned programmers do this, pointing inside a package or mistyping a path delimiter. For information on setting up the
CLASSPATH and codebase, 

If you are running an applet, you should check the following further points:
1. If your class isn't loading, recheck the HTML applet tag.
2. If you are writing to System.out, the results are displayed in the browser's java console. You'll have to create a window if you want one.
3. Make sure your browser is compatible with the Java language features you are using. Internet Explorer and older versions of Netscape's browsers have omitted some support for JDK 1.1. Try your applet in the JDK's appletviewer first.

Ans : 

">>" is a "signed" or "arithmetic" shift, namely, it replicates the sign bit on the left as it shifts.
The ">>>" operator is an "unsigned" or "logical" shift; it does a shift right and zero fill. However, ">>>" looks like it does a signed shift with negative bytes and shorts, where int promotion alters the sign.

This occurs when you have a non-canonical type, byte, or short, with a negative value, e.g.

byte b = -15; // 0xf1
b = (byte) b >>> 4; // why isn't b 0x0f ?

The initial expectation is that an unsigned shift right of 0xf1 would successively be (in binary)

0111_1000 then
0011_1100 then
0001_1110 then
0000_1111

But that doesn't happen. The rules of arithmetic in Java say that all operands are converted at least to int before the operation (and possibly to a more capacious type). That means our byte is promoted to an int, so instead of shifting 0xf1, we are shifting 0xfffffff1. If you shift right unsigned 4 places, you get 0x0fffffff. When you cast that to a byte it becomes 0xff, or -1.

The bottom line is that the final result is the same as if you had performed the signed shift because the unsigned shift applied to the intermediate int, not to the original byte. This anomaly means that ">>>" is useless for negative bytes and shorts. It is probably safer and clearer not to use it at all, but to mask and shift instead:

// not recommended
byte b = -15;
b = (byte) (b>>>4);
System.out.println("b= "+Integer.toHexString(b) );
// recommended
b = -15;
b = (byte) ( (b & 0xFF) >> 4 );
System.out.println("b= "+Integer.toHexString(b) );