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 & #39;Stream& #39; class seems to have a universal quantifier implemented (well hidden under the name & #39;allMatch& #39;). 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 (& #39;asScala& #39;). 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 & #39;implies& #39; operator, that is useful for writing Boolean properties (programming languages typically & #39;forget& #39; 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& #39;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 & #39;==& #39; instead, if only & #39;==& #39; 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 & #39;==& #39; 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">https://bitbucket.org/itu-squar... 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"> http://mdsebook.org with @thorsten_berger. 14/n
