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

[Brad Wetmore]

This is a little late, but catching up on a bunch of back email.

Why did you add:

     +JAVAC_MAX_WARNINGS = false

in places like:

     +JAVAC_MAX_WARNINGS=false
     +JAVAC_LINT_OPTIONS=-Xlint:all,-deprecation
     +JAVAC_WARNINGS_FATAL=true

The default is false (NOP) already:

     jdk/make/common/shared/Defs-java.gmk

     ifeq ($(JAVAC_MAX_WARNINGS), true)
       JAVAC_LINT_OPTIONS += -Xlint:all
     endif

Just seems like additional overhead for the maintainer to understand, 
instead of just the two lines.

Brad




On 7/20/2011 10:28 AM, Alexandre Boulgakov wrote:
> "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