Cross-Paradigm Interoperability Between Jadescript and Java

Giuseppe Petrosino

, Stefania Monica

and Federico Bergenti

Dipartimento di Scienze e Metodi dell’Ingegneria, Universit

a degli Studi di Modena e Reggio Emilia, Reggio Emilia, Italy

Dipartimento di Scienze Matematiche, Fisiche e Informatiche, Universit

a degli Studi di Parma, Parma, Italy

Keywords:

Agent-Oriented Programming, Jadescript, JADE.

Abstract:

Jadescript is a recent language for practical agent-oriented programming that aims at easing the development of

multi-agent systems for real-world applications. Normally, these applications require extensive and structured

reuse of existing software modules, which are commonly developed using object-oriented or legacy technolo-

gies. Jadescript has been originally designed to ease the translation to Java and, as such, it natively eases the

interoperability with Java, and therefore, with mainstream and legacy technologies. This paper overviews the

features that have been recently added to Jadescript to support effective two-way interoperability with Java.

Moreover, this paper thoroughly discusses the main ideas behind such features by framing them in a compari-

son with related work, and by outlining possible directions for further developments.

1 INTRODUCTION

Programming language interoperability is a key as-

pect of modern software development because it al-

lows software components written in various lan-

guages to interact and share data. It provides several

advantages when designing a new system or extend-

ing the functionality of existing systems, like platform

adaptation and code reuse. The rewriting of code in a

new language to solve previously addressed subprob-

lems is cumbersome, and it represents an obstacle to

the adoption of new languages. Moreover, languages

that operate at a higher level of abstraction often pay

inherent costs, e.g., in terms of worse run-time per-

formance. The interoperability with languages at a

lower level of abstraction, which can better express

the details of their low level of abstraction, can mit-

igate such issues. As a matter of fact, it is gener-

ally accepted that the most appropriate programming

language is different for each situation. This is be-

cause each language can represent better, or worse,

certain aspects of the addressed problems and of the

programs that are proposed as their solutions.

Jadescript (Bergenti and Petrosino, 2018; Bergenti

et al., 2018; Bergenti et al., 2020) is an Agent-

Oriented Programming (AOP) language. Its main ab-

stractions derive from agent technology, and therefore

it can be used effectively to model software systems

around software agents. Jadescript agents are based

on JADE (Bellifemine et al., 2005), a Java frame-

work with a long history (Bergenti et al., 2020) in the

development and administration of Multi-Agent Sys-

tems (MAS). JADE is considered the de facto refer-

ence implementation of the Foundation for Intelligent

Physical Agents (FIPA) speciﬁcations. Jadescript is

designed to be translated to Java, it is supported by

a static type system, and it adopts an event-driven

programming style. Jadescript provides language fa-

cilities to deﬁne agents, agent behaviours, and com-

munication ontologies with a syntax inspired from

agent pseudocode. The development of Jadescript,

and of its companion development tools, has re-

cently reached maturity with several advanced fea-

tures (Petrosino and Bergenti, 2019; Petrosino et al.,

2021; Petrosino et al., 2022b) that make it a com-

plete tool to program MASs. However, the develop-

ment of agent-based software to address real-world

problems, like the ones encountered in industrial ap-

plications of agents (Bergenti et al., 2015), requires

Jadescript agents to interact with existing software.

This is required to deal with legacy systems, for

which agents-based approaches have been success-

fully applied (Genesereth and Ketchpel, 1994), to cre-

ate graphical interfaces to improve the interactions

with users, or to access external software or hard-

ware (Iotti et al., 2020). One approach that is read-

ily available to achieve Jadescript-Java interoperabil-

ity uses the interaction capabilities of agents and the

fact that both Jadescript and JADE agents are FIPA

agents. Thanks to this, they can use standardized

Petrosino, G., Monica, S. and Bergenti, F.

Cross-Paradigm Interoperability Between Jadescript and Java.

DOI: 10.5220/0011619300003393

In Proceedings of the 15th International Conference on Agents and Artiﬁcial Intelligence (ICAART 2023) - Volume 1, pages 165-172

ISBN: 978-989-758-623-1; ISSN: 2184-433X

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

165

speech acts and shared ontologies to communicate

and coordinate. Therefore, the interaction between

Jadescript agents and Java objects can be achieved at

the agent level by designing speciﬁc JADE agents to

act as mediators or wrappers of Java objects. Such

an approach remains valid, but some drawbacks in

common situations are easily identiﬁed. One draw-

back is that the construction of mediator agents to

let Jadescript agents execute simple procedures writ-

ten in Java might constitute a development cost that

does not scale well to large projects. Moreover, this

approach adds considerable runtime overhead to the

