Applets on Linux

[Rob Hunter]

What steps do / should you normally follow to put an applet .class on a Linux web server? I'm trying to get an applet class to work on a local Linux server that is already working on a Windows machine. Bringing up a webpage on Windows works fine but doesn't work on Linux. Since I haven't gotten any suggestions that have helped resolve the problem (although I appreciate all responses) I thought maybe I should note all the steps taken initially and see if I missed something.
When I run java -version on the Linux server (if that helps):

java version "1.6.0_17"
OpenJDK Runtime Environment (IcedTea6 1.7.3) (suse-7.3-i386)
OpenJDK Client VM (build 14.0-b16, mixed mode)

[Peter Johnson]

What browser are you running on Linux? Does this help:
http://www.redips.net/firefox/enable-java-applets/

[Paul Clapham]

Peter, it would probably help if you read all of Rob's recent posts before trying to answer. There's a lot of background which has been left out of this latest post.

[Rob Hunter]

:-) Paul. I was hoping someone could just list out what steps they would take if they were first trying to get an applet to work. Maybe the first (basic) steps needed (if listed out) might point to something I haven't done.

[Rob Hunter]

Is there anything simplier I can try such as going on the Linux server and trying something directly (i.e. like an appletviewer or equivalent)? Start at more basic steps if can be so as to try and diagnose the problem? Any help would be appreciated as I'm getting well beyond frustrated with this. Thanks again all.

[Rob Hunter]

More general question now. When a client requests an applet what steps are passed through to get the applet? What happens on the client and the server when trying to get the applet (i.e. where does JRE and/or JVM come into play on the client and server)? I'm trying to compile the applet code on the Linux machine and it's complaining about the line :

   warning: The import javax.swing.JApplet is never used
   import javax.swing.JApplet;

I'm trying to extend JApplet in this class.

[Tim Holloway]

It actually isn't all that different running an applet on Linux than on Windows, especially since Microsoft doesn't provide any of its "useful" features to Things Java.

There are 2 major differences, however:

1. No one-size-fits-all Linux installer exists, so installing the JVM and browser plugins can be a challenge.

2. 64-bit Linux systems do have issues with Java (as well as Flash).

The browser MUST have a plugin. If there's any browser on any OS that has Java already built in, I don't know of it. But it's probably written in Java.

When the browser formats an HTML page that contains an applet reference, the plugin determines which installed JVM to use and makes URL requests for the applet's resources as defined by the HTML element context for the applet. Just to make this more fun, Microsoft used one method of referencing and the rest of the world used another so to be truly portable you needed a composite set of elements that would appeal to both environment. This is the most glaring exception to the "write once/run anywhere" model.

The applet itself runs on the client, using a JVM installed in the client operating in applet mode. The applet classloader knows to make URL requests for resources rather than look in the local path (which would be a security issue). It also ensures that the JVM is running under applet sandbox rules. Only a JRE is required to run applets - you don't need a client-side JDK.

[Ernest Friedman-Hill]

Rob Hunter wrote: I'm trying to compile the applet code on the Linux machine and it's complaining about the line :

   warning: The import javax.swing.JApplet is never used
   import javax.swing.JApplet;

I'm trying to extend JApplet in this class.

This is very worrisome. Perhaps you've got your own class named "JApplet" which is being extended accidentally? If your "applet" doesn't actually extend JApplet (or java.applet.Applet) it's not going to work in any browser.

But this is all getting too confusing: you need to solve one problem at a time. I see at least three completely separate things going on here:

1) Writing and compiling your applet
2) Serving your applet from a web server
3) Viewing applets on a Linux machine

You can and should solve each of these separately. For example, solve (3) by trying to view applets on some other known-good web site. Check the success of (1) by viewing your compiled applet in the "appletviewer" application that comes with the JDK. When you know (1) and (3) are OK, then and only then should you tackle (2).

[Rob Hunter]

Hi Ernest,
My class isn't named JApplet for both classes that extend JApplet and JPanel. Everything went smoothly with Windows so my frustration hit the roof after trying to get it working on Linux.
1. The problem I was having with compiling was that I wasn't putting "-cp ." after javac. I have 2 classes, one that extends JApplet and one that extends JPanel (in the extended JApplet class I make an instance of the extended JPanel class). When compiling the extended JApplet class it was complaining about the line I tried making the instance. I had thought because they were in the same directory I didn't need to do anything with the path but I guess I needed to include "-cp .". That works fine for me now.
2. The applet works fine when being served by a Windows server and when I try typing the URL of the .class in the browser directly I get a 500 server error. The URL is the same URL that comes up in the Java console when it complains it cannot find the class.
3. As you suggested I tried this on the Linux server, I'm ssh-ed into the Linux server and trying the appletviewer (I used /usr/lib/jvm/java-1.5.0-gcj-4.5-1.5.0.0/bin/) and I get the following :

