Saturday, November 15, 2008

Java Web Start Faq's

General Questions

What is Java Web Start?

Java Web Start provides a platform-independent, secure, and robust deployment technology. It enables developers to deploy full-featured applications to end-users by making the applications available on a standard web server. With any web browser, end-users can launch the applications and be confident they always have the most-recent version.

Why should I use Java Web Start?

It's an easy, robust, and secure way to deploy applications directly from the web. Developers can make applications readily available via the web. In addition, Java Web Start provides Java runtime environment (JRE) management capabilities, it's easy to set up, it's browser-independent, and it's an efficient way to deploy web application solutions.

Users can easily access applications much as they would a web page--without a separate installation step. From the desktop, users can access and use Java applications, using a richer and more responsive user interface than is available on a web page. And, once a Java Web Start based application is installed, users simply click to run the application whenever needed.

Users do not need to manually update applications because each time they launch an application, it is transparently updated from the web--so they always use the most recent version available.

How can I launch applications with Java Web Start?

You initially launch a new application by clicking on a link from a web page.

If you use an application frequently, create a shortcut from your desktop or from the Start Menu by allowing Java Web Start to place an icon on your desktop. Java Web Start may ask if you would like to create
shortcuts or an entry in the Start Menu. If you say "yes," all future launches of the application can start without a browser.

Java Web Start also provides an Application Cache Viewer which you can launch from the Java Control Panel. The Cache Viewer enables you to directly launch applications you have downloaded.

You can also launch an application from a command prompt by typing “javaws ” where

Does it matter how I launch an application?

No, applications launch in the same manner no matter which method you use: from a web page, from the shortcut on the desktop, from the Start menu, or through the Java Application Cache Viewer.

Java Web Start always checks to see if a newer version of the application is available for use and automatically downloads it if so.

If the application you are using has not been digitally signed, Java Web Start will launch it in a restricted and secure execution environment. An application that is not signed, or one that you do not trust, will never be run with unrestricted access to your local system or network.

What are the system requirements for Java Web Start?

Any client system that supports the Java version 1.2.2 or higher can use Java Web Start. Java Web Start works with virtually all browsers.

What platforms does Java Web Start run on?

Sun Microsystems provides versions for Windows 98/NT/2000/XP/2003, Solaris Operating Environment (SPARC and Intel editions) and Linux/i486. Apple provides a version for their OS X release.

What are the server requirements for Java Web Start?

Java Web Start uses HTTP for communication between the client and the server. You can use a standard web server to host an application. If you require additional services, such as version-based downloading, incremental updates, or pack200 compression for your applications, the web server will need to support servlets or Java Server Pages. A sample servlet implementing these features is provided in the samples directory of the JDK.

Is Java Web Start based on a standard?

Yes. Java Web Start 1.5.0 is the product-quality reference implementation of Java Network Launching Protocol (JNLP) technology, which was developed through the Java Community Process. JNLP is specification number JSR 056. Other platform vendors are encouraged to port Java Web Start to their platform or implement the specification.

For more information, see the JNLP specification.

Can I implement my own Java Web Start?

The underlying technology for Java Web Start, the Java Network Launching Protocol and API is being developed through the Java Community Process, so you can implement this protocol in any product. However additional licensing and terms must be met to implement any JCP technology including the JNLP technology.

What are the supported browsers?

Java Web Start supports primarily Internet Explorer 4 or higher and Mozilla. However any browser can launch JNLP files if you have set the MIME-type association correctly. Java Web Start uses the browser's settings and may launch a browser to show a URL; this feature may not work with unsupported browsers.

Is there a comprehensive list of online resources for Java Web Start?

· Java Web Start documentation page: http://java.sun.com/j2se/1.5.0/docs/guide/javaws/index.html

· Developer's Guide: http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/contents.html

· Java Web Start Discussion Forums: http://forum.java.sun.com/forum.jsp?forum=38

· JSR-56: http://jcp.org/en/jsr/detail?id=56

Can I deploy any application with Java Web Start?

Java Web Start is an application launcher for Java applications that are written to be web-deployed.

