Ask the Experts

February 12 - February 16, 2007
Experts: Dennis Gu, Calvin Cheung, and Margarita Fisher

Java Plug-in technology establishes a connection between popular browsers and the Java platform. This connection enables applets on web sites to be run within a browser on the desktop. In this Ask the Experts session, Java Deployment team members Dennis Gu, Calvin Cheung, and Margarita Fisher answered a variety of questions about Java Plug-In technology.

Markus Zywitza: What plans for SSV are made for the future? With J2SE 1.6 disabling SSV in the registry is not possible anymore. It is replaced by family clsids that are not supported by most vendors. While I see the need to protect customers from unsecure plugin versions, there are a lot of business critical applications working only with a specified micro version of J2SE. Are there plans to provide administration kits and/or (sufficient) documentation to enable running those applications side by side with applets requiring newer versions?

Calvin Cheung: As of now, the SSV feature will stay in Java SE (aka J2SE) 7. We now have a public document on the family clsids in Deploying Java Applets With Family JRE Versions in Java Plug-In for Internet Explorer. Within the page, it has a JavaScript example on detecting if family clsid support is available from the installed JRE's on the local machine. Disabling SSV in the registry is not recommended nor is it supported by Sun. But it should work in Java SE 6.

Mary Jacqueline Kennett: Sorry if this is naive. I would like to check my ASDL connection speeds and need to download a Sun Java Plug-in to do so. I am always nervous that this will conflict with other software in my Home XP Laptop system. Most of what I have came pre-installed. Is there anything that I should be cautious about before downloading the Plug-in software?

Calvin Cheung: Downloading and installing Sun's JRE which contains Java Plug-In shouldn't have any effect on the pre-installed software. There are couple of ways you can download Sun's JRE. One is to go to the java.com site and click on the "Download now" button. Please make sure to read and follow the instructions in the java.com site. Another way is to download an offline exe bundle from the Java SE Download page. Once you've downloaded the exe bundle, you can double click on it to start the installation.

Carol Frick: I have Java Web start 1.4.2 but applets don't open on certain websites. I've tried troubleshooting as outlined. I've tried upgrading but when I try to download it gets stuck on "checking configuration" and never progresses. I'm not sure at this point what my options are. What I was trying to download was the 5. \ listed on Java.com. When I check my Java start it states there are no upgrades.

Margarita Fisher: Java Web Start comes with the JRE. You can check the version of the JRE installed on your computer by going to the window's control panel and double clicking on the Java cup icon. Check the version of the JRE in the "About" section of the Java Control Panel. You can manually download and install the latest version of Java from the Java SE Downloads page.

Oğuz Yılmaz: I'm working on a project. It is designed as an applet. Indeed, I do not have much info about plug-ins. But I do not want anyone to convert my applet to an application. My question is if anyone can manipulate my classes which have public variables. How can I protect my applet to be converted into application. Can I protect someone to manipulate variables of my classes by making them private or protected? Finally, how much can someone use, exploit or crack my applet (without source code).

Dennis Gu: Theoretically, the applet is running under the sandbox security manager and is very safe to use. When a client is running an applet in the browser, it will download the jar file to its cache and run from it. But it will store it randomly using a different filename and location. Of course you should always use the best security practices in Java to write your applet code. This means things such as using private or package private instead of public variables and methods where possible, and avoid certain security anti-patterns. Then you should be fine.

Margarita Fisher: Java Plug-in allows end-users to cache an applet's resources locally. This means that end users have access to the class files that are generated when your applet is compiled. There are tools that would allow you to convert class files back into Java files. So potentially it is possible to get the source code for the applet. There are other tools, called Java code obfuscators. Such tools would rename classes, fields, and methods using short meaningless names. The resulting jars are smaller and harder to reverse engineer.

Matthew Hey:

1. What are your thoughts about extending the applet tag to have a new parameter to specify that "all the classes are contained within the jar files listed in the archive attribute". When you do a Class.forName lookup the current behavior is for the plugin to connect back to the server and ask for the class. For example, say the user is running Java 5, and you want to check for Java 6 to use some new features via reflection. If you do a Class.forName("java.awt.Desktop") the plugin connects to the server to request the Desktop class. It'd be nice if you could specify a <param name="all_classes_loaded" value="true"> or similar to stop this behaviour.
2. Any thoughts about extending the plugin to allow downloading native libraries? Similar in behaviour to Web Start, i.e., saying if you're running Linux use this library, on Windows use this library, etc. etc. (Rather than the Java Extension mechanism). For security reasons the plugin would only allow downloading libraries if the all of the jars making up the applet are signed and the user has accepted the 'warning' prompt.
3. Is there an equivalent mechanism for "cache_archive" and "cache_archive_ex" for use with the applet tag rather than the object/embed tag?
4. Are there any new plugin features in Java 6 (i.e., since Java 5)??

