RFR (JAXP): 8042244 : Re-examine the supportedness of non-SE org.w3c.dom.** API

[huizhe wang]

On 4/15/2015 3:22 PM, Lance Andersen wrote:
> Hi Joe,
>
> On Apr 15, 2015, at 6:11 PM, huizhe wang <huizhe.wang at oracle.com 
> <mailto:huizhe.wang at oracle.com>> wrote:
>
>> Hi Alan, Lance,
>>
>> On 4/15/2015 2:26 PM, Lance Andersen wrote:
>>> Looks OK other than what Alan suggested which I would think we could 
>>> add the SUID given it is in our code base.
>>
>> You guessed it right. It was the upstream source that was on my mind 
>> when I decided not to add a SUID. Yes, it's in our code base. But 
>> what if they later add a SUID?  Ivan submitted a patch to this alias 
>> in which he tried to fix the serial warnings for the jaxp/bcel 
>> classes by adding SUIDs. However, the upstream BCEL had been updated 
>> with different SUIDs. So I thought it's safer to suppress the 
>> warning. I saw previous patches where serial warnings were suppressed 
>> instead of fixed with SUIDs.
>
> They are adding SUIDs but not using the default SUID?  That could 
> cause some problems.  I just went through an exercise with 
> JMSException where the class was tweaked but did not have a SUID so 
> the default value changed and caused failures in WLS resulting in a 
> JMS MR to fix :-(
>
> Just something to watch over if nothing can be done in the short term.

I added the SUID.

They are using the default. However, as I mentioned, they've upgraded to 
a new version. We can have more discussion on the topic of serialization 
compatibility offline.

>>
>>>
>>> Please check DOMXPathTest as it looks like you were bit by netbeans 
>>> formatting for the comment for test().  Same is true for some of the 
>>> other classes where in some cases there is an empty line before the 
>>> start of a method comment and others there is not 
>>> (HTMLTableCellElement.java is an example).  If you have time, it 
>>> would be nice to be consistent, but I have seen netbeans to strange 
>>> things when you format similar to what you are seeing (though I am 
>>> not sure you are using netbeans)
>>
>> I re-generated the webrev for DOMXPathTest.  As for the DOM 
>> css/html/stylesheets/xpath classes, I wish to ask forgiveness :-)  
>> This is a quick move, short of remove. Theoretically, they could have 
>> been removed. So I thought it's probably not worth spending the time 
>> taking care of the formatting issues (old tags for that matter).
>
> This was not a big deal, I just wanted to point it out and let you decide.

Ok, thanks!

Joe

>>
>> Cheers,
>> Joe
>>
>>>
>>> Best
>>> Lance
>>>
>>>
>>> On Apr 15, 2015, at 3:23 PM, huizhe wang <huizhe.wang at oracle.com 
>>> <mailto:huizhe.wang at oracle.com>> wrote:
>>>
>>>> Please review the change related to the non-SE org.w3c.dom.** API: 
>>>> org.w3c.dom.css, org.w3c.dom.html, org.w3c.dom.stylesheets, 
>>>> org.w3c.dom.xpath.
>>>>
>>>> They came into Java SE along with the DOM API, but were not part of 
>>>> the Java SE and JAXP specification. For css, html and stylesheets, 
>>>> there is no implementation in the Java SE,  while for xpath, an 
>>>> experimental one. These types should not be exported through the 
>>>> java.xml module. Considering that there are references to them, 
>>>> we're moving them into a JDK module called jdk.xml.dom. The 
>>>> experimental DOM 3 XPath thus is no longer available through the 
>>>> DOM API (DOMImplementation).
>>>>
>>>> Please review:
>>>> JAXP change:
>>>> http://cr.openjdk.java.net/~joehw/jdk9/8042244/webrev/ 
>>>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8042244/webrev/>
>>>>
>>>> module.xml:
>>>> http://cr.openjdk.java.net/~joehw/jdk9/8042244/jdk/webrev/
>>>>
>>>> JBS: 8042244 : Re-examine the supportedness of non-SE 
>>>> org.w3c.dom.** API <https://bugs.openjdk.java.net/browse/JDK-8042244>
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>>
>>>>
>>>
>>> <Mail Attachment.gif> 
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>