I’ve seen a similar problem: I have a small group of systems(a few dozen) and I’m preparing to use JavaRa for Java housekeeping, but have stalled after running into an inconsistency with the step 1 detection to remove uninstallers. Here’s what I’ve seen: My “bench test” JavaRa 2.1 runs with Win7 x64 and Win7 x32 look great. With both, step 1 detects properly and “Remove Java Runtime” brings up uninstallers. For step 2 (my favorite feature), “Perform Removal Routine” works well also.
So, to reiterate, I’ve used JavaRa 2.1 with a couple of Win7 x64 systems and it runs fine as intended.
Where I hit a snag was with my first couple of “live user” tests. Both had Java 6u39 (standard config has been to start with 6u23 for a particular app requirement); one also had an older Java 4, the other had the recent Java7u13. The step 1 detection for uninstallers 1) didn’t find the old Java 4 and Java 6 on one system, and also didn’t show the Java 6 & Java 7 on the second system.
I haven’t done any real detective work to look for clues yet, but I wonder if Java variations with CLSID keys make JavaRa’s task all the more difficult and result in hit & miss problems like this.
My take on it at this point is that JavaRa is a great IT guy tool. I really like the “Perform Removal Routine” and the definitions file shows solid effort. Unfortunately, if JavaRa occasionally has a problem with step 1, it leaves the casual user with a “what do I do now” problem. As an IT guy, I guess my workaround is to use the Win 7 “uninstall a program” and then use the JavaRa “Perform Removal Routine” for deep cleaning…
Please let us know if there’s a JavaRa log, or maybe a CLSID key ID or something that could help us to help SingularLabs with the development effort!
Thanks, and keep up the good work!