Calvin Cheung:

1. The applet tag has been deprecated and I don't think it is a good idea to extend the applet tag to support new parameters. However, we can look into supporting it using the object tag. Can you also clarify "say the user is running Java 5, and you want to check for Java 6 to use some new features via reflection"?
2. With Java Web Start, native libraries (.dll, .so, etc.) need to be included in the signed jar files. JSR 277 will support the downloading of native libraries for Java Plug-in. The availability of JSR 277 is currently scheduled to be in our next major release - Java SE 7. See the JSR 277 specification.
3. No, according to the applet tag specification.
4. Yes. Please see Deployment Enhancements in Java SE 6.

Kinnaree Patel: My project requires that I should be able to open all the files whether HTML or non-HTML in the web browser itself. For example, if it's a PDF file or a document file then it should open in the browser itself. If appropriate plug-ins are not already installed then it should download the plug-ins first and then open the file in the browser. How do you do that using Java or maybe even using JSP?

Dennis Gu: Whether the special extension of a file can be opened by the browser is decided by browser's configuration, plus the plugin needed to be installed. For example, if it is .txt or .html, the browser should automatically open it by default. If it is a .pdf file, the Adobe plugin should be installed and registered with the browser so that is can be running inside the browser. In order to do some checkup in the front, you can use JavaScript. If you are trying to run a Java applet and you don't have Java plugin installed, the browser should prompt you with a link and ask you to download from it automatically.

Neil Galarneau: Why is support for the JRE Family Versions supposed to end with Java 6? The ability to specify a major version for applets gives the ISV much needed control over when they upgrade to a major version.

Calvin Cheung: In general, we recommend our customers to migrate to the latest family of JRE at their earliest convenience. The statement which you cited mentions support. That doesn't imply that this feature will disappear in Java SE 7. Also, it will be many years before Java SE 6 reaches the EOSL. We're still evaluating the number of customers who will continue to need this feature and we're planning accordingly.

Frank Klaus: Is it possible to start Internet Explorer 6 from the command line with a command switch that determines which Java plugin should be used? JRE 1.4.1 and JRE 1.5.0 are installed, and we would like to use one or the other depending on the application that we start.

Calvin Cheung: You can start Internet Explorer 6 from the command line with the URL as the argument. For example:

"C:\Program Files\Internet Explorer\iexplore.exe" http://www.sun.com

Starting in JRE 5.0u7 and 6, we have family clsid support for the 1.4.2 and 5.0 JRE family. Please refer to Deploying Java Applets With Family JRE Versions in Java Plug-In for Internet Explorer for details. In your HTML page you can specify the 1.4.2 family clsid so that the latest installed JRE 1.4.2 version on the machine will be used. Note that we no longer support JRE 1.4.1. Please migrate your applet to JRE 1.4.2 or newer JRE versions.

Frank Klaus: Calvin, thanks for your answer, I'll check it out. Can you answer the analogous question when we run Java applications with Web Start: Is it possible to tell Java Web Start which JRE should be used?

Calvin Cheung: Please refer to the Java Web Start 1.5.0 FAQ.

Neil Galarneau: We use applets in a product where we are a service provider to hundreds of other companies. When we have hundreds of companies using our applets anything that makes deployment harder hurts us. Have you considered making Java only need IT support for its first install, but having the updates to newer JREs not require IT intervention? If that would work it would help us stay more up to date JRE-wise.

Dennis Gu: To initially deploy the JRE on desktop machines, you can host the "Get Java" button on your web page. That way users can easily upgrade their machines and get the latest version of the JRE via a simple download. The Java Upgrade Program page has more infomation about the "Get Java" button. After a JRE has been installed on a machine, the Java Update feature will keep the machine up to date with the latest JRE release. Please refer to the Java Update page for details.

Greg Brown: Have you ever considered releasing a version of the Java plugin optimized for delivering rich internet applications (RIAs), along the lines of the Adobe Flash player or Microsoft's XAML browser applications (XBAPs)? Here's my thinking behind this question:

