Folks:
In watching this and other discussions and in sharing this information with the Insight Manager development community, I want all of you to know that we share your pain.
Seven years ago when Insight Manager was re-architected for a browser-based UI, there was something new and cool called Java that had just come out. Insight Manager XE, the first product in the series, elected to extensively use Java.
What that means is that not only was code being written in Java by us, but we were choosing components to license, like JDBC for the database and various JAR (Java ARchive) libraries that provide functions we'd rather not write from scratch.
Our experience back then was that Java was a little finicky, and rapid changes in the runtimes were causing incompatibility, particularly on the client side. Java runtimes weren't widely installed then, and so we tried to make it easy and provide a mechanism to supply the JRE to any browser that accessed IMXE without one. The incompatibility issues led us to also strictly enforcing the version that we had qualified the application with.
Insight Manager 7 represented a redesign of the UI and a lot of rewrites for speed and efficiency. A lot of the Java code was replaced with JavaScript and DHTML, but it still was there, causing headaches. When practical, we updated to an incremental version of the JRE to support. (e.g. IM7 SP2 used 1.3.1_02 and the last release, IM7 SP2.3 now uses 1.3.1_09...you have to wonder about the stability of anything that has 4 significant places in the version)
It's important to know what "practical" means. It's not good enough to try it out to see if it seems okay; a new version triggers the re-testing of the entire QA matrix, a very expensive and time consuming job. In some cases, it's worth it. In the change from _02 to _09, we had a reasonable expectation that things wouldn't be that much different. Updating to _09 however was important because of the security patches that Sun had made available.
Not only that, but in many cases, libraries that we have licensed from other vendors to use in our product have either not been updated to work with newer JREs, or in some cases, a newly rewritten JAR is required to work with a given JRE. That has the potential to have even more impact on the code we have written.
The story is now closed on IM7 and no more development work is being done on that product. The last and final release is IM7 SP2.3 and it "enforces" the use of the 1.3.1_09 Java runtime. No change to that practice is being contemplated and there is no user setting to disable it.
More recently, the introduction of HP Systems Insight Manager brings with it many lessons about what has gone before. Namely, the almost complete elimination of client-side Java code. The client portion of the hpSIM application is almost entirely JavaScript (which is interepreted by the browser and does not need a runtime) and Dynamic HTML. The only remaining Java code that requires the JRE are the table views (JavaScript was considered and rejected for this because of performance reasons).
Consequently, the dependency on a specific runtime has gone way down. In addition, we have seen more stability between Java releases in the 1.4.x timeframe, although those still exist. Today, we enforce a minimum runtime of 1.4.1_04 for hpSIM in a Windows browser and 1.4.2 on a Unix/Linux browser. We still would like to eliminate Java entirely if at all possible, and still are working to make that real in a future version.
We're not the only ones to have faced the problem. There are some prominent management products from other vendors that use Java but solved the problem by requiring the use of their own client application in place of a browser. That gave them more proprietary control over their environment.
The last remaining issue to comment on is in regard to multiple versions of the Java runtime being available on the same system to work with various applets. Java's design was specifically coded to allow this, but we, too, have noticed some of the incompatibilities and problems mentioned in this forum. One of my personal observations is that the 1.4 and later JRE uses a slightly different design, visible in the control panel applet. Various 1.4 versions seem to play pretty well together but throw a 1.3 in there and sometimes it gums up the works. Since hpSIM uses 1.4, it "plays nice" a little better with other applications also using some 1.4 variant.
All bets may be off when we get to 1.5. ;)
All that being said, Java does have some benefits to it, and HP will continue to use it for many purposes. As noted here, it is frustrating enough when an HP app requires a different version of a runtime than another app you have in your environment, but especially frustrating when the two incompatible apps are both from HP. (I personally spent a considerable amount of time a couple of weeks ago trying to talk to a ProCurve's HTML/Java interface with a newly installed system...which didn't come with--and now you can't download--the Microsoft JVM. Updating the firmware on the switch was required to allow it to use a 1.4 Sun JRE that was the same as hpSIM was using.) We are proceeding on three lines of inquiry to minimize the impact on customers:
1. Utilizing Java only where it's necessary and minimizing our dependence on 3rd party library JARs
2. Coordinating this aspect of the product technology through the HP CTO's office (which can only have limited success just because individual products have their own schedules and by their nature will be somewhat out of sync)
3. Hoping that the radical changes we have seen in the past between different versions of the JRE will not have as much of an impact.
In the meantime, this thread started out because of a "locked down" environment that only had 1.4.2 runtime available to the terminal services clients. Why not connect to the IM7 server using terminal services? If that server is not one of your normal terminal services hosts, it can be configured for remote administration that allows for 2 sessions. That would mean that only the IM7 server itself would need the 1.3.1_09 runtime. All of the client systems could potentially be used to get to IM7 without having the JRE itself. If in the context of the terminal services session the "lockdown" doesn't have the RDPCLIENT application, you can use the TSWEB terminal services web client ActiveX control.
Finally, I'd like to encourage anyone who would like minimize their Java angst to upgrade as quickly as possible to HP Systems Insight Manager because the pain factor is much less. If you don't already have the transition under way, you may want to wait just a short time for 4.1, a version expected next month. Not only does it smooth over some of the edges every dot-oh product has, it also has a data migration tool that brings your IM7 settings forward.
Thanks for everyone's input.
--David
