Michał Matłoka — Senior Software Engineer

Scala — getClass.getSimpleName on JDK8 is not fully reliable

This month I’ve learned that there is a bug which manifests when using Scala with JDK8. Let’s take a look at the piece of code:

Do you know what is the output? No, not a nice print line, but an exception:

The bug exists since 2009 and concerns double nested classes. It does not occur since JDK 9. If you’d like to get more details why it happens, take a look on the issue. Keep in mind that Scala compatibility charts support newer JDKs for running, not necessarily for compiling. Check the documentation.

Maciej Opała — Senior Software Engineer

This time something unusual: Groovy!

Currently, I’m working on a telco project with a huge legacy codebase. It’s also a mix of multiple technologies, with Groovy among others, and it was Groovy that I had some problems with.. at the very beginning.

So.. We have a MsgId here which is a class with id field of type ObjectId . If a message is too long, it splits into multiple parts and LongMsg is the class that represents such case. It holds two String arrays with split message parts and their ids. There’s also a MsgMapper class that takes a String array of raw ids and maps them to MsgId . Very simple. To illustrate it please have a look at this piece of code:

What’s interesting here is how the toString method is implemented in MsgId class. I’ve noticed this implementation during refactoring and changed it to include the name of the class and its fields:

There is an ids field in the given section of the specification and it’s an instance of a List of MsgId . And LongMsg.partsIds field returns an array of strings. So the first problem is that we have incompatible types here. Not only groovy coerced List to an array, but also coerced MsgId to String by invoking toString() on each element on the list. Why did it work? Because toString() was implemented incorrectly. Instead of being consistent with with JavaDoc which says:

Returns a string representation of the object. In general, the toString method returns a string that “textually represents” this object. The result should be a concise but informative representation that is easy for a person to read. It is recommended that all subclasses override this method.

it returned a String representation of a particular field. So there were two “problems” here. One with incorrect implementation of a toString method and the second with how Groovy behaves (which sometimes is useful, saves time and simplifies coder’s life). How can it be solved? I want to leave the correct version of toString() so I altered the spec code:

And it all works fine, again.

But, as I mentioned at the beginning of this post, that was just the start of the journey. It took me two days (yes!) to fix all the tests that were implemented in Scala, Groovy and Java. And I’ve just changed toString . Why so long? Because, as you probably noticed, LongMsg holds an array of String instead of ObjectId so it has compiled correctly, but failed at runtime.

Never ignore the standards while implementing. Make sure to always implement toString() method correctly and use it in a way it was designed to be used.

Photo by Zan Ilic on Unsplash

Adam Smolarek — Senior Software Engineer

ASCI art on the type level

This month I learned that there is a new symbol that I can use to write kind projections.

It is * .

The old way still works, but is deprecated as ? is going to be used in scala 3 for another purpose. Check here.

? will replace underscore for wild card arguments in the next Scala.

Instead of writing Map[_ <: AnyRef, _ >: Null] , you will write Map[? <: AnyRef, ? >: Null] and in kind-projector, you will use * instead of ? for a while, and after that * will be replaced with _ . So ? and _ will switch places :)

Wait what? But why?

There is a proposal to unify the meaning of _ both on type level and on a function level. Which will be an anonymous type parameter same way that _ is an anonymous function parameter when writing f(_) .

To sum up: currently, _ stands for wildcard on the type level. There is a need for a new symbol and ? was picked, but kind-projector already uses this symbol.

Because of this domino, there is now a new option in kind-projector to use * instead of ? .

It will be there for scala 3.1 nad 3.2. It will disappear in 3.3.

While it is around you can use it to migrate code that is using ?[_] to *[?] and finally to _[?] .

So for EitherT that is using kind-projection it can be like this:

1. Now: EitherT[?[_], Int, _]

2. Scala 3.1 and 3.2: EitherT[*[?], Int, ?]

3. Scala 3.3: ` EitherT[_[?], Int, ?]

Besides this small adventure in the land of kind-projectors, I’ve also read a pretty good book about game theory — “Thinking Strategically”. It’s a gentle introduction to the topic and consists of some theory and practical applications that are based on real-world examples, like the Cuban missile crisis.

The book discusses various approaches to sequential and simultaneous games, presenting a way to analyze them and pick an optimal solution if such exists. There are also references and recommendations for further reading, if you want to continue to explore the game theory.