Code review request: 7064075 Security libraries don't build with javac -Xlint:all,-deprecation -Werror

[Alexandre Boulgakov]

Hello Sean,

Have you had a chance to look at this webrev?

Thanks,
Sasha

On 7/18/2011 6:21 PM, Alexandre Boulgakov wrote:
> Hello,
>
> Here's an updated webrev:
> http://cr.openjdk.java.net/~smarks/aboulgak/7064075.2/
>
> I've reexamined the @SuppressWarnings("unchecked") annotations, and 
> added comments to all of the ones I've added. I was was also able to 
> remove several of them by using covariant return types on 
> sun.security.x509.*Extension.get(String) inherited from Object 
> CertAttrSet<T>.get(String). I've also updated the consumers of 
> sun.security.x509.*Extension.get(String) to use the more specific 
> return type, removing several casts and @SuppressWarnings("unchecked") 
> annotations.
>
> Also, please take a closer look at my changes to 
> com.sun.security.auth.PolicyFile.getPrincipalInfo(PolicyParser.PrincipalEntry, 
> final CodeSource) in 
> src/share/classes/com/sun/security/auth/PolicyFile.java lines 
> 1088-1094. The preceding comment and the behavior of 
> Subject.getPrincipals(Class<T>) seem to be more consistent with the 
> updated version, but I wanted to make sure.
>
> The classes where I added serialVersionUID's are either new or have 
> the same serialVersionUID as the original implementation.
>
> Thanks,
> Sasha
>
> On 7/18/2011 5:33 PM, Brad Wetmore wrote:
>> (Apologies to folks without access to the older sources.)
>>
>>
>> On 07/18/11 15:00, Sean Mullan wrote:
>>> On 7/18/11 5:35 PM, Alexandre Boulgakov wrote:
>>>> Is there an easy way to see when a class was added to the JDK?
>>>
>>> For standard API classes, you can use the @since javadoc tag which 
>>> will indicate
>>> the release it was first introduced in.
>>
>> Standard, exported API classes.  Some of the underlying support 
>> classes for API packages like java.*.* weren't always @since'd properly.
>>
>>> For internal classes, there is no easy way, since most don't have an 
>>> @since tag.
>>> I would probably write a script that checks the rt.jar of each of 
>>> the JREs that
>>> are archived at /java/re/jdk. The pathnames should be fairly 
>>> consistent, just
>>> the version number is different.
>>
>> Don't know which classes you're talking about here, but some classes 
>> started out in other jar files and eventually wound up in rt.jar.  
>> Also, some files live in files other than rt.jar.  I usually go to 
>> the source when looking for something.  If it's originally from 
>> JSSE/JGSS/JCE, you'll need to look on our restricted access machine.
>>
>> When I'm looking for something that is in the jdk/j2se workspaces, I 
>> go right to the old Codemgr data, specifically the nametable file, 
>> because many times the files you want may be in a src/<arch>/classes 
>> instead of src/share/classes.
>>
>> % grep -i SunMSCAPI.java 
>> <RE-repository>/5.0/latest/ws/j2se/Codemgr_wsdata/nametable
>>
>> % grep -i SunMSCAPI.java
>> <RE-repository>/6.0/latest/ws/j2se/Codemgr_wsdata/nametable
>> src/windows/classes/sun/security/mscapi/SunMSCAPI.java ada8dbe4 
>> a217f6b0 6c833bd3 d4ef32be
>>
>> That will usually give you a good starting point.
>>
>> Brad
>>
>>
>>
>>
>> Depending on rt.jar or not.
>>
>>> Chris, do you have any other ideas?
>>>
>>> --Sean