An application must be delivered in a set of JAR files and all application resources, such as images, configuration files, and native libraries must be included in the JAR files. The resources must be looked up using the method ClassLoader.getResource() or an equivalent method. Java Web Start only transfers JAR files from the web server to the client.

If an application is written to run in a restricted execution environment (sandbox), then access to disk is not permitted and the application may only connect to the host on which it resides.

Is Java Web Start a software distribution mechanism like Marimba and MS SMS?

Java Web Start is an application launcher for Java applications. It allows easy distribution of full-featured applications based on the Java platform from a web server to a client machine with minimal user interaction.

The software distribution technology is only one aspect of Java Web Start. It also provides security, updates to the applications, ease-of-use for end users, and flexibility for developers when they create the applications.

Is Java Web Start an application installer?

Java Web Start is an application launcher for Java applications that are written to be web-deployed. Java Web Start caches resources locally on the disk, but also provides a secure execution environment and a virtually transparent updating facility for applications. The end user does not need to manually initiate a software update because the application is updated each time it is used.

What version of the Java platform does Java Web Start work with?

Java Web Start launches only applications written for the Java platform versions 1.2.2 and higher.

How does Java Web Start relate to Java Plug-in Technology (applets)?

The two approaches are very similar. The key difference is in the user experience. If the Java application/applet needs to interact with a web page and be tightly bound to a web browser, then applets may be the solution. On the other hand, if browser independence is important, then Java Web Start is the deployment platform of choice. There are a number of other differences, but this is the fundamental difference.

Java Plug-in technology enables users to run Java applets inside a browser.

Java Web Start enables users to download full-featured applications with any browser. Once they have downloaded and launched an application, the browser can be closed, while the application continues working. The application does not depend on an open browser to function. The browser can be shut down or you can go to a different web page and the application will continue running.

Technical Questions

Do I need to change my application to work with Java Web Start?

If your application is written to the Java 2 platform, and is delivered as a set of JAR files, there should be no need to revise your application. Make sure that your application retrieves all its resources (such as images and resource bundles) from a JAR file, since Java Web Start launches an application by invoking the public static void main(String[] args) method.

If your application needs unrestricted access to the system, (for example, network or disk access), you will need to sign your code.

Is there a migration path from applets to applications?

Java Web Start is primarily designed for application deployment. You specify all requirements for your application in the JNLP file, and off you go. It does provide the ability to launch applets in much the same way as the traditional AppletViewer. The built-in AppletViewer provides an easy migration path for existing applets that want to take advantage of Java Web Start. However, it is not intended to be a full implementation of the Plug-In. The Plug-In is the primary launching vehicle for applets. The built-in AppletViewer in Java Web Start has limitations, for example, you cannot specify class files as resources and it does not accept policy files.

Is there a way to pass VM arguments to the Java Runtime?

