Ans : 

The Java specification actually consists of two parts, the language specification and the Java runtime environment. The language specification, like any other programming language, is independent of the platform on which it is deployed. Java’s runtime environment is a byte code virtual machine (VM) interpreter that allows an applet to run on any given platform. Think of it as a simulated CPU with a platform neutral machine language.

The Java compiler compiles Java source code into Java byte code, and this byte code is executed by the virtual machine. Because the Java environment and virtual machine are platform-independent specifications and have been ported to multiple platforms, compiled Java applets are themselves platform-independent.

There are two browsers that are currently available (or are about to be available) that run Java applets. HotJava is Sun’s Java-capable browser (written in Java) that runs on Solaris and Windows NT. As of this writing, beta versions of a Java-capable Netscape browser are available on Solaris, Windows NT, Windows 95, and of course Macintosh. 

Ans : 

More than likely, the problem is that you are using the version of showDocument with one parameter. This version calls a new page on the browser, which unloads the current page. This leads to two problems: First, the stop() method of your applet is called (no big deal but be aware of it). Second (and more seriously), the AppletContext is no longer valid. The way to get around this is through the use of HTML frames. Create a separate frame for the applet. You can then use the version of showDocument that has two arguments:
getAppletContext().showDocument(new URL("http://www.mysite.com"), "otherframe");
Optionally, you could call up a new web browser window with the following:
getAppletContext().showDocument(new URL("http://www.yahoo.com"), "_blank");

Ans : 

No. If you can't write to your server, you can't save the information on the current count. Your only option is CGI. Sorry. 

Ans : 

Applets can be loaded into Java applications like other user-interface elements, but you must use care to provide them with the connections and support they normally expect to receive from a web browser.

     Applets are a subclass of Panel, which in turn is a subclass of Component - the base class for all Abstract Window Toolkit (AWT) user-interface elements. In terms of building an interface, you can add an applet to a panel or window/frame just the same as you would a button:

     Applet myApplet = ...
     Panel p = new Panel();
     p.add(myApplet);
     p.add(new Button("Press me."));

     Applets generally require much more care, though, in how they are hooked up to the rest of the application. For an application to provide a general framework for linking in applets, it must provide objects that implement the AppletContext and AppletStub interfaces. (Note that one class can implement both interfaces.) For example, in the JDK (1.0.2 and 1.1), an applet call to getParameter gets relayed to an AppletStub object:

     /* in Applet.java (JDK 1.0.2 and 1.1): */
     public String getParameter(String name) {
            return stub.getParameter(name);
     }

     At the very minimum, you can provide an AppletStub object that returns null strings to any request for a parameter. A well-written applet should then provide its own default values.

Ans : 

No; applets can be delivered by standard http servers, just like other nontext data files.

     On the server side, applets exist as Java class files, image files, and any other data files needed by the applet. An http server can deliver these files the same as any others—it needs no special knowledge of Java technology. All the special behavior occurs on the client side, when a Java-enabled browser dynamically loads the class files and builds a running Java applet from them.
     Occasionally, you may encounter an http server that corrupts class files by serving them as text files - MIME type http/text - which is intended for files that use only the lower 7 out of the 8 bits in a byte. Java-compatible class files, however, are binary files; they use all 8 bits in a byte, so they must be sent in a binary mode—MIME type application/octet-stream. A symptom of this kind of corruption is a class format error, such as the following error message from Netscape Navigator:

     # Applet exception: error: java.lang.ClassFormatError
     java.lang.ClassFormatError
                 at netscape.applet.AppletClassLoader.loadClass.....

     If you encounter an http server that you suspect is corrupting its class files in this way, you can advise the server administrators to fix the problem: the relevant server configuration file should be changed to serve .class files as MIME type application/octet-stream.

Ans : 

Java is cross-platform, but that doesn't mean all platforms, browsers, and virtual machines operate identically. However, there are a number of steps a developer can take to ensure that their applet works reasonably well on most browsers.

Use Java 1.0 only. Use a Java 1.0 compiler and a Java 1.0 environment to test in. Do not use Java 1.1.

From day 1, run your tests in Netscape Navigator 3.0 and earlier. Of browsers that support Java, Navigator's probably the buggiest so if you can get something to work there it's more likely to run elsewhere. In particular, do not develop your applets using the appletviewer. The appletviewer's too reliable and too stable to accurately model real user experience.

From day 1, include multiple platforms in your tests and development. You may not be able to test on every platform Java supports, but Windows 95 and the Mac are a must. The Mac VMs in Navigator are some of the worst around so it's important to write for them. Windows NT is also a nice test, but I'd stay away from Solaris unless I had lots of time. It's too stable and reliable. However, Linux makes a very nice test since it's a stable OS (which you're not testing against) combined with a buggy VM and a strange GUI (which you are testing against). If you've got multiple people working on the project, have them work on different platforms and report bugs to each other. Better yet have them switch development environments daily so programmers are forced to make sure their code works in all browsers.

Learn to love layout managers. Provide plenty of extra white space in your user interfaces. Learn to hate absolute positioning. If you must use it, be sure to check font metrics. Don't just eyeball it. 

Avoid filename filters, multiple window interfaces, and other GUI features that don't translate well across platforms. 

I know this sounds a little perverted. I'm telling you to work with the worst tools rather than the best. But right now Sun's promise of "write once/run anywhere" translates into "write once/debug everywhere". And the fact is, users are far more likely to be using the buggy platforms like Mac/Netscape rather than stable ones like Solaris/appletviewer. Working around a bug in one VM generally doesn't cause problems on other VMs. In fact it will probably make your code more portable to platforms you haven't tested. However, assuming that your development environment is bug-for-bug compatible with users' runtime environments does cause problems. It is much easier to work with multiple platforms from the beginning, rather than developing a great app on Windows or Solaris and then porting it to all the other platforms. 

Ans : 

Use code like this,

getAppletContext().showDocument(
new URL("http://www.here.com") );

Or, to show the page in another window or frame,

getAppletContext().showDocument(
new URL("http://www.here.com"), "windowname" );

Ans : Browsers are starting to introduce support for this. Until they all have it, your best bet is to print a screendump. Using the browser to print the page may leave a blank where the applet is. Putting print
support in the applet will print the applet only, not the rest of the browser page.