0 Replies Latest reply: Oct 22, 2013 1:57 PM by 03236bd1-1a5d-4098-bfca-c9dab6207c73 RSS

    Maintaining JRE environment - class action lawsuit

    03236bd1-1a5d-4098-bfca-c9dab6207c73

      I'm starting to wonder why there has not been a class action lawsuit against Oracle for the IT costs of maintaining a JRE environment.  We have 11,000 computers on which none of our staff are administrators.  First off, we made the poor decision to purchase Kronos as our punch clock system since it runs on Java.  This means every staff member uses Kronos and therefore java. 

       

      Problem 1:  When Kronos is loaded it asks our users if they are sure they want to run this UNKNOWN app by signed publisher Kronos Inc.  Answering the question in the negative seems to break Java so that they cannot ever run the app unless we delete their Java cache.  This has resulted in a ton of support time to fix.  I managed to work around this by using deployment.properties to use a shared trusted certificate location and putting a trusted.certs file in there where Kronos is pre-approved.

       

      Problem 2:  When Java is two versions out of date, it prompts our users to update without first checking to see if they are admins.  I have heard directly from our users that they clicked on update because it was "recommended".  Java get partially installed and then gets permanently broken.  Even blocking the java site using our web filter doesn't help with this one.  Subsequent attempts to access the Kronos site results in the browser being redirected to the Java website which is then blocked by the filter.  Deleting c:\users\username\appdata\locallow\sun does not make it stop trying to redirect so I don't know where this settings is stored.  Deleting the user's profile does restore Java to functioning status.  This update warning happened to us, district wide this week, causing thousands of profiles to need wiping.   Who should pay for the hundreds of hours of support and the reputation damage to the support team?  I'm thinking Oracle. 

       

      I did set these two flags in deployment.properties which I had to retype manually since this $&*! forum won't let me paste text.

      deployment.expiration.check.enabled=false

      deployment.javaws.autodownload=NEVER

       

      This seems to get rid of the initial prompt for updating.  But if a user switches to their time card view from the punch screen, it loads a separate applet which then causes the update prompt again.  I still don't know why it ignores the setting on the second applet. 

       

      Problem 3:  With the new update of 7u40 and up, you can no longer get rid of the "are you sure you want to trust this app" prompt using deployment.properties.  You now have to make a DeploymentRuleSet.jar and sign it to create a whitelist.  Great, there goes another $160 per year for a code signing certificate which Oracle should be paying for.  Screwing around with this is what caused the update delay which in turn caused update fiasco in problem 2.

       

      There is so much shame to be passed around when it comes to the configuration and use of Java in a corporate environment.  If you count amount of money spent on technical staff salary every year on Java issues, I'm sure we have broken the $10,000 mark.  It doesn't have to be this way, Oracle.

       

      Recommended fixes.

      1.  Allow active directory based rulesets that don't require a signed JAR

      2.  Allow any method of white listing sites that doesn't require a signed JAR.  If malicious software has gotten admin rights on your computer, it's your own fault.

      3.  Have the updater check for admin rights before running

      4.  Have the "out of date" checker check for admin rights and remove the update option if they don't have it.