Java Web Start allows certain JVM flags to be set with the java-vm-args attribute of the j2se element (see Developer's Guide). Allowing the complete set could compromise security as well as limit portability across different platforms and implementations. You can set the maximum and initial heap size using the initial-heap-size and max-heap-size attributes of the j2se element, for example:

I don't want to rely on a server timestamp. How can I specify a versioned JAR and how can I get incremental updates of JARs?

Java Web Start supports versioned JARs and incremental updates. You can specify exact versions of the JAR files you want, instead of relying on timestamp information to determine if an update is available. Using version IDs also allows you to provide incremental updates from one version to another. See the JNLP Specification or the

Developer's Guide for details.

Are JAR files shared between applications?

Each JAR file that a JNLP Client (such as Java Web Start) downloads, is uniquely identified with a URL. If two JNLP files use the same URL, then the resource will only be downloaded once and shared. This is similar to the caching implementations used by web browsers.

How can I provide my own splash screen?

Java Web Start needs to put up the initial splash screen while Java is loading. For subsequent access, you can specify an image file to use for the splash screen in the JNLP file with the tag

 

where mysplash.jpg is the image file for your splash screen. The first time your application runs, it will use the standard splash screen. After that, it will use the image you provide.

How can I save the application state on the local system?

A sandboxed application can store state using the PersistenceService API. This API is similar to cookies for HTML pages. Thus, it is a secure way to store persistent information on the client computer. For more information, see:

· JNLP Specification

· Java Web Start Developers Guide

My application requires a specific version of the JRE. How do I specify this my JNLP file?

The tag specifies a platform version, where versionNum is 1.2, 1.3, 1.4, or 1.5.

You can request a specific product version by including a vendor URL in the href attribute. For Sun's JREs, the URL is http://java.sun.com/products/autodl/j2se For example, the following J2SE tag will request any Sun 1.3.1 implementation:

href="http://java.sun.com/products/autodl/j2se"/>

You can see all the versions of the installed JREs in the Java tab of the Java Control Panel.

Can I rely on Class-Path in the manifest file?

Java Web Start does not support the Class-Path entry in the manifest file. The Class-Path attribute is entirely file-centric, whereas Java Web Start and JNLP is web-centric, i.e., based on URLs. Thus, the two models do not merge easily.

Instead of relying on the Class-Path entry, you can list multiple JAR files in the JNLP file, for example:





In a JNLP file, you can factor out dependencies on a set of JAR files to another JNLP file using the element. Thus, you can achieve the same kind of re-usability and ease of maintenance as you do with the Class-Path entry. This feature is described in the specification.

JNLP also implements a just-in-time downloading mechanism, similar to applets. For each resource in a JNLP file, you can specify which parts should be eagerly or lazily downloaded. Eagerly loaded resources are loaded before the application is launched, lazily loaded resources later. Default is eager download. Furthermore, the specification includes an API for which you can programatically query Java Web Start about which resources are available and request them to be downloaded. Thus, you can write download/network aware applications.

See the JNLP specification for more information.

Can I use Java Web Start even if my application depends on or uses native code?

You can use Java Web Start to deploy Java Technology-based applications that depend on native code such as DLLs and SOs. Use the element to specify required native libraries. See the Developer's Guide for details.

How can I load resources within my application using Class.forName and ClassLoader.getSystemClassLoader?

Java Web Start uses a user-level classloader to load all the application resources specified in the JNLP file.

This classloader implements the security model and the downloading model defined by the JNLP specification. This is no different than how the AppletViewer or the Java Plug-In works.

This has the, unfortunate, side-effect that Class.forName will not find any resources that are defined in the JNLP file. The same is true for looking up resources and classes using the system class loader (ClassLoader.getSystemClassLoader).

To find application resources in Java Web Start, use the classloader that loaded your application, for example use the following call in the in the application;s main thread:

this.getClass().getClassLoader();

You can also use:

Thread.getCurrent().getContextClassLoader();

How can I launch Java Web Start from the command line?

You can launch Java Web Start from the command line as follows:

javaws [options] your-app-JNLP-URL

where your-app-JNLP-URL is the location of your application's JNLP file. For example:

javaws  http://java.sun.com/products/javawebstart/apps/swingset2.jnlp 

For complete command line syntax see: the Developer's Guide

How do I use multiple JAR files signed by different certificates?

The JNLP 1.0 specification requires all JAR files used in a JNLP file to be signed by the same certificate. This restriction avoids requiring the user to accept multiple certificates from the same source, and enables Java Web Start to know if the user has accepted all certificates used for an application.

However, Java Web Start can use multiple JAR files signed by different certificates, by using the component extension mechanism and multiple JNLP files. The only requirement is that the JAR files contain code from different packages. So, instead of the following:



What is the difference between an application server and a Web server?


Taking a big step back, a Web server serves pages for viewing in a Web browser, while an application server provides methods that client applications can call. A little more precisely, you can say that:

A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.

Let's examine each in more detail.

The Web server

A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.

Understand that a Web server's delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn't provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.

While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers.

The application server

As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).

Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.

In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques.

How do Web and application servers fit into the enterprise?

An example

As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function.

Scenario 1: Web server without an application server

In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.

To summarize, a Web server simply processes HTTP requests by responding with HTML pages.

Scenario 2: Web server with an application server

Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server's lookup service. The script can then use the service's result when the script generates its HTML response.

In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.

By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page. To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.

Caveats

