---
schema_version: "1"
id: b8a872a8333b64914ad96b48ea5ff489bf7487f6a5678aa5cc080aeef8fd290c
title: What’s New in Mule 4
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/4.3/mule-runtime-updates.md
canonical_url: https://docs.mulesoft.com/mule-runtime/4.3/mule-runtime-updates
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 4430d703e97709d49fd8bc2d961e28326f8e3bfd9e98814094d847ab8d6c526b
description: MuleSoft Documentation Site
release: "4.3"
latest: false
---
---
product: Mule Runtime
version: 4.3
keywords: news, updates, mule ESB, mule runtime, 4.0, Mule 4.0, Mule 4.0 for mule 3 developers, what's new Mule 4
---

# What’s New in Mule 4

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Mule 4’s simplified language and reduced management complexity enables you to speed up the on
ramping process and deliver applications faster.

If you are familiar with the concepts of the previous versions of the runtime, check the sections
below to learn what’s changing in Mule Runtime v4.0.

## Simplified Event and Message Model

Mule 4 includes a simplified Mule Event and Message model. In Mule 4, Flows are triggered by an
Event. An Event has a Message and variables associated with it. A Message is composed of a payload
and its attributes (metadata, such as file size). Variables hold arbitrary information, such as
Messages, payload data, or attributes. This simplified message model makes it easier to work with
data in a consistent way across connectors without information being overwritten.

## DataWeave 2.0: The New Mule Expression Language

In Mule 3, users had to contend with learning both the Mule Expression Language (MEL) and DataWeave.
MEL forced users to convert their payloads from binary data, such as XML or JSON documents, into
Java objects, so they could write expressions which access that data, for example when routing to a
specific location.

In **Mule 4**, DataWeave is now the default expression language. Combined with the built-in
streaming capabilities, this simplifies many common tasks:

- Events can be routed based on payload data, without first needing to convert them to Java objects.

- Binary data can easily be queried from an expression anywhere in your flow, for example, when
  logging.

- Larger than memory access to data happens transparently.

DataWeave 2.0 also features many improvements:

- Language simplifications. Everything is now a function.

- DataWeave scripts can now be packaged and reused, via the new imports and modules features.

- Support for multi-line comments.

- Support for calling static Java methods directly from DataWeave.

