Java Sketchbook: Getting Started with Java Web Start
by Joshua Marinacci
08/11/2005
Contents
What is Java Web Start?
How It Works
Deploying "My Pirate!"
Add a Description and Icon, and
Splash Screen Building
Add an Icon
Add a Splash Screen
Updating an Application
Removing an Application
Conclusion
Resources
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.
My Pirate!
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
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.
My Pirate!
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.
My Pirate!
Which will look like Figure 3:
Figure 3. "My Pirate!" splash screen
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.
Resources
Sample code for this article
Sun's Java Web Start home page
Java Web Start Developer's Guide and specifications
Joshua Marinacci first tried Java in 1995 at the request of his favorite TA and has never looked back.
Read more The Java Sketchbook columns.
View all java.net Articles.
Does Java Web Start address your desktop deployment needs?
Showing messages 1 through 35 of 35.
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 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.
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.
I was hoping JWS would be all I needed for deployment, but I will have to investigate alternate options like InstallAnywhere and EXE packagers.
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.
(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.
Participation
2005-08-12 02:19:05 pdoubleya [Reply | View]
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.
Cheers, Patrick
Participation
2005-08-12 10:41:30 mikeazzi [Reply | View]
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.
Participation
2005-08-12 07:30:44 markswanson [Reply | View]
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]
http://roomity.com is a bigger webstart app.
.V
Indeed
2005-08-11 05:08:39 pholthuizen [Reply | View]
Amen brother! And it completely replaces the use of MSI for our tailor made applications at our office...
Indeed
2005-08-11 06:47:04 danielmd [Reply | View]
Let me guess your office consists of engineers :)
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.
Indeed
2005-08-12 07:24:43 pholthuizen [Reply | View]
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)...
And you only have to pass the security dialog once...
Sincerely,
Patrick
Indeed
2005-08-12 09:08:10 danielmd [Reply | View]
Let me rephrase that, your deployment environment consist of corporate users, not general public users... i talk about this on the "open letter".
If you deploy it to the general public I would love to ear how is that working, how many request for support have you received...
Indeed
2005-08-12 21:56:20 pholthuizen [Reply | View]
- 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
Indeed
2005-08-11 16:23:54 joshy [Reply | View]
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.
Thanks,
- Josh
Indeed
2005-08-11 07:56:13 markswanson [Reply | View]
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/
Indeed
2005-08-11 10:12:48 danielmd [Reply | View]
do you have another example... it had no clipboard access (could not copy/paste), it still asks for file system access with a pop-up.
Indeed
2005-08-11 11:23:51 markswanson [Reply | View]
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.
Indeed
2005-08-11 13:59:01 danielmd [Reply | View]
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.
Indeed
2005-08-11 14:22:22 markswanson [Reply | View]
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.
Indeed
2005-08-11 16:20:47 danielmd [Reply | View]
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]
http://sunsolve.sun.com/search/document.do?assetkey=1-26-57740-1
Guess i was telling the truth, hum how about that :)
Something positive perhaps?
2005-08-11 19:56:39 grlea [Reply | View]
Hi Daniel,
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).
Graham.
Something positive perhaps?
2005-08-11 20:26:41 danielmd [Reply | View]
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 don’t 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 don’t, 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.
Indeed
2005-08-11 17:11:04 markswanson [Reply | View]
There are simple answers to your questions, and if you would stop being offensive and abusing your "anonymous coward" identity I will explain.
mark@ScheduleWorld.com
Indeed
2005-08-11 17:52:21 danielmd [Reply | View]
What the hell, anonymous? Don’t 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.
Indeed
2005-08-11 18:02:33 joshy [Reply | View]
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?
Thanks,
- Joshua
Indeed
2005-08-11 20:02:54 danielmd [Reply | View]
Hi Joshua,
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.
Indeed
2005-08-11 20:15:01 joshy [Reply | View]
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.
Indeed
2005-08-11 21:25:00 danielmd [Reply | View]
Josh and Java Web Start team,
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. 
版权所有 罗明