Ask for porting to Scala advice

Question
1

Hi, we have a biggie and oldie internal Java app, research database that is written in mostly vanilla Java. They kept to vanilla Java for performance and avoiding frameworks. Because of the vanilla nature there is a lot of custom code, verbosity and the code is huge so that maintainers avoid adding new features. Also because of extent people do not have time to devote for maintenance.

I proposed to migrate to Scala 3 because it comes with lots of goodies out of the box and high quality libraries. Also the code will shrink and I believe the patterns will become more obvious, but also more high level through the use of functional libraries. As a benefit the code is projected to be more maintainable.

However, I faced big opposition because they say

  1. Vanilla java will be here to stay for a long time but frameworks come and go
  2. Scala is dead (questionable) so why devote time to port it to something dead

I objected because

  1. Lack of new development (biggie code) has mothballed the valuable research, so it is way more dead than “Scala”
  2. New devs avoid contributing to this huge thing
  3. Bitrot obscures the fundamental ideas

I ask for advice because I’m split.

1 Like
2

I am working on a similar situation: Large Java codebase (118 source files) in need of a redesign. Chose Scala because it offers a way to make compositional data structure (in addition to subclassing), and can port the code incrementally because it can compile mixed Java/Scala programs. The code is ported now, and it runs with a few bugs to fix because of some minor things I didn’t understand properly at the time. I think this was a worthwhile effort because the software design is now a better match to the problem. There are pros and cons. Pros: A very helpful user community, good books, and Scala 3 is alive. Cons: Some struggle with IDE compatibility, but now mainly resolved due to using latest releases of plugins (Intellij IDEA). Some online tutorial material doesn’t work on new versions of Scala. I have some lingering discomfort with Scala that I can’t explain properly at the moment because of inexperience with the language. Something about having too many ways to perform a given task, as though the language design is trying to satisfy too many programming paradigms and syntaxes.

3 Likes
3

Thank you very much for the feedback. Highly apreciated.

4

I would second this. In my experience the Scala code is usually much easier to read and maintain than its Java counterpart. Scala is well-liked among developers who use it regularly, particularly for its technical elegance and suitability for complex systems.

I am not sure what kind of “death” is anyone talking about. The language is not the most popular in the world, but it is being actively developed on all fronts, language, tools and libraries, there are companies using it, large (like X / Twitter or LinkedIn) and small (like myself) - sometimes I would even say it is too much lively to my taste. Still, even if all development would be suddenly abandoned, there is no reason why you could not maintain an application with the tools you have now. As you say, if the application is old, it is probably much more dead than Scala - maintaining it in Scala will almost certainly be easier than in Java, as the language and libraries tend to direct you to nice and safe programming patterns.

2 Likes
5

Language versions also come and go.
“Vanilla Java” today is not the same as it was 5 years ago; which also was not the same as it was 10 years ago, and in 5 years it will also be different.

Also, any well maintained library and framework has endured the years as well. Like I don’t see Netty, Spring, Jackson, and other major Java projects going anywhere soon.

So this is a very weird argument IMHO. Especially, if no one is actively maintaining the code, you can always keep using the old stable versions.

Leaving aside that the language is far from dying.
It is true, however, that finding and training Scala developers is harder than finding and training Java developers.

Also, note that bad Scala code, can be worse than bad Java code.
And it seems they won’t be very fond of using the language, thus not motivated to learn and write code following best practices.

Also, you mentioned they care about performance.
When you write highly optimized Scala code, it usually ends up looking as very vanilla Java code; .e.g., using Arrays for unboxed primitives, using while loops, no complex types, no high abstractions, etc.
However, Scala 3 features like opaque and inline may actually allow creating good interfaces and produce highly optimized code.

Overall, I can see both reasons to both pick and not pick Scala.
So, maybe the best you can do is create a small PoC of how the code would look like and then try to convenience them.
But, if you find a lot of push against the language and its features, you will see that using Scala will quickly backfire.

2 Likes
6

Even if the benefits you imagine are realized, that does not necessarily result in business value.

“More maintainable” is not a value proposition unless it means “we have important bugs we can’t fix now” or “we have important features we can’t implement”. Usually “porting” or “rewriting” means feature Y will be broken while you have feature X disassembled on the garage floor.

Note that “avoid adding new features” can itself be a feature.

I agree that starting small is useful in mitigating risk.

Migrating to modern Java and JDK might be more effective.

The fundamental conditions that led to the current situation are unlikely to be solved by choice of language.

If a decision maker wants to rewrite a code base, then it gets rewritten anyway.

3 Likes