We present an overview of JTL (the Java Tools Language, pronounced "Gee-tel"), a novel language for querying JAVA [8] programs. JTL was designed to serve the development of source code software tools for JAVA, and as a small language to aid programming language extensions to JAVA. Applications include definition of pointcuts for aspect-oriented programming, fixing type constraints for generic programming, specification of encapsulation policies, definition of micro-patterns, etc. We argue that the JTL expression of each of these is systematic, concise, intuitive and general.JTL relies on a simply-typed relational database for program representation, rather than an abstract syntax tree. The underlying semantics of the language is restricted to queries formulated in First Order Predicate Logic augmented with transitive closure ( FOPL * ).Special effort was taken to ensure terse, yet readable expression of logical conditions. The JTL pattern public abstract class, for example, matches all abstract classes which are publicly accessible, while class { public clone(); } matches all classes in which method clone is public. To this end, JTL relies on a DATALOG-like syntax and semantics, enriched with quantifiers and pattern matching which all but entirely eliminate the need for recursive calls.JTL's query analyzer gives special attention to the fragility of the "closed world assumption" in examining JAVA software, and determines whether a query relies on such an assumption.The performance of the JTL interpreter is comparable to that of JQuery after it generated its database cache, and at least an order of magnitude faster when the cache has to be rebuilt. public abstract void () matches all methods (of a given class) which are abstract, publicly accessible, return void and take no parameters. Thus, in a sense, JTL mimics the Query By Example [80] idea.As in the logic paradigm, a JTL program is a set of predicate definitions, one of which is marked as the program goal.Even patterns which transcend the plain JAVA syntax should be understandable, e.g., abstract class { [long | int] field; no abstract method; } matches abstract classes in which there is a field whose type is either long or int and no abstract methods.The first line in the curly brackets is an existential quantifier ranging over all class members. The second line in the brackets is a negation of an existential quantifier, i.e., a universal quantifier in disguise, applied to this range.JTL can also delve into method bodies, by means of intraprocedural dataflow analysis, similar to that of the class file verifier. Consider for example cascading methods, i.e., methods which can be used in a cascade of message sends to the same receiver, as in the following JAVA statement (new MyClass()).f().g().h(); in which f, g and h are methods of MyClass. Then, the following JTL pattern matches all cascading methods:The curly brackets in the above pattern denote the set of values (including temporaries, parameters, constants, etc.) that the method may generate or use. The s...