execution of the target procedures, making Jadescript

agents unavoidably slow. On the other hand, the in-

troduction of a dedicated interoperability support in

Jadescript, together with a speciﬁc Java API, can sig-

niﬁcantly simplify the development process for the

discussed scenarios. The main contribution of this

paper is to discuss the recent changes introduced in

Jadescript to let agents easily interact with existing

code written in Java.

All the presented features introduced in Jadescript

to support effective interoperability with Java were

designed to satisfy a set of speciﬁc requirements.

First, the features should not excessively increase the

complexity of the language. For example, from a syn-

tactical perspective, most of the features are limited

to the introduction of the native modiﬁer, which can

be prepended to some of the constructs already avail-

able in the language. The use of this modiﬁer changes

the meaning of the modiﬁed constructs in ways that

are discussed in Sect. 2. Second, the design of each

feature should attempt to minimize the amount of ad-

ditional Java and Jadescript code required to achieve

interoperability. Unfortunately, this glue code cannot

be null in many cases, mostly because of the relevant

differences between the two languages.

This paper introduces all the presented features in

Sect. 2, which is followed by a discussion and a com-

parison with similar features of other AOP languages

in Sect. 3. After a brief discussion of the main pos-

sibilities to further improve the presented interoper-

abiltiy features, Sect. 4 concludes the paper.

2 JADESCRIPT-JAVA

INTEROPERABILITY

This section describes the design of the proposed sup-

port for the interoperability between Jadescript and

Java. As brieﬂy discussed earlier, the possibility for

Jadescript to effectively interface the Java virtual ma-

chine and its libraries is of paramount importance to

promote reuse of existing software modules.

2.1 Jadescript and Java Data Types

A recent paper (Petrosino et al., 2022a) provides a de-

tailed description of the Jadescript type system, and it

highlights that the data types adopted for Jadescript

are peculiar for several reasons. Actually, Jadescript

is an AOP language, and its data types considers

abstractions that are strongly related to agents and

MASs. Jadescript does not adopt the Object-Oriented

Programming (OOP) paradigm, and the language

purposely lacks the abstractions needed to manipulate

classes and objects. In addition, Jadescript is a very

high-level language, and its data types are part of the

means that it provides to deal with data at the adopted

high level of abstraction. Finally, Jadescript is de-

signed to target JADE, which makes the language–

and its data types–designed to work with the abstrac-

tions standardized by FIPA and adopted by JADE.

One of the main consequences of these peculiari-

ties of the Jadescript type system is that a one-to-one

relationship between Jadescript data types and Java

data types is not possible. Such a relationship is a

characteristic that several mainstream programming

languages, e.g, Kotlin and Groovy, provide to offer

a direct support for interoperability with Java. Its ab-

sence constrains the way the two languages can share

data when some code written in either one of them

reuses the code written in the other, and it ultimately

causes two major problems. First, note that Jadescript

is designed to be translated to Java, and therefore each

one of its data types has a corresponding represen-

tation in Java, either as a primitive data type, or as

a class or an interface. However, this might not be

the case in the future, which is the ﬁrst of the two

problems. Actually, the growing number of features

provided by Jadescript for agent programming might

require the introduction of new data types that might

not be properly represented in Java, and that, there-

fore, would be erased during the compilation pro-

cess. Second, Jadescript is not an OOP language, and

therefore no objects are available to Jadescript pro-

grammers, which causes the second problem because

not all Java data types can be properly mirrored by

Jadescript counterparts. In order to target both these

problems, Jadescript provides the features described

below to create Jadescript values in Java and to con-

vert values from a Java data type to a Jadescript data

type in a simple and effective way.

The set of interoperability features that has been

recently added to Jadescript are not limited to changes

in the language. Three sets of new utilities de-

signed to write Java code intended to interoperate

with Jadescript code are provided in the Jadescript

runtime support, as described below.

ICAART 2023 - 15th International Conference on Agents and Artiﬁcial Intelligence

166

First, to assist the conversion of values from Java

data types to Jadescript, the Jadescript class, in-

cluded in the Jadescript runtime support, exposes a set

of overloaded public static methods named valueOf.

Such methods take one parameter each, and they re-

turn, after applying suitable conversions, values com-

patible with Jadescript.

Second, in addition to the valueOf methods, the

Jadescript class provides a set of methods called

asX, where X is the name of one of the built-in

Jadescript data types, e.g., asInteger, asDuration,

and asPerformative. Each one of these methods

accepts a parameter of type Object, and it returns,

in Java, the conversions performed by the as oper-

ator in Jadescript. For example, expression "PT1S"

as duration in Jadescript converts the text literal

"PT1S", formatted according the ISO 8601 standard,

to a duration representing a duration of one second.

The same operation can be performed in Java by

invoking Jadescript.asDuration("PT1S"). Note

that not all conversions from Java values to

Jadescript values are possible, and when an in-

valid conversion is attempted, an exception of type

ConversionException is thrown.

Third, some Jadescript data types (duration,

timestamp, and performative) have Java coun-

terparts represented by classes provided by the

Jadescript runtime support. These classes pro-

vide methods to create values and execute

operations on the corresponding data types

in Java. For example, the Java expression

n.plus(Jadescript.asDuration("PT1M")) pro-

duces a Jadescript timestamp that represents the time

instant that follow n after one minute.

Finally, note that, when using the Jadescript-Java

interoperability features described in the remaining of

this paper, the conversion of a value from a Jadescript

data type to a Java data type is automatic and com-

pletely handled by the compiler. Instead, the conver-

sion of a value from a Java data type to a Jadescript

data type is not automatic, and it requires dedicated

glue code. However, when using an interoperability

feature from Java code, the use values of the correct

Jadescript data type is always enforced at compile-

time, with the notable exception of native expressions

and statements described in Sect. 2.

2.2 Creating Jadescript Agents in Java

Jadescript is supported by a set of tools designed to fa-

cilitate the development of agents. One of these tools

is a plug-in for the Eclipse IDE that provides a devel-

opment environment with useful features, e.g., syntax

highlighting. The plug-in also includes a wizard that

1 module m us ic

3 agent Mus ic D ow n lo ade r uses ontology Mu si c

4 on create with t i tl e as text,

5 ar t is t as text do

6 activate B u yTr a ck ( artis t , ti t le )

Listing 1: An example of a toy Jadescript agent.

assists programmers to conﬁgure and launch JADE

platforms and containers (Bellifemine et al., 2007)

populated with the agents written in Jadescript. An-

other way to launch Jadescript agents is via the com-

mand line (Caire et al., 2010) by specifying a Java

class generated by the Jadescript compiler for each

one of the desired agents together with respective

start-up arguments. However, in several applications,

it is necessary to start containers and agents in Java. A

set of new facilities provided of the Jadescript runtime

support simpliﬁes the usage in Java of agents written

in Jadescript.

Remember that a JADE platform is composed of

several connected containers. Each platform has ex-

actly one main container, and several peripheral con-

tainers. All peripheral containers register to the main

container at start-up by specifying the network ad-

dress and the port of the main container. A, main or

peripheral, container can be created in Java using the

Jadescript class by invoking the public static meth-

ods named newMainContainer or newContainer,

respectively. These methods accept the network ad-

dress and the port of the main container together

with a platform identiﬁer. Both methods return a

ContainerController instance, which can be used,

e.g., to create agents or to destroy the container.

For each agent deﬁned in Jadescript, the com-

piler generates a Java class with the same name

that provides a static method to create and initialize

the agent. This method accepts as parameters: the

ContainerController instance of the container in

which the agent will be created, a string that is used

as the local name of the agent, and one parameter for

each one of the parameters required by the on create

event handler of the Jadescript agent.

For example, consider the MusicDownloader

agent in Listing 1, whose primary job is to update a

music library with a track (if missing in the library)

speciﬁed at start-up by stating the title and the name

of the artist.

The code in Listing 1 is just an example to illus-

trate the creation of agents from Java code, so the

BuyTrack behaviour is omitted. Starting from this

agent deﬁnition, the Jadescript compiler generates the

Java class music.MusicDownloader, which contains

a static method named create. This method accepts

Cross-Paradigm Interoperability Between Jadescript and Java

167

1 public class M us i cD ow n lo ad e rM a in {

2 public static void m a i n ( Str i ng [] arg s ) {

3 Co nt a in er C on tr o ll e r ma inC ont ai n er =

4 J a des cri pt . n e wM ai n Co n ta ine r () ;

5 J a de sc r ip tA g en tC o nt ro l le r d ow n lo a de r =

6 mus i c . Mu si c Do w nl oad er . c re ate (

7 ma i nCo n ta ine r ,

8 " d o wn l oad er " ,

9 " Jo h ann Se b as t ian Bac h " ,

10 " Ce l l o S u it e No .1 , Pr e lud e ") ;

11 }

12 }

Listing 2: The creation of a main container and a Jadescript

agent in Java.

a ContainerController instance, the agent local

name, and two additional strings, one for the track ti-

tle and one for the artist name. This method returns a

JadescriptAgentController instance, which pro-

vides a thread-safe interface to the created agent that

can be used to issue lifecycle commands (e.g., to shut-

down and remove itself from the platform) or to notify