Technically, it is possible to develop RIAs using Java applets, but applets aren't generally as easy to build or as feature-rich as Flex or WPF applications: applets don't support a declarative, XML-based UI markup language like Adobe's MXML or Microsoft's XAML, and the Java GUI toolkits, AWT and Swing, are a bit dated and overly complex by comparison. Additionally, the Java Plugin is a significantly larger download and requires a lengthier installation process than the Flash Player (the .NET 3.0 runtime required by XBAPs is pre-installed on Windows Vista systems and will supposedly be installed via auto-update in Windows XP, so no download is required).

However, Java could, and should, be the leading platform for developing rich internet applications (RIAs) today. It is a solid, proven technology that is actively supported across all major operating system and browser versions. What is needed is a streamlined "Java Player" (possibly called "Java PE", for "Plugin Edition") that can be easily downloaded and installed by end users and is capable of running the "next generation" of Java-based web clients (imagine a Flash-like player with a JVM as a runtime rather than ActionScript).

Java PE would contain a complete, but scaled-down, version of the standard Java runtime, and would include a minimal set of classes required by all applications (for example, java.lang, java.net, and a GUI library - see below). Packages that aren't useful to most browser-based Java applications, such as RMI, JDBC, and CORBA, would not be included. However, the player would allow developers to specify additional required libraries to be downloaded (and cached) at runtime on a per-application basis, similar to Java Web Start. This approach would keep the initial plugin download size small but would allow developers to add additional functionality incrementally as needed.

Ideally, the player would include a new GUI toolkit optimized for delivering the best possible user experience on modern graphics hardware. This toolkit would support a declarative syntax similar to MXML or XAML, allowing developers to quickly build and deploy visually engaging applications for the player. However, it might also be useful to allow developers to specify a GUI toolkit as a runtime download; this would allow the player to run applications built using AWT, Swing, or even SWT without requiring the player to have built-in support for each toolkit, which would increase download size.

I realize that this would represent a significant departure from today's Java Plugin, but I believe that it would allow Java to compete effectively with newer rich client-enabling technologies and would create a strong platform for future web-based application development. What are your thoughts?

Margarita Fisher:There has been some investigation and prototyping going on to address the initial JRE download size issue. See Ethan Nicholas's blog. Also, check out Form follows function (f3) to find some answers to your comment on declarative language for Swing and Java 2D.

Ed O: I understand that Java applets and Plug-In applications running on Internet Explorer cannot access locations outside of the IE7 sandbox in Vista. Is this true? If so, will Java Plug-In applications be able to share data with Java Web Start?

Dennis Gu: Window Vista has built in new sandbox security, which restricts access to the filesystem from the browser process and everything associated with it. Java Plug-In is wholly contained within that IE7 sandbox. In order for Java Plug-In applications to share data with Java Web Start, we have changed our caching directory to a "Low" privilege directory. Therefore, other applications such as Java Web Start will be able to read and write to that directory as well. For more information, please see Chet Haase's blog Java on Vista: Yes, it Works.

Roger Nell: If I have two applets on a single page, how many JVMs are running? If I have two pages open on different tabs <ctrl-t> or different windows <ctrl-n> each with a single applet, how many JVMs are running? Is there a difference between FireFox and IE? Is there a technical article that addresses these questions?

Calvin Cheung: On windows, our JVM runs within the browser process. Currently, only one JVM can be loaded per browser process. Therefore, there's only one JVM for the above mentioned scenarios. There is a slight difference between Firefox and IE. For IE, you can have multiple IE processes (iexplore.exe). For Firefox, you can only start one Firefox process (firefox.exe). For example, if you double-click on the Firefox icon and then double-click it again, you'll see two Firefox browser windows but only one Firefox process. This is due to the differences in the browser design.

Kanda D Han: I want to install Java plug-in for my computer. How do I do it?

Margarita Fisher: Java Plug-in is part of the JRE. You can manually download and install the latest version of Java from the Java SE Downloads page.

Ezequiel Cuñado: I have a question about installing a system with some applets. I'd like users to be able to download and install the Java plugin automatically. The problem is that they are under a firewall and they can't access this url: http://java.sun.com/products/plugin/1.1.2/jinstall-112-win32.cab#Version=1,1,2,0. I don't want to manually install the plugin on each machine. I'd like users to be able to install by themselves (they are not advanced users). Can I place the plugin in my server machine? What is the best and easiest way for users to install it?

