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

[Lance Andersen]

Hi Joe,

On Apr 15, 2015, at 6:11 PM, huizhe wang <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.
> 
>> 
>> 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.
> 
> Cheers,
> Joe
> 
>> 
>> Best
>> Lance
>> 
>> 
>> On Apr 15, 2015, at 3:23 PM, huizhe wang <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/
>>> 
>>> 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>
>> 
>> 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
>> 
>> 
>> 
> 



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