Many web developers long for a way to build applications with
richer interfaces. They would love to build desktop applications
with all of the power that client-side Java provides, but don't want to
give up the ease of deployment that comes with web apps. How do you
launch a program without downloading installers? How to you make
it secure and safe to use? How do you update the program without
asking your users to go download a new version? These are features
that web app developers take for granted and don't want to give up
in exchange for a richer interface. It may seem hopeless, but there
is an answer: Java Web Start.
Java Web
Start (JWS) is a technology that lets you deploy a desktop Java
application directly from a web page. It provides security, safety,
and automatic updates when you roll out new versions. It will even
give your program an icon on the desktop. In short, Java Web Start
gives you the power of a desktop app with the ease of deployment
users expect from a web app.
This two-part series will tell you everything you need to know
to start using Java Web Start. By the end of part one, you will have
a simple running application that can be launched and updated from the
web. Part two will cover security, optimized downloads, and how to
polish your program to give it a professional shine.
What is Java Web Start?
Java Web Start is an implementation of the Java Network
Launching Protocol (JNLP) specification. It provides a way to
launch a desktop Java program from a web link and install it to
your users' desktops. Once installed, JWS will check for updates
every time the users run your program, ensuring they always have
the most recent version installed.
In addition to its launch capabilities, Java Web Start also
provides a protected sandbox for running untrusted applications.
This is similar to the applet sandbox in a web browser. It allows
users to run programs from potentially unsafe locations without
worrying that the program could delete files, steal information, or
replicate itself to other computers. In the age of viruses,
worms, and spyware, this is a big concern. With Java Web Start, you
can know that both you and your users will be protected.
Originally bundled as a separate download, Java Web Start is now
included in the JRE. If you have J2SE 5.0 on your computer (or Java
1.4, on Mac OS X) then you already have Java Web Start installed and
you can get started right away. While it does introduce a few new
APIs (mainly for dealing with the sandbox), you can get started
without writing any new code. You just need a JNLP descriptor
file.
How It Works
Java Web Start works by using a special file called the JNLP
descriptor, which is a small XML document that describes your
application and its needs. This file lists the .jars that make up
your program, the starting class with the main method, security
settings, and most visibly, a splash screen and an icon. Together,
these settings describe how the program is launched and how it
looks to your users.
Once you've written a JNLP file, you can put it on your web
server and make a link to it. When someone clicks on the link, their
web browser will download the JNLP file and start the JWS
application launcher. JWS will then download all of the .jars that
make up your program (along with any other resources like images
and icons), install an icon on the desktop (if requested), and then
start your program. The next time the user runs the program from
the desktop icon, JWS will check for any updated resources before
starting the program again.
If this all sounds pretty complicated, don't worry. We'll start
with a simple example so you can see how it all works. Imagine a
virtual pet game where the player raises pirates, leading them on
treasure hunts and boarding raids. The program could be called "My
Pirate!". This is what its JNLP might look like.
Let's go through this one line at a time. The first line
contains the XML prolog. This is what tells a parser that what
follows will be an XML file. This should be the same for any JNLP
file. Next is the jnlp element, with two attributes,
one for the href of the jnlp itself and one for the
codebase, which says where the .jars and other
resources will be downloaded from.
Inside the jnlp element are three sections:
information, resources, and
application-desc. information has purely
descriptive content. The title specifies, as you would
expect, the name of the program. This title will be used in the JWS
control panel, for the name of the desktop icon, and in the
platform-specific application manager, like the "Add and Remove
Programs" control panel in Windows. The information section can
contain other things like icons, a splash screen, or longer
descriptions, but the title is enough to get started.
The resources section tells Java Web Start which
.jars and other resources are required to run your program. These
are all relative to the codebase attribute in the
jnlp element. For example, the
mypirate.jar file must be on my web server at the URL
codebase plus href; in other words,
http://mypirate.com/downloads/mypirate.jar. The resources
section can also contain native libraries, extensions, properties,
and other elements, but jar is the most important.
The last section, application-desc, specifies some
attribute about the application. In this case I have told JWS that
the main class of my program is mypirate.Startup. All
JNLPs need this section so that JWS will know how to start the
program. Without, it JWS would throw an exception the first time I
try to run the program.
Deploying "My Pirate!"
In theory, you can just upload your JNLPs, .jars, and other files
to your website and call it a day. In practice, however, it's not
that simple. First, you must make sure you upload your files to the
same place specified in the codebase attribute of your
JNLP. For "My Pirate!" I would have to upload the files to
http://mypirate.com/downloads/. Even if I load the JNLP file
from somewhere else (generated by a servlet on another server,
perhaps), Java Web Start will still load the .jars relative to the
codebase specified in the JNLP file.
The second common stumbling block is the MIME type. Most web
servers don't yet understand how to serve jnlp files. If I just
dropped the files into a standard Apache server, the web browser
would probably think the file is plain text and show it in a
browser window rather than calling Java Web Start. I have to tell
my web server to serve any file with a .jnlp extension
as application/x-java-jnlp-file. Each web server has
its own configuration, but for Apache, you can add a line to your
httpd.conf next to the other AddType
lines, like this:
AddType application/x-java-jnlp-file .jnlp
That should be it. If I point my web browser at
http://mypirate.com/downloads/mypirate.jnlp, I will see the
JNLP downloaded and my program will start. Depending on my
particular Java Web Start implementation, it may ask me if I want
to keep this JNLP as a permanent application. If I say yes, it will
create a program icon on my desktop or hard drive.
Add a Description and Icon, and Splash Screen Building
A plain JNLP file for my program works, but it's missing a few
things. The "Add/Remove Programs" control panel in Windows will
list it simply as "My Pirate!" with no further information about
who made the program or what it does. It has no splash screen when
it starts, and it uses the generic coffee cup icon. In short, it
doesn't feel professional. Fortunately, the Java Web Start
developers thought of this and provided easy ways to add some
polish.
Add an Icon
To add an icon you must add an <icon> element
to the information section of your JNLP. The icon element needs an
href attribute containing the URL of the icon to use.
This icon can be a GIF or a JPEG, or another platform-dependent format
(BMP, ICO, PICT). Be sure to test the platforms you are targeting
to determine which formats will work. Mustang will improve PNG
support to give icons full transparency.
The icon will be loaded relative to the codebase, so I upload it to
the same location on my web server. Now my application on disk will
look like Figure 2 instead of Figure 1.
Figure 1. Standard JWS icon
Figure 2. Custom pirate icon
Add a Splash Screen
Java Web Start also supports splash screens. A splash screen is
an image that will appear while the program is launching. It provides
feedback to let the user know the program hasn't crashed during a
potentially long initialization routine. A splash screen also
serves as a visual identifier for your program and your company,
creating a consistent feel throughout. You can create a splash
screen by providing a second icon with its kind set to
splash.
If you don't provide a splash screen, Java Web Start will use
another icon element in your application. If there is
no icon element at all, then it will generate a splash
screen using the description and title of
your program. This typically is ugly, however, so I highly
recommend you provide your own splash screen.
Note: splash screens do not currently work on Mac OS
X.
Updating an Application
Updating your application is very easy. Just recompile your code
and upload your new .jars to the web server. The next time one of
your users starts the program (either via a link on a website or
from an icon on the desktop), JWS will check for the new .jars. If
the web server's .jar file timestamps are newer than the .jars on disk,
then JWS will download the new .jars, add them to the cache, and
then start your program. Java Web Start also provides a way to send
out incremental updates, where only the changes to a .jar are
downloaded instead of the entire .jar, but that is beyond the scope
of this article and is only useful for large (multi-megabyte)
applications. For more information on JarDiffs, take a look at the
"
Mapping Requests to Resources" section of the Java Web Start
Download Servlet Guide.
Removing an Application
Java Web Start makes installing an application super easy, so
it's nice that uninstalling is easy, as well. There is a program
called the Application Manager that lets you manage the Web Start
programs installed on your computer. This is part of the Java
Control Panel on Windows and Linux. On Mac OS X, it is an
application in the /Applications/Utilities/Java directory.
You can also run the javaws program from the command
line with no arguments to get to the cache viewer. The manager
program shows information about each JWS application and allows you
to start, update, or remove them. It also lets you create a desktop
icon for a JWS app if you want it to feel more native.
Conclusion
Java Web Start is a great technology for deploying desktop Java
applications without the usual headaches of desktop apps. In the
first part of this article you have learned how to create a simple
application, launch it from a web page, update it, and how to
improve the look of the application with icons and a splash screen.
Please join me in the second part, where we will look at the Java
Web Start security model, use Pack 200 to decrease download time,
and add some extra polish with documentation and file
associations.
Hi, did anyone else run into the problem with this demo where JWS starts and a small browser window with "open config file" in the center comes up - and if you click on this it prompts you to locate a file on the filesys?
I think I went through all the steps properly, but can't seem to get this to work.
Thanks!
-James
I am having problems with the example
2005-08-17 01:18:32 kanedafromparis
[Reply | View]
Hello, I did download your exemple, and I found that the Icons don't works properly.
The Slash works, properly exept that I have the Javawebstart slash screen behind. I wonder if that coul be a version problem. I using 1.4.1_05 on jws 1.2.0_05 (b01).
PS : I can not change my JVM. but wonder if that was a know bug.
Great idea with minor issues
2005-08-12 14:20:33 christian_schlichtherle
[Reply | View]
Hi Josh,
let me stress first that I absolutely love the idea of JWS. I am currently using it for my application TrueMirror. I don't even think the security warning is a big issue. All that you need to overcome this is certificate, full stop.
My issues are more practical ones:
+ I use <offline-allowed/> as my app doesn't need any network. Unfortunately, JWS usually does NOT recognize my updates (not even if do not use this tag). I use DSL to connect to my provider and my shared host is in the same providers network, so I don't have any reason to think that my connectivity is the cause of the issue. Unfortunately, there is no documentation about how JWS actually detects an update, so I have no choice but guessing. So far I could not track down the issue.
+ I would like to put my app on CD or DVD for distribution, too. Using HTML and JNLP this shouldn't be a problem, but it is (at least on Windows) as you cannot address the current directory (on CD-ROM) in the codebase attribute.
+ The icon support for transparency is poor. I tried PNG and GIF. but wasn't able to get something professionally looking for my icon (see web site).
As you can see this is nothing spectacular to fix, but a cause of daily annoyance...
Regards,
Christian
Still a ways off
2005-08-12 09:33:13 detorres
[Reply | View]
Funny how every blog on JWS results in JWS bashing. I don't mean to bash it, but I have to agree that it's not working like it should.
<br/>
<br/>
As a developer banking on using it to deploy an app to "real" people, that scares me. My app is deploying correctly for me, but will it work for my users? Only one of the WS links in this thread started for me, and like daniel, the application didn't really work. It will be interesting to see what happens during my beta testing. I'm praying that people are configuring their apps incorrectly. Let it work technically at least. Then I just have to worry about people's reaction to the "scary" dialogs.
<br/>
<br/>
I was hoping JWS would be all I needed for deployment, but I will have to investigate alternate options like InstallAnywhere and EXE packagers.
<br/>
<br/>
I understand what Sun is trying to do with JWS, and it makes sense. But to make it work for the masses, they need to be educated to appreciate what the extra steps are for. I also agree with daniel that a "smooth", non-secure option would be nice to have, but you have to clearly distinguish them so a user looking for a secure app can have confidence that he's not starting a non-secure JWS app.
<br/>
<br/>(Hey, where's my "preview" button?)
Still a ways off
2005-08-12 09:34:39 detorres
[Reply | View]
I think I'll just stop trying to post to this %)&$ site. This is pathetic. It works different every time I try to post.
Still a ways off
2005-08-15 23:56:23 jwenting
[Reply | View]
maybe if you stopped swearing and cussing it would work better?
One question--why is there no forum for community participation in JWS? I mean someplace we can discuss what features should be in place, problems there are, etc. I would love to see that. Two issues that came up recently I sent to the JWS team but got no response--there was a web form I found on a Sun site for JWS. That's OK, just want some way to give feedback.
There are a few issues that bother me right now. One is that my testing showed that for Tiger, if two JNLP apps reference the same JAR file (fully-qualified), two copies are pulled down, even though the JAR should be cached, I think. The second issue is that it seems JWS is single-threading the downloads (at least, that's how it looks from the status dialogue). Why not have an option for parallel downloads for certain deployments? Certainly in a corporate environment you can count on the bandwidth.
The third is that the JWS console is kind of hidden, at least on Windows. It's really a problem with JNLP apps being in their own class of things. What I want is a quick way to check the cache, flush it, get the latest versions, etc. I would normally expect to do this from add/remove programs, but the JWS apps there appear as normal apps. I end up hunting for the console whenever I need to flush the cache. Sorry, this is really griping as I don't know what exactly I'd prefer.
I have to say I have been enjoying JWS as an end-user checking out new demos from people on the web.
One question--why is there no forum for community participation in JWS? I got two words for you for an answer: Stanely Ho. This guy has been unbelievable in that rigid, closed, old school, soviet style way with which he has been managing the JWS project. He has consistenly ignored all sorts of pleas, and cries from the community for opening up, and relaxing the JWS process. I can understand why Vic and others are frustrated with him, and wish he would just go away. I think he's doing more harm to JWS overall than good with his attitude. I mean consider this for example: this is a JWS article front and center, and this related discussion has been raging since, but I have yet to see a single response from Stanely, how arrogant is that? I'm sorry, but people like this should either get on with the program, or get out of the way. Unless of course he's no longer on this project, which is fine with me.
I completely agree about the forum idea. The JDNC is a truly great example of how Sun projects can work with the community and most importantly get feedback from the community. I feel the one-way website submission mechanism that currently exists is one of the reasons JWS has been lost in the weeds over the past 5 years. Feedback by definition is a two-way mechanism.
wrt single-threading I thought I read they improved that recently but I can't remember which changelog.
wrt the cache I agree too. Further, I notice that when my JWS cache gets over some 2GB limit the jardiff/download mechanism starts to exhibit weird behaviour (the initial progressbar stops coming up even though it is downloading jardiffs) and eventually stops working. This would be less likely to happen if JWS managed its cache better and cleaned up obsolete versions of classes.
Cheers.
Great Features Rely On Server Side Code
2005-08-11 18:19:21 grlea
[Reply | View]
I really like Web Start.
But does anyone else find it just totally useless that the advanced download features of webstart are server-based?
I thinking particularly about PACK200 and JarDiffs.
In order for them to work, you have to deploy servlets that divert requests for JARs to the pack or jardiff versions (or something like that).
This isn't useful in a lot of scenarios, e.g. when publishing an app on java.net or on a hosted site that doesn't allow you to deploy servlets.
Why can't Webstart clients just be written to look for these things automatically?
Can anyone say whether there was a reason it was done this way?
Great Features Rely On Server Side Code
2005-08-11 19:09:01 markswanson
[Reply | View]
I don't find it totally useless (because I heavily rely on them) but if the question was, "Why can't the JNLP file specify jars from sites other than where the JNLP file was downloaded from in the first place?" then I'd say that's a great question.
I can only guess that the JWS developers just didn't want to step too broadly outside of the original Applet security rules. Perhaps they wanted to help minimize the chance of compromized jar files? If so (and it's pure speculation, of course) I think sealed and signed jars would do a much better job of that - and allow jars to be grabbed from anywhere.
I'd really like to see a JNLP option that allowed signed/sealed jar files to exist from multiple different locations. An _alternate_ location in case a server was down would provide excellent failover. Apps could still _not_ ask for all-permissions and run in the sandbox.
grlea: The WebStart folks have been quite good lately about accepting (and implementing) RFEs from the community. I say write it up and submit it - then post to java.net so we can add our comments and votes to it. I think it has a chance.
Cheers.
Great Features Rely On Server Side Code
2005-08-11 19:15:52 grlea
[Reply | View]
if the question was, "Why can't the JNLP file specify jars from sites other than where the JNLP file was downloaded from in the first place?"
Sorry, Mark, that wasn't the question, but I guess I wasn't all that clear (and a little defamatory as well.)
I guess the question was:
What is the reason that Web Start can use PACK200 and JarDiff files, but only if the server has a special process to deliver them?
Why can't Web Start have some way to automatically look for PACKed version or JarDiffs before looking at the original JARs?
I say write it up and submit it - then post to java.net so we can add our comments
A good idea. Thanks. : )
Graham.
Great Features Rely On Server Side Code
2005-08-12 07:18:09 markswanson
[Reply | View]
Just thinking out loud: once the client has the JNLP it should know which jardiffs to ask for. Extra HTTP HEAD requests could easily be made in parallel to see if the pack.gz files were there as well.
If the jardiff wasn't available then it could just download the full pack.gz - or fallback to the jar.
This, in combination with an alternate address(es) for the server with signed/sealed jars would be a great idea that would help java.net/sourceforge/etc.. projects a great deal.
The digital certificate issue bothers me (paying for certs from Verisign that signs certs for companies called "click yes to continue" - but that's a topic for another day.
Cheers.
a better example
2005-08-11 12:51:29 netsql
[Reply | View]
Has anyone sit down with a non engineer and gave him a use test of java web start, let me tell you I have and most people find the security pop-up a very scary thing, they get confused and don't know what they should do.
Java Web Start has so many flaws i will not even start discussing them, i know that efforts are being made to make easier to use in future version of mustang. This kind of application only works well with technically savvy people, if you sit down with a "real" person, and register the reactions you will see that this is not a technology directed to the masses (NOT READY FOR PRIME TIME).
No access to file system (what native application does not have access to file system?), scary security digital signature/certificates pop-up, have you ever seen a native application do that? I haven't and until there is a seamless experience between native and web start applications it will not be ready for prime time.
No our office does not consist of engineers, they are plain simple end users who are able to "install" a web start application by selecting it from our intranet and yes they are able to determine which button to click on the security dialog (it's also visible on the intranet as an installation instruction)...<br/>
<br/>
And you only have to pass the security dialog once...<br/>
<br/>
Sincerely,<br/>
Patrick
- Indeed I was talking about corporate users where everything works fine.
- In the beginning we created the installation instruction to make users press the right button on the security dialog, that was no problem at all as mentioned before. We had more problems with the shortcuts created by web start as some users didn't create them (additional installation instruction line) and didn't know how to get them at a later point, also some users threw them away and didn't know how to recreate them. But that is just a minor issue in my opinion, because after some explanation everything works fine now.
- I understand that in a public environment you are not able to make instructions like these and I think you may have problems with exact the same issues as ours but then in a less acceptable manner.
-- About the security dialog: I don't think it's much of a problem to have this security dialog as people start to know them through other ways as well (microsoft windows for example). The thing I have with the web start dialog is that it doesn't explain you the type of access the application wants. (isn't this addressed in mustang?)
-- About the icon creation: I think more installation options would be nice and also more programmer control in them, for example a repair and uninstall facility in the launch menu and the ability to force the icon creation instead of giving the end user the freedom.
Sincerely,
Patrick
After knowing about JDIC
2005-08-14 15:20:52 danielmd
[Reply | View]
I just started reviewing the JDIC project (just found out about it thanks to java.net editor), and it looks like many of the requests of better desktop integration are answered in JDIC, still the installation/deployment/update problem exists and JWS is a great idea in paper, a think that a better solution right now is to use JDIC and IzPack for deployment and an auto-update feature to keep it updated. I was already familiar with IzPack :-)
I have seen many examples of this kind of solution (JDIC+IzPack) and I was pleasantly surprised. Apart they don't work very well, but these two with an auto-updater might be do the trick with flying colors.
I got to stop bitching so much, it looks like i was simply using the wrong components/technology.
Java Web Start does have limitations but they are necessary to protect the enduser. It's true that you could just distribute your application as an EXE but that's where all of the spyware and viruses come from. Java Web Start hopes for something better.
Please wait for part two where I will cover how to use secure APIs that will protect your users and not require signed access or trigger warning dialogs.
Unsigned Java Web Start applications are more secure and provide access to the file system, and have no scary popups. For a good example of what can be done check out:
http://www.ScheduleWorld.com/
Clipboard access works fine.
The popup is a good thing. It is simply asking you to allow filesystem access yes/no. It's different than the scarry all-permission dialog box. This is an important component to running applications securely and folks will learn to appreciate it.
Clipboard did not work for me, i could not copy paste... and you don't see a native application asking for premission to access the file system, it is an abnormal behavior, it does not provide a semless experience.
The clipboard works fine - the same way in a normal Java application + extra support for iCalendar objects. Post a specific example if you are sure you have one.
Wrt permission - it's better/enhanced behaviour. The 'seamless' experience you are referring to allows applications to install spyware and viruses - essentially walk all over your hard drive and ship the contents out for others to look at.
Dude what the hell are you talking about? File access does not equal network access (if i block the application with a firewall how is it going to send back anything?)... and file permissions do not equal execute permission it is still possible to install spyware, and all other stuff with java webstart, and since it uses the firewall permissions that you give to javaw it means it is that much easier to create backdoors and trojans.
And again, i cannot copy paste so if you can this is already a problem that i am having, the application is not behaving normally in my enviornment, wich in my world makes it not ready for prime time, it does not behave in the proper way.
No, that's not how it works
2005-08-11 18:15:15 grlea
[Reply | View]
it is still possible to install spyware ...
it uses the firewall permissions that you give to javaw it means it is that much easier to create backdoors and trojans
I'm afraid what you've said there isn't true at all.
It's seems that you don't know a lot about Web Start's security model, so can I (politely) suggest you read a bit about Web Start and how it tries to protect users by offering a secure execution environment (that limits both file and network access much more than your firewall does).
You may be pleasantly surprised.
You may not.
At the least, you'll be able to make an informed argument.
No, that's not how it works
2005-08-11 19:33:57 danielmd
[Reply | View]
Your mistake is to think that the security model can't be breached (it has been in the past and there are no doubts that it will be in the future), and sandboxes contrary to popular believe do not fix all security problems. Just like it is breached on native Operating Systems.
You accept the reality you are given and can't see past that, if you ever worked in a security lab, or contacted with the security community, you would have known first hand that the java sandbox model has been compromised several times, fortunately nothing very serious ever escaped to the wild, and fixes have always been fast. I worked as a security consultant for 2 years, and i have seen what an exploited applet can do.
You really should read this: http://www.securingjava.com/chapter-five/
Security the greatest illusion of all :) it is amazing, people really think that java security can't be breached, simply amazing.
Have you learned nothing from Start Wars? Anakin turned Bad ;-) Trust can be a terrible thing.
No, that's not how it works
2005-08-11 19:38:35 danielmd
[Reply | View]
You've made a lot of criticisms.
Would you like to add something positive to the discussion?
You could maybe list some things that you think could be done to fix Web Start.
Or suggest something you think people should using instead (and why you think it is better).
Sure... If you read my comments you will see what I would like from JWS, anyway here it goes again...
Make it behave like a normal native application, with access to the filesystem, make it integrate properly with the Native OS (in most cases Windows, the task manager problem should not exist I want a process name not javaws.exe). In theory I love the JWS idea, the implementation is really a disappointment.
I dont know if you already did not due use cases for JWS, if you did I would love to see the results, use cases with hundreds of people with varying computer skill levels and see if they think that JWS is well implemented, and never mind security concerns just focus on the end user experience, and see if they enjoy using it, from my personal experience I dont, I think it is a pain to give permissions, because in the end if you want any functionality out of it you will have to trust it and then it becomes as insecure as a native application (well almost).
Ultimately what I would like is seamless end user experience for the windows platform; it is such a simple request.
What the hell, anonymous? Dont you see my freaking name (DANIELMD) and offensive are you kidding me... if you want to explain anything do so... but don't try to come up with false arguments.
If you think that Webstart is ready for prime time, great if you think that java applications should behave differently than native applications fine, we disagree. Technological Savvy people will have no difficulty, but 90% of the end user population will simply not like the way JWS works, signed or unsigned.
I tried your application and i could not do a simple copy/paste, if you think that is OK i don't. Sorry but your application does not work in my system, is this my fault? I tried to copy your comments and paste them it did not work, if you think this is acceptable well Good Luck to ya.
Hi Daniel. This is a technical website and I am sure that we can all be civil and discuss our differences. What features are you missing with Java Web Start? Would deploying your application with one of the many EXE builders accomplish what you desire?
Keep in mind that I am talking about Windows behavior.
I think that JWS is flawed by design, it should behave just like a normal native application on the native OS, I don't like the pop-ups, the signatures, I don't like the lack of integration with the windows task manager, just give filesystem privileges like any normal application.
Sorry if I was too offensive i did not realize that people can't handle words like hell, and i truly hate wend people act like they are the owners of the absolute truth, so I snapped.
I think java.net is not for me; you guys are just too sensitive and have a closed mindset, always accepting absolute truths 1+1 does not always equal two.
All the best, good luck, really liked the article.
Well I hope you won't leave java.net. It's a wide community with lots of room for different viewpoints.
JWS was designed to be as secure as an Applet, and more secure than a native application. This was an explicit design choice to address the modern world of on-demand applications that live in an environment of firewalls, spyware, and viruses. There are some tradeoffs, of course. To work with the sandbox you need to use special secure APIs that put more control in the hands of the user. It's a different way of programming that can be frustrating at first but has a lot of benefits.
I understand that this approach is not appropriate for all applications. For these cases there are a variety of EXE builders that will let you deploy a java app as a local native application. Some builders even include installers and over the web updating.
Incidentally the new version of Java (available to test at https://mustang.dev.java.net/ ) includes a lot of improvments to make webstart apps appear more native. The security screens are improved and feel less scary. There is a new Socket API that will be familar to anyone running the standard Windows firewall (it shows a popup asking for network access just like other native apps). We are also working on better taskbar/icon/process-list support. Please try out the latest builds and give us feedback. We put a priority on requests and patches from the community.
Thanks,
- Josh
About the open letter
2005-08-11 21:50:54 danielmd
[Reply | View]
Profiles, to make things clear...
I am talking in doing something like differentiating JWS by targeted market, just like the JDK branched to J2EE, J2SE, J2ME different targets different needs. The JWS could branch into JWS Corporate, JWS Personal.
I really hope that you guys can fix the main problems, as a former security consultant JWS makes perfect sense for the corporate environment it is a quick, hassle free way to deploy and update applications, and the JVM sandbox protection space is a much more secure environment than the majority of native operating system.
In the corporate environment the IT people can put up a intranet page teaching/training the staff, so people in the corporate environment will find nothing weird about the way JWS works they already have to memorize 11 passwords and face several pop-ups and password request, so a couple more is nothing to them.
On the other hand most end users (general public) don't work in a corporate environment, and even after being familiar with the way JWS works will find no advantage on the corporate/security features it brings over a native application.
One way to fix this would be to introduce Profiles to the JWS framework, with Profiles you could create a more friendly General Public Profile (that is not signed by a CA, and does not request filesystem access it is granted by default, recognizing system files that it cannot access, it behaves just like a normal native application the same rights the same duties).
And a second profile Corporate Profile (that is security conscious, requests for CA signature, has several versions in cache on the server/client, uses a catch-all service for data recovery, maybe use something like virtual partitions ala Solaris Zones/Containers, all sorts of corporate features).
I know that currently you have many fine-grain options, but they are all very restrictive, creating two Profiles that have very distinct and different targets would help in making JWS ready for General Consumption (making installers an obsolete technology).
Different targets should have different abilities (responsibilities and duties), and in this case the targeted audience is just to diverse, if being consulted I would recommend it with praise to any IT department as an effective way of deploying java applications, but if consulted on using JWS as a Public release target my recommendation would be a fat NO.
My view is that as of now JWS is a corporate technology not ready to be used outside of a Corporate environment, so not ready for Prime Time, i hope that in time something like I describe here finds it's way to the source tree, and i will study with attention the new additions and introductions of features.
I have watched thru out the years with great expectation the development of JWS (I love the idea, and I really think it would be an effective way to kill many deployment problems inherent to installer technology), I was expecting that the next version would be the one that brought the revolution to the masses, and every time I have been disappointed, still not ready for Prime Time is my conclusion. As of such it needs to be branded for what it is: a corporate technology, a great idea that works very well in a controlled environment, a pain to use outside that environment.
In the next version if not Mustang then Dolphin, rethink your target audience, make it general end user friendly, bring the revolution to the masses. It looks like Java will not be open sourced for a very long time so only you the JWS Team have the power to make it happen.
- This post is so long I decided to make it an Open Letter to the JWS Team; I hope it is seen as constructive criticism, I wish you all the best.
danielmd, I commend you for taking the effort to explain patiently, why JWS stinks - and shame
on the folks at Sun for not listening.
Yes, I myself have a JWS application (http://juwo.com) and when I wrote it, I thought - how
cool JWS is, so easy to deploy.
However when I gave potential (notice that I say 'potential') customers the JNLP link to my
app, they were simply befuddled by all the dialogs and the fact that the script in the html
to install JWS did not work always.
They got turned off, went away and never came back. My advisors are now recommending that I
implement in Flash, MS.Net instead of Java.
<br/>
To all you geeks at Sun, I wish I could say it less politely, but you need to be shaken awake,
"LISTEN TO THE EXPERIENCE OF THE GENERAL PUBLIC!!!"