RFR 8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss

Valerie Peng valerie.peng at oracle.com
Mon Sep 8 22:25:17 UTC 2014


Max,

Mostly look fine. Just some comments, questions (see below):

<src/java.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java>
1) line 71 - 76 was done in Krb5Context.java. Is it really necessary to 
move it here? I don't see a reason to.

<src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java>
1) line 1435, the cloning is removed? I didn't see a corresponding clone 
being done in the caller, e.g. ExtendedGSSContext.

<src/java.security.jgss/share/classes/sun/security/jgss/JgssExtender.java>
1) the class description mentioned the registration process is hardcoded 
in GSSManagerImpl. But it looks to me that it's actually done by the 
com.sun.security.jgss.Extender class?
2) do you think we should require permissions for calls to 
set/getExtender()?

<test/sun/security/krb5/auto/Context.java>
1) line 364: move it inside the if-block? Seems no value calling 
xstatus() when x is null.
2) line 401: move it inside the if-block? Since if x is null, then there 
is no output following this println() call.

Thanks,
Valerie

On 8/30/2014 6:59 PM, Weijun Wang wrote:
> Webrev updated at
>
>   http://cr.openjdk.java.net/~weijun/8042900/webrev.01/
>
> as per Alan's suggestions.
>
> Can anyone in the security team take a look?
>
> Thanks
> Max
>


More information about the security-dev mailing list