native events to the agent. Listing 2 shows an example

of the use of the generated class from Java.

2.3 Native Events

Jadescript adopts an event-driven programming style.

Agents and behaviours can include several event han-

dlers that deﬁne how to react to various external (i.e.,

messages from other agents) or internal (i.e., changes

of the internal state, failures, and exceptions) events.

Native events are an additional kind of event recently

introduced in the language. A Jadescript agent can

listen to native events through its active behaviours,

when they contain an applicable native event handler.

The details about received native events are reported

at runtime by predicates or atomic propositions, and

the programmer can use ontology declarations to de-

ﬁne schemas for them. The syntax for a native event

handler (here referred as NEHandler) is:

⟨NEHandler⟩ ::= ‘on’ ‘native’ ⟨Pattern⟩?



‘when’ ⟨Expr⟩



‘do’ ⟨CodeBlock⟩

where Pattern is an optional pattern (Petrosino and

Bergenti, 2019) for the predicate or the proposition

describing the event, Expr after the when keyword is

a boolean expression expressing additional precondi-

tions, and CodeBlock is a section of procedural code

that deﬁnes what to do when a matching event is se-

lected for handling.

In the current version of Jadescript, na-

tive events can be notiﬁed only from Java

code by using the method named emit on a

JadescriptAgentController instance. This

method accepts one proposition, which can be

deﬁned in Jadescript using proposition and

predicate declarations in ontologies. Note that the

Java code written to create containers and agents

is executed on a different thread than the ones

on which JADE (and consequentially, Jadescript)

agents execute. However, events notiﬁed through a

JadescriptAgentController instance are pushed

at the end of a queue internal to the agent, in a

thread-safe way. Actually, the mechanism that is used

to push an event to an agent is based on the Object

to Agent (O2A) facility (Bellifemine et al., 2007) that

JADE provides to safely interact with agents.

2.4 Use of Java Methods in Jadescript

This subsection describes a set of features that is pro-

vided to directly access methods written in Java from

Jadescript. To achieve this, two new constructs are in-

troduced in the language, namely the do native state-

ment, and the native expression.

The syntax of a do native statement (here re-

ferred as DNStatement) is:

⟨DNStatement⟩ ::= ‘do’ ‘native’ ⟨MetID⟩



‘with’ ⟨ArgList⟩



where Expr is an expression, Expr:Text is an ex-

pression evaluating to a text value, Identiﬁer is

a Jadescript identiﬁer, and ArgList is a comma-

separated list of expressions. This statement can be

used to invoke a Java static method identiﬁed by

MetID, with the arguments enumerated in the ArgList.

The method is resolved at compile time if MetID is a

Java fully qualiﬁed name expressed as a sequence of

identiﬁers separated by dots. In this case, the com-

piler can check the existence of the Java method in

the environment and the conformance of the types of

the arguments. On the contrary, if MetID is an ex-

pression evaluating to a text value, the method is re-

solved at runtime, using the obtained text as the fully

qualiﬁed name of the requested method. Java meth-

ods resolved at runtime are invoked in the generated

code using the Java Reﬂection API. In this second

case, the compiler does not check the conformance

of the types of the arguments, and a Jadescript excep-

tion (Petrosino et al., 2022b) is thrown if the types

of the arguments are not compatible with the param-

eters of any of the resolved methods. Note that, in

both mentioned cases, as mentioned in Sect. 1 and

Sect. 2, all data types used in the signature of the re-

quested method must be compatible with Jadescript

data types. Moreover, note that the do native con-

struct is a statement, and therefore it cannot be used as

an expression. This also means that the value returned

by the Java method is discarded after the execution of

the statement, and any data type is accepted as valid

return type for the method, void included. Intuitively,

ICAART 2023 - 15th International Conference on Agents and Artiﬁcial Intelligence

168

this is the main difference between do native state-

ments and native expressions, because the methods

invoked by native expressions are required to return

a value of a Jadescript-compatible type.

A native expression can be used as part of any

expression, e.g., as an operand of a binary opera-

tion. The syntax of a native expression, referred as

NExpr, is the following:

⟨NExpr⟩ ::= ‘native’ ⟨MetID⟩



‘(’⟨ArgList⟩‘)’





‘as’ ⟨Type⟩



where MetID follows the same syntactic rules used

in the do native statement, and similarly, MetID can

be used to specify the resolution mode (compile-time

versus runtime) of the method. For compile-time res-

olutions, the compiler checks, in addition to the con-

formance of the argument types to the parameter types

of the resolved method, the compatibility between the

Java return type of the method and the expected type

of the expression. In this case, the as clause with

