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

[Alexandre Boulgakov]

This is actually a complicated question. If a user sets 
JAVAC_MAX_WARNINGS=true globally, there are two things we can do:
We can listen to the user and exit with an error the moment one of these 
files comes along (in this case, we know there will be [deprecation] 
warnings), or we can ignore the user's request for the particular 
makefile by resetting JAVAC_MAX_WARNINGS=false.

I went with the latter simply because it allows for a full build with 
"make JAVAC_MAX_WARNINGS=true", which makes for easy bookkeeping.

-Sasha

On 8/17/2011 8:37 PM, Brad Wetmore wrote:
> 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