About the makefile. In some makefiles, you added: JAVAC_MAX_WARNINGS = false JAVAC_LINT_OPTIONS = -Xlint:all,-deprecation JAVAC_WARNINGS_FATAL = true
But some others, the more strict rules are applied: JAVAC_MAX_WARNINGS = true JAVAC_WARNINGS_FATAL = true What's the underlying warnings that we cannot always use the following options: JAVAC_MAX_WARNINGS = true JAVAC_WARNINGS_FATAL = true Thanks, Xuelei (Andrew) On 7/20/2011 7:22 AM, Alexandre Boulgakov wrote: > 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
