Hi Sasha, The updates look fine to me.
--Sean On 7/18/11 9: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
