Skip to content
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

Add ability to select Java versions on a per-module basis (1000USD bounty) #3480

Closed
lihaoyi opened this issue Sep 7, 2024 · 1 comment · Fixed by #3716
Closed

Add ability to select Java versions on a per-module basis (1000USD bounty) #3480

lihaoyi opened this issue Sep 7, 2024 · 1 comment · Fixed by #3716
Labels
Milestone

Comments

@lihaoyi
Copy link
Member

lihaoyi commented Sep 7, 2024


From the maintainer Li Haoyi: I'm putting a 1000USD bounty on this issue, payable by bank transfer on a merged PR implementing this.


Currently Mill just uses the global Java for everything, which is not ideal: many projects have different parts that require different Java versions. e.g. Mockito has a submodule that requires Java 21 https://github.com/mockito/mockito/tree/main/subprojects/java21-test, and of course Mill itself has different parts targetting different versions (e.g. half our thirdparty tests run on 11, half run on 17). Currently we get by with separate jobs on Github Actions, but that's clunky and annoying to work with since it doesn't reproduce locally.

Ideally we should be able to specify Java versions on a per-module basis, which Mill will download and cache as necessary to run those specific modules. As JVM downloads can be expensive, it is probably worth caching things globally (probably the same place we cache the Mill assembly jar?) rather than caching them in the out/ folder of each project

Gradle has something like this (https://docs.gradle.org/current/userguide/building_java_projects.html#sec:java_cross_compilation), and it feels like it would be very useful for Mill as well

@lefou
Copy link
Member

lefou commented Sep 7, 2024

See prior discussions in the related issue

@lihaoyi lihaoyi changed the title Add ability to select Java versions on a per-module basis Add ability to select Java versions on a per-module basis (1500USD bounty) Sep 15, 2024
@lihaoyi lihaoyi added the bounty label Sep 15, 2024
@lihaoyi lihaoyi changed the title Add ability to select Java versions on a per-module basis (1500USD bounty) Add ability to select Java versions on a per-module basis (1000USD bounty) Sep 15, 2024
lihaoyi added a commit that referenced this issue Nov 20, 2024
Fixes #3480.

Changes:

- adds `coursier-jvm` as a dependency to the `util` module, this library
is for fetching JVMs using coursier and the coursier
[jvm-index](https://github.com/coursier/jvm-index)

- add a `def javaHome: Task[Option[PathRef]]` task to
`ZincWorkerModule`. This defaults to `None`, which is the existing
behavior of using mill's java home.

- Users who want to use a custom JVM need to define a custom
`ZincWorkerModule` and override `def jvmId`, optionally `def
jvmIndexVersion`

- updates the `mockito` and `commons-io` examples to use the new
configuration options. Now these examples should run even when mill
itself is not running on java 11.

- This also required adding `-encoding utf-8` to the projects' javac
options.

- update the `run` and `test` tasks to use the `zincWorker`'s java home
if a different one specified

Notes:

* `JavaModule#compile` forks a new JVM for each compilation to support
custom JVM versions, and `ScalaModule#compile` does not support custom
JVM versions at all. This would require a deeper refactoring of
`ZincWorkerModule` to fix
*

---------

Co-authored-by: Li Haoyi <haoyi.sg@gmail.com>
@lefou lefou added this to the 0.12.3 milestone Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants