What JVMs on which OS's ?

J

Jenny

Hi All,

We're trying to make a decision about moving part of our product to the
web.

Before doing this, our marketing guys wants to know how many people might
actually be able to use it.

Does anyone know where I can find out what OS's ship with which JVM's?

95/2k/XP/Mac/Redhat/etc...

How dependent is it on the OEM (Dell, HP, etc) that distributes the
machine?



-Jenny
 
A

Andrew Thompson

Does anyone know where I can find out what OS's ship with which JVM's?

95

MSVM ( Java 1.1 )
2k
MSVM

XP

Some early - MSVM.

Now *none*. It is up to the user to get it from Sun (or
another JVM vendor of their choice) just the way it
should be.

OS 9.1 - Java 1.3.1 (AFAIR)
OSX - Java 1.4 (though I think 1.5 is trickling in..)
Redhat/etc...

Mostly '?'. I think it is up to the end user, not
that I understand that much of the situation with
the plethora of *nix variants.

It is safe to say that Solaris ships with the latest
(Sun) VM available at the moment of dispatch, though. ;-)

Use JWS for your Java versioning.
<http://www.physci.org/codes/javafaq.jsp#jws>

If you want to find out what any particular
client is running (in the browser, in any
case), point them here.
<http://www.physci.org/pc/property.jsp?prop=java.version>

HTH
 
U

Uwe Seimet

Andrew said:
OSX - Java 1.4 (though I think 1.5 is trickling in..)

Note that 1.5 is only available for Mac OS X 10.4, not for an older
version. I would expect many users not to run 10.4 for some time to come
as the upgrade is not for free.
 
T

tex

We design for & test Applets w/ M$JVM which started w/ IE5. This limits us
to
1.1 and AWT but it can do a lot and it seems universally acceptable. When
M$
said they would discontinue M$JVM, and they will, most of the vendors said
they
would include the latest Sun plugin with their shipments; but, we're not
there yet.
If you don't want to requrire user to download a plugin, then limit it to
1.1.
[We actually develop & test under latest Sun plugin, but limit ourselves to
M$JVM
compatibility, and test].

Apples have a better JVM and if you want it to run on Apples you can't use
CAB
files. Stick to Jars & Zips.

Life will be better when we can depend upon a better JVM as standard, but M$
would much prefer all to go w/ Net, but can't do that yet either as it won't
be
available as standard until Longhorn.


When XP 1st came out, thousands of computers were shipped w/o a JVM, but
very quickly, M$ and/or the Vendors changed that. Most of my users work
for the big companies, IBM Laptops are extremely common, and everyone
seems to have a JVM pre-installed.

Applets are very common. Some bank's depend upon them for their Web
payments and I understand even some of the Post Office functions use them.

If anyone knows of vendors not including JVM's I would like to know who
they are. I haven't run across it yet.


--tex
 
S

Steve W. Jackson

Andrew Thompson said:
MSVM ( Java 1.1 )


Some early - MSVM.

Now *none*. It is up to the user to get it from Sun (or
another JVM vendor of their choice) just the way it
should be.
<http://www.physci.org/codes/java/plugin.jsp>

And, IMHO, getting the JVM from Sun is *always* the best solution for
most platforms it supports directly (understanding that some platforms
do better with IBM's).
OS 9.1 - Java 1.3.1 (AFAIR)

Afraid not. Frankly, I'd say don't even consider supporting a Java app
on any Mac OS earlier than OS X 10.2. Apple's Macintosh Runtime for
Java (MRJ) only supported Java 1.1.8. Swing 1.1.1 support could be had
for a ton of extra trouble. It will *never* be updated and OS 9 is
slowly dying out over time.
OSX - Java 1.4 (though I think 1.5 is trickling in..)

In Mac OS X 10.3 through 10.4, Java 1.4 is available (can't recall about
10.2 off the top). In 10.4, it's pre-installed (1.4.2), whereas earlier
systems defaulted to some version of 1.3. Java 1.5 (aka 5.0) has been
made available only for 10.4 and will apparently never be made available
to earlier OS X systems.
Mostly '?'. I think it is up to the end user, not
that I understand that much of the situation with
the plethora of *nix variants.

It is safe to say that Solaris ships with the latest
(Sun) VM available at the moment of dispatch, though. ;-)

Use JWS for your Java versioning.
<http://www.physci.org/codes/javafaq.jsp#jws>

If you want to find out what any particular
client is running (in the browser, in any
case), point them here.
<http://www.physci.org/pc/property.jsp?prop=java.version>

HTH

My experience with a Mandrake system was that it had some non-Sun JVM on
it when we first began our testing, and it was far from compatible with
Sun's JVM. So we simply installed Sun's and went from there.

= Steve =
 
U

Uwe Seimet

tex said:
Applets are very common. Some bank's depend upon them for their Web
payments and I understand even some of the Post Office functions use them.

Hmm. I have made the opposite experience. No web page has wanted me to
download an applet for years. All banks I know - more than one ;-) -
handle the complete logic on the server and just a web-based interface,
based on dynamic web pages.
Downloading an applet is particularly inconvenient if you have a modem
line and are forced to load classes before you can actually do
something. You might even be forced to accept the applet in a dialog
window, because it is not a trusted application.
Many (particularly Windows) users do not have a current version of Java
installed because they just don't need it in their daily life.

My experience is: Applets once were a nice toy, but are hardly used
nowadays because there are other solutions, which are more convenient in
many respects.
 
N

Noah Fiedel

Hi Jenny,
Due to a variety of reasons, my company has up until now choosen to
stick with supporting the oldest & worst JVM, the MSJVM (Java 1.1 - or
so). This has bitten us on many occasions. Many features are completely
undocumented & it is difficult to even test compatability with the 1.1
VM. We were going to migrate to 1.4.2 as our *minimum* spec until I
read up on MVC & JSF (just for knowledge sake here) and realized that
it would be fairly easy to port our main/complex Applet to a regular
web page (no plugin required).
For what it's worth, supporting the MSJVM will severely limit you
in tems of Java standard library features - certain things will compile
but break on the MSJVM - such as the very broken Vector implementation.
Other things, like the entire swing library are unavailable.
Collections are virtually non-existent, and threading is very poor. I
honestly think that the reason Applets are not more commonplace is the
MSJVM & how limiting & terrible it's support for Java really is.
Do yourself a favor and either require the latest JVM, or just
implement the product as a vanilla page. There is always AJAX if you
want some nifty updates/refreshes to make your app a little less
dependent on the click-refresh syndrome.

-- Noah
 
A

Andrew Thompson

Do yourself a favor and either require the latest JVM, or just
implement the product as a vanilla page.

Wait a second.. If this is truly an application that can be
achieved using a vanilla web page. Then, the page should be
designed as pure HTML!

The only sense in introducing an applet to the mix
is if you want to offer things that are 'above and beyond'
what a regular web page can do.

Even then, you should have a completely functional HTML
form ready to whip up for the non-java users, perhaps with
the message "install Java for the D'n'D version".
 
T

tex

Hmm. I have made the opposite experience. No web page has wanted me to
download an applet for years. All banks I know - more than one ;-) -
handle the complete logic on the server and just a web-based interface,
based on dynamic web pages.

Trying to resolve online pay problem, Bank tech went thru several
browser settings to check including that JVM was enabled. Assumed
they are using an applet somewhere.

Tech friends told me that US Post Offices uses applets, that IBM uses them
them w/ Lotus, and that there are thousands of applets on the web.

I've installed one for mfr (internal use of salesmen, reps and distributors)
and all feedback is that it works great [my applet has caused the mfr
to become the "preferred supplier" for some of the disbtibutors because
of its ease of use] so I think nearly all business folks have JVM
preinstalled on all the computers they receive. They didn't even put
a JVM download link on the site, everybody's already got one.

I have shown demo applets to several people w/i 5-6 companies and,
again, all seem to have JVM and all works great.

I am keenly interested in JVM trends, applets trends, WebStart, and what
PC makers are shipping as standard.

Downloading an applet is particularly inconvenient if you have a modem
line and are forced to load classes before you can actually do something.

Applet logic is a small and fast download. I am able to add several small
images to make it look great in the initial Jar w/ the logic and it all
starts up fast, even for modem. The larger pics are then downloaded
while the user is working. Images cause a lot of waiting on the Web.
Not logic, and especially not logic in bytecode.

