Skip to content

scala3.library.3: Invalid module name: '3' is not a Java identifier #12899

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
makingthematrix opened this issue Jun 22, 2021 · 8 comments
Closed

Comments

@makingthematrix
Copy link
Contributor

Compiler version

3.0.0

Minimized code

in pom.xml add to dependencies:

<dependency>
            <groupId>org.scala-lang</groupId>
            <artifactId>scala3-library_3</artifactId>
            <version>3.0.0</version>
</dependency>

and then try to build the app with mvn. (please read on for detailed explanation).

Output

[WARNING] There are 1 pathException(s). The related dependencies will be ignored.
[WARNING] Dependency: /home/makingthematrix/.m2/repository/org/scala-lang/scala3-library_3/3.0.0/scala3-library_3-3.0.0.jar
   - exception: Unable to derive module descriptor for /home/makingthematrix/.m2/repository/org/scala-lang/scala3-library_3/3.0.0/scala3-library_3-3.0.0.jar
   - cause: scala3.library.3: Invalid module name: '3' is not a Java identifier

Expectation

There should be no warning about "'3' is not a Java identifier" and no later errors when the code tries to access the Scala library.

Details

This will happen in projects which use together Scala, Maven, and Java 9+. It's not a common combination, but currently this is the way to write programs like this one - an Android app written in Scala 3 that uses JavaFX as GUI, and is built with GraalVM native image. Currently there is no way to do it with SBT. But Maven works pretty well. Except this one issue.

Since Java 9, the Scala way of adding a suffix with the Scala version at the end of artifact id of the library is invalid - hence the error above. An easy way to fix it is to add a line to MANIFEST.MF of the library's jar file:

Automatic-Module-Name: <library name> 

This can be done from SBT. For example in case of scala3-library_3 it's enough to add something like this to dotty/project/Build.scala:

lazy val `scala3-library` = project.in(file("library")).
    asDottyLibrary(NonBootstrapped).
    settings(
      Compile / packageBin / packageOptions += Package.ManifestAttributes("Automatic-Module-Name" -> "scala3-library")
    )
  lazy val `scala3-library-bootstrapped`: Project = project.in(file("library")).
    asDottyLibrary(Bootstrapped).
    settings(
      Compile / packageBin / packageOptions += Package.ManifestAttributes("Automatic-Module-Name" -> "scala3-library")
    )

Please note that usually it's better to hardcode the value scala3-library instead of trying to derive it from the library name.

Actually, the same problem exists for all Scala 2 libraries. I wrote a Maven plugin that fixes this downstream - i.e. it unzips the downloaded jar file of the given Scala library, modifies MANIFEST.MF, and zips it again - but it would be better to have it fixed at the source. Here's the link to the plugin page where you can read more about this issue.

I'm planning to create a PR here in the Dotty project and when it's done I will link it to this bug report. This is the first time I do it, so sorry if I mess up something.

@smarter
Copy link
Member

smarter commented Jun 22, 2021

It seems to me that the most robust thing here would be to make a PR against sbt to have it automatically set Automatic-Module-Name (based on the organization + artifact name which should be unique) unless it's already set.

@makingthematrix
Copy link
Contributor Author

makingthematrix commented Jun 22, 2021

@smarter : This is advised against, sometimes even in capital letters ;) https://users.scala-lang.org/t/scala-jdk-11-and-jpms/6102/38 . As I understand, the reason is that Automatic-Module-Name should be stable across library versions, and it's too easy to have a random modification if it's derived.

@smarter
Copy link
Member

smarter commented Jun 22, 2021

I think that warning is way too strict. It originally comes from akka/akka@af411d2 which cites http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-February/000582.html, I've read that email and I don't think any of the reason cited for not deriving the name automatically are very good.

the reason is that Automatic-Module-Name should be stable across library versions, and it's too easy to have a random modification if it's derived.

If the name is only based on the organization and project name, then it won't randomly change, it's as stable as a project identifier can be. It would certainly be a lot more stable than not having Automatic-Module-Name and instead relying on the default behavior of deriving the name from the jar filename.

@makingthematrix
Copy link
Contributor Author

@smarter : Okay, how about something like this?

  lazy val `scala3-library` = project.in(file("library")).
    asDottyLibrary(NonBootstrapped).
    settings(
      Compile / packageBin / packageOptions += 
        Package.ManifestAttributes("Automatic-Module-Name" -> s"$dottyOrganization-${name.value}")
    )

@smarter
Copy link
Member

smarter commented Jun 22, 2021

I think that's fine but what I'm really suggesting is you should make a PR against sbt to do this by default, then we can just upgrade sbt and won't have to worry about this :). (Though I don't mind doing it ourselves as a stop-gap if getting this in sbt ends up taking time).

makingthematrix added a commit to makingthematrix/dotty that referenced this issue Jun 22, 2021
…ix _3

The issue is described in scala#12899

In this PR I decided to add `Automatic-Module-Name` values only to projects with the suffix _3, that is:
1. scala3-compiler_3
2. scala3-library_3
3. scala3-library-sjs1_3
4. scala3-language-server_3
5. scala3-staging_3
6. scala3-tasty-inspector_3
7. scaladoc_3
8. tasty-core_3
and for consistency also tasty-core-scala2. The values are derived from dottyOrganization + the project name.
@makingthematrix
Copy link
Contributor Author

@smarter : that's an interesting idea, but I'm not sure if it's not too much and if I'm good enough with sbt to do it :)

Anyway, for now, here's my PR: #12903

I will think about making that PR to sbt as well.

@smarter
Copy link
Member

smarter commented Jun 22, 2021

I've opend sbt/sbt#6561 to discuss this further.

@bishabosha
Copy link
Member

fixed by #12903

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants