A typical example if you want to illustrate conciseness of functional code could use collections and their operations. E.g. consider a class Customer and a method creating a sorted list of customer names from a list of customers.

Here is the Java implementation:

class Customer
{
    String name;

    ... // Other attributes.
}

List<String> sortedCustomerNames(List<Customer> customers)
{
    List<String> names = new ArrayList<String>();

    for (Customer customer : customers)
        names.add(customer.name);

    Collections.sort(names);

    return names;
}

Scala version:

class Customer(val name: String, /* ... other attributes */)

def sortedCustomerNames(customers: List[Customer]): List[String] =
  customers.map(c => c.name).sorted

NOTE

Conciseness in terms of keystrokes is not always a good measure of code quality and maintainability.

Also, in general I would not advise to switch from Java to Scala just because Scala is newer. If most of the team members are more familiar with Java, the team will be much more productive with Java than with Scala (or any other programming language they don’t know well).

I have been learning Scala in my free time for about two years now, and only recently (after attending an online course) I got the feeling I can be more productive in Scala than I am in Java. Before reaching this point, I would not have considered using Scala for production.

For all, everywhere where it is possible or for nothing, just use Java. This way this will work sane. I were making such experiments long time ago but in later times you rewrite everything to one or two (to you keep some things if that could not be done in another language) languages just for clarity.

If you can declare class shorter in 2 lines of code, that is not advantage you must not use language for this “feature”. For example also you can write beautiful functional code in xxx lines and spend yyy time and maybe in the same time you can write it in OOP style in xxx+150 lines in yyy-2hours time with perfomance benefit (who knows). What I want to say is that is not possible to say “this part will be better on Scala” and “this part on Java”. In development you must not discover features, in my opinion, you must just develop without mixing and think about general logic instead of implementation in language X or Y that’s why, in my opinion, for clarity and productivity you must pick language for project instead of for feature.

I suspect this is a matter of how good the programmers on the team are and how much they are willing to learn new things.

Scala is much more concise and expressive, but equally more complex. Any programmer who can make a good use of the high level abstractions it offers will like it and be more productive in it and will never want to go back to the oversimplified level of Java. But a programmer who is not good at high level abstractions or simply does not want to learn will never get it.

Also I don’t think you should use any cases tailored specifically to Scala. Just start writing the prototype in it and you’ll see whether it’s more productive or not. It should be more productive for everything to be worth switching.

And I definitely wouldn’t mix the languages except for using libraries written in the other. Start prototyping in Scala, see how well it goes and choose one or the other.

In my (admittedly limited) experience, the use case I’ve seen most is to use it to get a sense of superiority and smugness over your colleagues who actually ship things, and/or hide your limitations by blaming the “antiquated and inelegant” language you’re “forced” to use instead of the new hotness 😉