On 31 Jan 2013, at 11:53, Manik Surtani wrote:


On 31 Jan 2013, at 11:45, Mircea Markus <mmarkus@redhat.com> wrote:

Hi,


The REST module is written in Scala (both main + tests). We have some *test* contributions written in Java (thanks  mlinhard).
There was an IRC discussion on whether it's worth migrating the Java contribution to Scala code or not. 

Pros for migrating the contribution from Java to Scala:
- the REST module is written in Scala. Contributing these tests in Java would make the module bi-lingual, potentially confusing future contributors

Why?  You can choose what to write your tests in.

- even though this is not the case with this particular contribution, there might be code duplications between the scala test suite and java test suite.

Don't create separate test suites.  Put them in the same class path - e.g., src/test/scala - you can have .java files in here too, they will be compiled together, run together, can reference one another.


Cons for migrating the contribution from Java to Scala:
- there are contributors that are not familiar with Scala or are more proficient with Java(such as mlinhard). Forcing them to contribute in a language they are not familiar with would put them off

+1

- my general feeling over time was that people (including me) are not very enthusiastic about debugging and extending Scala code. So IMO if there's a choice between scala and java  (in the scope of the scala modules) we should stick to Java wherever possible (such as this contribution). 

That should not be a hard and fast rule for all modules.  I agree that some modules (like core) should just stick to Java.

I don't think that encouraging scala code is good purely for maintenance reasons. If there's a choice, it should be java. Not saying that learning a new language is not cool - but in practice people are a bit put off by maintaining Scala code. Its not only about what the writer of the code prefers as a language: it's more important what the maintainers of the code 
will has to work with.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)