JDK-7012538 : Deployment code should be friendly to Windows XP roaming profile users
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6,6u10,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_2000,windows_vista
  • CPU: generic,x86
  • Submitted: 2011-01-14
  • Updated: 2017-05-16
  • Resolved: 2011-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b128Fixed
Related Reports
Duplicate :  
JDK-6931373 - Deployment code should be friendly to roaming profile users
Duplicate :  
JDK-6681595 - Vista: Roaming profile users fail to access/use disabled Cache location Change button
Relates :  
JDK-7015128 - Build failure due to missing getLocalHome() in the UnixPlatform
Relates :  
JDK-8024685 - $USER_HOME not working anymore
Description
When Java installs on a Windows XP computer, it stores its updates, cache, and temporary files in the wrong data location.

On Windows XP there is this technology known as Roaming User Profiles. When a domain user logs in on the network their user profile is copied from the server to the local computer. When they log off, the profile copies back from the desktop to the server. This allows the user to go to any domain joined computer, log in, and their desktop and documents follow them to that computer.

Microsoft's way of handling temporary application files and other temp files is to create a special section of the profile for temporary data. This location may store as much data as necessary but does not copy back and forth to the network. On Windows XP this is called "\Local Settings\Application Data" and "\Local Settings\Temp" in each user profile, and is usually a hidden and/or a protected system folder.

However many 3rd party companies apparently do not understand how roaming works or its limitations, and Java really screws it up. JRE stores nothing in the Local Settings section and puts everything into the roaming side, which can total a couple hundred megs and adds to the roaming login/logout delays.

Meanwhile, it appears that most Java updates don't delete themselves after they install, each one leaving behind a 10-25 meg drag on the user's roaming login and logout times every time an update downloads to be installed. 

======

The fix:



4. Remove anything from "\{user}\Application Data\Sun\Java\Deployment\" that is not a user or JRE preferences file. (This means delete "Deployment\Cache\")

5. Store the deployment cache locally only, in "\{user}\Local Settings\Application Data\Sun\Java\Deployment\Cache\"

On Vista/Win7 the profile directory layout does change somewhat so the storage locations may be slightly different for those Windows versions. Generally using the registry locations for user profile folders should put the temp files and updates in the right temporary spot..

Note: part of required changes are in the install/autoupdate area and they are filed as 6931370.
*** (#1 of 1): 2010-03-02 11:02:34 PST ###@###.###
Comments
EVALUATION Specification: 1. Transparently convert existing old cache content and shortcuts to the new cache location. 2. Individual existing cache items are available for use immediately on-demand and does not have to wait after full cache upgrade. 3. Run as background process without GUI, triggered on first access to the cache (first running of applet or webstart). 4. Once complete, it will not be run again even the new cache is wiped out. 5. Items under old cache be intact for later conversion to different machines in the domain. 6. there should be one cache upgrade process per machine per user at any time. 7. there should be a limit on number attempts incomplete/failed full background upgrade Note: for this upgrade implementation from cache version 6, cache on WinXP at non-default location, or cache on Windows Vista or Windows 7 (already under non-roaming profile folders) would not be relocated.
28-01-2011
EVALUATION Fixed with changeset: http://closedjdk.sfbay/jdk7/deploy/deploy/rev/01caf08cac8b
28-01-2011
EVALUATION Proposed change: Move the default deployment cache off roaming user profile area to non-roaming profile area for application data. For example: C:\Documents and Settings\user\Local Settings\Application Data\Sun\Java\Deployment\Cache Local Settings is special folder for temporary or local application data that would not be copied from server when logging on or copied back to the server when logging off. Deployment cache copying will no longer contribute to the logging on and logging off synchronization cost. For a smooth migration to JRE 7, the relocation would: 1. transparently convert existing old cache content and shortcuts to the new cache location. Existing cache items are available for use after JRE installation complete. 2. be run as background process without GUI. 3. once complete, it will not be run again even the new cache is wiped out. 4. leave items under old cache intact for later conversion to different machines in the domain. Note that cache on WinXP at non-default location, or cache on Windows Vista or Windows 7 (already under non-roaming profile folders) would not be relocated. * Side-effects: The deployment cache contains only retrievable or regeneratable or session temporary application data. So, the possible side-effects from this change are few and mild, with reasonable resolutions. A. Non-default cache location: Currently user could configure deployment cache location using control panel. This change does not impact these use-cases. B. Default cache location: (1) Non-roaming: possible one time noticeable cache conversion activity. (2) Roaming but with dedicated machine: Windows Server domain user with an assigned desktop or laptop. Same as (1). (3) Roaming with non-dedicated Windows desktops. This is typical for school, sale or manufacturing environments. In this case, cache copy conversion noticeable performance delay on logging in to different machine for the first time. Also, caching of application data (through PersistenceService API) are not replicated along with roaming. However, this is similar to browser cookies, application should save needed application back to the server if needed before user logging out. If needed, user could configure the cache location using Java Control Panel to point to a Windows network share folder.
22-01-2011