Changes in 0.15.1

Detailed Changes

1. SARL Development Toolkit (SDK)

• Fixing the invalid specification of the SyntheticEventConstructorMandatoryParameter annotation. [more details]

2. Eclipse Products

• Avoid class-not-found exception when creating a project folder from examples. [more details]
• Fixing the comparator of folder names. [more details]
• Adding the missed MPC plugin that causes the IDE generating errors. [more details]
• Update the examples' codes for following the best practices in coding. [more details]

Major Changes

Number of major changes: 4

Generation of implicit event constructors

In SARL, events are fundamental constructs for agent communication, often requiring explicit constructor definitions to initialize their fields. Prior to this change, developers had to manually define constructors for every event, even when the event's structure was simple or followed a predictable pattern. This manual process introduced several inefficiencies:

• Repetitive constructor definitions for events with standard field initializations.
• Manual constructor writing increased the risk of inconsistencies or omissions, especially in large codebases.
• Developers spent unnecessary time on repetitive tasks, detracting from core logic implementation.

To streamline event definition and improve developer productivity, SARL introduced automatic constructor generation for events. This feature:

• Infers Constructors from Field Declarations:

The compiler automatically generates constructors based on an event's declared fields, eliminating the need for manual implementation.
Example:

event MyEvent {
	var description : String
	var payload : double
}

The SARL compiler now automatically generates constructors that are equivalent to the following SARL code:

event MyEvent {
	var description : String
	var payload : double
	new (description : String = null, payload : double = 0.0) {
		this.description = description
		this.payload = payload
	}
}

Space API outside the Janus SRE

In earlier versions of SARL, the Space Implementation API was tightly coupled with the Janus SRE (SARL Runtime Environment). This design choice introduced several limitations:

• The API's integration within SRE-specific code restricted its reusability in alternative runtime environments or custom implementations.
• Developers could not leverage the Space API independently of SRE, limiting the portability of agent-based systems.
• Changes to the SRE could inadvertently affect the Space API, complicating updates and extensions.

These constraints hindered SARL's goal of providing a generic, modular, and runtime-agnostic agent programming framework.
To address these issues, the Space Implementation API was moved from the SRE codebase to the SARL SDK.
The Space API is now part of the SARL standard library, making it independent of any specific runtime environment.
The API was redesigned to rely on abstract interfaces and runtime-agnostic contracts, ensuring compatibility with any SARL-compliant environment. Key abstractions, such as Space and SpaceSpecification, are now defined in the SARL SDK, while concrete implementations (e.g., SRE-based) are provided as plugins or extensions.

Existing SRE-based applications continue to function seamlessly, as the SRE now implements the generic Space API rather than defining it.

Library for creating agent working memory

Agent-based systems often require temporary storage and efficient manipulation of data during their execution, particularly for tasks such as reasoning, decision-making, or maintaining contextual state.
Prior to this change, SARL lacked built-in utilities for managing such short-term data structures. Developers had to rely on ad-hoc solutions—such as custom collections or external libraries.

SARL 0.15 introduced a simple "working memory" utility toolset. The working memory utilities are directly accessible within agent behaviors with the WorkingMemory capacity, enabling seamless interaction with other SARL constructs. A default skill is provided for implementing the WorkingMemory capacity based on data structure that maps knowledge names (or identifiers) to their values.

Robust Type Checker for Type Parameters

SARL supports generic constructs, such as parameterized events, to enable flexible and reusable agent-based systems. However, prior to the recent update, SARL's type checking mechanism—built on the Xtext framework—lacked robust validation for type parameter conformance. This limitation led to several challenges:

• Insufficient compile-time validation of type parameters could result in undetected type mismatches, manifesting as runtime exceptions.
• Developers could not fully leverage advanced generic programming features, such as bounded polymorphism or variance annotations, due to the absence of a dedicated type conformance checker.

To overcome these limitations, SARL implemented a dedicated type checker that builds upon the existing Xtext framework. This enhanced checker ensures that generic type arguments adhere to their specified bounds (for example, T extends Number). Additionally, it validates conformance in subtype hierarchies and enforces correct type relationships within inheritance chains and interface implementations, including complex scenarios.

Detailed Changes

1. SARL Language

1.1. SARL Language and Grammar

• Add the automatic generation of events' constructors. [more details]
• Accept different syntaxes for the specification of a main function in a class. [more details]
• Remove references to protocol features in the SARL metamodel. [1, 2, 3]

1.2. SARL Validator

• Implementation of a robust type checker for type parameters' conformance. [more details]
• Ensure singleton for the provider of configurable issue severities. [more details]

1.3. Java Model Inferrer

• Enable the generation of multiple Java files from a single SARL construct. [more details]
• Introduce fragments in the code of the JvmModelInferrer for enabling eaiser extension and specialization of the inferring process. [1, 2]
• Avoid Null Pointer Exception when the supertype of a event in unspecified in the compiled code. [more details]

1.4. Programmatic Code Builder

• Code builder includes new function that take JVM type references as arguments in addition to the String names. [more details]
• Regenerate the code builders for SARL for fixing the support of type parameters. [1, 2]
• Avoid to create multiple XBlockExpression when calling the getter function of the code builder. [more details]
• Avoid NPE when retreiving the resource from an expression builder. [more details]
• Add tests of the support of type parameters by the code builders [more details]

1.5. Third-party Syntax Color Style

• Add configuration expansion macros in the SARL's TeX style for specifying font size of the SARL code. [more details]

2. SARL Development Toolkit (SDK)

• Add the library for creating an agent "working memory". [more details]
• Move the space implementation API from the SRE code to the SARL API to be more generic and SRE-independent. [1, 2]
• Add the function injectMembers(Object) in the SRE utility class to enable to inject the SRE-dependent objects. [more details]
• Add the class MutableOptional. [more details]

3. Eclipse Products

• Avoid duplicate source folders when SARL and project extension have the same folders. [more details]
• Decrease the memory footprint for the SARL image provider. [more details]
• Fixing the implementation type of the default SARL editor in the plugin definition. [more details]
• Remove uncessary event constructors from the embedded examples. [more details]
• Remove references to protocol features in the standard SARL UI and Eclipse plugins. [1, 2]
• Use of the new code builder API in the Eclipse wizard when generating SARL files. [more details]
• Disable the warning related to the usage of javax inject annot...

Major Changes

Number of major changes: 4

Definition of Type Parameters for Events

Generics are a facility of generic programming that were added in several programming languages such as Java.
They were designed to extend SARL type system to allow "a type or method to operate on objects of various types while providing compile-time type safety".

A type parameter is an unqualified identifier.
Type parameters are introduced by generic declarations, e.g. of events, classes, interfaces or actions/methods.

A event is generic if it declares one or more type parameters.
A generic event declaration defines a set of parameterized types, one for each possible invocation of the type parameter section.
All of these parameterized types share the same class at runtime.

Documentation: in official documentation

Change details: 1, 2, 3, 4, 5, 6

Transition from Java 17 to Java 21

Since the beginning of its life, SARL supports version 8 (before 2021) and 17 (after 2021) of Java.
However, several modules from Eclipse are now requiring the version 21 of Java.
Consequently, the SARL development team as decided in 2024 to apply to SARL a transition from Java 17 to Java 21.

Version 0.14.0 requires Java 21 as a minimum requirement.

New Product for MacOS Silicon

From version 0.14.0 of SARL, a new OS architecture is officially supported: MacOS Silicon on ARM architecture.
In additional to the previous products for Linux, Windows and MacOS on Intel, the product for MacOS on ARM (Silicon) is now available for download. [more details]

Make easier the scoping of emitted events

From the SARL API, it is possible to scope the receivers of SARL events, with a guard associated to the emit function.
For example, the following code emit the event MyEvent only to the agents that have there identifier equals to the identifier value.

emit(new MyEvent) [it.UUID == value]

To make the scope coding more easy, operators have been introduction for comparing Address (the argument of the scope) to UUID value, and for comparing Address to SpaceID. Therefore the previous code could be simplified to:

emit(new MyEvent) [it == value]

Detailed Changes

1. SARL Language

1.1. SARL Language and Grammar

• Events could be defined with generic type parameters. [more details]
• Implementation of generic events in the event bus of the Janus SRE. [more details]
• Reserve the keyword "protocol" for futur usage. [more details]
• Fixing NPE in MWE2 code builder generator. [more details]

1.2. SARL Validator

• Events could be defined with generic type parameters. Add warning messages related to the use of generic type parameters in events. These messages are related to the code efficiency that is assumed to be lower than for not-generic events. [more details]
• Add missed check of generic arguments when extending a generic super type (class, interface). [more details]

1.3. Java Model Inferrer

• Events could be defined with generic type parameters. Generate specific Java code for generic events. [more details]
• Avoid NPE when the JVM model is partially generated by the model inferrer. [more details]

2. SARL Development Toolkit (SDK)

• Add operator for comparing Address and UUID, and Address and SpaceID. [more details]

3. SARL User Interface

3.1. Eclipse Products

• Enable the building of the macOS product for Apple Silicon. [more details]
• Include the Java Runtime Environment (JRE) in the SARL Eclipse products. [more details]
• Avoid exceptions due to unlinked editors. [more details]
• Activate the SARL debug perspective when a SARL program is suspended for debug. [more details]
• Fixing the links to the examples' wizards from the welcome page. [more details]
• The information in the "about texts" are injected from the global properties from the BOM. [more details]

4. Janus Run-time Environment

• Implementation of generic events in the event bus of the Janus SRE. [more details]

5. Command-Line Tools

5.1. janus

• Add more command line options for selecting the type of JVM executor service. [more details]

6. SARL Documentation

6.1. Documentation of the SARL SDK

• Fixing document for the definition of generic events. [1, 2]

6.2. Documentation of tutorials

