RFR (JDK10/jaxp) 8181154: Fix lint warnings in JAXP repo: deprecation

[huizhe wang]

>> #11
>> com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java 
>>
>>
>> 1166     final public void setYear(BigInteger year) {
>>
>> nit: for consistency you should reorder the keywords to:
>>
>>          public final void
>>
>> same file:
>>
>>  - BigInteger.valueOf((long) 1) => BigInteger.ONE
>>  - new BigDecimal(TWELVE) => introduce a constant DECIMAL_TWELVE?
>>  - new BigDecimal(TWENTY_FOUR) => introduce a constant 
>> DECIMAL_TWENTY_FOUR?
>

Added the two constants.

>
>
>>
>> #12
>> com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java
>>
>>   81 @SuppressWarnings("deprecation")
>>   82 public abstract class AbstractSAXParser
>>   83     extends AbstractXMLDocumentParser
>>   84     implements PSVIProvider, // PSVI
>>   85               Parser, XMLReader // SAX1, SAX2
>>
>> A better solution would be to deprecate the methods that implement
>> deprecated methods - and avoid using deprecated APIs elsewhere...
>>
>> #13
>> com/sun/org/apache/xerces/internal/util/AttributesProxy.java
>>
>>   36 @SuppressWarnings("deprecation")
>>   37 public final class AttributesProxy
>>   38     implements AttributeList, Attributes2 {
>>
>> I wonder whether deprecating the methods implementing a deprecated
>> API would allow to remove @SuppressWarnings("deprecation") - maybe not
>> in this case since this class needs to implement a deprecated interface
>> and a non deprecated one (and therefore the class itself can't be
>> deprecated). Anyway it might be good to add the @Deprecated
>> annotations to deprecated methods.

We'll take a closer look at this through [1], for both #12 and #13, and 
#17 as well. AttributesProxy is used quite widely. We'll need to get 
into the details to see if we can remove the deprecated AttributeList.

Since there are import references that are deprecated, the suppress 
annotation has to be added at the class.

[1] https://bugs.openjdk.java.net/browse/JDK-8183972

>>
>> #14
>> com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java
>>
>> if _main use deprecated APIs then maybe _main should be @Deprecated
>> as well.

Done.
>>
>> #15
>> com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java
>>
>>  207     private static Integer m_synch_object = 1;
>>
>> This is not correct! Since this object is only use as a synchronization
>> lock then please change this to:
>>
>>          private static Object m_synch_object = new Object();

Ok, fixed now. But I don't think the sync is necessary, logged 
https://bugs.openjdk.java.net/browse/JDK-8184019 to take a look later 
and can also do some cleanups.

>>
>> #16
>> com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java
>>
>> Can this class be changed to stop using deprecated APIs instead?

It can probably be removed, will do so through 
https://bugs.openjdk.java.net/browse/JDK-8184020.

>>
>>
>> #17
>> javax/xml/parsers/SAXParser.java
>> org/xml/sax/helpers/ParserAdapter.java
>> org/xml/sax/helpers/XMLReaderAdapter.java
>>
>> Can these classes be changed to stop using deprecated APIs instead?
>> Or at least a cleanup issue logged for that effect?

Most likely we can't since these are public APIs. DocumentHandler for 
example, is still usable. We can probably add forRemoval  and then 
remove in the next release.

>>
>> That's all!

Thanks for all of that!

Best,
Joe

>>
>> best regards,
>>
>> -- daniel
>>
>> On 05/07/2017 19:48, Joe Wang wrote:
>>> Hi,
>>>
>>> This patch fixes deprecation warnings in the jaxp repo. I'm limiting 
>>> the changes to deprecation or the 102 classes. The cup-generated 
>>> classes, XPath*.java, could use some cleanup or even rewrite, but 
>>> that will be left in future works (JDK-8183580).
>>>
>>> Most of the changes are straight-forward, but I did have trouble 
>>> with the replacing clazz.newInstance() with 
>>> clazz.getDeclaredConstructor().newInstance() since in some cases I 
>>> got RuntimePermission problems. So for most of such cases, I've 
>>> replaced them with getConstructor() instead, thanks Alan for the 
>>> suggestion. For specific cases such as xsltc/compiler/Parser.java, 
>>> I'm using getDeclaredConstructor() because some of the classes 
>>> didn't have a public constructor.
>>>
>>> Again, please bear with me for the cup-generated classes that have 
>>> super long lines (e.g. XPathParser.java). Please read with Udiffs 
>>> instead of Sdiffs.
>>>
>>> Some of the boxing (e.g. Integer.valueOf()) in the BCEL classes may 
>>> not be necessary, but that's how they look in BCEL to which an 
>>> update is scheduled in JDK 10.
>>>
>>> All tests passed.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181154
>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181154/webrev/
>>>
>>> Thanks
>>> Joe
>>>
>>