the Type speciﬁcation is optional. For runtime res-

olution, however, the compiler cannot infer the type

of the expression because no information about the

invoked method is provided at compile-time. In this

case, the as clause is mandatory and the data type of

the value returned by the method must conform to the

type speciﬁed by Type, or an exception is thrown.

2.5 Native Ontology Concepts

Jadescript (communication) ontologies are abstrac-

tions provided to let programmers deﬁne a set of en-

tities that are of primary importance for agent com-

munication. As a matter of fact, ontologies can be

used to ensure that agents share the same interpreta-

tion of the contents of exchanged messages. Agents

can explicitly use one or more ontologies. When they

use ontologies, they can create values of the entities

declared in the used ontologies, manipulate those val-

ues, and use them as contents of messages. One of

the main abstractions provided by ontologies are con-

cepts. Concepts are entities with a structure deﬁned in

terms of properties, and they can be used as terms of

other entities like other concepts, or, e.g., predicates

to express logical facts about them, and agent actions

to refer to actions that agents can perform.

The support for Jadescript-Java interoperability

presented in this paper introduces a new type of ontol-

ogy declaration, which is a different ﬂavor of concept

and it is called native concept. Native concepts are

concepts whose concrete implementation is deﬁned

by the programmer in Java. To create a native con-

cept, the Jadescript programmer needs to declare it as

an ordinary concept in an ontology declaration, but

prepending the native keyword to it. By doing this,

the compiler generates a Java abstract class with the

same name of the concept, and it includes a partial

implementation of it. In particular, for each property

declared in the concept, two abstract methods, namely

a setter method and a getter method, are included.

When using native concepts, the programmer is

supposed to write a concrete Java class that extends

the generated abstract class with the additional re-

quirement of including a constructor with no param-

eters in the concrete class. This is important be-

cause, when a concept is deserialized from the con-

tent of a message, its constructor with no parameters

is invoked by the receiving agent before automatically

populating the properties of the concept using the set-

ter methods. After the concrete class is deﬁned, the

programmer can bind it to the ontology declaration by

invoking the public static method named bindNative

of the Jadescript class.

The adopted approach to support native concepts

in Jadescript has several advantages. First, the pro-

grammer is guided in the deﬁnition of the concrete

class by the Jadescript and Java compilers, ensur-

ing that the programmer writes Java code that is us-

able from Jadescript. Second, each execution envi-

ronment can have its own concrete implementation of

a native concept, while, at the same time, preserv-

ing the details of the concept that are essential for

message exchange. For example, consider a MAS

composed of several agents executing in two con-

nected containers, one on a desktop computer, the

other on an Android smartphone. These agents can

talk about abstract windows sharing a common inter-

pretation of the graphical interface, which is only con-

cerned with properties like its title and its graphical

components. However, when an agent on the desktop

chooses to construct a window visible to the user, a

JFrame instance from the Swing library is shown. At

the same time, when an agent on the Android smart-

phone chooses to show a window, an Android activity

is started and activated.

2.6 Native Functions and Procedures

Jadescript agent and behaviour declarations include

several event handlers, properties, procedures, and

functions. In particular, these last two constructs can

be used to deﬁne parameterized sections of procedu-

ral code (possibly, with side effects). The main differ-

ences among these two constructs is that functions are

supposed to return a value, so they have a return type

known at compile time, and they can be applied as

part of expressions. Instead, procedures are supposed

not to return a value, and they can be executed only by

means of the do statement. Jadescript allows the dec-

laration of top-level functions and procedures, which

Cross-Paradigm Interoperability Between Jadescript and Java

169

1 module ex amp le s . math

3 native function sqr t ( x as real) as real

Listing 3: Declaration of a native function.

ensures that they can be part of a module instead of

being internal to a speciﬁc agent or behaviour dec-

laration. Top-level functions and procedures can be

used from anywhere inside the module, or they can

be imported into other source ﬁles outside the module

by using import declarations.

Top-level functions and procedures have been re-

cently extended with the possibility of implementing

them in Java, using an approach similar to native con-

cepts described previously. Native function and pro-

cedure declarations are syntactically similar to ordi-

nary top-level functions and procedures. The only

differences are that they are introduced by the native

keyword, and they have no body (and, consequently,

no do keyword at the end of their header). For exam-

ple, Listing 3 shows the declaration of a native func-

tion named sqrt that accepts one real parameter and

computes one real value.

For each native function and procedure declara-

tion, the Jadescript compiler generates a Java inter-

face with the same name and a single Java abstract

method. The abstract method has a parameter for

each one of the parameters declared in the Jadescript

native counterpart, and an additional ﬁrst parame-

ter of type InvokerAgent named invokerAgent.