• Add exercises:
  • Basics of SARL syntax. [more details]
• Fixing the documentation of the TGOB library. [more details]
• Fixing the URL to the source code in the examples' documentations. [more details]

7. Tools for SARL Contributors

• Fixing security alert about http connexion. [1, 2, 3, 4, 5, 6, 7]
• Add scripts for updated the hard-coded versions of maven plugins. [more details]
• Code quality:
  • Fixing code for removing warnings on boxing and outboxing. [more details]
• CodeQL Action on Github:
  • Add cache in CodeQL setup. [more details]
  • Upgrade versions of actions in CodeQL setup. [1, 2]
  • Create codeql.yml [more details]
• The API documentation is fixed. [more details]
• Upgrade major libraries:
  • Java 21: Apply Java 14 syntax for var and instanceof constructs. [more details]
  • Eclipse 2024-06. [1, 2]
  • Xtext 2.36.0 [1, 2, 3, 4, 5, 6, 7, 8, 9]
  • Maven 3.9.9.

Major Changes

Number of major changes: 3

Transition from Java 8 to Java 17

Since the beginning of its life, SARL supports version 8 of Java.
However, Java has considerably evolved during the past decade; And the lastest long-time-support version of Java is 17.
New features have been added and enhancements have been made since Java 8.
These features and enhancements improve startup, performance, memory usage, and provide better integration with containers.
Moreover, the recent tools such as Eclipse and Xtext require to use at least the version 17 of Java to have benefits of the feature enhancements and bug fixes.

Consequently, the SARL development team as decided in 2021 to apply to SARL a transition from Java 8 to Java 17.
Moving from Java 8 to Java 17 was a significant amount of work (approximatively 18 months) and will apply major changes in all the SARL projects.

Version 0.13.0 requires Java 17 as a minimum requirement.

Many the modules and artifacts of SARL have change of their names to obtain a unified naming convention that is also compatible with those that must be used for Java modules.

Details: [1, 2, 3, 4, 5, 6, 7, 8, 9].

Novel SARL Project Structure

Since few years, contributors to SARL notify the high complexity of the SARL project structure.
It was almost impossible to compile a sub-project of SARL without downloading and compiling all the sub-projects.

The transition from Java 8 to Java 17 gives us the opportunity to rethink the structure of the SARL project and its sub-projects.
There is not any more a single project for all SARL (with its associated root pom file).
The SARL project is splitted into different sub-projects that may be compiled independently.
Each project is dedicated to a specific set of features and tools. These sub-projects are:

• sarl-bom: Provide the Build-of-Material, i.e., a shared list of Maven dependency, for all the SARL sub-projects;
• sarl-baseutils: Set of Maven artifacts that are independent of SARL but needed to build the SARL artifacts;
• sarl-lang: Provides the language definition, the associated compiler (including the Maven plugin) and code formatting styles for different text editors;
• sarl-sdk: Set of Maven artifacts that constitute the SDK for all the SARL developers;
• sarl-apputils: Shared projects for building applications that are using a SARL compiler;
• sarl-sre: SARL runtime environment (or SARL virtual machine);
• sarl-docs: Tools and Doclet for the generation of the documentation, including the API documentation pages;
• sarl-cli: Set of command-line tools (sarlc, sarldoc, janus...);
• sarl-eclipse: Eclipse-based editor for SARL;
• sarl-officialdoc: Markdown files of the official documentation of SARL.

Integration of a Goal-oriented Behavior in the SARL API

The SARL Standard Development Kit (SDK) includes a novel API dedicated to time-based goal-oriented behaviors.
Goal-Oriented Behavior (GOB) is a general term that covers any technique taking into account goals of the agents.
GOB is not supported by a single technique.
This new feature of the SARL API corresponds to a standard GOB that is used in video game applications.
This API equips the agents with an action selection mechanism to select the best action to be realized for archieving one of the agent goals.

Documentation: SARL website

Detailed Changes

1. SARL Language

1.1. SARL Language and Grammar

• Enable the static modifier for the members of agent-oriented type declarations. [more details]
• Add automatic variable converters from Object type to base/native types. [more details]

1.2. SARL Validator

• When the unary minus operator and a call to an extension method are used in the same expression, the operational semantic of this expression may be not the one expected by the developper, e.g., -2.abs. In the example, according to the priorities of the SARL operators, it must be interpreted as -abs(2) == -2. However, some developper could misinterpret this expression as abs(-2) == 2. When this type of expression is found in the code, the SARL compiler generates a warning to notify the deveopper that he/she may have not coded the correct expression. [more details]

1.3. Java Model Inferrer

• The detector of pure functions that is embedded in SARL may cause a stack-overflow error when it is analysis a recursive function. The code of the detector was rewritten to avoid this error. [more details]
• Several null-pointer exception were fixed in the SARL compiler. [1, more details, 3, 4]
• Do not generate import statements for types that are declared in the default package. [more details]

1.4. SARL Batch Compiler

