TheServerSide.com is highlighting the news that originally appeared on java.sun.com regarding daylight savings time changes starting next year on the second Sunday in March (Mar 11, 2007) instead of what’s been the first Sunday in April.
But why should we care?
Well, we should apparently as this “this affects the JVM because it compensates for DST in various countries and older JVMs’ information about DST is incorrect. Downloading a current JVM, meaning the JSE6 beta, 1.5.0_06 or later, and 1.4.2_11 or later, corrects the problem. However, note that this may imply a regression test of applications just in case the newer JVMs introduce incompatibilities; also note that Sun does not suggest anything older than 1.4.2_11, which may affect users still on 1.3 or older.”
But then again, who will still be using JDK 1.3 or older next year? Why not move up to at least JDK 1.5 or 5.0 as it’s lightweight, allowing for annotations and more?
This is actually a big deal -- lots of companies still use older app servers that don't run with JDK 1.5. This may be what gets them to upgrade. I think changing DST is really stupid.
Steve,
Working in a large manufacturer plant where a lot of the equipment hasn't been supported for the last decade (VAX VMS), I'd say this will very much be a problem. Moving to JDK 1.5 sounds great in theory, but is not always possible. Upgrades == outages == unjustified $$. For example, one of our apps uses a third party library that does not run in 1.4, nevermind 1.5. The library in question uses some obscure security functions that are incompatible with later versions of the JDK, and the third party in question is a goverment institution, who in turn contracted it out. Did I mention this piece of software is fairly critical to a certain operation? This is only one example, there are lots.
So should we care? Absolutely.
These are good points. It sounds like a growing "Y2K"-like concern, potentially. What can be done? What do you two and others suggest?
It's been said before. 'Legacy' is an ugly word to the press, bearing shades of a Luddite shop full of steampunk difference engines, but in an IT shop, legacy often means 'That code thats been running our business for 10 years - or more' You think 1.3 is old? I just stood up a virtual machine this week to install an app that bundles 1.2. The app didnt run - the jvm doesn't support Pentium 4 processors.
The idiots in Congress brought this on all of us. It was clear and obvious that this would cause such issues -- but they went ahead and did this anyway.
This is doubly ironic in that the previous poster's software from the government won't be upgradable to cope with an issue created by the government.
Like others have said - an upgrade to 1.5 may not be a big deal on its own, but it implies a variety of other techstack upgrades that may not be feasible. Appservers in particular - we'd happily upgrade from Java 1.4 to 1.5, but the corresponding Weblogic 8 to 9 upgrade is a bigger problem.
For the same reason, we have clients on older versions of our product, still running Java 1.3 on Weblogic 6. It's old and clunky, but we don't really want to spend all the effort on upgrading what's essentially a legacy product.
The fact that we are even having to discuss this problem to, me is a flaw in the JVM. Not being flexible enough to adapt to change -- in this case it is the time. I would propose the jvm has a method of non-ubtrusive or automatic hotfix and not require a jvm restart which could cost $$. The JVM doesn't have to be a dumb terminal. : )
This is a self-inflicted y2k promblem with arguable benefit. This time around, there is more code to be checked and tested.
The JVMs in mobile phones are not (usually) upgradable and you're stuck with what's out there... and there are a lot of JVMs out there. The US tends to be more PDA or BREW-centric with regard to mobile apps, but the rest of the world, especially Europe, makes a lot of use of J2ME and this is the sort of legacy issue that bugs us.
As per Woody, this issue is self-inflicted.
I'm beginning to think the IT industry got hooked on IT crises by Y2K and has been lobbying to re-invent such crises on a smaller scale every so often.
Look at Sarbannes-Oxley (SOX) legislation (US). While primarily intended to address accounting, it contains IT password management provisions! These are rather specific and ignore than many IT infrastructures, some of which are quite secure, are not amenable to the password change policies forced by SOX. SOX also ignores the advice of various security experts who have stated that it does not improve security -- end-users are more likely to use lower-quality passwords or write them down now.
The daylight savings time legislation seems like just another little mini-crisis co-sponsored by the IT industry to ensure that there's always plenty for them to do.
People on platforms where there's no Sun JDK more recent than 1.4.x may have a difficult time upgrading to JDK 1.5, too. There's more to the world than just Windows, Solaris, Mac OS X, and Linux x86.
For those who care, it turns out that Sun did fix this in 1.3.1 as of 1.3.1_19.
What fix are we talking about in the SUN 1.3.1_19? Also the original idea that everyone should just jump to JDK 5.0 is just plain wrong, maybe we should just start using JDK 6?
What about us poor Windows 95 users? Don't we suffer enough already?
If you're still using Windows 95 I'd say you've got bigger problems. Win95 and Win98 have both been EOL'ed by Microsoft. You need to either upgrade to XP or switch to a Linux distro if your hardware is that dated.
dst sucks
What is the difference between Form PA and Form SR?
my site is better than yours