I am rewriting a large Java codebase to use Scala because the data structures are better described using mixins instead of inheritance. About 30% of the code creates the data structures, and about 70% manipulates the data structures in a profoundly procedural and mutable manner. I am starting to rewrite the 30% in Scala to create the data structures as mixins of traits, but I wish to keep the 70% in Java to preserve my sanity. Currently I am using VSCode not by choice, because I can’t get my preferred Intellij IDEA to compile even the most basic code. Is it correct to assume that the Java code can still manipulate the data structures with setters/getters even though the instances are now compositions instead of inheritance chains? Will the recommended file directory tree for sbt automatically make the Java and Scala code know about each other (and if not, how to specify this)? I am reading the previously recommended books (which are excellent by the way), but they do not cover these codebase matters in detail.
Yes - the trait works as a Java interface too. You might need to use the @BeanProperty annotation if your Java code is some enterprise Spring thing that assumes a naming convention on getters and setters for reflection.
I sometimes start with a Java interface and implement in Scala if I’m really worried about compatibility.
Yes, stick the Scala code under src/main/scala , src/test/scala and the Java code under src/main/java , src/test/scala.
There is an SBT option compileOrder you may need to fiddle with, see: sbt Reference Manual — Java Sources.
IntelliJ and VSCode will pick up the structure from an SBT project.
Many thanks. Sorry for my delay in replying, as have been on other projects.
Hi Mr Serpent,
After a pause in programming because of other projects and holidays, I have this morning reconfigured my Java program into the two source subdirectories (java and scala) as you specified, and created an IntelliJ project using sbt as the maker. The new Scala plugin seems to fix my previous problems with using IntelliJ for Scala. The program entry point is now a Scala class that subclasses javafx.Application, which then calls the Java code (which itself doesn’t now need to be a subclass of javafx.Application), and it works! (Note that I don’t use ScalaFX, as JavaFX is already heavily used in my codebase). The usual time-consuming debugging involved some javafx libraries not being able to access other javafx libraries, but this was rectified by making sure that the sbt config file and IntelliJ project config both referred to a consistent set of javafx libraries for both compiling and runtime. An unexpected problem was the Scala startup needing to pass the right types of parameters to javafx.Application.launch, but sorted out eventually. Now that the Java code all runs correctly within a Scala startup, it should be straightforward to incrementally migrate some Java classes into Scala to achieve the composition-based data structures (using traits and mixins) that I am aiming for. Thanks again for your advice.
Just curious, which config specifically? Compile time deps should be fully covered by IntelliJ keeping in sync with the sbt build files, the latter being “the source of truth”. Runtime deps from within IntelliJ launchers should be fully derived from sbt, as well, and consistent standalone runtime deps can be prepared using packaging via sbt-assembly or similar.
IIRC all of this worked nicely for me with a JFX/SFX project, too - but that’s a couple of years ago, and it was a pretty simple project, sans raw Java code, so perhaps I’ve just been lucky…
Yes, I wondered if my solution was overkill. I do not have a good knowledge of sbt details nor how it interacts with IntelliJ. So I just started making things consistent until it worked. It would be very cool if sbt were the source of truth for IntelliJ, but it is not clear to me how that would be. I am not using SFX, so maybe for you SFX was helping in some way. Also, I’m using java libs 21.0.5 and Scala 3.6.3, neither of which existed a couple of years ago. The config snag was revealed when the code tried to construct MenuBars and ToggleButtons, so I don’t know if your app used some of those Controls. When I get some time I’ll try to minimise the config options, but at least now I have something working that allows me to make progress on the coding.
The quick summary is that, if you set things up as an sbt-based Project in IntelliJ, the IDE will read in the build.sbt and arrange everything to match, with an “sbt” tab on the side of the editor, showing the sub-projects.
From that point forward, it pays attention to the sbt file, and if anything changes, it will prompt you to reload that. (It’s not lightning-fast, but generally just takes a minute every now and then.) So once it’s set up, it’s extremely convenient.
(Caveat: I haven’t done this with a mixed Java/Scala project myself, so I don’t know if there are limitations there.)
Yes, what you describe is precisely what I see and have been using the past few days. What I don’t know is how that happens, but it sounds like IntelliJ itself will read the build.sbt file, though I don’t see why it should. Or maybe the Scala Plugin provides that functionality? It seems to handle mixed Scala/Java just fine.
Adding to @jducoeur’s explanation, there’s the IntelliJ documentation. I have had some projects with mixed Scala/Java, ranging from Scala with a couple of Java enums to Java code with Scala tests, and I haven’t run into any issues, neither at the sbt nor the IntelliJ level.
Of course your issues may be due to a bug in sbt/IntelliJ integration or JFX idiosnycrasies or something completely different - but if you are somehow tampering with deps working around sbt, in IntelliJ config or elsewhere, that’s a more likely culprit.