• Add an option for converting the warnings to errors. [more details]

2. SARL Development Toolkit (SDK)

• Add in the SARL API an implementation of the time-based goal-oriented behavior that is used in video games. [more details]

3. SARL User Interface

3.1. Eclipse Products

• Fixing the classpath containers of SARL and Janus for devel and release versions of the IDE. [more details]

3.2. Maven Integration in Eclipse

• Fixing the m2e configurator to properly set the classpath for a SARL project. [more details]
• Integration tests are usually coded in the source folder src/it. These folders are now supported by the SARL m2e plugin and automatically created. [more details]

3.3. Launching Configurations

• Ensure that the classpaths that are used for launching an application in the Eclipse IDE contain unique bundle entries. [more details]

3.4. Preferences

• When the SRE is preinstalled in the Eclipse IDE (as it is the case for Janus), the property page associated to this SRE must not allow to change the name and location of the SRE. A read-only editing page for the preinstalled SRE's properties has been included in the Eclipse products. [more details]
• When the page for editing the SRE properties cannot be created, an error message is shown in a dialog box. [more details]

3.5. Wizards

• In the dialog box that permits to create a SARL Maven project, the box "Create simple Maven project" is now selected by default. [more details]
• When a SARL Maven project is created, the wizard creates by default the all folders for SARL code. [more details]

3.6. Other UI Components

• The Xtext editor that is used for editing SARL code is extended to avoid null-pointer exception and the loose of the link between the SARL file and the editor. [1, 2]
• Fixing the condition for enabling the popup-menu action dedicated to the transformation of a regular SARL project to SARL Maven project. [more details]
• The Java package explorer is located in the bottom panel. [more details]
• Add onboarding images in SARL perspectives. [[1](http://sarl.io/sarl/sarl/commit/9ae9702068576257f3b28...

1. Major Changes

Number of major changes: 4.

1.1. Enable static and instance features in the parameters' default values

SARL allows you to specify a default value for a formal parameter of a function or a constructor.
When a default value is specified, it means that the caller of the action can skip passing a value for the corresponding argument. And, when the function is called, the default value is given to the skipped argument.

Up to the version 0.11 of SARL, the expressions that constitute the default values must reference static or constant expressions, and these features must not have border effect.

Since the version 0.12 of SARL, the first restriction is no more applied. Consequently, the default value expression could reference either static and instance features (1, 2). The constraint on the feature's border effects is still valid.

For example, the following code is valid in SARL:

agent A {

	var aField : int

	def aFunction(p : int = aField) {
	}

}

It means that the value of the p parameter is the value of the aField field when the aFunction function is invoked.

1.2. Add "abstract" into the modifiers for events

The abstract modifier is added into the list of the accepted modifiers for a SARL event (details). For example, the following code defines an abstract event with name A:

abstract event A

An abstract event is an event that cannot be instantiated, but it can be derived. When an abstract event is derived, the subtype usually provides constructors that are compatible with the super type's constructor.

1.3. Agent Error Handling

In SARL, as for the Akka actor framework, there is an important distinction between failures and validation errors:

• A validation error means that the data of a command sent to an agent is not valid, e.g. an unexpected event according to a communication protocol. This should rather be modelled as a part of the agent protocol than make the agent throw exceptions.
• A failure is instead something unexpected or outside the control of the agent itself, for example a database connection that brokes. Opposite to validation errors, it is seldom useful to model such as parts of the protocol as a sending agent very seldom can do anything useful about it.

In order to make the agent able to react to failures, the SARL API defines a specific event that is representing any failure or validation error that the agent could handle if it is interested by: Failure.
Each time an agent needs to be notified about a fault (into its agent tasks for example), an occurrence of this event type is fired in the internal context of the agent.

Several failure events are pre-defined in the SARL API:

• AgentKillFailure: when the agent killing cannot be realized (the major cause of a killing failure is the fact that the agent to be killed contains sub-agents).
• TaskFailure: when an agent task (managed by the Schedules capacity) has failed.

Also, the AgentKilled event has been updated in order to provide the cause of the agent's killing.

Finally, the SARL API provides tools for propagating failures in the hierarchy of agents, to the parents and to the children.

1.4. Agent Observation and Probing

The multi-agent system is composed of multiple elements, including agents, behaviors, contexts and spaces, but not limited to. Organizational models in multi-agent systems usually position agents as actors-observers within environments shared by multiple agents and organizational structures at different levels of granularity. Then, the agents may have the capacity to observe the environment and the other agents, without directly interacting with them. The observing agent is able to extract information from another agent or from a society of agents, that could be opaque according to a possible holonic architecture of the system.

Observation means that data or information could be extracted from the observed object without filtering from this latter. The observer is not intrusive from the agent point of view. In other words, the observed agent has no knowledge about the fact it is observed or not. In this case, it cannot adapt its behavior on its observation status.

An observation mecanism was defined into the Janus SRE. Since the version 0.12 of SARL, this observation mecanism is moved into the SARL SDK and transformed as an API that is independent to the SRE (1, 2, 3).
In the same set of commits, the naming service for the multiagent system components has been moved from the Janus SRE to the SARL DSK.

Because an agent is defined as an autonomous entity, the agent is supposed to be able to specify if a part of itself is observable or not, i.e. to specify the access rights to its fields.
The concepts of "observable" and "not observable" field are introduced in SARL 0.12 (1, 2).

This observability flag could be defined statically by annotating the observable field, or one of its enclosing type, with the @Observable annotation. The second method is to implement a dedicated agent skill implementing the capacity FieldAccessValidationCapacity that enables the agent to manage the access rights to its fields dynamically.

2. Other Changes

2.1. SARL Programming Language

2.1.1. SARL Language

a) Detection of pure functions

• The following function names are considered as standard names for pure functions (1, 2): abs,acos, cos, asin, sin, atan, atan2, cbrt, ceil, compare, compareTo, cosh, empty*, exp, floor, hypot, log, log10, log1p, max, min, pow, random, rint, round, signum, signh, sqrt, tan, tanh, ulp.
• The functions toString(JsonBuffer) was marked as pure but it has border effects. The Pure annotation is removed from the function (details).

b) Detection of immutable objects

