Undeniably multi-line strings can improve the readability of the code and facilitate reviews but I would prefer if we didn't refactor existing tests from Java to Kotlin mainly for two reasons: 1. Losing the history is an important disadvantage for me. Quite often, I find my self looking in the history of the tests to find the parts of the core that were changed. Or the opposite, looking for instance how an API works by checking the tests that were added in a particular commit. 2. The feature is already present as experimental in Java 13 [1] so we could start using it in the near future (eventually we will start using a newer jdk) so from my point of view there is no big rush to use Kotlin for this.
If I had to choose between the history and multi-line strings I would opt for the history. I lived with normal string concatenation for a while so I am accustomed to reading the code the way it is without too much struggle. No objections for using Kotlin for new tests. Best, Stamatis [1] https://openjdk.java.net/jeps/355 On Tue, Dec 17, 2019 at 1:27 AM Kevin Risden <kris...@apache.org> wrote: > I don't see a major benefit to switching to an entirely new language to get > multiline strings. I agree that sticking to Java makes sense. > > Kevin Risden > > > On Mon, Dec 16, 2019 at 12:50 AM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > Feng>Introducing another language > > > > It is the same language that is used for the build scripts, so it is not > a > > new language. > > > > Danny> in the code evolving and the Scala has many > > Danny> tricky problems especially the version compatibility > > > > Kotlin has strong backward compatibility. > > > > Julian>Transitioning our tests to a different language (Kotlin) is a > > Julian> drastic solution. It requires developers to understand a new > > language, > > > > Note: most of the time, test code is just a glue code between input data > > and asserts. The complicated logic is not there (which is good by the > way). > > > > At the same time, it means it will be very little new to understand. > > > > Vladimir > > >
