If I am generating for distribution I might not want to build the application just for the platform I am building on, do you know how to tell sbt to build three versions, one for each plaform?
You can probably make multi module SBT project, where 3 modules exist specifically to handle each of the 3 platforms.
Why not just build on Java 8 only? Thatâs what nearly everyone in Scala OSS does. Itâs a bit hard to offer advice unless we know a little more about your motivation to do it some other way.
1 Like
Because the JVM ecosystem has progressed quite a lot since Java 8. And I donât think that Scala wants to give up its Java interop possibilities. If this would be the case, Iâd out of the game.
I honestly would hope Lightbend would have an official position about moving towards post-Java 8. But all I get to hear is âPlease subscribe to our commercial support, than we can help.â Funny thing: Lightbend does not offer commercial support, if you not a key-player in the IT business; at least that was the last answer from Lightbendâs sales department.
After all, it is usually us developers who convince companies to adopt Scala.
@SethTisue I am sorry if my post sounds harsh and it is not against you personally. But I am just fed up on how this topic is treated by Lightbend.
@SethTisue Donât mean to be pushy but I agree with @dubaut. Some libraries simply wonât work with older versions of the JDK or if they do we have to use older versions that are not maintained.
1 Like
Scala works on Java 9+. Itâs âjustâ the module system support that is missing. But that shouldnât block you from using new functionalities from Java 9+.
Is there any need to switch to modules when migrating past Java 8? No. Mark Reinhold on July 17, 2020 (Mark Rheinold is chief architect of Java https://twitter.com/mreinhold/status/1284181068145295362).
No.
There is no need to switch to modules.
There has never been a need to switch to modules.
Java 9 and later releases support traditional JAR files on the traditional class path, via the concept of the unnamed module, and will likely do so until the heat death of the universe.
Whether to start using modules is entirely up to you.
1 Like
First of all, Java 9+ is officially not supported by Scala and this means that enterprise-level applications should not use Java 9+.
Secondly, if libraries decide to adopt the module system, you will have a hard time using them. Please remember my original questions. All I got here were workarounds. No solid solutions to my problem.
1 Like
Your original question was whether there were any comprehensive tutorials. The answer was no.
Thatâs a sucky answer, so a lot of people are trying to help you with your actual use case, regardless of your original question. Donât make this about people dancing around your original question which was answered quickly and fully.
What you got are workarounds because the answer to your original question is clear but unfortunate.
1 Like
Following table suggests that running Scala under Java 9+ is supported: JDK Compatibility | Scala Documentation
Yes, integrating JPMS with Scala is hard and unsupported. However that doesnât block anyone from using JARs (including JARs that require Java 9+) and newest additions to Java 9+ standard library. In fact my SBT/ Scala example above uses JARs with OpenJFX 14 that require Java 11+ and itâs running fine.
So to recap: Scala is officially compatible with Java 9+ as long as you donât use JPMS.
2 Likes
I know that I got workarounds and I have to use one of them. However, this is not a satisfactory situation. All we get when asking for Java 9+ support its annoyed responses. Apparently this is an open wound for whatever reason.
I am not sure where you gathering this. As far as I understand this table, it his recommended to use JDK 8 and everything else has experimental support by the Scala compiler. Who can effort experiments when building enterprise-level software? This page contains lot of perhapses and maybes.
I am not sure why you so strongly try to defend this path of action by the developers of Scala. This cannot be an acceptable situation for them, either. What I would expect the least is an official position on all these topics. And it is not only me whoâs requesting those features here. It comes up several times when talking to companies you want to convince to adopt Scala. They ask for support and I get the impression that neither the community nor Lightbehd is interested in supporting them.
I have not defended anything. I just donât understand why you consider Java 11 unsupported by Scala.
No, the article says JDK 8 and JDK 11 are supported except for JPMS.
Support for non-LTS versions of Java is experimental though, but such Java versions arenât recommended for production usage unless you are willing to upgrade Java versions regularly. Java 9, Java 10, Java 12 and Java 13 are already EOLâd. The only non-LTS Java version that is supported by Oracle is Java 14, but it will be EOLâd this month when Java 15 comes out. It makes IMO little sense to support Java versions already abandoned by Oracle.
3 Likes
Yeah, this. Itâs true that JDK 11 was considered experimental for a while, but itâs been officially supported for quite some time now. It doesnât use all the features of JDK 11, but thatâs by no means the same thing as saying that itâs unsupportedâŚ
3 Likes
As for JPMS probably it requires solid experience with it to design, develop and maintain a robust solution. OSGi (another module system for Java) support already suffers from bit-rot in akka / akka-http:
What passage of that web page is giving you this impression? I genuinely donât understand your claim. Is there somewhere we need to improve the clarity of the prose?
The JDK 8 feature set is absolutely, definitely, 100% supported by Scala on JDK 11, commercially (by Lightbend) and otherwise (in OSS world). We have officially supported JDK 11 for a long time now.
1 Like
False.
False.
1 Like
Hi all,
I was hit by this problem when trying to use some Scala libraries in a Maven project - Maven is required to compile Scala/Android projects with GraalVM Native Image. (I will look into using sbt but itâs a bigger issue). So instead, for now, I wrote a plugin that modifies the manifest file of a given Scala JAR in the local Maven repo. It adds a line Automatic-Module-Name: <library name> and it looks like this is enough.
I imagine itâs a very rare situation to build Scala with Maven and Java 9+, but if you do that, please try it out:
Also, I have a big favour to ask to any library creator and maintainer: Please, add automatic module names to your libs. I know in most cases itâs not necessary, but it also wonât hurt anyone. If you use sbt to build your lib, you only need to add these two lines somewhere in your build.sbt:
Compile / packageBin / packageOptions +=
Package.ManifestAttributes("Automatic-Module-Name" -> name.value)
(name here is the name of the library, without the version suffix).
2 Likes
Automatic-Module-Name: Calling all Java Library Maintainers - Branch and Bound suggests:
For libraries itâs essential to pick a globally unique module name. A long-standing practice in Java is to use reverse DNS notation for packages (e.g.
com.acme.mylibrary.core). We can apply the same to module names. Name your module after the root package of your module. This is the longest shared prefix of all packages in the module (for the previous example it might becom.acme.mylibrary). Read Stephen Colebourneâs excellent advice on why this is a good idea. Ensure your module name is valid, meaning it consists of one or more java identifiers separated by a dot.
Also I think this is copy-pasted code and I donât know where it originates, but e.g. scala/project/AutomaticModuleName.scala at 2.13.x ¡ scala/scala ¡ GitHub says:
* !! DO NOT BE TEMPTED INTO AUTOMATICALLY DERIVING THE NAMES FROM PROJECT NAMES !!
*
* The names carry a lot of implications and DO NOT have to always align 1:1 with the group ids or package names,
* though there should be of course a strong relationship between them.
I wrote those two lines myself. From what you linked, I understand itâs safer if the value is hardcoded, yes?
It seems so, yes.
1 Like