• SARL compiler knows that objects of specific types are immutables, i.e. they cannot be modified. This immutability of objects is used in order to determine if an code expression has border effects or not, and possibly generate an error message when a border effect cannot be accepted.
• The following types have been added into the list of the immutable types (1, 2): Annotation, Boolean, Byte, Character, Clock, Double, Duration, Event, Float, Instant, Integer, LocalDate, LocalDateTime, Long, MonthDay, OffsetDataTime, OffsetTime, Pair, Period, Permission, Short, Year, YearMonth, ZoneDataTime, ZoneId, ZoneOffset.
• Any type that is marked with the @Data annotation is implicitly considered as immutable (details).

c) Automatic object conversions

• An Unique Universal IDentifier (UUID) may be represented by a string of characters or by an instance of the SARL/Java type UUID. The SARL compiler is able to do an automatic conversion from a string of characters to UUID, and from an UUID to a string of characters (details).
• The SARL compiler is able to do an automatic conversion from a string of characters to a number and from a number to a string of characters (details).

d) Annotations of code

• Add the annotation @SarlAsynchronousExecution into the language API in order to help the SARL editor to show up the calls to functions that are run asynchronously (details). This annotation has no effect at run-time by itself. It is only a marker for the SARL code editing purpose.
• Replace the annotation @IssueOnCall by @ErrorOnCall, @WarningOnCall and @InfoOnCall (details). These annotations are used by the SARL compiler for generating an error, warning or information message when the annoted feature is invoked.

2.1.2. SARL Validator

