Which Java version to target?

[wizofaus]

Are there any up-to-date statistics available that give a good idea of
what Java version most web users have installed on their machines?

I'm developing a java applet as part of a web site, and I'd like to
know that most users will be able to view it without any issues - as it
is, if I compile it to target JDK 1.5, all the machines other than my
own that I've tested it on won't load the applet, and worse still,
don't give any sensible user feedback as to why. I accept there will
also be a percentage of users with an exceptionally old java version
installed (or worse still, none at all), but I'd like to keep this to a
minimum without sacrificing too many features that come with the later
java versions.

 

[Nate Smith]

Are there any up-to-date statistics available that give a good idea of
what Java version most web users have installed on their machines?

I'm developing a java applet as part of a web site, and I'd like to
know that most users will be able to view it without any issues - as it
is, if I compile it to target JDK 1.5, all the machines other than my
own that I've tested it on won't load the applet, and worse still,
don't give any sensible user feedback as to why. I accept there will
also be a percentage of users with an exceptionally old java version
installed (or worse still, none at all), but I'd like to keep this to a
minimum without sacrificing too many features that come with the later
java versions.

well, i'd stay with 1.4.lat.est, then.

that's what i hate about java - no upward compatibility.

other than that, it's fun!



- nate

 

[Sudden Disruption]

wizofaus,

Are there any up-to-date statistics available that give a good idea of
what Java version most web users have installed on their machines?

Great question.

And while we're at it, what percentage of websites have a Java
component?

Someone must keep track of this stuff.

It might help promote Java's adoption.

Sudden Disruption

 

[asj]

Are there any up-to-date statistics available that give a good idea of
what Java version most web users have installed on their machines?

With regards to Java penetration of the desktop browser, the latest
stat is here:
http://www.thecounter.com/stats/2006/June/java.php

I would strongly suggest using 1.4x

 

[Thomas Hawtin]

Are there any up-to-date statistics available that give a good idea of
what Java version most web users have installed on their machines?

[...]

I would strongly suggest using 1.4x

Based on what reasons? I assume most people use the Windows on-line
automatic update thing, which means they'll be using 1.5. OTOH, perhaps
lots of corporate machines are stuck on ye olde 1.4.

Tom Hawtin

 

[wizofaus]

With regards to Java penetration of the desktop browser, the latest
stat is here:
http://www.thecounter.com/stats/2006/June/java.php

I would strongly suggest using 1.4x

That's my current intention. It means no generics, which as a C++
programmer is frustrating, but I can live with it.

The site you gave doesn't actually give any version information though,
from what I can see.

Presumably it's not too hard to throw together some javascript/java
combination that will detect the current java version and give a
sensible error if it's not adequate (or even present), along with a
link to download a latest VM.

 

[Andrew T.]

I'm developing a java applet as part of a web site, and I'd like to
know that most users will be able to view it without any issues - as it
is, if I compile it to target JDK 1.5, all the machines other than my
own that I've tested it on won't load the applet, and worse still,
don't give any sensible user feedback as to why.

It does not have to be that way. E.G.

1. An applet that uses generics can be compiled with a class
format of 1.4. Then Java 1.4 can load the applet and pop a dialog
warning the user that it requires 1.5.

2. A Java 1.1 applet can load an entire other applet (so it can check
for necessary Java and load the 1.5 applet)

3. JWS wrapping the applet can specify a Java minimum version.

HTH

Andrew T.

 

[wizofaus]

It does not have to be that way. E.G.

1. An applet that uses generics can be compiled with a class
format of 1.4. Then Java 1.4 can load the applet and pop a dialog
warning the user that it requires 1.5.

That interests me...but at least with NetBeans, I haven't been able to
get it to target an earlier version. You say a warning - what's likely
to occur if they continue to use the application?

2. A Java 1.1 applet can load an entire other applet (so it can check
for necessary Java and load the 1.5 applet)

It does seem from what I've read elsewhere that this is the only
reliable way of gracefully handling older JVM/JRE installations that
works across all browsers.

3. JWS wrapping the applet can specify a Java minimum version.

I gather JWS is java web start - which seems to be related to starting
standalone applications, which I've no need to do at this point.

The main criteria I have for the application is for it to "just work":
that is, I should be able to walk up to almost any reasonably
up-to-date system, access the relavent web page, and have the applet
available and functioning. Anything that requires any sort of download
or setup procedure is a no-no.
Of course, there will always be a percentage of users whose systems
aren't adequately configured, and I want to be able to handle those as
gracefully as possible, but the main aim is to keep those cases to a
minimum.

 

[Nate Smith]

The main criteria I have for the application is for it to "just work":
that is, I should be able to walk up to almost any reasonably
up-to-date system, access the relavent web page, and have the applet
available and functioning. Anything that requires any sort of download
or setup procedure is a no-no.
Of course, there will always be a percentage of users whose systems
aren't adequately configured, and I want to be able to handle those as
gracefully as possible, but the main aim is to keep those cases to a
minimum.

i hear ya.


- nate

 

[The_Sage]

Reply to article by: (e-mail address removed)

Date written: 12 Jun 2006 17:25:52 -0700
MsgID:<[email protected]>

Are there any up-to-date statistics available that give a good idea of
what Java version most web users have installed on their machines?

I'm developing a java applet as part of a web site, and I'd like to
know that most users will be able to view it without any issues - as it
is, if I compile it to target JDK 1.5, all the machines other than my
own that I've tested it on won't load the applet, and worse still,
don't give any sensible user feedback as to why. I accept there will
also be a percentage of users with an exceptionally old java version
installed (or worse still, none at all), but I'd like to keep this to a
minimum without sacrificing too many features that come with the later
java versions.

This is the web and you should use HTML, DHTML, CSS, animated gifs, jpg, zips,
javascript, etc, whenever and wherever possible. There is no good reason to use
JAVA unless you have something necessary for your audience that can only
conveyed using JAVA. Flash and JAVA and other technology should be reserved for
rare occasions and compatibility should be restricted to no more than two
revisions back. That means when using advanced technology, you should alienate
those in your audience who refuse to keep up with technology. Since the higher
the technology the more of your audience you alienate, hence the reason to keep
it to a minimum.

The Sage

=============================================================
http://members.cox.net/the.sage/index.htm

"All those painted screens erected by man to shut out reality
-- history, religion, duty, social position --
all were illusions, mere opium fantasies"
John Fowles, The French Lieutenant's Woman
=============================================================

 

[Chris Uppal]

That's my current intention. It means no generics, which as a C++
programmer is frustrating, but I can live with it.

Take heart ! The absence of generics will probably make this easier for
you -- Java generics resemble C++ templates in so few ways that your C++
experience would be likely to get in the way.

-- chris

 

[Oliver Wong]

This is the web and you should use HTML, DHTML, CSS, animated gifs, jpg,
zips,
javascript, etc, whenever and wherever possible. There is no good reason
to use
JAVA unless you have something necessary for your audience that can only
conveyed using JAVA.

From what I heard, every browser has a slightly different API exposed to
JavaScript. If you don't want to write browser specific code, Java might be
the way to go.

Flash and JAVA and other technology should be reserved for
rare occasions and compatibility should be restricted to no more than two
revisions back. That means when using advanced technology, you should
alienate
those in your audience who refuse to keep up with technology. Since the
higher
the technology the more of your audience you alienate, hence the reason to
keep
it to a minimum.

Are you saying the OP should go with the more recent technology, or go
with older technology?

- Oliver

 

[The Ghost In The Machine]

In comp.lang.java.advocacy, Oliver Wong
<[email protected]>
wrote

From what I heard, every browser has a slightly different API exposed to
JavaScript. If you don't want to write browser specific code, Java might be
the way to go.

Java applets are far heavier than Javascript. Of course
applets in this context appear to be a bodge to work
around a broken implementation of what's supposed to be
standard Javascript.

But at least applets are single-behavior -- if the
environment's set up properly and the proper tags are used.
<APPLET> has been deprecated, and <OBJECT> as suggested
by W3 doesn't quite work. IE needs something *very*
specific -- and in fact it looks an awful lot like an
ActiveX reference (which makes sense since the Java
plugin is an ActiveX implementation, which just happens
to sandbox Java).

<APPLET> was nice and clean, and <OBJECT> as specified by W3
isn't too bad, but Microsoft goofed even that up.

Thanks, Microsoft, for breaking *both*.

</sarcasm>

