Skip to main content

Integration of javaws and java/javaw

3 replies [Last post]
lsomchai
Offline
Joined: 2003-06-10

In J2SE 5.0, the Java Plug-in and Java Web Start (JWS) are integrated very well. However, the development of JWS application that use JWS service is not comfortable enough. For example, we have to test the application that use service by deploying and running with javaws.

If possible, we should integrate the javaws and java/javaw together. This will let we develop JWS application as a normal application. A normal application can use some nice service such as open a default web browser. And, we can test application with many configuration that can be control in the Java Control Panel.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
chris_e_brown
Offline
Joined: 2004-09-14

It'd be nice if standalone applications (not Webstart or Applets) could access the user's proxy configuration, including (if possible) login and password.

I'd like users to be able to use my standalone application, which uses Jakarta Commons HTTPClient (because the standard stuff in the java.net.* package just isn't reliable or efficient for non-trivial use), without having to re-enter info that's in their browser, so that they can get on with their work (it's all too technical for a lot of them, and it creates heavy support costs for myself). Native apps seem able to do this, it's a pain that Java can't... As I'm using HTTPClient, I need access to all these settings, so "magical" proxy configuration using the standard java.net package isn't enough (it'd be a good start though).

- Chris

bjb
Offline
Joined: 2003-06-12

JNLP should be a standard extension of J2SE and a basic implementation has to be available in J2SE.

Basically, all the webstart services will be implemented there using regular existing API.

The following interface can be implemented in that ways :
- BasicService :should be ok, but for isWebBrowserSupported();
- ClipboardService : ok, using j2se regular clipboar;
- ExtendedService : ok, using regular java.io;
- FileOpenService : ok, using regular javax.swing & java.io;
- FileSaveService : ok, using regular javax.swing & java.io;
- PersistenceService : ok, if data to persist is less than 6kB using java.util.prefs.Preferences else using storage in the user.home in a subfolder starting with a dot (ux hidden like) using some regular J2SE java.io.
- PrintService : ok, using regular java print (the latest API)

Problem is for the following services :

- DownloadService : will need to bring the download service inside the J2SE.
- ExtensionInstallerService : this means that "on-demand" extensions would be part of J2SE ?!
- SingleInstanceService : this one is not there in J2SE ... not sure about the way to implement.

Hence at the end there will be two implementations of the spec, the one that is available at runtime in application mode and the one in webstart mode. Both should use as much as possible common features (caches, download of extensions, ...) so that at the end of time the only difference you can feel is the difference of security policy ;-)

This leads to the topic of "on demand feature and on demand security granting" for webstart. But this is another topic ...

cowwoc
Offline
Joined: 2003-08-24

Another very basic mismatch:

In Java Webstart, you load native libraries from within a JAR.

In a standalone application, it is impossible to do the same thing using System.loadLibrary().

At the very least, it should be possible to System.loadLibrary() from within JARs. This is pretty common sense. The same application should be able to act as both a JWS and standalone application.