[JSON_PROCESSING_SPEC-62] Allow builder object to be reused for DRY creation of Json Created: 26/Aug/14  Updated: 02/Sep/14

Status: Open
Project: json-processing-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: tirams Assignee: jitu
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: builder, json

 Description   

The current builder object is not reusable once build() is called the map is cleared
Want to be able to do something like:

//a base builder
JsonObjectBuilder builder = Json.createObjectBuilder().
                            add("name", "Peter").
                            add("required", false).
                            add("unique", true);
boolean keepSettings = true;
JsonObject baseObj = builder.build(keepSettings);
//note: if you add a new keepSettings parameter to build method to optionally 
// retain the current elements in the current map we can we extend the base 
// properties and add some more to the internal map, keepSettings for build 
// tells it to not clear out the map (as it does now) so we can go on using the 
// same builder to construct with.

//now we can tweak the current builder by adding a new property or overriding one
builder.add("addedField", "extra");

// and make a object from the current base and tweaked map of prop/vals.
JsonObject builtOnObj = builder.build();

Current implementation doesn't allow for reuse of a built builder you'd have to create another object and copy / paste everything set that was set above

— OR —

Another option to implement this need would be to be able to construct a new builder by passing in an existing one so that the map values can be reused for example:

//start with a base object
JsonObjectBuilder baseBuilder = Json.createObjectBuilder().
                            add("name", "Peter").
                            add("required", false).
                            add("unique", true);

//pass the base object into the constructor of a new builder object 
JsonObjectBuilder specialBuilder = Json.createObjectBuilder(*baseBuilder*).
                           add("addedMember", "addtionInfoOnBase").
                           add("moreStuff", "alsoThis");

// again pass on the starting elements for the map of this builder
JsonObjectBuilder extraSpecialBuilder = Json.createObjectBuilder(specialBuilder).
                           add("supa", "awesome");

//then we can create the objects , without having to copy/paste all the prior settings
// for each ones builder
JsonObject baseObject = baseBuilder.build();
JsonObject specialObject = specialBuilder.build();
JsonObject extraSpecialObject  = extraSpecialBuilder.build();



 Comments   
Comment by kchung [ 02/Sep/14 ]

Thanks for the suggestion. However, I must say it does not agree with the basic builder pattern used by the current API. Extending the life span of a builder may lead to memory leaks, and sharing implementations in two builders may cause confusion.

Currently, there are some efforts to add editing operations (including appending to an array) to immutable JSON structures after they are built. The idea is similar to your 2nd suggesting. It goes like this.

  JsonArray orig = Json.createJsonArrayBuilder(). ... .build();
  // create a new builder based on the original array
  JsonArrayBuilder ab = Json.createJsonArrayBuilder(orig);
  // do some editing and get a new array
  JsonArray new = ab.add(...).build();

Of course the operations on ab are not restricted to append, but can include insert, replace, and remove.

Of course this change can only happen in the next release of the API, so nothing has been committed.





[JSON_PROCESSING_SPEC-63] Add support for non-blocking IO when reading and writing JSON Created: 28/Sep/14  Updated: 07/Mar/17

Status: Open
Project: json-processing-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0-next

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: jitu
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Add support for non-blocking IO when reading and writing JSON.



 Comments   
Comment by salyh [ 19/Feb/15 ]

what about adding java.nio support to JSR 374?





[JSON_PROCESSING_SPEC-69] Add ultility to construct JsonStructure from raw JSON string Created: 04/Apr/15  Updated: 10/Mar/17

Status: Open
Project: json-processing-spec
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0-next

Type: New Feature Priority: Minor
Reporter: kchung Assignee: kchung
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, JsonArrayBuilder and JsonObjectBuilder can be used to create JSON object models from scratch. However, the process is cumbersome and verbose. There should be an easier way for doing this.

I am proposing something like the following:

JsonArray a = JsonUtil.getArray(
    "[{'abc': 'xyz', 'ss': 1234}, {'m\\'n': 'l\"m'}]");