Calvin Cheung: We no longer support the Java Plug-in 1.1.2 version and therefore the above URL is no longer valid. For autodownload, please use the following URL for the latest JRE 5.0 update release:

http://java.sun.com/update/1.5.0/jinstall-1_5-windows-i586.cab

or the following URL for the JRE 6 release:

http://java.sun.com/update/1.6.0/jinstall-6-windows-i586.cab

Alternatively, the user can visit the java.com page and click on the "Download now" button to download and install the latest JRE available for consumers.

javier5005: I must use some programs from the government and other institutions, including some secure pages to access different institutions. However, they require different versions of Java to access, to install, or to work with. So this obligates me to first uninstall and then install the version required every time. This is a real nightmare. I've tried changing the configuration on Java Control Panel -JNLP configuration, but this doesn't work. How can I keep Java updated, and choose the right version for each program, page, and installer? I would think that the updated version MUST support any program made with older versions, correct?

Dennis Gu: The Java Update feature will keep your machine up to date with the latest JRE release. For more information, please see refer to the Java Update Guide.

Cindy Vogel: Can an applet written in JDK 1.4.2 invoke Java Scripts or vise versa in the following browsers?

Safari 1.2+
IE 5.x+
Mozilla 1.0+

Dennis Gu: We do support Java to JavaScript using LiveConnect in JDK 1.4.2 and above for IE5.x+ and Mozilla 1.0+ browsers. The Safari browser uses the Java Plug-In supported by Apple, and I think it supports LiveConnect as well for Safari 1.2+. Also see the document Supported System Configurations in Java 2 Platform v1.4.2.

Cindy Vogel: Dennis, thank you very much for the answer. I have found the instructions on how to invoke Javascript from applet for JDK 1.5 at http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/java_js.html. But I could not find a similar online document for JDK 1.4.2. Would you please send me the link if there is one?

Is JRE 1.4.2 the most widely installed Java runtime version? If not, which JRE version is? We are planning to develop an applet to run on IE, Firefox/Mozilla (on both Windows and Mac OS), and Safari browsers. Should we write the applet to JDK 1.4.2 or other version? How to set the applet parameters so that it can run on any JRE installed on a client machine? Our goal is to minimize the probability to download and install JRE for our end users.

Dennis Gu: Here is the doc for JRE 1.4.2: the Java Plug-In 1.4.2 Developer Guide. I think they are pretty similar. The most popular JRE now is JDK 5.0 with update release. JDK 6 was just released end of last year. If you deploy a new applet, I would like you to use either JDK 5.0 or JDK 6. If you use the OBJECT/EMBED tag in an HTML file, you can specify the version number to ask which JRE to run. Here is an example for the EMBED tag:

http://webcem01.cem.itesm.mx:8005/web/java/tutorial/deployment/applet/embedtag.html

Tim Strawhacker: My plug-in uses static versioning to download a 1.4.2_13 plug-in. When it does so, the active JRE in the Java control panel changes to match, and things work fine. But, if a user later changes the active JRE setting in the Java control panel back to the previous setting (in this case, 1.4.2_08), IE6 dies, the whole browser, as soon as the user goes to the web site with my applet. Crashing the browser is pretty drastic behavior. Is there anything I can programmatically do to handle this situation?

Margarita Fisher: I am not quite sure what you mean by "changes the active JRE setting." Here is my understanding of what you are trying to describe. After the user installed JRE 1.4.2_13, s/he opened the Java Control Panel for JRE 1.4.2_13 and in the "Advanced" tab selected a different JRE (namely 1.4.2_08) from the drop down list. The above makes the Plug-in from 1.4.2_13 use the Java VM from 1.4.2_08. This feature is not supported. The Plug-in is tightly coupled with the JRE it comes with and should only use the Java Runtime Environment it came with. It is expected that the Plug-in from one version of the JRE might not work with the Java VM from another version of the JRE. This is why the option to specify a different version of the Java runtime has been removed from Java Control Panel starting with JRE 1.5.0.

There is no way for your applet to determine if the Plug-in is using a different version of the JRE because your applet never starts. The first thing the plug-in tries to do is start the VM. Since it does not succeed in starting the VM due to version incompatibility, your applet will never start to handle this situation.

If I did not understand your use case scenario, please send me more details on the steps your user takes to "change the active JRE setting."