java.lang.StringIndexOutOfBoundsException: String index out of range: 0
   at java.lang.String.charAt(libgcj.so.11)
   at gnu.javax.swing.text.html.parser.htmlValidator.validateNameOrIdAttribute(l
ibgcj.so.11)
   at gnu.javax.swing.text.html.parser.htmlValidator.validateAttribute(libgcj.so
.11)
   at gnu.javax.swing.text.html.parser.htmlValidator.validateParameters(libgcj.s
o.11)
   at gnu.javax.swing.text.html.parser.htmlValidator.openTag(libgcj.so.11)
   at gnu.javax.swing.text.html.parser.support.Parser._handleStartTag(libgcj.so.
11)
   at gnu.javax.swing.text.html.parser.support.Parser.restOfTag(libgcj.so.11)
   at gnu.javax.swing.text.html.parser.support.Parser.Tag(libgcj.so.11)
   at gnu.javax.swing.text.html.parser.support.Parser.parseDocument(libgcj.so.11
)
   at gnu.javax.swing.text.html.parser.support.Parser.parse(libgcj.so.11)
   at gnu.xml.dom.html2.DomHTMLParser.parseDocument(libgcj.so.11)
   at gnu.classpath.tools.appletviewer.TagParser.<init>(libgcj-tools.so.11)
   at gnu.classpath.tools.appletviewer.StandaloneAppletViewer.<init>(libgcj-tool
s.so.11)
   at gnu.classpath.tools.appletviewer.Main.main(libgcj-tools.so.11)
Exception in thread "main" java.io.IOException: Exception: String index out of r
ange: 0
   at gnu.xml.dom.html2.DomHTMLParser.parseDocument(libgcj.so.11)
   at gnu.classpath.tools.appletviewer.TagParser.<init>(libgcj-tools.so.11)
   at gnu.classpath.tools.appletviewer.StandaloneAppletViewer.<init>(libgcj-tool
s.so.11)
   at gnu.classpath.tools.appletviewer.Main.main(libgcj-tools.so.11)

Any suggestions to what's going wrong here? It's the exact same code as on Windows and the exact same parameters are being passed in the PARAM tags to the applet as well. I should now that on the Windows server where I compiled the code the java version is 1.6. Thanks so much for your response and help. I really appreciate it.

Robert Pike

[Tim Holloway]

The current directory is never implicit in the classpath for a Java compile or execution. It's as much for security reasons as anything else. So if you want it, you have to ask for it. And that's true under any OS. Windows, Linux, whatever.

You cannot request a class directly from a browser and expect it to work. At best, the binary contents of the class will simply download and either display in the browser window or ask for a place to be saved. At worst - when the class is in a jar - it simply won't be accessible at all. You have to reference the class in terms of the HTML applet elements so that they will invoke the browser's applet run plugin. The plugin will then download the classes and jars into the JVM it invokes to run the applet.

I see your browser is set up to use the "gcj" Java implementation. gcj isn't a very good choice even though it's what comes with the OS. For one thing, Swing support is questionable. For another, there are certain incompatibilities.

A 500 server error is an indication that something major is wrong. Most likely in the process that builds a page that presents the applet. You never get a 500 error from client-side applet code.

But the server should DEFINITELY not be running under gcj. J2EE doesn't work well at all under gcj. Use the Sun, er Oracle JVM or something equally robust.

[Rob Hunter]

