-
Bug
-
Resolution: Fixed
-
P2
-
6u18, 6u19
-
b03
-
generic, x86
-
generic, windows
-
Not verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2198901 | 7 | Audrey Lin | P2 | Closed | Fixed | b104 |
| JDK-2188393 | 6-pool | Audrey Lin | P2 | Closed | Won't Fix | |
| JDK-2188856 | 6u21 | Audrey Lin | P3 | Closed | Not an Issue |
This a placeholder for research on what the requirements of J4B are for shipping AU. Now that we have AU2.0, it needs to be revisited.
Questions are:
Should the JRE J4B install au2.0 at all?
If we install au2.0 for J4B, should we disable AU? (current 6u17 behavior with au1.0)
If they have an older AU version from non-J4B build that's installed and running (say 6u15), and then install a J4B with au2.0, do we have to disable the old running au2.0?
To clarify, the scope of this CR is *only* to re-implement the J4B behavior that existed in 6u17. That is: install and disable Auto Update by removing the RUN key for jusched and setting the encypted DISABLE value for the EnableAutoUpdateCheck registry value under HKCU\Software\JavaSoft\Java Update\Policy.
Any changes to this behavior will be handled by new RFEs
Questions are:
Should the JRE J4B install au2.0 at all?
If we install au2.0 for J4B, should we disable AU? (current 6u17 behavior with au1.0)
If they have an older AU version from non-J4B build that's installed and running (say 6u15), and then install a J4B with au2.0, do we have to disable the old running au2.0?
To clarify, the scope of this CR is *only* to re-implement the J4B behavior that existed in 6u17. That is: install and disable Auto Update by removing the RUN key for jusched and setting the encypted DISABLE value for the EnableAutoUpdateCheck registry value under HKCU\Software\JavaSoft\Java Update\Policy.
Any changes to this behavior will be handled by new RFEs
- backported by
-
JDK-2188393 need to resolve j4b vs au2.0 scenarios
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- duplicates
-
-
- Closed
-