Can't compile JavaFX projects (regression?)

[s-bernard]

More precisely, since commit a124774, a simple JavaFX project cannot compile and log the following errors:

[info] Compiling 1 Java source to ./out/javafx/compile/dest/classes ...
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by sbt.internal.inc.javac.DiagnosticsReporter$PositionImpl$ (file:/~/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scala-sbt/zinc-compile-core_2.12/1.2.5/zinc-compile-core_2.12-1.2.5.jar) to field com.sun.tools.javac.api.ClientCodeWrapper$DiagnosticSourceUnwrapper.d
WARNING: Please consider reporting this to the maintainers of sbt.internal.inc.javac.DiagnosticsReporter$PositionImpl$
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
[error] ./javafx/src/ButtonApp.java:1:1: package javafx.application does not exist
[error] import javafx.application.Application;
[error] ./javafx/src/ButtonApp.java:2:1: package javafx.stage does not exist
[error] import javafx.stage.Stage;
…

Basically it cannot find the JavaFX packages.

Latest commit tested: 80eb7e0
Tested with java-11-graalvm and java-11-openjdk.
Was working as expected before a124774.

Sample code

cat build.sc

import mill._, scalalib._

val javaFXVersion = "13.0.2"

object javafx extends JavaModule {
  def mainClass = Some("Main")
  def ivyDeps = Agg(ivy"org.openjfx:javafx-controls:$javaFXVersion")
}

cat javafx/src/ButtonApp.java

import javafx.application.Application;
import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.layout.VBox;
import javafx.scene.control.Button;

public class ButtonApp extends Application {
  public static void main(String[] args) {
    launch(args);
  }

  @Override public void start(Stage stage) {
    var button = new Button("Please Click Me!");
    button.setOnAction(e -> stage.close());
    var box = new VBox();
    box.getChildren().add(button);
    var scene = new Scene(box);
    stage.setScene(scene);
    stage.setTitle("Just a button");
    stage.show();
  }
}

cat javafx/src/Main.java

public class Main {

  public static void main(String[] args) {
    ButtonApp.main(args);
  }
}

[lefou]

It is probably an change in coursier, which might got a version bump as a transitive dependency.
Looks like you now need to depend on ivy"org.openjfx:javafx-controls:13;classifier=linux or whatever your platform is. javafx-controls with classifier is a transitive dependency of javafx-controls without classifier.

Might be related to #759

Maybe @alexarchambault sees more and can comment?

Here is the pom.xml of javafx-controls:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.openjfx</groupId>
  <artifactId>javafx-controls</artifactId>
  <version>13</version>
  <parent>
    <groupId>org.openjfx</groupId>
    <artifactId>javafx</artifactId>
    <version>13</version>
  </parent>
  <dependencies>
    <dependency>
      <groupId>org.openjfx</groupId>
      <artifactId>javafx-controls</artifactId>
      <version>13</version>
      <classifier>${javafx.platform}</classifier>
    </dependency>
    <dependency>
      <groupId>org.openjfx</groupId>
      <artifactId>javafx-graphics</artifactId>
      <version>13</version>
    </dependency>
  </dependencies>
</project>

(I posted this before: https://gitter.im/lihaoyi/mill?at=5e3175b5433e1d40397320f8)

[s-bernard]

I've just tried with classifier=linux with a124774: same behavior (I'm on linux).

Actually, I tried with some garbage classifiers like ivy"org.openjfx:javafx-controls:$javaFXVersion;classifier=aiueauieai" and I have the same results as without classifier: 4f4fab6 compiles and runs as there was no classifier and a124774 & 80eb7e0 fail to compile with the same package xxxx does not exist errors. No error on javafx.compileClasspath like when you change the artfactId.

[alexarchambault]

coursier does fetch the OS-dependent artifacts. It does from the CLI at least:

$ cs fetch org.openjfx:javafx-controls:13
~/.cache/coursier/v1/https/repo1.maven.org/maven2/org/openjfx/javafx-base/13/javafx-base-13-linux.jar
~/.cache/coursier/v1/https/repo1.maven.org/maven2/org/openjfx/javafx-graphics/13/javafx-graphics-13.jar
~/.cache/coursier/v1/https/repo1.maven.org/maven2/org/openjfx/javafx-graphics/13/javafx-graphics-13-linux.jar
~/.cache/coursier/v1/https/repo1.maven.org/maven2/org/openjfx/javafx-base/13/javafx-base-13.jar
~/.cache/coursier/v1/https/repo1.maven.org/maven2/org/openjfx/javafx-controls/13/javafx-controls-13-linux.jar
~/.cache/coursier/v1/https/repo1.maven.org/maven2/org/openjfx/javafx-controls/13/javafx-controls-13.jar

Same kind of result on macOS.

You might be missing OS and JDK-related infos in the way you're calling the coursier API. The high level API of coursier sets them up this way.

@lefou If that's a possibility for you, I would advise using the higher level API (coursier.Resolve, coursier.Fetch, coursier.Artifacts, etc.), described here, rather than the low-level one, to lower the odds of that kind of issue.

[lefou]

@alexarchambault Thanks for your comments. I'll have a look.

[rom1dep]

For the record, bumped into that as well when updating mill to > 0.5.3

[s-bernard]

Hello, any news on this issue? Thanks.

[lefou]

No, we discussed the implementation a bit (in #775), but nobody did the work yet.

[siddhartha-gadgil]

I may need to work around this issue, and wanted advice. I have done the following for now, and it seems to work. Is this likely to cause some trouble somewhere else?

override def unmanagedClasspath = 
      T{
        import coursier._
        val files = Fetch().addDependencies(dep"org.nd4j:nd4j-native-platform:1.0.0-beta7").run()
        val pathRefs = files.map(f => PathRef(Path(f)))
        Agg(pathRefs : _*)
      }

[lefou]

@siddhartha-gadgil unmannagedClasspath is what it is called, unmanaged. So there is a slighly chance, that dependencies provided there may collide with some provided by ivyDeps. But besides that, I think it's a perfectly reasonable work-around.

[siddhartha-gadgil]

Thanks. I will watch out for this, especially with transitive dependencies.