Skip to main content

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

  • From: "headius (JIRA)" < >
  • To:
  • Subject: [json-processing-spec issues] [JIRA] Commented: (JSON_PROCESSING_SPEC-1) Do not require that all content end up in String or char[]
  • Date: Mon, 26 Nov 2012 20:33: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:comment-tabpanel&focusedCommentId=350704#action_350704
 ] 

headius commented on JSON_PROCESSING_SPEC-1:
--------------------------------------------

I hope you can elaborate on that a bit. Supporting byte streams but still 
transcoding everything to UTF-16 char strings would defeat all the gains of 
being able to work directly with bytes.

The factory suggestion still seems like the cleanest way. In an ideal world, 
we'd be able to register a factory that receives the incoming byte[] + 
offsets and we can then construct whatever string-like structure we want from 
that. It would avoid unnecessary transcoding for languages and libraries that 
can work directly with bytes, and it would eliminate lots of transient 
objects and overhead from going to String eagerly.

I'd like to understand better what you mean by "supporting byte streams".

> 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] Commented: (JSON_PROCESSING_SPEC-1) Do not require that all content end up in String or char[]

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