This reference provides a fac¸ade that allows per-

forming operations on behalf of the agent, e.g.,

to write messages to the container message log,

to shut the agent down, or to activate or deacti-

vate behaviours. Actually, the availability of the

invokerAgent argument is the one of the main ad-

vantages of using native functions and procedures in-

stead of native expressions and statements. Note that

an InvokerAgent instance is substantially different

from the JadescriptAgentController instance de-

scribed in Sect. 2. The former represents the agent

from an internal perspective, i.e., it is the agent who

called the native function or the native procedure, and

it is used to perform operations within the Java thread

of the agent. The latter, instead, is a proxy for the

agent intended to control the agent from the outside,

to issue commands, or to notify events from (possi-

bly) another Java thread.

In order to use a native function or procedure, the

programmer is supposed to create a concrete imple-

mentation of the generated interface. For example,

Listing 4 shows a simple implementation of the na-

tive function declared in Listing 3. Note that the im-

plementation class that provides the bodies of native

1 public class S q rtI mp l

2 implements e x amp l es . m a t h . sq r t {

3 public Do u ble sqrt ( I nv o ke r Ag e nt

4 inv o ker A ge nt , D oub l e x) {

5 return Mat h . s q rt ( x) ;

6 }

7 }

Listing 4: Implementation of the native function sqrt.

functions and procedures must be bound at runtime

by means of the method named bindNative available

in the Jadescript class, similarly to the mechanism

avaiable for native concepts.

3 RELATED WORK

Jadescript is not the ﬁrst AOP language that provides

support for interoperability with Java. As a mat-

ter of fact, several AOP languages are designed to

work within Java-based environments. One language

that shares relevant similarities with Jadescript, espe-

cially in the architecture of its main implementation,

is SARL (Rodriguez et al., 2014; Feraud and Galland,

2017). SARL is an AOP language based on Xtend,

which is a Java dialect that is tightly integrated with

Xtext, which is a tool that is used by the current im-

plementation of the Jadescript compiler. Thanks to

this design choice, SARL code can readily use code

deﬁned in Java or in Xtend. The SARL programmer

can easily access ﬁelds, invoke constructors, and in-

voke instance and static methods with the common

dot notation. SARL, through its features inherited

by Xtend, also provides OOP abstractions to directly

deﬁne classes, interfaces, enumerations, and annota-

tions. This approach allows writing code that is easily

interoperable with Java code, and this is possible ul-

timately because SARL adopts both AOP and OOP

paradigms. Jadescript was designed not to be an OOP

language, and therefore it cannot enjoy the beneﬁts of

immediate interoperability with Java like SARL does.

Jason (Bordini and H

ubner, 2006) is an

AgentSpeak(L) (Rao, 1996) interpreter written

in Java. AgentSpeak(L) provides a way to express

agent programs based on the Belief-Desire-Intention

(BDI) agent architecture, which equips agents

with practical reasoning abilities. Jason extends

AgentSpeak(L) with several additions, e.g., plan

failure handling, and agent communication based on

speech acts. Moreover, it implements the underlying

BDI agent architecture in Java, offering programmers

the possibility to customize the architecture by

extending Java classes.

ICAART 2023 - 15th International Conference on Agents and Artiﬁcial Intelligence

170

The interpreter loop is at the core of the Jason

agent architecture. The loop is composed of steps

to which parts of the reasoning process of the agent

are delegated. Almost all parts of the loop can be cus-

tomized (Bordini et al., 2007) by extending the Agent

class and overriding the corresponding Java methods.

Moreover, the environment the agents are situated in

is implemented in Java using a speciﬁc API to imple-

ment environments and to provide sensing capabili-

ties to agents. Finally, the body of Jason plans are se-

quences of private actions and of updates to the belief

base or to the set of goals to be achieved by the agent.

The list of actions that can be executed, and the effects

of these actions, is deﬁned by the environment or by

internal actions, which are instances of Java classes

that implement the InternalAction interface.

ASTRA (Dhaon and Collier, 2014; Collier et al.,

2015) is an implementation of AgentSpeak(L) ex-

tended with teleo-reactive programming capabilities

and support for encapsulated rules. ASTRA intro-

duces a speciﬁc abstraction for interoperability with

Java called module. A module is a direct mapping

of a Java object into a namespace of agent actions

and sensors. Each action and sensor corresponds to

a Java method annotated with @ACTION and @SENSOR

in the user-deﬁned module class, which extends the

ASTRA class Module. The module code can ac-

cess and modify the internal state of the agent by

means of the inherited ﬁeld agent. For example,

an action or a sensor implemented in Java can use

agent.beliefs().addBelief(b) to update the be-

