'path' feature

[wimjongman]

I have added a method to get the last entry of a path. Let me know if this is useful and I will create a PR.

	/**
	 * Searches the given path and returns it.
	 * 
	 * @param entries, the list of entries to traverse
	 * @return Json the Json at the give path or null
	 */
	public Json path(String... entries) {
		if (entries.length == 1) {
			return at(entries[0]);
		}
		if (has(entries[0])) {
			return at(entries[0]).path(Arrays.copyOfRange(entries, 1, entries.length));
		} else {
			return null;
		}
	}

Usage

Json name = json.path("info", "title", "contact", "name");

{
    "openapi": "3.0.1",
    "info": {
        "title": "OMS - Database REST API",
        "description": "This is the TD/OMS Database REST API.",
        "contact": {
            "name": "Remain software",
            "url": "https://remainsoftware.com",
            "email": "[email protected]"

Advantage

With this feature we can traverse down a path without having to worry about NPE's

[bolerio]

I agree something like this is needed, but I'd prefer to have following the JSON Path standard (see https://en.wikipedia.org/wiki/JSONPath). There is an implementation of that in the mjson-ext project (see https://github.com/bolerio/mjson-ext/tree/master/jsonpath), but it has a 3d party dependency which is a bit counter to the mjson minimalistic philosophy.

If we have a JSON Path implementation with no extra dependencies, we could somehow include in the mjson API, either within the at method so one can write things like:

obj.at("$.prop1.prop2[4].prop3")

or as a separate path method like you suggest (to avoid the ambiguity of property names that look like path expressions).

[wimjongman]

Yes, of course. I did not realize this. Here is the RFC [1]. I will take a look at it.

[1] https://datatracker.ietf.org/doc/rfc9535/

but it has a 3d party dependency which is a bit counter to the mjson minimalistic philosophy.

Yes, that's why I picked your implementation. One class and no dependencies. Thank you for writing it.