Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

MDT/OCL 3.1.0 API Changes

< MDT

API Changes in 3.1.0 (Indigo)

The 3.1.0 release has support for "hidden" opposites by introducing a new expression type OppositePropertyCallExp in the Ecore binding. It enables reverse navigation across an EReference that does not have an opposite declared.

3.1.0 closes many gaps that existed between the OCL 2.3 specification and the 3.0.0 implementation. In particular:

  • evaluation of invalid and null has been aligned with the standard
  • the UnlimitedNatural constant * is handled reasonably in more cases, including sorting
  • collection operations defined on Collection(T) that weren't found due to redefinitions in the specific collection subtypes Sequence(T), Bag(T) etc., are now resolved properly
  • the subtype relation between UnlimitedNatural and Integer is now considered when resolving operations on UnlimitedNatural expressions

There are a few known remaining issues that will be fixed only after the Indigo release:

  • The UnlimitedNatural expression * is represented as an Integer with value -1 at runtime. Comparisons of * with -1 erroneously evaluate to true.
  • Numeric equality between Java numeric types and between OCL numeric types is defined slightly differently. In particular, the OCL standard considers Integer a subtype of Real and asserts that 3=3.0 which is not the case for the corresponding Java runtime representations: Integer.valueOf(3) and Double.valueOf(3.0) do not compare equal (although the Java expression 3==3.0 evaluates to true which may be considered a glitch in the Java type system). This difference can lead to idiosyncrasies when combining values that OCL would consider equal in a collection that asserts element uniqueness, such as a Set. While the Java runtime representation allows the set to contain Double.valueOf(3.0) and Integer.valueOf(3) at the same time, OCL would collapse these values into one. Particularly for the Ecore binding this can lead to "surprises."

Back to the top