Note that I'm using single quotes for JSON strings, otherwise I'll have lots of \" as required in Java. I am not proposing allowing single quotes for JSON string (which is not allowed in JSON) in general. This utility will need to convert ' to " before sending it to JsonReader.

Note also \ is used to allow ' or " inside the JSON string, but this is just some details that we should not worry for now.

Such utility will be very useful in writing JSON tests. But it should be useful to JSON users.



 Comments   
Comment by mitemitreski [ 04/Apr/15 ]

Single quotes are great idea but we need to make sure somehow that it is clear that this is intended as a helper only and not standards derailing.

Is JavaDoc enough for this ?

Comment by kchung [ 06/Apr/15 ]

We need to be clear that single quotes can only be used in this method. We'll have to do our best in the javadocs, since it the only thing we have for the spec.

Comment by maiden168 [ 07/Mar/17 ]

I am not sure that we need it.





[JSON_PROCESSING_SPEC-88] Why are all 1.1 methods default and implemented with UnsupportedOperationException? Created: 25/Feb/17  Updated: 10/Mar/17

Status: Reopened
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-pr
Fix Version/s: 1.0-next

Type: Bug Priority: Major
Reporter: Mark Struberg Assignee: maiden168
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently all new 1.1 methods are either default methods (for interfaces) or implemented in the API by throwing an UnsupportedOperationException (for abstract classes). Do we really need this?

If correctly implemented those lines will never get executed. I discovered this when working on the code coverage for Apache Johnzon.

If you have simple interface declarations (without default methods) or abstract methods then you immediately get a compile error. Now the compile passes but you need to find any unimplemented method by manually checking each method.

I understand that default-methods are great for interfaces which might get implemented by users (e.g. a ServletFilter etc). But does it make sense for methods which MUST be implemented by a vendor?

I'd suggest to just remove all the default behaviour - which is just a throw new UnsupportedOperationException anyway.



 Comments   
Comment by maiden168 [ 06/Mar/17 ]

Agree.

Comment by maiden168 [ 07/Mar/17 ]

commit 8832deb4998cf11b79f09556b3002668a95295d4

Comment by Mark Struberg [ 08/Mar/17 ]

committed but not pushed maybe? Cannot find those changes - txs!

Comment by maiden168 [ 08/Mar/17 ]

https://github.com/json-p/api-ri/commit/8832deb4998cf11b79f09556b3002668a95295d4

Comment by Mark Struberg [ 08/Mar/17 ]

Well, now I'm slightly confused

I originally used the github repo but then I figured that it contained outdated content back then.
So I switched to git://java.net/jsonp~git which is also listed on the spec page on java.net.
And Lukas seems to push to this java.net repo as well (just pulled his changes from yesterday).

Which is the 'cannonical' downstream repo users are supposed to use?

txs and LieGrue,
strub

Comment by maiden168 [ 08/Mar/17 ]

Ooops... Thanks for pointing on it. Two way sync suppose to work, but it doesn't. I resubmitted all 3 my patches to java.net and you should see them now.

Comment by Lukas Jungmann [ 08/Mar/17 ]

I don't think removing 'default' from methods in interfaces was good idea - with 'default' API remains backwards compatible, without 'default' there is no backwards compatibility ... and I'm afraid this goes against some EE rules...

Comment by Mark Struberg [ 08/Mar/17 ]

@Lukas the backward compat in EE is very important from a user perspective. And we still have this. Every program which got created with JSONP 1.0 will also work with JSONP 1.1, regardless whether the new methods have default impls or not.

Default methods are really great if you have an interface which is intended to get implemented by a user. E.g. a ServletFilter or when they need to create some wrapper etc. But if the only implementation is the JSONP implementation itself, then it is perfectly backward compatible for the user afaict.

Comment by Lukas Jungmann [ 08/Mar/17 ]

@Mark: programs perhaps but what about older jsonp implementations? Isn't what you are saying against what is written ie here: https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces ?

Comment by Mark Struberg [ 08/Mar/17 ]