Hi Tim,
Just so I fully understand the process going on. When the client makes a request to the Linux server what happens on the server-side involving Java and what happens on the client-side Java-wise that gets the applet to eventually perform the tasks it needs to do?
"For one thing, Swing support is questionable. For another, there are certain incompatibilities." - comments like these make me wonder because of my lack of understanding of the overall procedures taken to finally display the applet.
Right now the browser is making a request to the server for a html page and all is fine in that regard, it also is running some cgi apps I have with no problem. I'm just wondering how requesting plain html pages and requesting the applet differs from the server perspective. I thought the applet would be retrieved in the same sort of manner and then handled on the client-side within a container. If I understood this more I could probably eliminate some of the things I'm looking at.
You suggested getting a different version of java - would that help only with the appletviewer or also with retrieval of the applet as well? Sorry for the basic questions but I'm not 100% sure if some of the assumptions I had were correct or not.
Thanks again for the help/info Tim. I appreciate your (and everyone else's) help and time.

Robert Pike

[Tim Holloway]

No special processing goes on on the server when applets are run. The server serves up the applet jars and classfiles the same way it does image files, javascript files, or css files. The applet code is NOT embedded in the applet page HTML, only a reference to the applet, just as the HTML img tag is only a reference to an image. And, incidentally, files under WEB-INF cannot be used in applets because the server doesn't "see" files in WEB-INF for download purposes. So Applet classes and jars have to go in the "public" part of the WAR.

The difference between an image and an applet is that an image doesn't require a browser plugin to render, because image rendering is already built int.

The applet tag includes an OBJECTID or (Microsoft CLSID) reference that tells the browser to activate the applet plugin. Actually, they're intended for any sort of plugin, but if you use the ID assigned to the applet plugin, that's what gets started.

The applet plugin then makes separate URL requests to the server to retrieve the classes and jars that were requested as part of the HTML tags that invoke the applet. These URL requests are just plain-vanilla HTTP file download requests just like the one that the built-in IMG tag processor uses to download an image. The difference is that the plugin passes the downloaded files to the JVM that it's using so that that JVM can find and run the applet code.

So I think you've got the right general idea.

As far as JVMs go, if you're running the J2EE server on Linux, it should be running a Sun-compatible JVM (not gcj). The same is true for browsers running on Linux client machines. In the first case, it's because gcj doesn't handle J2EE very well. In the second case it's because gcj doesn't handle Swing very well, either. If the applet doesn't run using Swing, it MIGHT work, but Swing isn't the only part of gcj that's not up to spec, so I can't guarantee.

[Rob Hunter]

Hi Tim,
Not knowing Linux that well and trying to simplify my question without throwing in additional elements that might further confuse, I left out an important part. The overall application I have is written in both Perl, Java, and HTML. In cgi-bin I have a Perl executable that reads files from the htdocs directory, parses, and prints to the output buffer. The problem lay with having the mods.md.*.class files underneath the cgi-bin directory. I moved the .class files to the htdocs directory and adjusted my applet tag properties accordingly and it now works fine. One question though: how (or can I) set the cgi-bin directory to accomodate both executables and also .class files? I would prefer having the setup in the way I had it with the scripts and classes in the same directory structure unless you can suggest a better way of doing it. Thanks so much for the help as well. I really appreciate it.

Robert Pike

[Tim Holloway]

Don't even think about it. For security purposes, the cgi-bin directory should not be inside a WAR. Otherwise you're at risk for people finding a way to download, dissect, and possibly hack your CGI code.

Also, Java server-side classes cannot run from cgi-bin, since that's not part of the J2EE classpath.

Applet classes (and jars) shouldn't be in cgi-bin, since they have to be downloadable, and, as I said, you don't want anything in cgi-bin to be downloadable. cgi-bin is for server-side logic.

[Rob Hunter]

Hi Tim,
Right now the 2 .class files are in a browsable directory, same as html pages are so they are downloadable. What the quickest/easiest/etc.., way to put the files into a more secure setup without requiring much from someone who wants to put it on their system? Thanks again.

Rob

[Tim Holloway]

There are limits on how secure you can make this. The class files must be publicly downloadable, which means that they have to be publicly readable. Essentially, that means that the same type of rules apply for class files as for image or javascript files.

[Pat Farrell]

Expanding on what Tim H said, there are limits. Which raises the question: why are you trying to use applets in 2010? They made sense last century.

[Tim Holloway]

Pat Farrell wrote:Expanding on what Tim H said, there are limits. Which raises the question: why are you trying to use applets in 2010? They made sense last century.

I wouldn't go that far. Sometimes you have really gnarly logic that is best handled client-side. Your options are:

1. JavaScript (which I like less every time I use it)
2. ActiveVirus, er ActiveX controls. Assuming that you never intend to sell anything to anyone who uses anything but IE/Windows
3. Flash. Assuming you like security issues and having to do your editing with non open-source products
4. Java Applets.

It can be a real nuisance to run applets, since the JVM neither comes built into Windows nor installs trivially like Flash. However, if your client audience is suitable, it's much more secure than the other options and more performant than many of them as well.

I should point out that the security issues on how to locate JavaScript, ActiveX, and Flash components are basically the same as for Applet classes, so you don't lose anything there, either.

[Pat Farrell]

Tim Holloway wrote: Sometimes you have really gnarly logic that is best handled client-side. Your options are:

1. JavaScript (which I like less every time I use it)
2. ActiveVirus, er ActiveX controls. Assuming that you never intend to sell anything to anyone who uses anything but IE/Windows
3. Flash. Assuming you like security issues and having to do your editing with non open-source products
4. Java Applets.

I agree that Javascript is evil, has the same security concerns, etc. And both ActiveX and Flash give me the willies. I truly believed in applets last century. I spent months and months working on it. My efforts were not rewarded.

These days, I just use jQuery and let it handle the issues. With Google's CDN, you often don't have to have your client pay for the download, since jQuery is used so widely.

Back on topic, an applet is just a binary blog delivered by the HTTP server. Whether its hosted on Linux, BSD or Windows should make no difference.