Yes it's certainly easier to make a transition into Scala, but I don't think using Scala will solve the actual problem, even if it does have FP capabilities and encourage immutability.
Java's types aren't broken enough to force you into a terrible architecture. Trying to use them badly (that is, in the way that everybody seems to think that you're supposed to use them for enterprise apps) seems to be the actual culprit.
What I found is writing Scala that is not striving for ~100% immutability and functional style does not bring much benefit. It is just a different syntax, that is nicer than Java on one hand, but also big and not straightforward on the other (in the C++ sense, so 'Scala' does not have a conventional coding style, it ranges from Java to Scalaz). Also, making core 'half-functional' does not bring any benefits in terms of composability, concurrency, reasonability (about the code).
That's why I am pro Clojure.
All the functional goodness of easier to reason about code. A much more concise way to express common patterns, and a type system powerful enough to abstract away things that you have to repeat in Java. More dynamism than is possible to use safely in a dynamically-typed language, because I can write code that simply "does the right thing" in a principled, safe way that the reader can confirm by checking the types, whereas in something like Python it would be impossible for a reader to see whether that code was buggy.
> It is just a different syntax, that is nicer than Java on one hand, but also big and not straightforward on the other
Actually the syntax is often more straightforward than Java's. E.g. {} just means a block in a sense that's handled consistently everywhere in Scala, whereas in Java {} are required on a try/catch or a method but optional on an if/else.
> making core 'half-functional' does not bring any benefits in terms of composability, concurrency, reasonability (about the code).
Of course it does, or at least if it doesn't then the whole functional programming effort is a mistake. Any "pure" core is a) relative to some notion of equivalence that might or might not correspond to the things that are important to your particular problem and b) doesn't do anything without an impure interpreter. See e.g. http://conal.net/blog/posts/the-c-language-is-purely-functio...
Keeping old programming style sure allows to lessen frustration compared to diving right into working with immutable collections but the difference won't be that big if you are learning anyway.