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.

Sign up for GitHub

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

Jump to bottom

Convert Java rules to use Toolchain Resolution #4592

Closed
katre opened this issue Feb 6, 2018 · 12 comments
Closed

Convert Java rules to use Toolchain Resolution #4592

katre opened this issue Feb 6, 2018 · 12 comments
Assignees
@comius
Labels
P1 I'll work on this now. (Assignee required) team-Rules-Java Issues for Java rules type: feature request

Comments

@katre
Copy link
Member

katre commented Feb 6, 2018

Toolchain resolution is available in native rules. Java rules should be updated to use toolchain resolution and platforms, rather than the existing javabase and java_toolchain options in JavaOptions.
@katre katre added type: feature request P1 I'll work on this now. (Assignee required) category: extensibility > toolchains labels Feb 6, 2018
@katre katre assigned katre and lberki Feb 6, 2018
@katre
Copy link
Member Author

katre commented Feb 6, 2018

Some work has been done already to convert JavaToolchainProvider and JavaRuntimeInfo into ToolchainInfo instances. Future work will be to centralize access to those objects, and then convert them to use toolchain resolution instead of the current late-bound-attributes for lookup.

@katre katre mentioned this issue Feb 6, 2018
Merged
@lberki
Copy link
Contributor

lberki commented Feb 6, 2018

to be clear: I thought you were working on this. In what areas do you require my help?

@katre
Copy link
Member Author

katre commented Feb 6, 2018

Mostly I need help in terms of code and design reviews. This isn't scheduled and I'll only be tackling it on a best-effort basis.

@lberki
Copy link
Contributor

lberki commented Feb 6, 2018

Excellent, then we are on the same page. I'd love to see this happen, but I also can't commit more time than the occasional code/design review.

@ittaiz
Copy link
Member

ittaiz commented Dec 9, 2018

@katre is this issue the same as #5462? (which is now closed) If not can you please explain how they relate?
Thanks!

@katre katre mentioned this issue Dec 10, 2018
Closed
@katre
Copy link
Member Author

katre commented Dec 10, 2018

Yes, this is the same as #5462, which I closed as a dupe.

We have committment for work on this in 2019Q1, I will try and make sure the appropriate issue is tagged in the commits relating to the work, so that interested parties can follow along.

@ittaiz
Copy link
Member

ittaiz commented Dec 14, 2018 via email

@cushon cushon mentioned this issue Jan 19, 2019
Closed
@lberki lberki mentioned this issue Mar 27, 2019
Closed
@meisterT
Copy link
Member

@katre can you please update this issue?

@katre
Copy link
Member Author

katre commented May 11, 2020

All of the code is in place, but we haven't flipped the flag for Bazel because no one was available to write the toolchain rules for the Java toolchains. Once that is done we can test flipping the flag and see where downstream projects stand.

@katre katre mentioned this issue May 11, 2020
Closed
@jin jin added team-Configurability platforms, toolchains, cquery, select(), config transitions and removed category: extensibility > toolchains labels May 12, 2020
@shs96c
Copy link
Contributor

shs96c commented May 13, 2020

Is this something that the community can get involved in? Is there a guide or an design doc outlining what it means to "write the toolchain rules for the Java toolchains"? I'm guessing this is more than just adding a new toolchain type and a couple of targets.

@katre
Copy link
Member Author

katre commented May 13, 2020

The toolchain types exist. the big issues are still, I think, design issues: where do the toolchains live (currently it's some mix of @bazel_tools//tools/jdk, @rules_java, and several @java_tools-type repositories).

I'm not sure who is actually in charge of the state of the Java rules: @lberki, can you clarify who is the decider?

@davido
Copy link
Contributor

davido commented May 13, 2020 •
edited
Loading

[...] and several @java_tools-type repositories

I'm not sure who is actually in charge of the state of the Java rules: @lberki, can you clarify who is the decider?

Another question is who is in charge to conduct a new java_tools release, e.g. with bumped Error Prone version? REAMDE.md in this repository: [1] is claiming:

A new java_tools for the javac version used by bazel is released monthly.
The first RC should be cut at least 7 days before the bazel release,
around the 25th day of the month.

However, the last release of java_tools was conducted in February 2020: [2].

[1] https://github.com/bazelbuild/java_tools#release-schedule
[2] https://github.com/bazelbuild/java_tools/releases

@comius comius assigned comius and unassigned katre and lberki Dec 7, 2020
@comius comius mentioned this issue Dec 8, 2020
Closed
bazel-io pushed a commit that referenced this issue Dec 9, 2020
@comius @copybara-github
Add toolchain definitions for Java.
3733065 
Design document: https://docs.google.com/document/d/1MVbBxbKVKRJJY7DnkptHpvz7ROhyAYy4a-TZ-n7Q0r4/edit

A new macro remote_java_repository is defined, which creates an additional
repository with BUILD file containing toolchain target and registers it.

An additional repository prevents download of all JDKs (even if not
used).

Similarly local_java_repository rule is extended to add toolchain
target. In case the local JDK is not present a fake toolchain is added in
order to provide a nicer error message (without it toolchain resolution
fails without giving a clear message what was wrong).

Default_java_toolchain macro is extended to define toolchain rule as well.

Local JDKs version is autodetected.

Addresses #4592

Closes #12588.

PiperOrigin-RevId: 346570811
@comius comius mentioned this issue Dec 10, 2020
Closed
bazel-io pushed a commit that referenced this issue Dec 10, 2020
@comius @copybara-github
Attach Java runtime to Java toolchains
37eb1d7 
Defining a new rule "java_runtime_version_alias", which uses a custom configuration flag transition to select a specific version of remote JDK.

Added a weird "selected_java_runtime" attribute, which needs to exist until the incompatible_use_java_toolchain_resolution is flipped.

Added the test for the attached runtime and fixing the test for host_javabase (now it is only modified for targets in exec configuration).

Bootstrap_toolchain had to be moved to another file, because of java_runtime attribute, which is not yet released.

Related to #4592

Closes #12677.

PiperOrigin-RevId: 346825514
This was referenced Dec 11, 2020
Open
Open
@gregestren gregestren added team-Rules-Java Issues for Java rules and removed team-Configurability platforms, toolchains, cquery, select(), config transitions labels Dec 11, 2020
@comius comius mentioned this issue Dec 15, 2020
Closed
bazel-io pushed a commit that referenced this issue Dec 17, 2020
@comius @copybara-github
Fix Java tests to use Java toolchain resolution.
f5b6abc 
The flag is flipped for tests, old configuration options `javabase` and `java_toolchain` are marked deprecated. All the tests are fixed to execute using new toolchain resolution.

Changed `local_java_repository` to generate `java_runtime` with `java_home` parameter set (instead of srcs). This behaves better, because `java_stub_template.txt` then does not need runfiles to execute produced `deploy.jar`. Kept the same version with `srcs` in the `jdk.WORKSPACE`.

Related to #4592.

Closes #12695.

PiperOrigin-RevId: 347969628
@comius comius closed this as completed Jan 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@comius comius

Labels
P1 I'll work on this now. (Assignee required) team-Rules-Java Issues for Java rules type: feature request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix Java tests to use Java toolchain resolution. comius/bazel
9 participants
@shs96c @katre @davido @jin @meisterT @ittaiz @comius @lberki @gregestren