Tim Strawhacker: Nope, I think that pretty well covered it. The short answer (that I passed along to my manager) is for our documentation to simply tell the users "don't do that" (although one of the users said they didn't do it, but simply had the Java control panel open -- apparently that kept the 1.4.2_08 plug-in selected?). I'm surprised that the consequences are to crash the whole browser, but it doesn't matter. The customer just shouldn't do that.

I'm also wondering what to do with customers who have the 1.5.0_06 plug-in installed. As I understand it, that build disallows static versioning, but doesn't contain the family clsid that went in with 1.5.0_07 as an interim solution. Some of our customers aren't going to be able to just upgrade the plug-in manually -- short of telling the customers that our product won't work correctly with a 1.5.0_06 plug-in installed, what can we do?

Margarita Fisher: The idea of the SSV is to disallow usage of older JREs if a newer JRE is available. This is done for security reasons. So customers who will have 1.5.0_06 installed won't be able to run your applet with an older JRE. The best thing to do is migrate your applet to run with the newer JRE.

Andrey Ashikhmin: When will Java Plug-In Technology be supported in 64-bit distributions of the JRE?

Calvin Cheung: Java Plug-in will be available in 64-bit JRE distributions in Java SE 7.

Steve Harper: I'm about to write the HTML page for an applet that will be deployed using IE on intranets using the 1.6 JRE. The 1.6 Plugin documentation on Intranet deployment with IE says that we can download the JRE from our own WebServer by using something like:

"http://my_company.com/plugin/jre-6-rc-windows-i586.exe#Version=6,0,0,99"

It appears that for 1.6 you've changed the way version is stated. Is 99 the "bug fix" version associated with the first release? Where would I find what to change 99 to for the next release? Will that be published on the page where I download JRE's from Sun. Also, does it make any sense to use the static version format of the classid for Java 6? Or does Family classid make any sense? The article on Family classid available from the Java 6 Release Notes says of the Family classid feature: "Support for this feature is expected to be withdrawn in the Java Platform, Standard Edition 7 (Java SE 7)." So it makes no sense to use that to prevent my Java 6 applet from every running under Java 7, right? Or would using the good old ClassId of: 8AD9C840-044E-11D1-B3E9-00805F499D93 make most sense for a Java 6 applet? As you can tell, I'm confused.

Calvin Cheung: The 4 numbers in the version have the following meaning:

• The first one, 6, corresponds to the major version
• The second one, 0, corresponds to the minor version
• The third one, 0, corresponds to the update version multiplied by 10
• The fourth one, 99, corresponds to the build number

For example, for JRE 6u1 b02, the version will be 6,0,10,2.

We've been using this versioning scheme since JRE 5.0u2. It is used for better error reporting. In case there is a crash and a Hotspot error log is generated, we can see exactly which JRE version and build was used to produce the problem.

Regarding the family clsid support: since the document has been made public, we have found many customers deploying applets requiring older versions of JREs, so we will likely continue support for the family clsid in Java SE 7 and beyond.

Steve Harper: Here's a snippet of my HTML page that uses static versioning:

<OBJECT classid="clsid:CAFEEFAC-0016-0000-0000-ABCDEFFEDCBA"
Width = 420 Height = 150
codebase="./codebase/jre-6-windows-i586.exe#Version=6,0,0,99">
<PARAM NAME="type" VALUE="application/x-java-applet;version=1.6">

How does the new 6,0,0,99 version relate to the one used on the application/x-java-applet;version value? Is what I have above correct? Does IE even use this other "version" value (is it only for Mozilla browsers?)

Calvin Cheung: Since the Java Plug-in for Internet Explorer is implemented as an ActiveX control, you don't need to use the "type ". The "type " parameter is used in the EMBED tag for Mozilla browsers. Please refer to the section Deploying Applets in a Mixed-Browser Environment in the Java Plug-IN Developer Guide for J2SE 5.0 for details.

Phil Lambert: How do we prevent untrusted web pages from calling a previous version of the JRE when the clsid calls are used?

Calvin Cheung: If you have JRE 5.0u6 or a newer version installed on your machine, your machine is protected from untrusted web pages using a previous version of the JRE. Please refer to the alert Java Plug-in and Java Web Start May Allow Applets and Applications to Run With Unpatched JRE.

Kai Nerda: What is SSV?

Dennis Gu: SSV stands for Secure Static Version. It is a feature that allows an HTML file to specify which JRE family to run. For more information about this feature, please see the documents Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer and the alert Java Plug-in and Java Web Start May Allow Applets and Applications to Run With Unpatched JRE.