Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8164089

Java update and custom location issues

    XMLWordPrintable

Details

    • x86_64
    • windows_7

    Description

      A DESCRIPTION OF THE REQUEST :
      I indicated v8 u101 only because I had to choose one option, and that is the one I currently have installed. The problem I am reporting, though, is not in the Java runtime, but in the installers that have demonstrated this same behavior ever since I first owned a PC in 2011.

      During my initial installation of Java, each time that I have initialize a system drive, I have utilized the full installer download. That installer offers the client the option of installing to a custom folder location. I appreciate that; I like to be organized. It is easier for me to trace problems, verify contents, and locate possible malware when I am able to organize my programs folders my way.

      Unfortunately, your Java automatic update mechanism has never respected the client's custom installation locations that your own download installer offers to begin with. It also fails to respect client start menu organization.

      I eventually got tired of performing a manual installation every couple of weeks in order to keep my computer organized the way that I want it, so now I allow the auto update routine to perform--which clutters up my folder tree (and irritates me). :) But I still, every time, need to reorganize my Start Menu folders back the way I want them because I have to look at that every day, and I refuse to let it get out of hand.

      Honestly? If everybody's installation routines were as inconsiderate as yours, I would never be able to make sense of what is going on in my computer.

      It really would be really, really nice if you could fix the installation routines so that they would be as user-friendly as most everyone else's modern installers and updaters. I don't really know anything about writing code, but I would be willing to bet that the Start Menu and Programs folder location options are so common--that the code could just be imported from another open-source application, and the time spent on that task would be minimal. Maybe?

      Well, thank you very much for putting up with me, and any consideration that you give to my suggestions!

      Sincerely,
      Brett

      JUSTIFICATION :
      To modernize the installation/update process to be user-friendly, insofar as respecting the end-user's desire to maintain and organize their files and folders in a manner that they deem best for them.

      To bring that process up to the same standards that are now recognized and maintained in almost all mainstream software companies today. Considering that most software is installed one time and updated occasionally--or even rarely; in the case of Java, this is so much more important due to the environment of frequent updates necessary due to the multitude of applications for your software, and the necessity for frequent security patches. Providing modernization to your installation/update routines just one time will benefit your end-users in a profound and immeasurable way--for years to come. So much time saved!!

      To allow the update routines to respect (there's probably a better way to say that, but that is the best I can come up with right now) the customized installation location options that your downloaders ALREADY offer to begin with; and to bring the same continuity to the Start Menu options, which more often than not parallel the organizational (OCD) desires of the end-user.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      Users have come to expect most software installers to offer customizable installation locations, and customizable Start Menu locations, for the purpose of personalizing and organizing our own hard drives in the manner that we see fit.

      In the case of installation packages that are so user friendly, it is a common expectation that automatic update routines will mirror the choices made during the initial installation of that same program from the same company.
      ACTUAL -
      Currently, even though the Java downloadable installers offer a custom installation location, when one does utilize this to create a custom folder location (for example: C:\Program Files\Internet\Java\) -- when the user runs the updater weeks later, the updater is not programmed to mirror that choice that the user was originally offered. Not only does the routine not update to the custom location, it does not even recognize that the custom location exists.

      The result is that, after the update routine runs, it places the new version of Java in the default location (C:\Program Files\Java\), cluttering the main program folder. Not only that, but the updater fails to REMOVE the older version of Java that was placed in a custom location with the blessing of your own installation download! This, gentlemen, is a potential security flaw. I only know this because I read the documentation on your website extolling clients to REMOVE OLD VERSIONS OF Java!

      Further, there is no current option in your installer to create a custom Start Menu location. Now, I know how to move files and folders in the Start Menu. But after spending all that time making my Start Menu look pretty, I have to run an update which places a new set of files in the Start Menu in the--You Guessed It!!--In the default Start Menu location. Which means the client is now compelled to spend time making his (or her!) Start Menu look the way it used to before he (or she :)) ran the Java Update routine.

      Attachments

        1. screenshot-1.png
          screenshot-1.png
          69 kB
        2. screenshot-2.png
          screenshot-2.png
          55 kB
        3. screenshot-3.png
          screenshot-3.png
          74 kB

        Activity

          People

            billyh William Harnois
            webbuggrp Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: