Class Helper$CheckKeys

  • public class Helper$CheckKeys
extends java.lang.Object
    The contents of the JsonAST-Package are, in general, provided strictly for informational & reference purposes. If further research & investigation of Google's CDP API are necessary, one may deserialize the Browser-API and / or the JavaScript-API from the Java-HTML '.jar' file, and review the AST's programmatically. The AST Node Java-Classes have been meticulously documented exactly for that purpose.

    Generally, though, there really is very little need to review, understand, or programmatically analyze the CDP API. And the contents of this entire package, again, are largely here for reference only.


    This particular class falls under the Package "Sub-Category" of "Constructor Helpers". All that really means is that the methods inside this class are all invoked, solely, by the AST-Node's class constructors to build an instance of the node.

    The methods in this class are nothing more than "Json Data Extraction" utilities that are (mostly, sort-of) grouped by their use - primarily for the common purposes of "code-reuse", readability, and efficiency. These constructor helpers isolate a series of semi-complicated JSON extraction methods which read Google's CDP API from their respective '.json' definition files, and convert them into an in-memory Abstract Syntax Tree.

    Nothing too complicated is going on here. It, sort of, just helps to separate these procedures out into their own source files so, thereby hopefully making this whole thing easier to read & understand.
    There are two implementation methods of the "Check Keys" feature in this class. The first "Check Key Method" may be used with any of the six Entity subclasses: PPR, TCE, TypeNode, CommandNode & EventNode.

    The second variant of "Check Keys" may be used on JsonObjects which have been retrieved from the (top level) "domains" array, and are to be extracted and parsed into instance of class Domain.

    For both of these methods, all that is occuring is an "assertion statement", nothing more, nor anything less. The assertion being promulgated is to make sure that only Json Properties which match exactly with a well-known and well-documented sub-list of expected property names occur. The intention is two fold.

    The first goal is to make sure to catch any unexpected changes that might ever occur in future versions of the CDP JSON spec files. The second is to help understand, exactly, (nail down) what is and is not guaranteed to be true about a 40K line long '.json' File. The tests in these two methods help make obvious / elucidate what is absolutely true when parsing these files!

    That's really all this is.



    Stateless Class:
    This class neither contains any program-state, nor can it be instantiated. The @StaticFunctional Annotation may also be called 'The Spaghetti Report'. Static-Functional classes are, essentially, C-Styled Files, without any constructors or non-static member fields. It is a concept very similar to the Java-Bean's @Stateless Annotation.

    • 1 Constructor(s), 1 declared private, zero-argument constructor
    • 2 Method(s), 2 declared static
    • 2 Field(s), 2 declared static, 2 declared final


    • Method Summary

      • Methods inherited from class java.lang.Object

        clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait