Back to Blog Archive

Tested Changes from DataWeave 1.0 to DataWeave 2.0

Posted on: October 23, 2017

This article lists all of the documented changes from Dataweave 1.0 to Dataweave 2.0. We have tested these changes using Anypoint Studio 7.0 Beta. At the time of writing it appears that some changes have yet to be implemented or have not been documented correctly.

We have to consider that Studio 7.0 is still in Beta and make allowances accordingly. You will find notes regarding these ‘unimplemented changes’ and ‘documentation errors’ after each feature in bold and contained in [square brackets].

The following is our categorisation of the various changes from DataWeave 1.0 to 2.0:

  • Important new features, which allow us to make things which could only be done indirectly with DataWeave 1.0 or weren’t even possible.
  • Other new features, not as groundbreaking as the features in 1, though they are good to know about.
  • Behavioural Changes, where the behaviour of certain functions have changed.
  • Major Syntax Changes
  • Minor Syntax Changes

Important new features

    • DataWeave is now the expression language in Mule 4, replacing MEL. MEL can still be used as follows: #[mel:mel expression], though this is not encouraged because MuleSoft have now adopted the use of DataWeave. For the simple use case of extracting a value from the Mule event, DataWeave syntax remains identical to that of MEL, so you might find that some scripts from older versions work in Mule 4 without any changes, even though they’re technically being processed via a different language engine. If you still need to use MEL, you can include it in your projects by adding the compatibility package.  [Works as documented.]

The use of DataWeave instead of MEL simplifies many common tasks:

      • Events can be routed based on payload data, without first needing to convert to Java objects. This is possible because DataWeave transforms any data type to its canonical form, and the DataWeave script works on this canonical form.
      • Binary data can easily be queried from an expression anywhere in your flow  (for example, when logging) without the need to use transformers. This is possible due to the same reason as above.
      • Larger than memory access to data happens transparently. This is due to the way Mule 4 EE handles streams, which is clearly explained in detail here.
      • Data can be read multiple times or accessed randomly with the DataWeave expression language without side effects.
      • Data can be sent to multiple places, without the user caching that data in memory first.


  • Now it is possible to import and create DataWeave modules. This is very handy because finally we can properly write and import DataWeave libraries. [Wasn’t able to import a module I’ve created. I tried placing the dwl script both inside or not inside a folder and in multiple locations (src/main/resources, src/main/mule, directly in project path) to no avail.]
  • Multiple functions are no longer packaged as part of the core functions module. The package they belong to must be manually imported in the header before they can be called. [Works as documented]
  • Now it is also possible to call Java methods via DataWeave. Note that you can only call static methods via DataWeave (methods that belong to a Java class, not methods that belong to a specific instance of a class). Moreover,  you can instantiate a new object of any class. Note that after creating an instance, you can’t call its instance methods via DataWeave, you can however reference its variables (even if these are private). [Works as documented.]


Other new features

  • Added index as 3rd param to certain operators (see table below)
  • New key-value pair selector (.&) returns all matching keys and values. It returns them as a single object containing these. Thus, if payload is {a:1, b:2, a:3}, whilst payload.a returns 1 and payload.*a returns [1,3], payload.&a returns {a:1, a:3}.  [Works as documented.]
  • New namespace selector (.#) returns the namespace used. [Works as documented.]
  • New supported syntax for match when using arrays [head ~ tail]. [I did not manage to get the match to work (using both dw 1.0 and 2.0 syntax). Moreover, I cannot quite understand how to use the ~ syntax for arrays.]
  • Block comments can be added over multiple lines, using the /*  */ notation. [Works as documented.]
  • Improved error messages with call values and stacktrace. [Works as documented.]
  • Type checking and type inference have been introduced. [Managed to define type in function argument, although not sure if this is only what type checking and type inference entail as new features in 2.0.]


Behavioural Changes

  • Removed automatic coercion from object to array (this implies for example, that the map function no longer works over an Object). [Works as documented.]
  • The functions filter, distinctBy and groupBy are overloaded to operate on objects. [Works as documented.]
  • The functions map, mapObject and filter support a null input (in which case they return null). [Works as documented.]

So, the eight lambda-based traversal operators in DataWeave can be categorized as follows:

  • 2 which work only on arrays (map, reduce),
  • 2 which work only on objects (mapObject and pluck) and
  • 4 which work on both (orderBy, filter, distinctBy and groupBy).
Function Name Works on Arrays & Objects $$ $$$ Works on Null
map Arrays Only Index N/A Yes
reduce Arrays Only Accumulator N/A No
mapObject Objects Only Key Index Yes
pluck Objects Only Key Index No
filter Arrays & Objects Index when on Array, Key when on Object On Objects, it is documented that this is Index, though when tested this currently does not work. However, when using named parameters, this third parameter works. Yes
orderBy Arrays & Objects Index on Array, Key on Object N/A No
distinctBy Arrays & Objects Index on Array, Key on Object N/A No
groupBy Arrays & Objects Index on Array, Key when on Object On Objects, it is documented that this is Index, though when tested this currently does not work. However, when using named parameters, this third parameter works No


Major Syntax Changes

  • Changed all type names format, now written without a colon and with an upper case letter (Object instead of :object as before). [Works as documented.]
  • Operators can now be written in the standard function manner (i.e. functionName(arguments). For example, typeOf(x) instead of typeOf x and pow(x,y) instead of x pow y. [It seems that only unary operators and operators on numbers like pow, mod etc., can be written in this form. I don’t think they will allow map, filter and other lambda-based operators to be written in this form.]
  • when, unless and otherwise are no longer used for conditional logic. They have been replaced by if and else. This requires that you slightly change the order of the expression. In general:  if (condition1) result1 else if (condition2) result2 … else resultn. Condition must be in brackets. [Not exactly as documented, although I did manage to get things to work in the form I described.]


Minor Syntax Changes

  • Updated version header to %dw 2.0. [Works as documented.]
  • Removed % from all other directives. [Works as documented.]
  • Custom functions are declared in the DataWeave header via the keyword fun, rather than function. Also, function body must be separated from the function signature using = (instead of space). For example, fun functionName(args) = body. [Works as documented.]
  • The .. operator is no longer used for selecting ranges (still works as a descendants selector). Its functionality is replaced by to. Example: [2 to 15]. [Works as documented.]
  • Namespace prefixes can no longer contain the character – (dash). [Works as documented.]


We hope this article was useful, we we’ll be publishing updates as they come, and if you are able to get some of the above tests to work, we would be grateful if you could write how you managed it in the comments and we’ll update this article accordingly.


2 Comments for “Tested Changes from DataWeave 1.0 to DataWeave 2.0”

  1. Troy says:

    Excellent article. I’m currently working on a Mule 3 project and considering migrating to Mule 4. We have over 50 Mule applications, and they use MEL expressions extensively (i.e. every place a script is, it is a MEL expression).

    Changing every single expression to DataWeave is a huge migration, and made especially difficult because of the lack of support for things that were easy in MEL, such as calling java classes, etc.

    You mention a compatibility package. I’ve asked Mule representatives if it is possible to use MEL expressions in Mule 4, and they’ve all told me you cannot. Could you please provide more information about the compatibility package. If there is a way to use MEL expressions in Mule 4, I would love to know!


    • James says:

      Hi Troy,

      I was quoting Mulesoft’s documentation when I mentioned the compatibility package. However, I cannot find this documented now, most probably it was removed. I wrote my article not long after Mule 4 was released and from then onwards much more documentation has been added/replaced.

      You can try using the “mel:” prefix before MEL expressions as in: #[mel:payload.keySet()]



Contact Us

Ricston Ltd.
Triq G.F. Agius De Soldanis,
Birkirkara, BKR 4850,
MT: +356 2133 4457
UK: +44 (0)2071935107

Send our experts a message

Need Help?
Ask our Experts!