Many (particularly Windows) users do not have a current version of Java
installed because they just don't need it in their daily life.

That is unfortunate, and my personal view is that M$ realized what applets
could do and, failing to be able to customize M$JVM (lawsuit w/ Sun), they
wanted to retard its utility while they get NET ready. M$ is making much
noise about "Rich Client" aps and how neat they'll be w/ net.

I can make really neat JVM1.1 Rich Clients that run everywhere today.

My experience is: Applets once were a nice toy, but are hardly used
nowadays because there are other solutions, which are more convenient in
many respects.

I have also heard about the downplaying of applets, and that is unfortunate,
because they offer excellent delivery of Rich Clients, which is my interest.

If you want bouncing balls, exploding words, and all sort of cuteness, I
agree that there are better ways. If you want hard-core, complex
logic in a daily use tool, now applets are one of the best choices. I build
tools for daily, fast & efficient use.

I am currently working on a tool (in-house first, and months later applet
for the Web) where the product rules are currently kept in Excel with >100
worksheets (user's 1st choice, thus reducing rule-set, and many un-coded
rules that users must learn). Thing takes 20 solid minutes to load from
local hard drive. A competetor is on the web with 35-40 Web pages (user's
1st choice which reduces rule-set) and each page has a large amount of
javascript coding. I will replace all with one fast page, and it will be
much better and faster for users.

I've been watching Flash over past few years, and I think its script
language (goes to a bytecode) is now powerful enough for some complex
logic, but it seems more awkward and more limiting than Java.

My understanding is that ActiveX has been turned off by many users
because of security problems.

Eventually NET will be readily available, and M$'s history is they it will
eventually work, and will probably become the best tool for Rich Clients if
you don't care about non-Windows users.
 
?

.

Hi All,

We're trying to make a decision about moving part of our product to the
web.

Before doing this, our marketing guys wants to know how many people might
actually be able to use it.

Does anyone know where I can find out what OS's ship with which JVM's?

95/2k/XP/Mac/Redhat/etc...

How dependent is it on the OEM (Dell, HP, etc) that distributes the
machine?

You are asking the wrong question. The short answer to your question is
that there is no easy answer to your question.

The reality is that even if the OS ships with a JVM, you don't want to go
with that. Testing the application would become a nightmare. You'd have to
test against any version that has or does ship with the OS plus any
versions arising from patches.

I'd recommend that you package a JVM with the application. Create an
installer for each platform and install a JVM with the application. Make
the scripts for the application point to the JVM you installed (don't
update system variables and rely on that).

If you do that the question then becomes, what JVMs exist for each
platform. You can start at java.sun.com. If you don't see your OS listed
there, you will have to go to the manufacturer of the OS. For example, I'd
get the JVM from Apple, HP and IBM for Mac OS, HP-UX and AIX,
respectively.
 
A

Andrew Thompson

On Fri, 05 Aug 2005 15:13:11 GMT, tex wrote:

I am not quite sure where to jump into this thread, ..but

(earlier 'Java is almost universal' text from tex trimmed)

(Dr. Uwe.S.)
It seems to me that you two are seeing opposite extremes
of the spectrum in the types of users you encounter.

My expereience suggest somewhere in the middle.

To Dr. Uwe, I feel I have a reasonable idea of the types
of (tech. head, latest games machine, online payments
without thinking twice) user that tex describes, but
can you give me a better idea of the sorts of users
*you* are basing your experiences on? Are they in academia?
Medical professionals? Moms'n'pops? Give us a rough idea
of the types of users you regularaly encounter.

*Fortunately*, the rush to 'do it as an applet' has fallen
to the logic that 'if it can be done in a web page - use
a web page'. That is a principle I strongly advocate.

Don't go throwing an applet at it (with any number of
associated useability issues) when the vanilla HTML page
can be just as good in a lot of ways, and far better in some.
Trying to resolve online pay problem, Bank tech went thru several
browser settings to check including that JVM was enabled. Assumed
they are using an applet somewhere.

Your presumption of an applet in this process amounts to no
more than that. It might well have been JS* or Flash. URL?

