Read on Twitter
The first exercise today was to take my #scala example of checking a simple constraint on an #ecore instance and translate it to #java (after I already done this for #python and #js). The key part of the result is attached both in Scala and Java. 1/14
Neither of the two solutions is perfect, but I was surprised how badly #Java lands here. Not only worse than #Scala, but also worse than #Python and #javascript. This thread collects my reflections on the comparison. 2/n
In Java, only the 'Stream' class seems to have a universal quantifier implemented (well hidden under the name 'allMatch'). You can only check it once on a stream, because of the run-once restriction. Super irritating if you are thinking declaratively. 3/n
Checking a pure property on a #Java stream has a side-effect. It destroys the stream. Still thanks to @mauricioaniche and @englebertv for pointing me to streams. 4/n
When writing the Scala version I complained that I need to convert between Java and Scala collections ('asScala'). I was surprised that in Java I still, like in Scala, had to inject conversions (to "streams()" now) because the classic types have poor API. 5/n
I always thought the pain of conversions was a price for using Scala (asScala), and the need to convert between the 2 standard libraries. It would go away in Java, because I will no longer need to shift between them. Wrong. In Java I need to shift between its own libraries :) 6/n
In Scala, I had to add my own 'implies' operator, that is useful for writing Boolean properties (programming languages typically 'forget' to include it). 7/n
Not so bad though - I could add my own implication, because #Scala (and #Kotlin, #Xtend, #csharp, etc.) provides an extension mechanism that can help here once for all. Java does not, so I settled for using the standard expansion with negation and disjunction. 8/n
My biggest pain was hiding in a rather unexpected place. #Java's pragmatics of equality testing seems badly suited for writing conditions on how syntax objects are related. As _.equals is a method you cannot call it on a null ref, but must first test for null. 9/n
This could be avoided using '==' instead, if only '==' had the expected behavior for Strings! Strings, strangely enough, are not a simple type in Java. So _.equals fails if one of your Strings is null, while '==' cannot see that two Strings with same content are the same.10/n
This little complication led to the monster worm above with a ternary operator to handle nulls and strings in Java. 11/n
The entire code can be found in https://bitbucket.org/itu-square/mdsebook/src/master/mdsebook.fsm.java/src/main/java/mdsebook/fsm/java/Constraints.java including the boilerplate to load the Ecore models and iterate constraint checks on them. 12/n
There are plenty similar examples in Java online, so you might find the Python (/mdsebook.fsm.py/), Scala (/mdsebook.fsm.scala/), and Javascript (/mdsebook.fsm.js/) more interesting. Search from root in the same bitbucket repo. 13/n
Examples in more languages are in the works, as the material for our upcoming textbook http://mdsebook.org with @thorsten_berger. 14/n
