John S. Gage wrote:
>
> Apparently, David and I, working in very
> different areas, have had essentially no problems whatsoever delivering
> the JVM with our applications. Wayne, on the other hand, appears to
> have had problems...perhaps because his client base is much larger and
> more diverse.
>
The reason behind this is straightforward enough to
understand: scale and approach.
We do not deliver java applications to the desktop. We do
not install nor assume a jvm exists at the desktop. We use a
java application server to deliver HTML applications to the
desktop.
To improve the user interface, we have thought about
adding javascript (not the same thing as java and not
dependent upon java), but due to various versions of
javascript in various browsers, this can be challenging.
Our experience with javascript within browsers mimics our
several year old experience with java applets which relied
on the jvm supported by the browser, which also varied
tremendously from version to version and thus workstation to
workstation. Our central campus folks have just
re-discovered this when they rolled out an HR application
heavily coded in javascript. It fails on most Macintosh
workstations!
Our constraints are as follows:
- We assume only a browser on the client. That's the only
control we have over the client desktop, support and
configuration is provided by others.
- WE could only use javascript or java as supported by the
browser.
- Among the potential 6,000 workstations which can access
our applications, there is no version consistency among
broswers.
This has lead to chaos assuming anything other than basic
HTML at the browser.
I have mentioned in the past that this assumption of ours
is in the process of changing:
- javascript is gradually becoming focused on the ECMA
standard, used by all browsers version level > 5. Soon,
browser levels < 6 can be considered obsolete, but not yet.
- jvm support at the browser and OS level can be safely
assumed to not exist anymore. This allows one to use
dynamic JRE downloading and java webstart to configure
client machines with known versions of the jvm and
application.
There are issues with the latter situation: Because
Microsoft will no longer load a jvm with IE or the OS, JRE
downloads on MS platforms will be required. For folks
connected to high speed networks this will not be a speed
problem, but it will present to everyone a user interaction
problem. For example, just rolling out a SSL protected web
application caused an overload of user support calls when
the certificate we used was not a standard one and a new
user dialog to download and accept a new certificate was
presented to end users. They considered this to be an extra
burden and an unreasonable expectation on our part.
Anyone seen the JRE download and installation process?
Providing user support for that and all the things that
could go wrong to over 6,000 potential users is a nightmare
thought. But it is on the same order of magnitude of
getting any client software installed on such a large number
of workstations. Personally visiting each workstation is
out of the question, so that leaves some sort of
non-intrusive or transparent and reliable network
distribution method. I don't know of one yet.......
So, while I believe that running java applications in a
well known jvm on any arbitrary client workstation is a
possibility, the advantages of having an execution
environment already present to user support are substantial.
That is why MS .NET and C# java replacement activities are
so important to the long term future of java on the desktop.
IF MS succeeds and jvm distribution remains a user support
issue, then java on the desktop will only be viable to those
with tight control over desktops or very smooth end users.
