Skip to main content

[json-processing-spec issues] [JIRA] Updated: (JSON_PROCESSING_SPEC-1) Do not require that all content end up in String or char[]

  • From: "jitu (JIRA)" < >
  • To:
  • Subject: [json-processing-spec issues] [JIRA] Updated: (JSON_PROCESSING_SPEC-1) Do not require that all content end up in String or char[]
  • Date: Mon, 26 Nov 2012 22:22:12 +0000 (GMT+00:00)
  • Auto-submitted: auto-generated


     [ 
http://java.net/jira/browse/JSON_PROCESSING_SPEC-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jitu updated JSON_PROCESSING_SPEC-1:
------------------------------------


We are supporting creation of parser objects using byte streams like 
InputStream (rather than character streams like Reader). Some of the provider 
impl take advantage of working with byte streams for certain encodings and 
don't convert to characters internally.

At the application level, most users would be consuming them as String and 
the provider impls produce the String when it is asked. The pull parser is 
lazy in that sense. You are suggesting to add something like the following 
approaches:

1) A way to register/use factory
JsonParser {
    void setFactory(SomeFactory<T> f)

    // valid in VALUE_STRING, KEY_NAME states
    // go through SomeFactory to create T
    T getStringObject(byte[] buf, int offset, int len)
}

or 

2) one other alternative using already existing JsonString interface

JsonParser {
+    JsonString getString();
}

// May be existing JsonString is good enough(no need to add additional 
methods like getBytes etc)
JsonString {
   ..
+  byte[] getBytes();
+  Charset getCharset();
}

I think exposing bytes doesn't work well at the application level for various 
reasons. One of the reasons is escaping of characters and one cannot expose 
the internal buffer directly as it is. I think a custom provider and a 
subtype of JsonParser would be good for this case.

I will start a thread on the users list. Please follow there.

> Do not require that all content end up in String or char[]
> ----------------------------------------------------------
>
>                 Key: JSON_PROCESSING_SPEC-1
>                 URL: http://java.net/jira/browse/JSON_PROCESSING_SPEC-1
>             Project: json-processing-spec
>          Issue Type: New Feature
>            Reporter: headius
>             Fix For: 1.0-pr
>
>
> In my work on the JRuby project, it has become painfully obvious that many 
> Java APIs lose performance out of the gate because of the cost of decoding 
> all incoming bytes to char[] before processing them. This also makes it 
> difficult for JVM languages that use a different String representation to 
> use those APIs.
> I propose that the JSON processing API for Java should not impose String or 
> char[] on consumers unnecessarily. In the style of the "spymemcached" 
> library, it should be possible to register a factor that can create strings 
> of other forms directly from the incoming bytes, allowing for parsing and 
> processing JSON without ever decoding. This would make it possible (and may 
> be necessary) to match the performance of C-based libraries, and allows 
> consumers that do not want decoded characters/strings to use the raw bytes 
> directly.
> I will be monitoring this JSR once activity begins and discussions are made 
> public.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[json-processing-spec issues] [JIRA] Updated: (JSON_PROCESSING_SPEC-1) Do not require that all content end up in String or char[]

jitu (JIRA) 11/21/2012

<Possible follow-up(s)>

[json-processing-spec issues] [JIRA] Updated: (JSON_PROCESSING_SPEC-1) Do not require that all content end up in String or char[]

jitu (JIRA) 11/26/2012
 
 
Close
loading
Please Confirm
Close