Modern software often relies on the combination of several software modules that are developed independently. There are use cases where different software libraries from different programming languages are used, e.g., embedding DLL files in JAVA applications. Even more complex is the case when different programming paradigms are combined like within applications with database connections, for instance PHP and SQL. Such a diversification of programming languages and modules in just one software application is becoming more and more important, as this leads to a combination of the strengths of different programming paradigms. But not always, the developers are experts in the different programming languages or even in different programming paradigms. So, it is desirable to provide easy to use interfaces that enable the integration of programs from different programming languages and offer access to different programming paradigms. In this paper we introduce a connector architecture for two programming languages of different paradigms: JAVA as a representative of object oriented programming languages and PROLOG for logic programming. Our approach provides a fast, portable and easy to use communication layer between JAVA and PROLOG. The exchange of information is done via a textual term representation which can be used independently from a deployed PROLOG engine. The proposed connector architecture allows for Object Unification on the JAVA side. We provide an exemplary connector for JAVA and SWI-PROLOG, a well-known PROLOG implementation.
Business applications often are implemented with object oriented techniques. JAVA
currently is one of the most used object oriented programming languages with rich libraries
and a very active community. There are tools based on JAVA for writing complex rules,
but these tools still come with flaws [
Many approaches have been proposed to make PROLOG available in JAVA, but in many cases there is no clear distinction between JAVA and PROLOG as they use PROLOG concepts like terms and atoms directly in JAVA. Our efforts are to keep PROLOG structures off from JAVA, but to enable in JAVA the use of existing PROLOG rules and facts. Therefore we propose a fast, portable and intuitive connector architecture between JAVA and PROLOG.
In our approach, objects can directly be used as PROLOG goals, without creating complex structures in JAVA that represent the terms in PROLOG. Member variables that are equal null in JAVA are translated into PROLOG variables. Those variables are unified by PROLOG when querying a JAVA object as a goal in PROLOG. The values, the variables are unified with, are set to the corresponding member variables of the JAVA objects. We call this mechanism Object Unification. Apart from using existing JAVA classes for Object Unification, we also provide in PROLOG a generator for JAVA classes. The instances of generated classes unify with terms initially passed to the generator.
The remainder of this paper is organized as follows. In Section 2 we look at related work and compare those concepts with our own approach. Section 3 introduces the components of the proposed connector. We show the mechanics of the object term mapping in Section 3.1 and in Section 3.2 the parsing of PROLOG terms in JAVA. An exemplary interface for JAVA and SWI PROLOG completes the connector architecture in Section 3.3. After that, the workflow with our connector architecture is shown in Section 4 from two viewpoints: from JAVA and from PROLOG. In Section 5 we evaluate our approach and finally discuss future work in Section 6. 2
Providing a smooth interaction mechanism for JAVA and PROLOG is a challenging problem that has been studied in several research papers of the last decade.
A well known and mature interface between JAVA and PROLOG is JPL [
An interesting approach is INTERPROLOG [
The concepts of linguistic symbiosis have been used in [
A customisable transformations of JAVA objects to PROLOG terms was introduced
with JPC [
In [
In [
The connector for PROLOG and JAVA is based on our work with mappings between
objects in JAVA and terms in PROLOG. Before we discuss the individual parts of our
connector, we recap briefly the highly customisable Object Term Mapping (OTM) which
we have introduced in [
In the listing below instances of Person are given followed by the textual term representation under the default mapping and under the Prolog-View personView1: Person p1 = new person(1, 'Homer', 'Simpson'); Person p2 = new person(2, 'Bart', 'Simpson'); p1.setChildren(new Person[]{p2}); // default mapping of p1 "person(1,'Homer','Simpson',[person(2,'Bart','Simpson',[])])" // mapping of p1 under the Prolog-View "personView1" "person('Homer', 'Simpson', [child('Bart')])"
All the information needed for the creation of textual term representations are derived from the classes involved in the mapping. The default mapping uses the information of the classes structure itself. The customised mapping uses the information contained in the annotations @PlView. 3.1
We only need two classes in JAVA to request PROLOG as shown in Figure 2. The conversion as well as the parsing is implemented within the wrapper class OTT (ObjectTerm-Transformer). The class Query is used to start a call to PROLOG. An example for the usage of these classes is shown in Figure 3. The object o1 is destined to be unified in PROLOG. It has references to two other objects o2 and o3 which will lead to a nested term structure in PROLOG. When the instance query gets o1 passed to its constructor, query creates an instance of OTT, here ott1. For all the other references in o1 instances of OTT are created in a nested way, namely ott2 for o2 and ott3 for o3.
o3 o1 o2 ott2 query ott1
ott3
In order to create the textual term representation of o1, the instance query causes ott1 to call its toTerm() method that triggers a recursive call of toTerm() in all involved instances of OTT. In doing so, the first operation is to determine which fields have to be mapped. Dependent on the viewId of the requested Prolog-View or on the default mapping, an array of Field references is created that contains all the needed member variables for the particular view in the corresponding order. The information about the Fields is retrieved with help of the Reflection API in JAVA. The same way, additional information like PROLOG types and viewIds for particular member variables are saved within such arrays. As the information about a view of a class is solid and does not change with the instances, this field information is just created once and cached for further use. For the creation of the textual term representation the functor is determined either from a customised functor element of an @PlView annotation or from the class name in the default case. After that, the Field array is iterated and the string representation for its elements are created. The pattern of those strings depend on the PROLOG type that is defined for a member. If a member is a reference to another object, the toTerm() method for the reference is called recursively. 3.2
After query has received a textual representation of the unified term from PROLOG, it is parsed to set the unified values to the member variables of the appropriate objects in JAVA. The parsing uses again the structure of the nested OTT objects as shown in Figure 3. The class OTT has the method fromTerm(String term). This method splits the passed string into functor and arguments. The string that contains all the arguments is split into single arguments. This is done under consideration of nested term structures. According to the previously generated Field array the arguments are parsed. This parsing happens in dependence on the defined PROLOG type of an argument. For instance, an atom either has single quotes around its value or, if the first character is lowercase, there are no quotes at all. If there is a quote detected, it is removed from the string before assigning it as a value for the appropriate member variable. Assignments for referenced objects in o1 are derived recursively by calling the fromTerm(String term) method of the appropriate instances of OTT, in our example ott2 and ott3. 3.3
Although the complete mapping process is located in JAVA, we still need an interface
to the PROLOG implementation of choice in order to connect both programming
languages. The open-source PROLOG implementation SWI-PROLOG [
We have JAVA on one side and the C interface FLI on the other, so we need the glue to enable the communication between these two worlds. This is done by the JAVA Native Interface (JNI), which enables the usage of in C defined functions in JAVA. With the help of the JNI, we implemented a bridge between JAVA and the SWI-PROLOG system. As mentioned, we focus on the simple transmission of strings that represent terms in PROLOG. This differs from the interface JPL, as our interface does not need complex class structures in JAVA to represent terms in PROLOG. We simply send strings to PROLOG and receives strings from it. The transmitted strings already satisfy PROLOG’s syntax and thus can be converted directly into terms on the PROLOG side.
Via the FLI we provide backtracking if there are more solutions. This leads to a return that contains the next unified term in PROLOG. After sending from JAVA a string containing a goal with the logical variable X, our interface for SWI-PROLOG returns the unified term as a string back to our JAVA application. The user on the JAVA side now can call backtrack() to send a backtrack command to SWI-PROLOG which returns the next solution. 4
We start from two viewpoints: JAVA and PROLOG. Each viewpoint describes the development phase using our connector architecture.
From JAVA The default mapping enables the JAVA developer to use already existing JAVA classes in PROLOG as facts or as goals. If the default mapping of an object in JAVA does not provide a desired term structure in PROLOG, the textual term representation of the object can be altered by using the appropriate @PlView annotations. To unify an existing JAVA class the developer just has to wrap it within an instance of Query and call its method unify in order to call the class’ textual term representation as goal in PROLOG: Person p = new Person(); p.setId(1); Query q = new Query(p, "personView1"); q.unify();
The example request to PROLOG above contains an instance p of the class Person from Section 3. Note, that the only value that is set for p is the id attribute. The other attributes are not initialized and therefore equal null. The class Query manages the call to PROLOG. The optional second parameter of the constructor of Query defines which Prolog-View is used for the object p. It is specified by the viewId element of a @PlView annotation, here personView1. When the method unify() is called the textual term representation is created. This is done either according to the default mapping or under the consideration of existing @PlView annotations that are defined for the class Person or any other referenced classes in Person. This string is already a valid term in PROLOG with arguments that represent the attributes of p and all referenced objects in p. The textual term representation has only arguments for attributes that are mapped as defined by the default mapping or by a referenced @PlView annotation. The textual term representation then is used as goal within the PROLOG query.
In the example above, most attributes of p are equal to null in JAVA. As null is a value that can not be transformed into an appropriate type in PROLOG it has to be handled in a particular way. We consider null to be in PROLOG a (logical-)variable that is supposed to be unified. After sending a call to PROLOG containing null values, the resulting variables are possibly unified in PROLOG. The unified term is sent back as string and parsed in JAVA. Changes to the initial string sent from JAVA to PROLOG will be detected and set to the initial object by JAVA reflections, in our example to the instance p of Person. This means, those attributes that formerly have been equal to null are set to the values of the variables unified in PROLOG. The original object p now has been updated and represents the solution of the unification process in PROLOG.
An important feature of PROLOG is unknown to JAVA: the backtracking mechanism. The method unify just returns the first solution PROLOG provides. But via backtracking PROLOG is able to provide other unifiable solutions. These solutions can be retrieved with another method of Query that is called backtrack(). It sends a backtrack request to PROLOG in order to retrieve the next solution, if there is one. The same way a the solution is set to the original object via unify(), the solution via backtrack() is set to the variables of the original object in JAVA. As it is not sure that there even are other solutions, backtrack() returns a boolean in JAVA whether a solution was found by PROLOG or not.
Similar to JPL, we have implemented a third request: get all solutions of a goal in one call. This is called findall(), named after the built-in predicate in SWI PROLOG. This method returns an array of the requested objects, e. g. Person. As the method returns multiple objects with different values in their variables, we have to create for each solution a new object. So, when using this method the original object is not touched at all. Creating new objects for every solution is the reason why we need the unifiable objects to have a default constructor in JAVA.
Beside these basic methods for Object Unification there is a method for asserting JAVA objects to the PROLOG database. This method is called persist() and just takes the generated string representation of the PROLOG term and asserts it by using the assertz/1 predicate. After that method call the term representation of the appropriate object is available as fact in PROLOG.
From PROLOG Another viewpoint is the writing of PROLOG terms that are destined for the use in JAVA. In contrast to the previous viewpoint, there are no suitable JAVA classes yet within the current project. So, we show now how is easy it is to write PROLOG libraries that are accessible from JAVA by generated classes.
In [
We also have introduced in [
A Rule in PROLOG can be made accessible from JAVA using the PVN to describe a rule’s head. From this PVN expression we generate JAVA classes with the appropriate @PlView annotations. For this purpose we have developed two predicates in PROLOG: create_class_from_pvn(?Pvn, ?Class) create_annotation_from_pvn(?Pvn, ?Annotation) Typically for PROLOG, both predicates can have the first or the second argument as input. The first predicate generates from a PVN expression source code for JAVA containing all necessary classes. These classes map directly to the terms in PROLOG from which we started from. The second predicate is used to generate the @PlView annotations.
To evaluate our approach we reimplemented the London Underground example as in
[
In our first implementation we use JPL in order to retrieve a station connected to a given station: 1 public class Line { 2 public String name; 3 public Term asTerm() { 4 return new Compound("line", new Term[]{new Atom(name)}); } } 5 public class Station { 6 public String name; 7 public Station(String name) { this.name = name; } 8 public Term asTerm() { 9 return new Compound( "station", new Term[]{
new Atom(name)}); } public Station connected(Line line) {
String stationVarName = "Station"; Term[] arguments = new Term[]{asTerm(), new Variable(stationVarName), line.asTerm() }; Term goal = new Compound("connected", arguments); Query query = new Query(goal);
Hashtable<String, Term> solution = query.oneSolution();
As one can see, the implementation with JPL leads to a lot of lines of code. In the method connected the complex term structure is created in order to query the predicate connected. The result handling is tedious again. With our approach we do not have to create any term structures in JAVA. Instead, we need to implement an extra class Connected representing the goal in PROLOG with the predicate connected/3:
As the following table shows, our approach needs less lines of code to implement the London Underground example than the implementation with JPL. However, lines of code do not say anything about the code’s complexity and information density. Our class Connected is very simple. It contains only member variables and two simple constructors whereas in JPL already the method connected() of the class Station is fairly complex.
With the data of the complete London Underground with 297 stations, 13 lines and 412 connections, we made 50,000 executions1 with both implementations. The result of the performance test is presented in the following table: ø execution time of 50:000 calls 1:2s 2:6s
Castro et al. did a similar comparison between JPL and their LOGICOBJECTS [
Aside from a performance improvement in form of field structure caching, as
mentioned in Section 4, we identified that getting and setting the values of the member
variables via Reflections is slow. In the future we want to use static calls as often as
possible instead of using the Reflection API. In order to make use of direct calls, we need
to generate Specialized OTT classes (SOTT) for all classes that we want to map. These
generated classes contain highly specialized toTerm() and fromTerm(String)
methods that call their member variables directly if public or with their getter and setter
methods. This attempt picks up concepts from our prior work in [
The presented interface in Section 3.3 has proven to be well applicable for SWI-PROLOG. However, our approach is not limited to this PROLOG implementation. We currently develop a standard interface based on pipes that is suitable for most PROLOG implementations and completes our generic approach. This way, we want to accomplish a portable solution that is independent from any PROLOG implementation.
In addition, we further want to reduce the necessary lines of code. In our current approach we use a wrapper class called Query for calling a PROLOG goal. Instead, we could have used an abstract superclass that is extended by the class of an object that is going to be mapped. This superclass manages the OTT objects that contain the logic behind the creation of the textual term representations and the parsing. Even the request control for unify(), backtrack() and findall() then is part of this superclass. Using the abstract superclass the request for PROLOG from JAVA in the Underground example in the lines 16, 17 can be reduced to a single line containing just the method call connected.unify() which additionally saves the initialisation of a Query object.
However, the approach with a superclass has a big drawback: we want to be able to use almost every class in JAVA for the Object Unification. This will not work for classes that already extend a class because JAVA does not support multiple inheritance yet. In JAVA 8 there is a new feature called Default Methods that allows to implement a method directly within a JAVA interface. Using this new feature we can implement all the needed functions as Default Methods in an interface. Because multiple JAVA interfaces can be implemented by a single class, we achieve with this new interface the same reduction in lines of code as with an abstract superclass. This way, we can avoid the multiple inheritance problem for classes.