In any event, Java .jar files *ARE* zip archives, with some
minor addons (the only one I'm aware of is META-INF/MANIFEST.MF).

Are you saying the OP should go with the more recent technology, or go
with older technology?

Go with technology that supports the most revenue [*].
This may be specific to the business one's in; for example,
if one knows that the customers will be Linux, then
one can either go with a Firefox-only solution (great,
especially with embedded SVGs) or with a solution that
is as light as possible in the goofiness possible with
Javascript, applets, JNLP/Java Web Start, layering, and
XML transformations (since browsers such as dillo and lynx
don't appreciate all of the niceties thereof -- in fact,
they don't really appreciate *any* thereof).

With an IE-only solution, one might be able to have slightly
more flexibility (since IE attempts to do it all) but one
also has to deal with IE's brokenness in a number of key
areas, such as embedded SVGs, CSS2, and PNG transparency.

Longer term, I for one hope IE's idiocies are dealt with,
either by shooting IE, or by Microsoft fixing its bugs
nice and robustly. (Given their track record, I'd worry.)

Unfortunately, IE is the dominant browser.

- Oliver

[*] customers roughly = revenue but it's not 1-1, obviously.

 

[wizofaus]

This is the web and you should use HTML, DHTML, CSS, animated gifs, jpg, zips,
javascript, etc, whenever and wherever possible. There is no good reason to use
JAVA unless you have something necessary for your audience that can only
conveyed using JAVA. Flash and JAVA and other technology should be reserved for
rare occasions and compatibility should be restricted to no more than two
revisions back. That means when using advanced technology, you should alienate
those in your audience who refuse to keep up with technology. Since the higher
the technology the more of your audience you alienate, hence the reason to keep
it to a minimum.

The Sage

The applet is essentially a WYSIWYG graphical form editor - supports
drawing boxes, lines, text-boxes, images etc. on to a form, and moving,
resizing etc. with the mouse. I don't doubt that it might (at a
stretch) be possible with Javascript, but Javascript simply doesn't
have the support libraries available that Java does.

It's the only part of the application so far that requires Java: the
rest is all CGI-backed DHTML.

And yes, I generally agree that trying to support old technology for
the sake of a larger market share is generally a short-sighted plan,
but it's basically about striking a reasonable balance: there's no
point trying to take advantage of every last little feature of the
latest and greatest version of a particular technology if only 1% of
your intended user base will be able to run your software, and equally,
it's foolish to battle on with ancient feature-poor technology just for
the sake of being able to support a handful of extra users that within
a year or so will no doubt end up upgrading their systems anyway.

 

[wizofaus]

Take heart ! The absence of generics will probably make this easier for
you -- Java generics resemble C++ templates in so few ways that your C++
experience would be likely to get in the way.

True, but for instance, I just wasted at least an hour today trying to
figure out why I was getting an ArrayStoreException - turned out it was
because I was accidentally adding the wrong object type to a Vector
(and subsequently converting it to an array). Being able to declare as
a Vector< > with the right type would have saved me that drama, as the
compiler would have picked it straight away.

 

[Chris Uppal]

(e-mail address removed) wrote:

[me:]

True, but for instance, I just wasted at least an hour today trying to
figure out why I was getting an ArrayStoreException - turned out it was
because I was accidentally adding the wrong object type to a Vector
(and subsequently converting it to an array).

I am surprised.

-- chris

 

[Sudden Disruption]

wizofaus,

Excellent advice Sage. As simple as possible, but no simpler.

latest and greatest version of a particular technology if only 1% of
your intended user base will be able to run your software, and equally,
it's foolish to battle on with ancient feature-poor technology just for

It's the old law of disproportionality. Shoot for the sweet spot in
the middle. **** the fringes. They'll be addressed by some nich
market anyway.

Being able to declare as a Vector< > with the right type would have saved me that
drama, as the compiler would have picked it straight away.

The strength of strong typing originally brought to the world by
Modula-2. It was called the bondage and discipline language and lots
of people hated it - right up until they started debugging.. The more
you are FORCED to define, the less will be assumed.

Beware the assumption.


Sudden Disruption

 

[Oliver Wong]

The applet is essentially a WYSIWYG graphical form editor - supports
drawing boxes, lines, text-boxes, images etc. on to a form, and moving,
resizing etc. with the mouse. I don't doubt that it might (at a
stretch) be possible with Javascript, but Javascript simply doesn't
have the support libraries available that Java does.

You might be interested in http://www.ajaxsketch.com/

- Oliver

 

[Dag Sunde]

You might be interested in http://www.ajaxsketch.com/

Nice...

Their motto is "Ajax for everyone...", so I tried it in IE...

"OOPS! - Firefox 1.5 (or higher) Required..."

:-D

 

[wizofaus]

Nice...

Their motto is "Ajax for everyone...", so I tried it in IE...

"OOPS! - Firefox 1.5 (or higher) Required..."

It's certainly impressive for what it is (though obviously incomplete -
undo/redo appears not to work, and I couldn't see anywhere to set the
rounded corners on rects), but anything that doesn't work under even
the latest IE is hardly viable at this point. I actually wanted to use
SVG originally as the basis for my form editor, but SVG doesn't
natively support embedding HTML text. Mine has an in-place text editor
that is basically a mini-word-processor, allowing the control of text
formatting, paragraph alignment, bullets & numberings etc. etc. I
actually know this much is quite doable in Javascript, as I've seen it
done (FCKEditor), but it was reasonably straightforward in Java, using
the HTMLEditorKit/JTextPane classes (although it needed a lot of
tweaking to get things to behave the way they should).