I don't think so. In CDI we also introduced new interfaces. And in Servlet and JSF as well. Since decades. A JSONP implementation which uses this new interface is expected to implement all the new methods. Otherwise it would also never be able to pass the TCK, isn't?

The paragraph you mentioned imo really only targets the user facing APIs.

Comment by Lukas Jungmann [ 08/Mar/17 ]

All I'm trying to point out is that method addition to existing interface breaks backwards compatibility and using 'default' methods can "fix this". Adding new interface is different story, extending existing interface to add new stuff there is another one as well...

...and we saw breakages while working on TCK for jsonp...

Comment by maiden168 [ 08/Mar/17 ]

Defaults on interfaces just hide the backwards compatibility problems by moving them from compile time to run time.

Comment by maiden168 [ 09/Mar/17 ]

I have to reopen this issue and revert the changes. We need these defaults for backwards compatibility. Backwards compatibility is a requirement for Java EE components. We cannot break it on minor update.

Comment by rmannibucau [ 09/Mar/17 ]

@maiden168 did you check it was breaking the bytecode? I think it only breaks the implementation and the default impl is broken for any usage (by design) anyway so I'm not sure it is backwd incompatible even if the method have one default flag in the bytecode, this being unusable it can't break anything or anyone.

Comment by maiden168 [ 10/Mar/17 ]

Without defaults there are huge problems with TCK tests. This is the reason why I reverted this fix. As I was writing above, I agree that defaults should not be there. I think it will be fair if we will defaults in this version and remove them in the next major version update (2.0). So I'll reopen this issue and target it to the next version.

Comment by Mark Struberg [ 10/Mar/17 ]

I am pretty sure it would work, but not a biggie. The API is good enough as is. Would just love to learn what did break the backward compatibility?





[JSON_PROCESSING_SPEC-22] Injection support for JsonParserFactory/JsonGeneratorFactory Created: 29/Oct/12  Updated: 07/Jan/13

Status: Open
Project: json-processing-spec
Component/s: None
Affects Version/s: 1.0-next
Fix Version/s: 1.0-next

Type: New Feature Priority: Major
Reporter: jitu Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

http://java.net/projects/json-processing-spec/lists/users/archive/2012-10/message/112

This can be considered for later releases






[JSON_PROCESSING_SPEC-9] Adding methods to JsonParser to get objects Created: 14/Jun/12  Updated: 20/Sep/14

Status: Open
Project: json-processing-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: jitu Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Something like the following, that gives the objects from the parser

/**

  • getJsonValue(JsonObject.class) is valid in START_OBJECT state,
  • moves cursor to END_OBJECT
    *
  • getJsonValue(JsonArray.class) is valid in START_ARRAY state
  • moves cursor to END_ARRAY
    *
  • getJsonValue(JsonString.class) is valid in VALUE_STRING state
    *
  • getJsonValue(JsonNumber.class) is valid in VALUE_NUMBER state
    */
    public <T extends JsonValue> T getJsonValue(Class<T> clazz) { return null; }


 Comments   
Comment by kchung [ 20/Sep/14 ]

This issue, together with issue 29, would be useful for processing big JSON data. It is important to be able to load the JSON values are of interest and skip those that are not.

However, it is most likely that the criteria for getting or skipping JSON values lies within the values themselves. For instance, say we have an array of objects representing the contacts, and we are only interested in getting the contacts who are females that live in New York city. We'll need to process some parts of the object to determine if it should be loaded or skipped, and we cannot make that decision at the beginning of an object. How to factor that into the API is the challenge.





[JSON_PROCESSING_SPEC-31] Incremental processing of large strings Created: 03/Dec/12  Updated: 03/Dec/12

Status: Open
Project: json-processing-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jitu Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Provide way to parse/process large string values incrementally in parser






[JSON_PROCESSING_SPEC-32] matchName(String) methods on JsonParser Created: 03/Dec/12  Updated: 03/Dec/12

Status: Open
Project: json-processing-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jitu Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JsonParser#matchName(String) kind of methods are required for performance.
http://java.net/projects/json-processing-spec/lists/users/archive/2012-11/message/40






Generated at Thu Mar 23 11:12:43 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.