Recently, XML Web services have blurred the line between application servers and Web servers. By passing an XML payload to a Web server, the Web server can now process the data and respond much as application servers have in the past.

Additionally, most application servers also contain a Web server, meaning you can consider a Web server a subset of an application server. While application servers contain Web server functionality, developers rarely deploy application servers in that capacity. Instead, when needed, they often deploy standalone Web servers in tandem with application servers. Such a separation of functionality aids performance (simple Web requests won't impact application server performance), deployment configuration (dedicated Web servers, clustering, and so on), and allows for best-of-breed product selection.

Oracle Application server

What is an Application Server?

Think of an application server as a traffic officer for all your enterprise data.
Application servers are the middle ground—the middle tier—between your database
and your software applications, handling all application operations between users and
your organization’s business applications and databases. So an application server is a
central location for developing and deploying business applications—without it, the
software that runs your business lives in isolated silos, making maintenance more
costly, upgrades more complex, and performance much slower.

Key Benefits· Simplify your infrastructure and reduce integration costs by connecting older
and newer applications easily without extensive coding.

Improve reliability and availability of applications while reducing the cost of deployment.
· Reconcile data from multiple systems.
· Scale out your applications to more users without compromising system
performance.
· Reduce costs of systems maintenance and administration.

Requirements Checklist

If your business meets most of these criteria, it’s time to consider a move to an
application server:
· You’re adding more applications and other systems that need to share
information.
· Your IT portfolio is growing, and you need to manage and administer a number
of different applications with limited resources.
· Scalability, reliability, and security are becoming more important as your
business grows.
· You need easier access to basic metrics and corporate-wide information about

Threads and runnable types

Q: What's the difference between Thread and Runnable types?

A: A Java Thread controls the main path of execution in an application. When you invoke the Java Virtual Machine with the java command, it creates an implicit thread in which to execute the main method. The Thread class provides a mechanism for the first thread to start-up other threads to run in parallel with it.

The Runnable interface defines a type of class that can be run by a thread. The only method it requires is run, which makes the interface very easy to to fulfil by extending existing classes. A runnable class may have custom constructors and any number of other methods for configuration and manipulation.

Q: How does the run() method in Runnable work?

A: It may help to think of the run method like the main method in standard single threaded applications. The run method is a standard entry point to run or execute a class. The run method is normally only executed in the context of an independent Thread, but is a normal method in all other respects.

Premium Content: Follow this link for subscription informationMore details available to subscribers:
How does the run() method in Runnable work?

Q: A Thread is runnable, how does that work?

A: The Thread class' run method normally invokes the run method of the Runnable type it is passed in its constructor. However, it is possible to override the thread's run method with your own.

Premium Content: Follow this link for subscription informationMore details available to subscribers:
A Thread is runnable, how does that work?

Q: Why not override Thread to make a Runnable?

A: There is little difference in the work required to override the Thread class compared with implementing the Runnable interface, both require the body of the run() method. However, it is much simpler to make an existing class hierarchy runnable because any class can be adapted to implement the run method. A sub-class of Thread cannot extend any other type, so application-specific code would have to be added to it rather than inherited.

Separating the Thread class from the Runnable implementation also avoids potential synchronization problems between the thread and the run method. A separate Runnable generally gives greater flexibility in the way that runnable code is referenced and executed.

Q: What's the difference between a thread's start() and run() methods?

A: The separate start() and run() methods in the Thread class provide two ways to create threaded programs. The start() method starts the execution of the new thread and calls the run() method. The start() method returns immediately and the new thread normally continues until the run() method returns.

The Thread class' run() method does nothing, so sub-classes should override the method with code to execute in the second thread. If a Thread is instantiated with a Runnable argument, the thread's run() method executes the run() method of the Runnable object in the new thread instead.

Depending on the nature of your threaded program, calling the Thread run() method directly can give the same output as calling via the start() method, but in the latter case the code is actually executed in a new thread.

Q: Can I implement my own start() method?

A: The Thread start() method is not marked final, but should not be overridden. This method contains the code that creates a new executable thread and is very specialised. Your threaded application should either pass a Runnable type to a new Thread, or extend Thread and override the run() method.

Your Title