Re: [Bug 198] New: return java.lang.CharSequence in getTextCharacters()

--------------050703040208070709030803
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[email protected] wrote:

>http://www.extreme.indiana.edu/bugzilla/show_bug.cgi?id=198
>
>           Summary: return java.lang.CharSequence in getTextCharacters()
>           Product: XmlPull.org
>           Version: 1.1.2
>          Platform: All
>        OS/Version: All
>            Status: NEW
>          Severity: enhancement
>          Priority: P5
>         Component: Design
>        AssignedTo: [email protected]
>        ReportedBy: [email protected]
>
>
>I would like to have: java.lang.CharSequence getTextCharacters() in XmlPullParser
>This is easier to use than char[] getTextCharacters(int[]).
>
>See also: http://developer.java.sun.com/developer/bugParade/bugs/4838318.html
>The Java SDK will in future allow much more CharSequence type parameters where
>it currently requires String type parameters.
>  
>
sounds interesting and worthwhile to pursuit.

>As far as I see it, getTextCharacters(int[]) was mainly added for performance reasons, since getText() is also available.
>  
>
exactly.

>And as already stated in the docu for getTextCharacters(int[]), that the content
>is only available (valid) until any next() call, the same should be true for
>this new method. So that the implementation only needs to store/maintain one
>instance of CharSequence. The implementation then only changes the internal char[] buffer, the start offset and the length before it returns the same CharSequence again.
>  
>
exactly!

>If the general idea of the above would be accepted,
>
i think it is *very* good idea,

> then I even would like to 
>continue with adding two new public interfaces to the API like illustrated here:
>
>interface XmlText extends CharSequence {
>    // implement all methods from CharSequence
>    
>    /** read content as integer value. 
>     * This would allow the implementation to supply primitive value types
>     * without the need of intermediate object creations.
>     */
>    int parseInt() throws java.text.ParseException
>  
>
>    /** read content as long value */
>    long parseLong() throws java.text.ParseException;
>
>    // same for all other primitive Java types
>
>  
>
you may not know but i attempted to do exactly this, see:
http://www.xmlpull.org/v1/addons/java/wrapper/src/org/xmlpull/v1/wrapper/XmlPullParserWrapper.java
i just never really followed up on that (and had no binary XML ...)

>    /** build same hash code as java.lang.String does, so that
>     * this instance can be used in java.lang.Map for lookups
>     */
>    int hashCode();
>  
>
you mean this for text content and not parser instance?

this may be tricky if parser implements this interface but i think could 
be specified in documentation for case when parser.getEventType() == TEXT

>    /** compares this instance with any other CharSequene character
>     * by character
>     */
>    boolean equals( Object o );
>  
>
ok

>    /** trim whites at the left and right side. 
>     * NOTE: this would again return the same instance
>     */
>    XmlText trim();
>  
>

>    String toString();
>  
>

>}
>
>Another interface XmlAttibute is implemented just like the class above.
>The XmlAttribute interface may additionally supply methods with information
>from the validator like isNumberType().
>
>Finally on XmlPullParser the following methods need to be added:
>
>    XmlText      getXmlText();
>    XmlAttribute getXmlAttribute(int index);
>  
>
i would add this

interface XmlAttributeAccessor {

	XmlAttribute getXmlAttribute(int index);
}


why not make parser just implement (optionally!) XmlText or interface 
XmlAttributeAccessor?

this will require no changes to XmlPull API and more important will not 
make XmlPullParser bigger and/or impossible to implement on J2ME (think 
kXML2 :))

>Comment:
>Supplying XmlText and XmlAttribute as part of the API would allow the
>JIT-compiler to inline the implementation of CharSequence.charAt(int)
>from the XmlText and XmlAttribute implementation where ever it is used,
>as long as there is only one implementation of XmlText and XmlAttribute
>for the current class loader.
>  
>
i think this will be also true in case when parser implements those 
interfaces?

>While just returning a CharSequence instance (which is implemented in several
>classes, like in String) does not allow the JIT-compiler to optimize (inline).
>And charAt(int) will be the most frequently used method here.
>  
>
will this inlining work if parser implements those interfaces?

this sounds very reasonable and i see no reason why not add 
XmlText/XmlAttribute to XmlPull addons (this addon obviously would only 
work in JDK 1.4 but i think it is fine when we are concerned about best 
performance for J2SE).

if it looks OK to you please send patch for XmlPull (to i just add those 
interfaces to addons as they are now) and if possible look on XPP3 
source code <http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/> and if 
you can send me patch with the implementation of it (as class that 
extends MXParser* so still a version of XPP3 for J2ME/JDK 1.2 could be 
compiled) i will be more than happy to make it part of XPP3.

thanks,

alek

-- 
The best way to predict the future is to invent it - Alan Kay


--------------050703040208070709030803
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">


<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap=""><a class="moz-txt-link-freetext" href="http://www.extreme.indiana.edu/bugzilla/show_bug.cgi?id=198">http://www.extreme.indiana.edu/bugzilla/show_bug.cgi?id=198</a>

           Summary: return java.lang.CharSequence in getTextCharacters()
           Product: XmlPull.org
           Version: 1.1.2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Design
        AssignedTo: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
        ReportedBy: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>