* You can check if Java is enabled using *JavaScript*,
and all it takes is a page change to transmit that
information back to the server.
Tech friends told me that US Post Offices uses applets, that IBM uses them
them w/ Lotus, and that there are thousands of applets on the web.

That does not mean they have much idea what they
are doing. Especially in terms of ..
I've installed one for mfr (internal use of salesmen, reps and distributors)
and all feedback ...

...just hypothetically if they have provided an applet
for feedback.

Don't laugh - it may not be an applet specifically,
but a lot of sites 'hear no bad reports' because the
user tries to report something and fails on first
attempt, or approaches the process of reporting
a bug/error only to find it all too complicated.

The site loses the business, never hears from the
potential client again, and has no idea what they
missed out on.
Applet logic is a small and fast download. I am able to add several small
images to make it look great in the initial Jar w/ the logic and it all
starts up fast, even for modem. The larger pics are then downloaded
while the user is working. Images cause a lot of waiting on the Web.
Not logic, and especially not logic in bytecode.

Just as an aside. Unfortunately, few applet devlopers have
that level of savvy. You up for writing a tutorial?
I am currently working on a tool ..

And just as another aside. It is good to hear of your
enthusiasm for applets and, in a small way, that every
developer that writes applets helps spread the JVM to new
users and thus make Java the x-plat/generic solution that
would best suit both end clients and Java developers.

Hope it goes well.

Also, I would be interested in looking over some of your
applet implementations (the web pages themselves).
Do you use HTMLConverter? The applet element? JWS? ..what?
 
A

Andrew Thompson

You don't think the OS should come with a JVM?

I wrote that entire document with the view that
the latest Java Plug-In should ship on every OS.

Or perhaps, NOT! SheeEEsh. How many times and in
how many ways do I have to say these things?
 
T

Tim Tyler

Andrew Thompson said:
I wrote that entire document with the view that
the latest Java Plug-In should ship on every OS.

Or perhaps, NOT! SheeEEsh. How many times and in
how many ways do I have to say these things?

First you say that it's up to the user to get their
JVM from Sun, and that that's the way it should be.

Then you say, you wrote a document with a view
that "the latest Java Plug-In should ship on
every OS".

....and then you contradict this in the next sentence.

I'm not sure blame for misunderstandings should be
placed entirely with your listeners. After your
clarification, I still can't make out what you
think on the subject of whether JVMs should come
with the OS.
 
T

tex

(earlier 'Java is almost universal' text from tex trimmed)

The most important part of 'Java is almost universal' is how
common is the JVM. I think it is almost alwasy pre-installed,
I think you can just about count on it. When, and if, this
changes, it would be good for all of us to know.

It is important because it means you, Jenny, and all of us can
develop applets where they make sense, and my contention
is they make sense a lot more than people realize.

Some of the reasons I think JVM is universal:

1. MS tried to quit including JVM, and there was such clamor
that MS extended its support of JVM, and most other vendors
said they would ship Sun's if MS stopped [from eWeek], and I
expect they intend to ship Sun's plug-in eventually. Maybe some
have already started.