lief base of the agent with the addition of a new belief

b. At the beginning of each interpreter cycle, all the

sensor methods of each used module are invoked to

give them the opportunity to change the belief base or

to emit appropriate events. Instead, actions are in-

voked explicitly within ASTRA plans by means of

the ubiquitous dot notation. ASTRA modules are

designed for reusability and their usage is expressed

with statements in the body of an agent declaration.

An abstraction similar to Jason environments or

ASTRA modules is absent in Jadescript because

Jadescript provides no abstraction to explicitly model

an environment. However, the sensing and acting

abilities provided by them and by Jason internal ac-

tions can be easily deﬁned in terms of the native state-

ments, expressions, events, functions, and procedures

discussed in Sec. 2.

4 CONCLUSION

Software agents provide a unique opportunity to pro-

mote reusability and adaptability of quality soft-

ware (Bergenti and Huhns, 2004). However, this de-

sirable result cannot be effectively achieved without a

means to enable smooth interactions between agents

and other pieces of software developed in using main-

stream, or even legacy, technologies. For this reason,

an AOP language that aspires to be used for the devel-

opment of real-world agent-based solutions needs to

provide an effective support for interoperability with

mainstream languages like Java. This paper presented

and discussed the main additions to Jadescript to sup-

port interoperability with Java, highlighting the im-

portance of such additions and comparing their de-

sign with similar supports provided by other AOP lan-

guages, namely SARL, Jason, and ASTRA.

The set of discussed features can be further de-

veloped and improved in the future. For example,

Jadescript does not currently provide a support to cus-

tomize parts of the internal agent architecture, like

Jason and several other AOP languages do. The

prospect of this support is secondary to additional

work that might be addressed in future versions of

Jadescript. In particular, future work might address

the deﬁnition of the subtyping and inheritance mech-

anisms to reuse agent and behaviour deﬁnitions. This

improvement to the language does not seem particu-

larly involved because Jadescript is designed to trans-

late these deﬁnitions to Java classes. In addition, the

Jadescript runtime support could provide the facili-

ties to let programmers extend these classes to di-

rectly customize the architectural details of a class of

agents or behaviours. This improvement of the lan-

guage would allow the injection of custom code in the

various phases of the agent and behaviour lifecycles.

Moreover, it would provide the ability to change the

default implementations of the core mechanisms of

the agents, e.g., the behaviour scheduling algorithm

or the algorithm that puts inbound messages into the

private message inbox of the agent.

Finally, it is worth noting that additional dis-

cussions on interoperability features are expected if

Jadescript would target other platforms than the Java

virtual machine in the future. The interoperability

features presented in this paper are general enough to

easily support such a prospect, ensuring that the syn-

tax and the semantics of the interoperability features

would remain the same from the Jadescript side, inde-

pendently of the target platform. However, other lan-

guages and platforms could inspire new ideas for in-

teroperability features or present unforeseen require-

ments and constraints.

Cross-Paradigm Interoperability Between Jadescript and Java

171

ACKNOWLEDGEMENTS

This work was partially supported by the Italian Min-

istry of University and Research under the PRIN 2020

grant 2020TL3X8X for the project Typeful Language

Adaptation for Dynamic, Interacting and Evolving

Systems (T-LADIES).

REFERENCES

Bellifemine, F., Bergenti, F., Caire, G., and Poggi, A.

(2005). JADE–A Java Agent DEvelopment Frame-

work. In Multi-Agent Programming, volume 25 of

Multiagent Systems, Artiﬁcial Societies, and Simu-

lated Organizations, pages 125–147. Springer.

Bellifemine, F., Caire, G., and Greenwood, D. (2007). De-

veloping Multi-Agent Systems with JADE. Wiley Se-

ries in Agent Technology. John Wiley & Sons.

Bergenti, F., Caire, G., and Gotta, D. (2015). Large-scale

network and service management with WANTS. In

Industrial Agents: Emerging Applications of Software

Agents in Industry, pages 231–246. Elsevier.

Bergenti, F., Caire, G., Monica, S., and Poggi, A. (2020).

The ﬁrst twenty years of agent-based software devel-

opment with JADE. Autonomous Agents and Multi-

Agent Systems, 34(36).

Bergenti, F. and Huhns, M. N. (2004). On the use of agents

as components of software systems. In Methodologies

and Software Engineering for Agent Systems, pages

19–31. Springer.

Bergenti, F., Monica, S., and Petrosino, G. (2018). A script-

ing language for practical agent-oriented program-

ming. In Proceedings of the 8

ACM SIGPLAN Inter-

national Workshop on Programming Based on Actors,

Agents, and Decentralized Control (AGERE 2018) at

