The Scala compiler can run on any on JVM from 8 up, and once you’ve run the compiler, the resulting bytecode can also run on any JVM from 8 up, which could be a completely different JVM than the one you compiled the code on. You’re the developer, so both of those JVM choices are under your direct control. The details of how to exercise that control that depend on your OS and on your method of compiling and/or running code: via a build tool? IDE? scala command? application server? there are a ton of ways to run Scala code. And that’s a good thing, it’s part of why the language is so useful in such a wide variety of scenarios.
I intend to ask my sysadmin to update Java on my “remote” machine. However, I am a bit confused about which version of Java is suitable for Scala 3.3.1. Is Java 8 the only option, or are there others?
Also, let me just say that I appreciate all the suggestions that I have received here. You have given me a lot to think about.
I am not allowed post the code because it is not yet approved for open-source, and I am not sure I can recreate a simplified version with the same problem.
I have a new idea about what the problem could be, and I intend to pursue it when I get a chance. It may be a problem with floating point calculations in my algorithm in certain situations. When I figure it out I will post it here in case anyone is curious about it.
Thanks again for all the suggestions.
1 Like
Thanks for that information. I saw it after my previous post. Just one more question. What do you consider the best Java version to use with Scala 3.3.1? Or is anything after Java 8 just as good as anything else?
Generally speaking, there’s no reason to use anything lower than 17 unless you have a specific, known reason to do so. 21 is maybe still a bit new to be recommending as a default choice.
17 is faster than 11 and 8 and just generally better in a lot of ways. 8 is vastly ancient and 11 is… just plain ancient. Using 8 or 11 for no reason is just punishing yourself.
These days very big, very conservative shops where upgrades are difficult and expensive and have to be justified to the budget people are the main places where 8 and 11 are still alive. The rest of us are generally on 17 — or 21, if we’re a bit adventurous.
2 Likes
our doc page on this is JDK Compatibility | Scala Documentation
I had the JVM on my remote machine upgraded from version 8 (1.8.0_91) to version 21 and – lo and behold – everything seems to work now, including repeatability across machines!
Wow, what an episode! I probably spent well over a week trying to track down the problem and was starting to worry that might never find it – which would have been a crisis for me.
Now I am wondering if my code has some near-singularity that I still need to address, but that concern is less critical now. The fact that it could be so sensitive to some floating-point roundoff error is not a good sign I guess – if that is indeed the problem.
In any case, the Java version thing has always been a mystery to me. For many years I had erroneously assumed that the JVM was automatically upgraded if necessary when I upgraded the Scala compiler.
I had also assumed that version 8 was a fairly recent version (or 1.8, which is a bit confusing it itself). I finally did a quick search on Java versions and found that it is almost 10 years old. I guess I should have been more aware of my development environment.
4 Likes
Great news, congrats!
1 Like
So many issues can be magically fixed by changing Java versions 
Happens on Coursera discussion forums all the time. People keep using ancient Javas without knowing. I’ve lost count of the number of people I’ve told to switch to Java 11 or 17. I feel like there is a “Google funnel” that makes unsuspecting people install Java 8 (or 1.8 in Oracle numbering).
Anyway congrats! 
2 Likes