• Generate an error when a generic-type parameter is hiding another generic-type parameter (details).
• Do not warn if a called feature on occurrence is considered as an immutable object ([details](http://github....

1. Major Changes

Number of major changes: 4.

1.1. Janus version 3

Janus is the official SARL run-time environment (aka. SARL virtual machine).
This release of SARL provides a MAJOR NEW IMPLEMENTATION of Janus with its version 3.

In the past, the change from version 1 to version 2 was due to a total re-implementation of Janus in order to follow and support the SARL metamodel.
This time, Version 3 of Janus is a total re-implementation with the SARL language, i.e. we have written the code with SARL not anymore with Java.

The major benefits of the new implementation with the SARL language are:

• Direct usage of the SARL concepts and statements;
• Ability to generate the same SRE to different target platforms (Java, Python, etc.);
• Proof-of-concept related to the capabilities of the SARL language to cover complex application's implementation.

In addition to the total re-implementation with SARL language, the software architecture of Janus was re-thinking and optimized in order to improve the global run-time performances of the SRE, and to be more modular in order to extend modules of Janus with new third-party modules (based on Bootique modules).

1.2. New types of participants in spaces

From the SARL metamodel, spaces are entities in which the agents are able to interact or communicate.
The agents that are part of a space are named participants.

From our experience during the past years, different types of participants may be involved into a space.
First, the agents constitute the largest part of these participants.
Second, external software, such as an graphical user interface (GUI), may have to listen for events or emit them into a space in order to setup an interaction with the agents.

Nevertheless, having only a single type of participant defined causes issues into the SARL run-time environment (SRE) when it is time to decide if a space should be destroyed or not. Indeed, the SRE is in charge of destroying the spaces when they are not used anymore (usually when there is no more agent inside).

A problem occurs when all the agents have leaved the space, and only GUI remain. In this case, the SRE was not able to detect this case and to destroy the space. This issue could be seen because the SRE never stops to run, even when all the agents were killed.

In order to solve this issue, two types of participants are defined:

• Strong Participant: it corresponds to the regular meaning of a participant (and the default one). When a strong participant is involved into a space, the SRE cannot destroy the space. Typical strong participants are the application agents.
• Weak Participant: it is a participant that is considered as optional by the SRE. In order words, when a space has only weak participants, it is considered as releasable by the SRE. Typical weak participants are GUI objects.

Whatever the type of participant, they have the same level of abilities for using the space. For example, in the case of an event space, the strong and weak participants have all the abilities to emit events, and receive them.

1.3. New agent spawning API

The spawning functions of the agents have encountered a big change: they are not replying anymore the unique identifier of the just spawned agents. Now, the spawning functions return void.

This change was forced by the need to execute in parallel the different spawning processes when multiple agents are spawned at the same time. In this case, it is almost impossible to retreive the unique identifiers of the agents before returning from the spawning function.

In order to use the unique identifier of the just spawned agent after the call to the spawning function, the new guideline is to generate the identifier, give it to the spawning function, and use it after, as illustrated by the following example:

var agentIdentifier = UUID::randomUUID
typeof(MyAgentType).spawnInContextWithID(defaultContext, agentIdentifier)
doSomething(agentIdentifier)

1.4. New tool for SARL contributors: an Eclipse DSL with embedded SARL

In past, it was not so easy to install and set-up an complete and working development environment for the SARL contributors. It was due to the usage of different technologies such as Eclipse DSL, Java, Maven and Xtext.

In order to have a ready-to-use environment, as much as possible, a specific Eclipse product is now available into the SARL project: sarl-dsl.
This new product includes:

• Regular Eclipse framework for domain specific language implementation, that includes:
  • Eclipse environment,
  • Java development environment,
  • Maven integration into Eclipse, and
  • Xtext libraries;
• SARL compiler integration into Eclipse;
• Janus run-time environment;
• Eclipse Checkstyle.

2. Detailed Changes

2.1. SARL Language

2.1.1. SARL Language Grammar

• Add specific Java cast into the generated Java code for avoiding compilation error (1, 2).
• Remove any reference to Eclipse JDT from io.sarl.lang module (1, 2).
• Change the generation of hashCode and equals to avoid null pointer exception when running them into the SRE (details).

2.1.2. SARL Core Library

• All:
  • Removing all locks and synchronized collections (1, 2, 3, 4, 5)
• Spaces:
  • Add the concepts of strong and weak participants into the spaces (1, 2, 3, 4). Both of these types correspond to participants into a space. When a space has at least one strong participant, it cannot be destroyed and removed from the ststem. When a space has only weak participants, it could be removed from the system. A typical strong participants may be a regular agent. And, a typical weak participants may be an user interface that is interacting with agents.
  • Remove the deprecated spaces implementation (details).
• Bootstrap:
  • Add observer on the SRE start and stop (details).
  • Remove the function getBootAgentId from the SARL programmatic bootstrap (details).
  • Add a timeout parameter to the shutdown function of the SRE bootstrap (details).
• Events:
  • Fixing the invalid value for the field parentContentId of the MemberJoined event (details).
  • Fixing the invalid value of the Memberleft source (details).
• Agent:
  • Add the function setSkillIfAbsent into the Agent API (details).
  • When the skill references were cleared from any part of the agent, the getSkill function of the
    agent does not thrown UnimplementedCapacityException exception anymore (details).
  • Updating skill management with a conccurent set/queue instead of a non-thread safe implementation (details).
• Skill:
  • Tuning the skill uninstallation process to prevent null pointer exception (details).
  • Introduce a new class for representing a skill containe, and update the skill lifecycle accordingly (details).
• Agent Tasks:
  • Force the agent tasks to have a not-empty name (details).
  • Tuning the every tasks stopping process (details).
• Address:
  • Rename the field agentId to participantId into the Address class (details).
• Others:
  • Make as volatile the field that may contain internal SRE data into the SRESpecificDataContainer class (details). This change enables a better synchronization of the attached SRE data's field when it is accessed from multiple threads.
  • Make the ClearableReference atomic (details).

2.2. SARL Development Toolkit (SDK)

2.2.1 Core Library

• Remove the returned addresses from the spawning functions ([details](http://github.com/sarl/sarl/commit/e5b335f9d1fd4...

• Fixing the invalid building of the classpath URL on Windows operating systems (details).

1. Major Changes

Number of major changes : 8

1.1. Support of Java 11

The entire SARL project was tested against the versions 8 and 11 of Java.
The version 8 must still be used for running the SARL DSL Environment in order to create SARL libraries that could be used on a JRE 1.8.

For application developers who are using SARL, they could use either Java 8 or Java 11 for running the SARL Development environment, or
the SARL applications that are the result of the SARL compilation.

1.2. Try-with-resources

The try-with-resources statement is a try statement that declares one or more resources.
A resource is an object that must be closed after the program is finished with it.
The try-with-resources statement ensures that each resource is closed at the end of the statement.
Any object that implements AutoCloseable, which includes all objects which implement Closeable, can be used as a resource.

The following example reads the first line from a file. It uses an instance of BufferedReader to read data from the file.
BufferedReader is a resource that must be closed after the program is finished with it:

def readFirstLineFromFile(path : String) : String {
	try (var br = new BufferedReader(new FileReader(path))) {
		return br.readLine
	}
}

In this example, the resource declared in the try-with-resources statement is a BufferedReader.
The declaration statement appears within parentheses immediately after the try keyword.
The class BufferedReader, inherited from Java libraries, implements the interface AutoCloseable.
Because the BufferedReader instance is declared in a try-with-resource statement, it will be closed regardless of
whether the try statement completes normally or abruptly.

1.3. Implicit Names for Lambda Formal Parameters

When a lambda (also known as closure) has multiple parameters, and no name is provided by the SARL developer, the SARL compiler in its previous version generates an error because it was able to consider only it as an implicitly declared variable, i.e. there was too many implicit parameter to declare by the compiler and it cannot do that.

In its version 0.10, the SARL compiler is able to a generate default name for each of the formal parameters of a lambda, even if there are multiple unnamed parameters.
The implicit name for the first parameter becomes $0, $1 for the second, $2 for the third, etc.

The example below shows the definition of an interface, a class that is calling an instance of the previous interface, and a piece of code that is invoking the class.
It is interesting to note that the arguments' values of the lambda expressions are accessed with their implicit names.

interface MyInterface {
	def a(a : int, b : char, c : String)
}

class MyClass {
	def b(lambda : MyInterface) {
		lambda.a(1, '2', "3")
	}
}

var i = new Myclass
i.b [
	println($0)
	println($1)
	println($2)
]

1.4. Introduction of the two events ParticipantJoined and ParticipantLeft

The events ParticipantJoined and ParticipantLeft are introduced.
The first is fired when an agent has joined a space that has participants, e.g. an event space.
The second is fired when an agent has left a space.

1.5. Better Concurrent Execution with Read-Write Locks

The uses of mutual exclusion locks were replaced by similar uses of read-write locks.

A read-write lock maintains a pair of associated locks, one for read-only operations and one for writing.
The read lock may be held simultaneously by multiple reader threads, so long as there are no writers.
The write lock is exclusive.
The read-write lock implementation guarantees that the memory synchronization effects of writeLock operations also hold with respect to the associated readLock.
That is, a thread successfully acquiring the read lock will see all updates made upon previous release of the write lock.

A read-write lock allows for a greater level of concurrency in accessing shared data than that permitted by a mutual exclusion lock.
It exploits the fact that while only a single thread at a time (a writer thread) can modify the shared data, in many cases any number of threads can
concurrently read the data (hence reader threads). In theory, the increase in concurrency permitted by the use of a read-write lock will lead to
performance improvements over the use of a mutual exclusion lock.

1.6. Tool for generating the API documentation

Sarldoc is a documentation generator for the SARL language for generating API documentation in HTML format from SARL source code.
The HTML format is used for adding the convenience of being able to hyperlink related documents together.
To pass source code to sarldoc, you have to provide the names of the folders in which the SARL code files are located.
Then, the sarldoc tool generates a set of HTML files that contains the API documentation of your program.

1.7. Performance improvements

The SARL compiler was reviewed in order to remove several memory leaks that cause low performances when compiling large number of SARL files. Even if this task is always active, several improvements have been obtained in this version of SARL.

1.8. New demonstration: the Reynold's Boids

Boids is an artificial life program, developed by Craig Reynolds in 1986, which simulates the flocking behaviour of birds. The name "boid" corresponds to a shortened version of "bird-oid object", which refers to a bird-like object.
As with most artificial life simulations, Boids is an example of emergent behavior; that is, the complexity of Boids arises from the interaction of individual agents (the boids, in this case) adhering to a set of simple rules. The rules applied in the simplest Boids world are as follows:

• separation: steer to avoid crowding local flockmates;
• alignment: steer towards the average heading of local flockmates;
• cohesion: steer to move toward the average position (center of mass) of local flockmates.

The SARL development environment provides an implementation of the Reynold's Boids within the set of available "examples."
This version of the Boids is implemented with the Java AWT graphical library.

2. Detailed Changes

2.1. SARL Language

2.1.1. SARL Syntax

• Add support for try-with-resource statements (details).
• When a lambda has multiple parameters, and no name is provided by the SARL developer, the compiler generates default names for each of the formal parameters. The implicit name for the first parameter is $0, $1 for the second, $2 for the third, etc. (details).
• throw becomes a statement that has side effect (details).

2.1.2. SARL Validator

• Use read-write locks in place of the mutual exclusion locks (1, 2).
• Avoid the generation of "possible side-effect on occurrence" when occurrence is used within complex expressions (details).
• Change the texts associated to the warnings on the possible invalid usage of occurrence (details). The meaning of previous error message was not enough clear to the SARL developers. The message is refactored in order to be more explicit and clear.
• Remove the search of the Xtext library on the classpath when validating (details).
• Allow to ignore warnings related to raw types (details).

2.1.3. Java Model Inferrer

• Use read-write locks in place of the mutual exclusion locks (details).
• Avoid memory leaks caused due to cyclic references in the action prototype provider (1, 2).
• Add release() function in the GenerationContext type in order to limit memory leaks (details).
• Use string representations for the SARL version (details). The version of SARL was stored into a floating-point number. This approach was fine until the version becomes 0.10. With this version number, it is impossible to make the difference between 0.1 and 0.10.
• Fixing the automatic annotation related to the purity of the function (details).

2.1.4. SARL Core Library

• Use read-write locks in place of the mutual exclusion locks (details).
• Events:
  • Add the events ParticipantJoined and ParticipantLeft, and the associated supported into the SRE (details).
• Context:
  • Updating the documentation of getOrCreateSpaceWithSpec in order to indicate that the default space is ignored (details).
• Annotations:
  • Enable the DefaultSkill annotation ([details](http://github.com/sarl/sarl/commit...

1. SARL Language

1.1. SARL Language Grammar

• Major upgrades:
  • Upgrade to Xtext 2.17.1 (1, 2, 3). This version of Xtext provides better performances. It is also fixing issues related to the Xtext editor.
• Upgrade to Eclipse 2019-03 (details). See major implications of this upgrade.
• Operators:
  • Add overriding of the cast operator (1, 2, 3): it is now possible to create overriding functions that may be invoked when the as operator is used and the standard casting behavior cannot be applied. Several casting operations are predefined for convertings numbers and strings.
• Active Annotations:
  • Enable active annotations on SARL type declarations. (details)
• References to it into the closures/lambdas:
  • Bug fix: implicit references to it into the closures are not causing serialisation issues, e.g. when the lambda is embedded into an event as the scope of this event. (details)
  • Bug fix: avoid infinite loop when searching for it references into the lambda expressions (details).

1.2. SARL Validator

• The validator warns only when a event firing declaration does not concern an early-exit event. (details)
• The warning "unused function" is not any more generated when a function is invoked with one of its arguments with a default values (details).

1.3. Java Model Inferrer

• Avoid Java error when using it variable into the serializable lambdas. (details)
• Make the generation of the type members faster. (details)
• Ignoring files without Xtext content during the generation of the Java code (details).

2. SARL Development Toolkit (SDK)

2.1. New Features

• Add casting operators for:
  • strings and numbers (details).
  • strings and booleans (details).
  • Big numbers (details).
• Bootstrap API:
  • add functions into the Bootstrap API (details): setSpecificContextUUID, setUniverseContextUUID, getUniverseContextUUID, setUniverseSpaceUUID and getUniverseSpaceUUID.
  • deprecate setDefaultContextUUID (details).

2.2. Time Extension

• Replace the numeric constants into the inline expressions of the time extension by the corresponding static constants (details).

3. Eclipse Product

3.1. Multi-platform Configurations

• Removing all the support for x86 architectures (details). These architectures are not any more supported by the Eclipse framework. Consequently, these is not any more a SARL product for the 32-bit platforms.

3.2. UI Components

• Add the action "Convert to SARL Maven Project" into the pop-up menu on a project (details). This option enables to convert a standard SARL project into its equivalent Maven SARL project.
• Do not display the editor's inconsistent state when the editor is dirty (details). This small update is a first answer to the old issue related to the inconsistent state of the editor comparing to the rest of the widgets (errors are appearing into the editor and not into the other widgets).

4. External Contributions to SARL: Examples

• Fixing the Sierpinski fractal demo in order to follow the recent evolution of the SARL syntax (details).

5. Janus Run-time Environment

• Allow cancellation of scheduled tasks before any future object is not provided by the Java thread manager (details). The cancellation is buffered until the future object is provided by the Java thread manager. At this time the task is automatically cancelled.
• Upgrade to ZeroMQ 0.5.0 (details).
• Upgrade to Hazelcast 3.11.2 (details).

6. Maven Tools

• The batch compiler must not fail when only warnings were found into the compiled SARL code (details).

7. SARL Documentation

7.1. Documentation of the SARL Language

• Complete the documentation on the casting features (details).

7.2. FAQ

• Add FAQ questions from the Sebastian Sardina's FAQ. (details)
• Add FAQ for creating a project from a typical example of application (details).

7.3. Documentation of SARL Code

• Add a documentation that explain how to create an API documentation for the SARL code, as Javadoc is doing for any Java code (details).

8. Tools for SARL Contributors

• Removing support for x86 architectures because Eclipse 2019-03 is not any more supporting them (details).
• Upgrade to Maven API 3.6.0 (details).
• Upgrade to Tycho 1.3.0 (1, 2). Add Tycho compiler options into the Maven pom file (details).
• Upgrade Arakhne libraries to version 15.2 (details).
• In the massive testing API, replacing the hard-coded \n by System.lineSeparator() to avoid errors on Windows (details).
• Removing reference to org.eclipse.equinox.ds, and replacing it by `org.apache.felix.scr (details).