ACM SIGPLAN Conference Systems, Programming,

Languages and Applications: Software for Humanity

(SPLASH 2018), pages 62–71. ACM.

Bergenti, F. and Petrosino, G. (2018). Overview of a script-

ing language for JADE-based multi-agent systems. In

Proceedings of the 19

Workshop “From Objects to

Agents” (WOA 2018), volume 2215 of CEUR Work-

shop Proceedings, pages 57–62. RWTH Aachen.

Bordini, R. H. and H

ubner, J. F. (2006). BDI agent pro-

gramming in AgentSpeak using Jason. In Proceedings

of the 6

International Workshop on Computational

Logic in Multi-Agent Systems (CLIMA 2005), vol-

ume 3900 of Lecture Notes in Artiﬁcial Intelligence.

Springer.

Bordini, R. H., H

ubner, J. F., and Wooldridge, M. (2007).

Programming multi-agent systems in AgentSpeak us-

ing Jason. Wiley Series in Agent Technology. John

Wiley & Sons.

Caire, G., Bellifemine, F., Trucco, T., and Rimassa, G.

(2010). Jade Administrator’s Guide. Available at

jade.tilab.com.

Collier, R. W., Russell, S., and Lillis, D. (2015). Re-

ﬂecting on agent programming with AgentSpeak(L).

In Lecture Notes in Computer Science, volume 9387.

Springer.

Dhaon, A. and Collier, R. (2014). Multiple inheritance

in AgentSpeak(L)-style programming languages. In

Proceedings of the 4

ACM SIGPLAN International

Workshop on Programming Based on Actors, Agents,

and Decentralized Control (AGERE 2014) at ACM

SIGPLAN Conference Systems, Programming, Lan-

guages and Applications: Software for Humanity

(SPLASH 2014).

Feraud, M. and Galland, S. (2017). First comparison

of SARL to other agent-programming languages and

frameworks. In Proceedings of the 8

International

Conference on Ambient Systems, Networks and Tech-

nologies (ANT 2017) and of the 7

International Con-

ference on Sustainable Energy Information Technol-

ogy (SEIT 2017), volume 109 of Procedia Computer

Science. Elsevier.

Genesereth, M. R. and Ketchpel, S. P. (1994). Software

agents. Communications of the ACM, 37(7):48–55.

Iotti, E., Petrosino, G., Monica, S., and Bergenti, F.

(2020). Exploratory experiments on programming au-

tonomous robots in Jadescript. In Proceedings of the

Workshop on Agents and Robots for Reliable Engi-

neered Autonomy (AREA 2020) at the European Con-

ference on Artiﬁcial Intelligence (ECAI 2020), volume

319 of Electronic Proceedings in Theoretical Com-

puter Science. Open Publishing Association.

Petrosino, G. and Bergenti, F. (2019). Extending message

handlers with pattern matching in the Jadescript pro-

gramming language. In Proceedings of the 20

Work-

shop “From Objects to Agents” (WOA 2019), volume

2404 of CEUR Workshop Proceedings, pages 113–

118. RWTH Aachen.

Petrosino, G., Iotti, E., Monica, S., and Bergenti, F. (2021).

Prototypes of productivity tools for the Jadescript pro-

gramming language. In Proceedings of the 22

Work-

shop “From Objects to Agents” (WOA 2021), volume

2963 of CEUR Workshop Proceedings, pages 14–28.

RWTH Aachen.

Petrosino, G., Iotti, E., Monica, S., and Bergenti, F. (2022a).

A description of the Jadescript type system. In Pro-

ceedings of the 3

International Conference on Dis-

tributed Artiﬁcial Intelligence (DAI 2022), volume

13170 of Lecture Notes in Computer Science, pages

206–220. Springer.

Petrosino, G., Monica, S., and Bergenti, F. (2022b). Robust

software agents with the jadescript programming lan-

guage. In Proceedings of the 23

Workshop “From

Objects to Agents” (WOA 2022), CEUR Workshop

Proceedings. RWTH Aachen.

Rao, A. S. (1996). AgentSpeak(L): BDI agents speak out

in a logical computable language. In MAAMAW 1996:

Agents Breaking Away, pages 42–55. Springer.

Rodriguez, S., Gaud, N., and Galland, S. (2014). SARL:

A general-purpose agent-oriented programming lan-

guage. In Proceedings of the IEEE/WIC/ACM Inter-

national Joint Conferences of Web Intelligence (WI

2014) and Intelligent Agent Technologies (IAT 2014),

volume 3, pages 103–110. IEEE.

ICAART 2023 - 15th International Conference on Agents and Artiﬁcial Intelligence

172