JDK-8004653 : AuthCacheBridge should not be in sun.net.www.protocol.http package
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-12-06
  • Updated: 2017-07-04
  • Resolved: 2014-03-31
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.
8u20Fixed 9 b12Fixed
sun.net.www.protocol.http.AuthCacheBridge is problematic for modularization because it's in the same package as the http protocol handler and so creates a split package issue for the base module.

This bridge needs to re-examined and possibly refactored so that we don't have any dependencies on deploy code in the sun.net.www.protocol.http package.
kind of code refactoring. Mark as not verified.

applying patch from Chris and will send out for review.

I added an attachment that contains a changeset that implements a fallback to use reflection in the case where AuthenticationInfo is not public ( old 6 JRE's ), see https://bugs.openjdk.java.net/secure/attachment/19477/8004653.patch Andy, Can you take this patch and run it through the usual deploy review/test/push process? Or let me know and I can do it. I would like to get this into JDK 9.

In JDK 7 FCS, the public modifier was added to sun.net.www.protocol.http.AuthenticationInfo. I have confirmed that with the above deploy patch, jdk7u-dev compiles fine. Since there is no use of reflection, or other trickery, and the dependencies are static, once compilation succeeds then we can have confidence in the change. AuthenticationInfo has not changed in JDK 8, or 9. Therefore, the only release family remaining that would need some changes ( make AuthenticationInfo public ) is JDK 6.

AuthCacheBridge appears to be a delegate to expose, previously private/package-private, methods from AuthenticationInfo to the deploy code. Since JDK7 the required methods, and the top-level type, have the public modifier. This delegate would appear to be redundant now. A simple change with JDK9 builds fine, and proves the above. See http://t4.ie.oracle.com/~chhegar/webrevs/8004653/webrev.00/webrev/, or 1) hg mv src/common/share/classes/sun/net/www/protocol/http/AuthCacheBridge.java src/common/share/classes/com/sun/deploy/security/AuthCacheBridge.java 2) Fix up package name and imports in AuthCacheBridge.java --- --- src/common/share/classes/com/sun/deploy/security/AuthCacheBridge.java 2014-03-24 15:46:11.891906915 +0000 +++ src/common/share/classes/sun/net/www/protocol/http/AuthCacheBridge.java_SAVE 2014-03-24 15:46:09.255907011 +0000 @@ -2,10 +2,10 @@ * Copyright (c) 2006, 2012, Oracle and/or its affiliates. All rights reserved. * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */ +package com.sun.deploy.security; -package sun.net.www.protocol.http; - -import com.sun.deploy.security.AuthKey; +import sun.net.www.protocol.http.AuthCacheValue; +import sun.net.www.protocol.http.AuthenticationInfo; /** * The class is to resolve the problem of getting at private information in the --- 3) Fix up imports in CredentialManager.java --- diff -r 6b1472d04094 -r 6d3b886a8ed2 src/common/share/classes/com/sun/deploy/security/CredentialManager.java --- a/src/common/share/classes/com/sun/deploy/security/CredentialManager.java Fri Mar 07 11:01:46 2014 -0800 +++ b/src/common/share/classes/com/sun/deploy/security/CredentialManager.java Mon Mar 24 15:46:11 2014 +0000 @@ -7,7 +7,6 @@ import com.sun.deploy.config.Config; import com.sun.deploy.trace.Trace; -import sun.net.www.protocol.http.AuthCacheBridge; import sun.net.www.protocol.http.AuthCacheImpl; import sun.net.www.protocol.http.AuthCacheValue; --- The only issue now is that the deploy code needs to be able to run with previous JREs, down to JRE 6.

This is a blocker to building modules that include the closed repositories. Chris has agreed to contact the deploy team with a proposal on this.