For details, see the links to [DataWeave documentation](#see_also).

## Streaming Management

Mule 4 automatically handles data streams for users. This greatly simplifies working with data in
the runtime because:

- Data can be read multiple times or accessed randomly using the DataWeave expression language
  without side effects.

- Data can be sent to multiple places, without the user caching that data in memory first.

- Users can transparently access larger than memory data.

- Users can customize whether data is stored on disk using streaming strategies.

## Non-Blocking, Self-Tuning Runtime

Mule 4 includes a new execution engine that is based on a non-blocking runtime. This is a
task-oriented execution model allowing you to take advantage of non-blocking IO calls and avoid
performance problems due to incorrect processing strategy configurations.

As a result of this new engine, you no longer have to configure exchange patterns. Instead, flows
always function synchronously. If you wish to achieve asynchronous type patterns such as fire and
forget, you can use the `<async>` processor.

Each Mule event processor can now inform the runtime if it is a CPU intensive, CPU light, or IO
intensive operation. This helps the runtime to self-tune for different workloads dynamically,
removing the need for you to manage thread pools manually. As a result, Mule 4 removes complex
tuning requirements to achieve optimum performance.

## Enrich Events Directly from Connectors/Modules

For any given module operation, it is now possible to define a target (or target variable), which
saves the result in a variable:

```xml
<http:request target="myVar" config-ref="requestConfig" method="GET" url="http://mulesoft.com"/>
```

This saves the Mule message in the `myVar` variable to be accessed later. This reduces flow
complexity by removing the need for an enricher.

You can also control what is stored in the variable using the targetValue attribute. For example, if
you wanted to only store the response code from an HTTP request, you could do the following:

```xml
<http:request target="myVar" targetValue="#[attributes.statusCode]" .../>
```

## Simplified Connectors and Modules Experience

Mule 4 introduces more consistency around modules and connectors, creating one unified experience
for how to interact with Mule components.

Transports have been completely replaced by Mule Modules. Modules and connectors can be created and
managed using the Mule SDK, which provides a single way to extend Mule.

## Simplified Error Handling and New Try Scope

Mule 4 includes a simplified way to manage errors. Instead of dealing with Java exceptions directly,
there is now an Error concept built directly into Mule. Furthermore, Mule Modules and Connectors
declare what Errors may occur for any given operation. This makes it easy for you to discover
possible errors at design time and catch them.

Exception strategies are replaced by error handlers allowing you to catch errors based on both type
and arbitrary expressions.

You can configure your error handlers to catch errors so that the flow can keep processing, or they
can be re-propagated.

There is also a new Try Scope, which allows you to catch errors in the middle of a flow without
having to create a new flow, specifically to catch that error.

## Batch is easier to use and is now a scope

In Mule 3, batch jobs were top-level concerns, similar flows. But we’ve simplified this so it is now
a scope that can live inside a flow–– making it easier to understand, invoke dynamically, and
interact with other Mule components. There are also no longer a special set of variables (i.e.
recordVars) for batch. You can now just use flow variables directly; this reduces the complexity and
makes it easier to learn how to write batch jobs.

## Improved Upgradeability with Classloader Isolation

Mule 4 loads each Module in its own classloader, isolating the modules from internal Mule code
making runtime upgrades a lot simpler by protecting you from changes by the runtime or connectors:

- Connectors are now distributed outside the runtime, making it possible to:

  - Get connector enhancements and fixes without having to upgrade your runtime.

  - Upgrade your runtime version without breaking compatibility with other modules.

- There is now a well-defined Mule API, so you can be sure you’re using supported APIs.

- There is classloader isolation between your application, the runtime, and connectors, so that any
  library changes that happen internally will not affect your app.

## Improved support for configuration

Mule 4 features an easier way to configure environment specific properties, which is
Spring-optional. With it, you can now define application-specific properties in a YAML file inside
your application. These will be the default properties for your application and you can override
them using system properties. In the future, we’ll also be using this metadata to provide an
improved configuration management UI from runtime manager.

## Connectors and Modules Updates

### Database Connector

The database connector has undergone minor updates:

- Bulk operations have been separated so that operations do not change behavior depending on the
  received payload

- There’s single experience for executing static and dynamic queries.

- DataWeave transformations can be embedded inside the insert/update operations so that you can
  construct the datasets you want to send to the DB without having a side effect on the message or
  using enrichers

- The connector will use Mule’s new streaming framework to handle large data sets.

### File and FTP Connectors

The File and FTP connectors have been improved so that they are operation based and share the same
set of operations. This enables many new capabilities:

- The ability to read files or fully list directories’ contents on demand, unlike the old transport
  (which only provided a polling inbound endpoint)

- Top level support for common file system operations such as copying, moving, renaming, deleting,
  creating directories, and more

- Support for locking files on the file system level

- Advanced file matching functionality

- Support for local files, FTP, SFTP and FTPS

### JMS Connector

The JMS connector has been updated to utilize the new, simplified connector experience. In addition
to the JMS listener and sender, you can also consume messages in the middle of a flow using the JMS
consume operation.

### Scripting Module

The scripting module is now updated for Mule 4, enabling you to now embed your Groovy, Ruby, Python,
or JavaScript scripts inside Mule flows. You can inject data from the Mule message into your code
using the new parameters configuration attribute.

```xml
<script:execute engine="groovy">
    <script:code>
         return "$payload $prop1 $prop2"
    </script:code>
    <script:parameters>
         #[{prop1: "Received", prop2: "A-OK"}]
    </script:parameters>
</script:execute>
```

### Spring module

Mule 4 decouples the Mule internals from Spring, ensuring that users don’t need to know Spring to
learn Mule and enables Spring users to select which version of spring they run. To use Spring beans,
now you add the Spring module to your application, and simply import your Spring bean files.

```xml
<spring:config name="springConfig" files="beans.xml"/>
```

### VM Connector

The VM connector has been updated to utilize the new, simplified connector experience. In addition
to the VM listener and sender, you can also consume messages in the middle of a flow using the VM
consume operation

### Other Modules and Connectors

All other modules and connectors that have been updated have been updated to be consistent with the
overall Mule 4 experience, but have otherwise gone through no functionality changes unless
explicitly noted in their release notes.

## Mule SDK

The Mule SDK is a successor to the Anypoint Connector Devkit. It enables developers to easily extend
Mule and create new Mule modules which can be shared in Exchange. Unlike Mule 3, where there were
multiple ways to create extensions, the Mule 4 SDK provides a single way to extend Mule, assuring
consistency and upgradeability of components. It was used to build all Mule 4 modules and
connectors.

While similar to DevKit in many respects, it features many improvements:

- The SDK does not generate code, which enables extensions to get new runtime features without
  having to be re-released

- Transactions support

- Request-Response message sources support

- Dynamic configurations

- Router support

- Non Blocking operations

- Classloading isolation

## See Also

- [Mule Events](https://docs.mulesoft.com/mule-runtime/4.3/about-mule-event)

- [DataWeave Language](https://docs.mulesoft.com/mule-runtime/4.3/dataweave)

- [Migrating from DataWeave version 1 to 2](https://docs.mulesoft.com/mule-runtime/4.3/migration-dataweave)

- [Core Components](https://docs.mulesoft.com/mule-runtime/4.3/about-components)

- [Try Scope](https://docs.mulesoft.com/mule-runtime/4.3/try-scope-concept)