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

Alexandre Boulgakov alexandre.boulgakov at oracle.com
Wed Jul 20 10:28:17 PDT 2011


"JAVAC_MAX_WARNINGS = true" is the same as "JAVAC_LINT_OPTIONS = 
-Xlint:all", so the only warnings being ignored are deprecation warnings.

-Sasha

On 7/19/2011 8:10 PM, Xuelei Fan wrote:
> 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



More information about the security-dev mailing list