2. All users (business folks most commonly w/ late model
IBM TP's) I've tried to show applet demos had JVM, and they
did not even know what JVM nor applets were. It just worked.

3. A Web stat w/i past year or so, said ~90% machines had
Flash player and JVM (Flash player % was slightly higher).

4. College son just bought new DELL w/ XP Media Player
and just came w/ JVM installed & ready. Applet came up
immediately.

5. Hearsay from other techs saying they see JVM on all
machines even though they don't do Java nor consiously
see applets in their day-to-day browsing.


RE: Dr. Uwe Seimet's not seeing applets anymore. I don't
see them either; however, there are a lot of things you don't
see much of on the Web and that is the inter-company stuff
that ya gotta sign on to see, and an employee of a big co may
only see the kind of stuff his co supplies. A lot of sophisticated
stuff cannot be seen. One of the co's I did some work for had
a $30,000,000 (thats millions) contract w/ Anderson to install
their internal company and B2B Web stuff. Dr. Seimet will see
none of it (nor did I). I am not saying there are zillions of
hidden applets in B2B, but how ya gonna know? There is
certainly one.

If an applet can do a good job and JVM's are everywhere,
use one.

*Fortunately*, the rush to 'do it as an applet' has fallen
to the logic that 'if it can be done in a web page - use
a web page'. That is a principle I strongly advocate.

I've heard that from everyone, too, and for quite a while I
kinda believed it. Like its general knowledge. As I think about
it more, and see JVM's everywhere, I belive this thinking has
caused a great deal of harm, and is wrong.

If an HTML page is better by your metic, or maybe you
worry about a visitor w/ a VGA screen running Win3.0,
by all means, but if an applet does it better, then do it w/ an applet.

Using basic stuff and designing for 1.1 seems to work very
well. I heard so much trouble w/ 1.0 that I did'nt even try to
consider Java until IE5.0 & 1.1, and then I very slowly started
looking into it.

Applet compatibility problems? Ya ever read the HTML books
with whole chapters telling me how to create stuff twice, once for
IE and again for Netscape, and even now ya see: "If you are using
AOL, then do . . .". and "If you are having problems with this
page and IE6, then download the. . ." Mindboggling compatibility
problems did not seem to stop Web developers before.

What are applets best for? This would take too long to go into
but, basically, your gray applet window is a window to the host
where you can pour data through to the user very efficiently
compared to new pages all the time. There is some talk about
the "NEW" technique used by Google maps, so that you don't
have to reload the page all the time. Jeeze! Applets have had
that ability for a long time.

I can provide a user with a much better and faster experience
getting info w/ an Applet than w/ multiple pages. With an applet
I have a canvas where I can show anything I can dream up.

I don't like the Web b/c looking for product info is soooo time
consuming. Yes, a huge amout could be done w/ better design,
but an applet is a very, very powerful tool to get information from
the host to the user. [Also, I'd rather slowly use the Web than
visit a rep and use the ph to get paper literature. Still, the Web
is WAY too much like, well pages, rather than an inteligent
agent helping me find info].

Consider our local Jr college. 5-10,000 students, and at registration
time, Web access nearly stops as many stu's are searching for classes,
registering, paying, etc. as the server builds 1000s of Web pages in
response to user clicks. We're talking about 30min & more wait
times for a page. All classes on all campuses could be packed into
a (relatively) small download and searching w/b instanteneous. Yes,
ya gotta go back to host for updates as classes fill, but with just a
few bytes going back & forth, the server would'nt even sweat
w/ thousands of on-line stu's. A stu's full account info and transcripts
are just a small amout of info when packed, but its no small deal
when 1000's of pages are assembled in the host and sent w/ just
some of the info on each of dozens of pages. If each stu logs on
and got an applet (few 100k), and all further work is done w/
packed data, and presentation assembly done on the client where
we have 100's of millions of instructions/sec to use, it could be
nearly pleasant for the stu.

I have also considered ways to entice user into loading new JVM,
but this is too long already.
The site loses the business, never hears from the
potential client again, and has no idea what they
missed out on.

This is key. Does your targets have JVM? I think overwhelmingly
user have it. It is important to know this info and when and if it is
changing.

Just as an aside. Unfortunately, few applet devlopers have
that level of savvy. You up for writing a tutorial?
I would consider that. Don't know what forum is appropriate nor when
I could do it right.
Hope it goes well.
Thanks. Running a little behind, partly b/c all programming seems to and
b/c it is difficult for user's to express rules, especially, those they do
in their
head.

Also, I would be interested in looking over some of your
applet implementations (the web pages themselves).
Do you use HTMLConverter? The applet element? JWS? ..what?

Right now I don't have any to show to public as they are private to the
business and I would not like to show my demo's and attract others to my
potential clients. At some point I would be happy to, perhaps as part of
the tutorial.

Excuse my ignorance, but I don't know what an HTM Converter nor
applet element are. I use the "<applet" tag if that has bearing. I assume
JWS is Webstart, & I don't use it b/c it is not 1.1.

--tex
 
A

Andrew Thompson

I've heard that from everyone, too, and for quite a while I
kinda believed it. Like its general knowledge. As I think about
it more, and see JVM's everywhere, I belive this thinking has
caused a great deal of harm, and is wrong.

If an HTML page is better by your metic, or maybe you
worry about a visitor w/ a VGA screen running Win3.0,
by all means, but if an applet does it better, then do it w/ an applet.

It depends what 'it' is.

A form and nothing more? Definitely HTML.
Use JS for validation.

It is light, easy, and with well written styles, can
resize to the user's default font size (automatically,
no JS needed).

