Lean JSON Library for Java, with a compact, elegant API.

^^ Reasoning for single exception: it makes sense to have one specific exception to catch when invoking tiny specialized library. ^^

Exception handling changes:

• added MJsonException
• throw MJsonException (also unchecked exception) instead of RuntimeException, when mJson encounters error condition it cannot handle and that is not illegal argument / unsupported operation exception.
• replaced dangerously empty catch (Throwable t) {} clause with normal handling of IOException
• throw MJsonException instead of IllegalArgumentException
• throw MJsonException instead of UnsupportedOperationException

Additionally:

• addressed build warnings about pom.xml deprecated ${groupId}+ ${artifactId} references which were replaced with current ${project.etc} syntax (Maven 3.2.2 warning)

Not sure if a great idea, but an 'overlay' or 'overwrite' method would behave sort of like 'with', except recursively it will perform a merge (actually maybe 'merge' is a better name for such a method then): if A is overlaid over B, all properties in A that are not in B will be copied to B and also all properties in A that are also in B will replace B's values. But because this is done recursively, we may have nested properties deep in B's structure be preserved instead of just disappearing.

So this is essentially a recursive "with". While "with" overwrite blindly, a recursive with does a deep merging.

I've only seen the need for this popup very rarely though.

I have several cases where I have the json element in a hierarchy (eg after an event has occurred) but I need to know its key in the parent json. Basically I need to recurse the path back to the top level. This is remarkably hard to do efficiently! Ive considered several possibilities:

1. Use google guava BiMap instead of HashMap in the ObjectJson. Then use .inverse() to find the key. Would work but BiMap must have unique values (a Set), and I suspect that will cause trouble
2. store the key in the child object when the child is created. Also works but needs care or it causes bugs when serialising or when making misc changes like moving parent.
3. store a ref to the parent key in the child somehow - much like 2)
4. iterate the keys in the parent looking for an equals() match on the associated value - nice, but is it efficient in a big parent? What about two separate keys with the same value? - the BiMap problem.

Any ideas?

Persistable json objects usually carry some kind of technical identifier with them. Is there some way to compare two json objects without technical properties?

For example: {"id":"1","type":"car","model":"Ferrari","color":"red"} {"id":"2","type":"car","model":"Ferrari","color":"red"}

Both objects represent the same car (functional equality) but they are not equal/identical because of their different IDs. If there would be a way to exclude/ignore certain properties during the equals operation would be a great feature. Maybe the API could look something like car1.functionalEquals(car2,"id"); whereas the last argument is a variable parameter list. Or maybe it would be better to mark technical properties within the interal data structure of mjson itself for beeing able to handle nested/more complex objects. This would require some API for marking properties as beeing "excluded" from the functional equals comparison.

The following code produces a NullPointerException:

Json json = Json.object();
String value = json.at("notAvailable").asString();

What is the advantage of json.at("...") returning null instead of a json object? I would have expected the java null value from the asString() method.

The method Json.read() for example will never return the actual Java null. Could this also be done for the method json.at("...")?

I integrated mjson inside a JSF web application and it requires the Json instances to be serializable: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: mjson.Json$ObjectJson

The issue may be solved by adding "implements Serializable" to the objects ArrayJson, BooleanJson, NullJson, NumberJson, ObjectJson and StringJson. What do you think?

As stated in the javadoc of the interface Json.Factory the method make(Object) allows me to plug-in my own mapping of java.util.Date to Json. But how to achive this without reimplementing the whole method?

Futhermore I would like to know if it is possible to globally map the other way around from a Json string to java.util.Date. I would have expected something like Json.asDate() or Json.asType(Class type) for the conversion to Java instances.

Seems pretty advance and nice:

https://code.google.com/p/json-path/

Since Spring framework is adopting it, probably it's going to gain industry acceptance, and there's nothing else like it.

1. I have my schema file in src/main/resources
2. In schema i have construction like "$ref": "#/definitions/deleteSchema"
3. I open schema ResourceLoader resourceLoader ; .... Json.Schema schema = Json.schema(resourceLoader.getResource("classpath:" + jsonSchemaFile).getURI());
4. I have NPE

Caused by: java.lang.RuntimeException: java.lang.NullPointerException
        at mjson.Json$DefaultSchema.<init>(Json.java:1009) ~[mjson-1.3.jar:na]
        at mjson.Json.schema(Json.java:1035) ~[mjson-1.3.jar:na]
        ... 48 common frames omitted
Caused by: java.lang.NullPointerException: null
        at mjson.Json.resolveRef(Json.java:462) ~[mjson-1.3.jar:na]
        at mjson.Json.expandReferences(Json.java:508) ~[mjson-1.3.jar:na]
        at mjson.Json.expandReferences(Json.java:529) ~[mjson-1.3.jar:na]
        at mjson.Json.expandReferences(Json.java:519) ~[mjson-1.3.jar:na]
        at mjson.Json$DefaultSchema.<init>(Json.java:1006) ~[mjson-1.3.jar:na]

Hi,

I'm trying to convert JSON from/to String as follows:

    String myJSONString = "{\"user\":\"myuser\",\"pw\":\"mypass\",\"log\":true}";
    System.out.println(myJSONString);
    Json json = Json.read(myJSONString);
    System.out.println(json.toString());

That is, I expect that myJSONString.equals(json.toString()) returns true, but it does not.

The values that System.out.println() show are:

{"user":"myuser","pw":"mypass","log":true} {"log":true,"pw":"mypass","user":"myuser"}

For myJSONString and json.toString(), respectively. Therefore, json.toString() inverts the string. Is this a bug? I want to load/store the same JSON string from/to disk several times but due to this behaviour I'm not able to do that.

PS: The problem is that next time I load the MyJSONString from this it cannot be validated using the JSON schema.

Junit is currently deployed to Maven Central with scope compile, which isn't necessary and requires end users to exclude it as a transitive dependency. It's also licensed under EPL, which could confuse people who see that mjson is licensed under Apache 2.

The current release of MJSON (1.4.1) includes junit as a dependency in it's pom. This is surprising since it promises to have no dependencies. I see that it's actually been fixed in master but no new version has been released since 2017.

Hey , is it possible to pretty print Json as a string ? For now I found only 2 toString methods(default one and one with maxCharacters) and non of them is able to pretty print Json object

Updated HashMap usages to use LinkedHashMap to preserve order of key insertion in Objects.

AFAIK this is not part of the spec yet makes the behavior consistent with other JSON parsers: 1 2 3 4

		public Json delAt(String property) 
		{
			Json el = object.remove(property);
			removeParent(el, this);
			return this;
		}

when there is no value for the property being deleted, the removeParent call leads to an NPE

The current default implementation of Json.toString will output an ellipsis (...) when the traversal is about to output the same object (same Java reference). This is to avoid circularity issues and because the aim of toString was for display purposes. We might break backward compatibility (and maybe this can be made optional), but this decision is a bit counter-intuitive. One expected toString to at least produce a valid JSON string. Because we set out to support graphs in this API and not just trees, we have to handle circular structures. But we can do this in a separate method, e.g. displayString or some such. Alternatively, we could offer a hook to be provided by the user to deal with serializing the same object, but in a different context.