for this year. Yes, a straw poll of developers (as you've done on
jswiki-
users) will certainly show that developers are fine with JDK 5 -- I'm
Please note that jspwiki-user contains users - the people who apply
jspwiki in their daily life. They are exactly the crowd we want to
reach.
jspwiki-dev then contains developers. They are users, too, but as
you say, they are probably fine with JDK 5.
to upgrade. There's a lot of old equipment out there, and we're not
even
talking about the developing ("third") world, where a 386 is hot
stuff.
Yes, we are not. So why bring it up?
The impact is that for a very large number of organizations
(thousands)
that my client organization is parent to, they are limited by (as I've
mentioned previously) lack of time, expertise, but particularly,
compati-
bility with existing systems is the biggest determining factor.
I would still like to know hard numbers for how many devices, which
platforms, and why they cannot run JDK 1.5.
knowledge, they (a national institution) have several existing systems
that *cannot* be upgraded because (a) the vendor doesn't exist or has
stopped production,
We still exist. Sun still exists. Are you saying someone went ahead
and installed JSPWiki on those computers and does not exist anymore?
Or what are you saying?
We are only talking about ugprades of JDK 1.5 - not HW upgrades
(since I am not at all convinced those are needed. As I said, a
newer version of JSPWiki is likely to be more resource-demanding than
a new version of JDK. The minimum requirement for Java 5 is Windows
98 and 64 megs of RAM. Running JSPWiki in such a configuration would
already be very demanding [not to mention the idea of running Win98
as a server OS... shudder...]. Why exactly would someone need to
upgrade their HW or OS which would result from Java 5 rather than
JSPWiki 2.6?
Pretty much the only option that I can think of are people running
either Solaris 7, or earlier version of glibc on RH7 or 8 systems,
for which JDK 5 is not available. But it is unlikely that these
people will be upgrading until they have to, and retrotranslator
should help them out most of the time anyway.
or (b) we don't have the manpower to make major
changes to an existing system (e.g., we have one guy maintaining a
really
ugly, fragile system with a million customizations done over a long
period by multiple contractors). And that's why the IT department
won't
move from JDK 1.4, nor are they willing to support multiple
versions due
to path issues.
Which path issues? JDK 5 lives very nicely along all other JDKs.
You set the JAVA_HOME, and java will happily run as many JVMs in as
many configurations as you would like. I routinely run JDK 1.4, 5
and 6 applications on my Mac, not always even knowing which one I am
using.
If your admin is incapable of figuring this out, they are unable to
install and upgrade JSPWiki too. So no harm done there.
But beyond the parent organization, requiring JDK 5 may
very likely mean that the child organizations (typically local
libraries
and non-profit orgs) will have to use an older version, and will not
be able to use the customized version I've been working on as part
of a
hive plan.
Retrotranslator should work for you then, since you are deploying a
customized, compiled version anyway - not the official branch.
Also, if the environment is homogenous enough, you can even deploy
the entire JRE as a part of your system. Makes it easier for your
admins, too.
After all, you're the vendor and getting paid to develop this custom
version, not us ;-)
I would highly recommend that you check out what the situation is,
and get the hard numbers. If they've replaced HW or reinstalled the
OS in the past three years, they are very likely already running JDK 5.
/Janne