Also, HTML forms do not suffer the same keyboard focus
problems experienced by some browser/VM combinations
(either your applet gets the focus, and the page
will no longer scroll using the keyboard keys,
or it never gets focus via normal keyboard traversal).

Secure applications, definitely Java.
D'n'D? You could probably do that with JS, but I
would recommend Java.

Something else? It depends...

More to the point, what are you doing in your applets,
that you *cannot* provide in HTML? Or HTML and a simple
(or complex) Javascript. Well written DHTML could do a
lot of the things done by GUI interfaces I have seen
done as applets. And better.
Right now I don't have any to show to public as they are private to the
business and I would not like to show my demo's and attract others to my
potential clients. At some point I would be happy to, perhaps as part of
the tutorial.

Excuse my ignorance, but I don't know what an HTM Converter nor
applet element are. I use the "<applet" tag if that has bearing.

You are safe from the HTML converter then, no need
to think further on it.

The APPLET element was deprecated in HTML 4.0, but
I find the tag too useful to give up. I either use
applet tags consistently (with a versioning applet
I wrote), or enlist the help of webstart for JVM
versioning of 1.3+ applets/applications.
 
S

Scott Ellsworth

Responding to just one small piece of the argument:
Consider our local Jr college. 5-10,000 students, and at registration
time, Web access nearly stops as many stu's are searching for classes,
registering, paying, etc. as the server builds 1000s of Web pages in
response to user clicks. We're talking about 30min & more wait
times for a page.

When you use an applet, you put some complexity on the user and take it
off the server. Appropriate at times, but I find that not that many
applet authors are really good at the kind of generalized testing that
makes life easy for the applet users. Thus, most applets end up making
the user's life harder, not easier. There are exceptions.

The example you gave is kinda frightening. A 30 minute wait time is
something like half a second or so dedicated to each user, assuming they
are all hitting at once. That said, the majority of content should be
available from static web pages. (If you have, for example, a class
list with the number of openings left, do not generate it every page
hit. Use a few millis every second to generate the static page, then
serve it with the regular web server.)

At the least, a few apps I have written made for that kind of load ran
on fairly cheap hardware.

An applet might still be the best solution, but I suspect that server
side could also be made to work with a bit of load balancing, a decent
db behind it, and judicious static page generation.

Scott
 
T

tex

Also, HTML forms do not suffer the same keyboard focus
problems experienced by some browser/VM combinations
(either your applet gets the focus, and the page
will no longer scroll using the keyboard keys,
or it never gets focus via normal keyboard traversal).

My interest is blding applications and don't intend for user
to scroll (though it could occur). Except for card-layout to
build Tabbed pages, I always use my own layout and sizes,
just as a Windows application which it more closely resembles.
The live applet as well as the demo applets launch from a link
on a page to shed the chrome. That said, I don't want to lose
focus when I need it. Can it occur that my applet lose
keyboard focus and a mouse click in, say a text box, won't
bring it back?

My aps are not part of a page of stuff. It is the purpose of
the page, which is otherwise mostly empty. Exception:
On the live applet my applet's request for another html page
of Text (help) could not control the size of the new html page;
however, a link on the page outside of my applet could bring
down the right sized html help page, so my applet calls the link
on the page outside the applet.

More to the point, what are you doing in your applets,
that you *cannot* provide in HTML? Or HTML and a simple
(or complex) Javascript.

Maybe JS can do it all, and I just don't know enough about
JS & DHTML. Need to think more about it, but perhaps
you can resolve some of it for me:

1. Applet byte code logic is very small. I can type untold
lines of code yielding a much smaller class than the source
text. JS seems to be text oriented. Consider a 10,000
row table of 10 integers/row. Say, 100K bytecode. In
text, the table may be 500K. As binary the Table
could be cleverly encoded maybe reducing its size much
more.