I would like to have: java.lang.CharSequence getTextCharacters() in XmlPullParser
This is easier to use than char[] getTextCharacters(int[]).

See also: <a class="moz-txt-link-freetext" href="http://developer.java.sun.com/developer/bugParade/bugs/4838318.html">http://developer.java.sun.com/developer/bugParade/bugs/4838318.html</a>
The Java SDK will in future allow much more CharSequence type parameters where
it currently requires String type parameters.
  </pre>
</blockquote>
sounds interesting and worthwhile to pursuit.<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">
As far as I see it, getTextCharacters(int[]) was mainly added for performance reasons, since getText() is also available.
  </pre>
</blockquote>
exactly.<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">And as already stated in the docu for getTextCharacters(int[]), that the content
is only available (valid) until any next() call, the same should be true for
this new method. So that the implementation only needs to store/maintain one
instance of CharSequence. The implementation then only changes the internal char[] buffer, the start offset and the length before it returns the same CharSequence again.
  </pre>
</blockquote>
exactly!<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">
If the general idea of the above would be accepted,</pre>
</blockquote>
i think it is <b>very</b> good idea,<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap=""> then I even would like to 
continue with adding two new public interfaces to the API like illustrated here:

interface XmlText extends CharSequence {
    // implement all methods from CharSequence
    
    /** read content as integer value. 
     * This would allow the implementation to supply primitive value types
     * without the need of intermediate object creations.
     */
    int parseInt() throws java.text.ParseException
  </pre>
</blockquote>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">
    /** read content as long value */
    long parseLong() throws java.text.ParseException;

    // same for all other primitive Java types

  </pre>
</blockquote>
you may not know but i attempted to do exactly this, see:<br>
<a class="moz-txt-link-freetext" href="http://www.xmlpull.org/v1/addons/java/wrapper/src/org/xmlpull/v1/wrapper/XmlPullParserWrapper.java">http://www.xmlpull.org/v1/addons/java/wrapper/src/org/xmlpull/v1/wrapper/XmlPullParserWrapper.java</a><br>
i just never really followed up on that (and had no binary XML ...)<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">    /** build same hash code as java.lang.String does, so that
     * this instance can be used in java.lang.Map for lookups
     */
    int hashCode();
  </pre>
</blockquote>
you mean this for text content and not parser instance? <br>
<br>
this may be tricky if parser implements this interface but i think
could be specified in documentation for case when parser.getEventType()
== TEXT<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">
    /** compares this instance with any other CharSequene character
     * by character
     */
    boolean equals( Object o );
  </pre>
</blockquote>
ok<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">
    /** trim whites at the left and right side. 
     * NOTE: this would again return the same instance
     */
    XmlText trim();
  </pre>
</blockquote>
<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">
    String toString();
  </pre>
</blockquote>
<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">}

Another interface XmlAttibute is implemented just like the class above.
The XmlAttribute interface may additionally supply methods with information
from the validator like isNumberType().

Finally on XmlPullParser the following methods need to be added:

    XmlText      getXmlText();
    XmlAttribute getXmlAttribute(int index);
  </pre>
</blockquote>
i would add this <br>
<br>
interface XmlAttributeAccessor { <br>
<pre wrap="">	XmlAttribute getXmlAttribute(int index);
}</pre>
<br>
why not make parser just implement (optionally!) XmlText or interface
XmlAttributeAccessor?<br>
<br>
this will require no changes to XmlPull API and more important will not
make XmlPullParser bigger and/or impossible to implement on J2ME (think
kXML2 :))<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">
Comment:
Supplying XmlText and XmlAttribute as part of the API would allow the
JIT-compiler to inline the implementation of CharSequence.charAt(int)
from the XmlText and XmlAttribute implementation where ever it is used,
as long as there is only one implementation of XmlText and XmlAttribute
for the current class loader.
  </pre>
</blockquote>
i think this will be also true in case when parser implements those
interfaces?<br>
<blockquote
 cite="[email protected]"
 type="cite">
  <pre wrap="">While just returning a CharSequence instance (which is implemented in several
classes, like in String) does not allow the JIT-compiler to optimize (inline).
And charAt(int) will be the most frequently used method here.
  </pre>
</blockquote>
will this inlining work if parser implements those interfaces?<br>
<br>
this sounds very reasonable and i see no reason why not add
XmlText/XmlAttribute to XmlPull addons (this addon obviously would only
work in JDK 1.4 but i think it is fine when we are concerned about best
performance for J2SE).<br>
<br>
if it looks OK to you please send patch for XmlPull (to i just add
those interfaces to addons as they are now) and if possible look on <a
 href="http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/">XPP3 source
code</a> and if you can send me patch with the implementation of it (as
class that extends MXParser* so still a version of XPP3 for J2ME/JDK
1.2 could be compiled) i will be more than happy to make it part of
XPP3.<br>
<br>
thanks,<br>
<br>
alek<br>
<pre class="moz-signature" cols="103">-- 
The best way to predict the future is to invent it - Alan Kay
</pre>






</body>
</html>

--------------050703040208070709030803--