Is there any way to write parsing logic using json?

Question

I have a map in java Map<String,Object> dataMap whose content looks like this -

{country=Australia, animal=Elephant, age=18}

Now while parsing the map the use of various conditional statements may be made like-

if(dataMap.get("country").contains("stra")

OR

if(dataMap.get("animal") || 100 ==0)

OR

Some other operation inside if

I want to create a config file that contains all the rules on how the data inside the Map should look like. In simple words, I want to define the conditions that value corresponding to keys country, animal, and age should follow, what operations should be performed on them, all in the config file, so that the if elses and extra code can be removed. The config file will be used for parsing the map.

Can someone tell me how such a config file can be written, and how can it be used inside Java? Sample examples and code references will be of help.

I am thinking of creating a json file for this purpose

Example -

Boolean b = true;
        List<String> conditions = new ArrayList<>();
        if(dataMap.get("animal").toString().contains("pha")){
            conditions.add("condition1 satisifed");
            if(((Integer.parseInt(dataMap.get("age").toString()) || 100) ==0)){
                conditions.add("condition2 satisifed");
                if(dataMap.get("country").equals("Australia")){
                    conditions.add("condition3 satisifed");
                }
                else{
                    b=false;
                }
            }
            else{
                b=false;    
            }
        }
        else{
            b=false;
        }

Now suppose I want to define the conditions in a config file for each map value like the operation ( equals, OR, contains) and the test values, instead of using if else's. Then the config file can be used for parsing the java map

Answer 1

Just to manage expectations: Doing this in JSON is a horrible, horrible idea.

To give you some idea of what you're trying to make:

Grammars like this are best visualized as a tree structure. The 'nodes' in this tree are:

• 'atomics' ( 100 is an atom, so is "animal" , so is dataMap ).
• 'operations' ( + is an operation, so is or / || ).
• potentially, 'actions', though you can encode those as operations.

Java works like this, so do almost all programming languages, and so does a relatively simple 'mathematical expression engine', such as something that can evaluate eg the string "(1 + 2) * 3 + 5 * 10" into 59 .

In java, dataMap.get("animal") || 100 ==0 dataMap.get("animal") || 100 ==0 is parsed into this tree:

           OR operation
         /             \
  INVOKE get[1]         equality
   /       \            /       \
dataMap   "animal"    INT(100)  INT(0)

where [1] is stored as INVOKEVIRTUAL java.util.Map :: get(Object) with as 'receiver' an IDENT node, which is an atomic, with value dataMap , and an args list node which contains 1 element, the string literal atomic "animal" , to be very precise.

Once you see this tree you see how the notion of precedence works - your engine will need to be capable of representing both (1 + 2) * 3 as well as 1 + (2 * 3) , so doing this without trees is not really possible unless you delve into bizarre syntaxis, where the lexical ordering matching processing ordering (if you want that, look at how reverse polish notation calculators work, or something like fortran - stack based language design. I don't think you'll like what you find there).

You're already making language design decisions here. Apparently, you think the language should adopt a 'truthy'/'falsy' concept, where dataMap.get("animal") which presumably returns an animal object, is to be considered as 'true' (as you're using it in a boolean operation) if, presumably, it isn't null or whatnot.

So, you're designing an entire programming language here. Why handicap yourself by enforcing that it is written in, of all things, JSON, which is epically unsuitable for the job? Go whole hog and write an entire language. It'll take 2 to 3 years, of course. Doing it in json isn't going to knock off more than a week off of that total, and make something that is so incredibly annoying to write, nobody would ever do it, buying you nothing.

The language will also naturally trend towards turing completeness. Once a language is turing complete, it becomes mathematically impossible to answer such questions as: "Is this code ever going to actually finish running or will it loop forever?" (see 'halting problem'), you have no idea how much memory or CPU power it takes, and other issues that then result in security needs. These are solvable problems (sandboxing, for example), but it's all very complicated.

The JVM is, what, 2000 personyears worth of experience and effort?

If you got 2000 years to write all this, by all means. The point is: There is no 'simple' way here. It's a woefully incomplete thing that never feels like you can actually do what you'd want to do (which is express arbitrary ideas in a manner that feels natural enough, can be parsed by your system, and when you read back still makes sense), or it's as complex as any language would be.

Why not just ... use a language? Let folks write not JSON but write full blown java, or js, or python, or ruby, or lua, or anything else that already exists, is open source, seems well designed?