2. Can JS download decode, use, encode (for size) and
ship back binary data files (say like the one above)?

3. Does JS allow the equivalent of a Canvas class?
i.e. can I draw all I want?

4. Would you build Excell or Word as a JS web page?

5. Is M$ wrong about Thick clients and wasting their
time cuz JS can do as well at complex logic and massage
data as well?

6. If you wanted a numeric entry data box right justified
like typing into a calculator, can you do that in JS?

7. Can I somehow shorten JS names: e.g.
if (window.document.form.category.selectedIndex == 0 ||
window.document.form.category.selectedIndex == 1)
{
if (window.document.form.SubCat1.selectedIndex == 2 ||
window.document.form.SubCat1.selectedIndex == 3)
.. . .
kinka makes COBOL seem terse.
Well written DHTML could do a
lot of the things done by GUI interfaces I have seen
done as applets. And better.
Well written anything is better, and most stuff is not
well written nor well designed including Windows aps. Good
GUIs seem to be an art in itself. Lotta VB Windows stuff
is a bunch of dropdown boxes, text boxes, and very unfirendly
and unhelpful, and requires too many screens, and too much
going back & forth, much like most of the Web.

--tex
 
T

tex

When you use an applet, you put some complexity on the user and take it
off the server. Appropriate at times, but I find that not that many
applet authors are really good at the kind of generalized testing that
makes life easy for the applet users. Thus, most applets end up making
the user's life harder, not easier. There are exceptions.

That is a GUI problem. It is not the applet's fault, except on certain
things
e.g. JVM 1.1 has 2? fonts, and ya gotta work at it (glyphs or images of
other fonts) if you want another. But my concern is not with graphic
artists
work, such as building a nice viewing magazine page, or web page, or
brochure. I'm concerned with data & logic and tools and user helpful
applications, not a page. I think the Web developer mind-set is Page,
not application. Done correctly, an applet will help the user.

The example you gave is kinda frightening. A 30 minute wait time is
something like half a second or so dedicated to each user, assuming they
are all hitting at once. That said, the majority of content should be
available from static web pages. (If you have, for example, a class
list with the number of openings left, do not generate it every page
hit. Use a few millis every second to generate the static page, then
serve it with the regular web server.)

The 30min was while I was with daughter using schools computers,
but it is always a frustrating wait during registration and frequently
many many minutes. Kids keep banging the "send" button and
complaining, and wondering if the servers is down instead of back
logged (cuz that happens too), and ya gotta wonder after a while.

Conceptually; however, a large simultaneous user base is better
served by an applet-type concept whereby you send the newest
app once, and then packed data during the session. There is no
reason to have thousands share a computer when they all have
very powerful ones right in front of them. It is nuts that we all
have GB processors with powerful graphics engines on our desk and
generate the presentation on a server like we are stuck in the 70s
with IBM mainframes controlling dumb terminals.

At the least, a few apps I have written made for that kind of load ran
on fairly cheap hardware.

An applet might still be the best solution, but I suspect that server
side could also be made to work with a bit of load balancing, a decent
db behind it, and judicious static page generation.

I am certain there is much room for improvement w/o applets for the
JR College. I think the Web pages are too busy with unnecessary
images and I think each page is being generated live with Java (JSP?)
each time, and there may be other bottle necks that I'm not aware of.
Perhaps it is all done one one server provided by the state and shared
by all the Jr Colleges.

Bottom line. The ability to download an application to take care of
presentation & logic, and ship compact data back & forth, was given
to us w/ applets, and, perhaps, not promoted enough. I think their
value is much higher than their use.
 
A

Andrew Thompson

On Mon, 08 Aug 2005 20:44:17 GMT, tex wrote:

[snip]

Your post raised some interesting points, but a lot
of the answers had me thinking 'that depends on..'

It would be a lot quicker if I could see an actual example.
Could you perhaps drop me a link via email when you
have a publicly viewable page and we can continue much
more quickly (probably off group)?

You can contact me, andrewthommo, at gmail dot com.

[ Ultimately though, the fact that you are used to Java
and have little skill in JS suggests to continue with
applets, especially if they are ostensibly working for you. ]
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,598
Members
45,149
Latest member
Vinay Kumar Nevatia0
Top