Extending Eclipse JDT to Support Java Projects with a Bazel Build

Subscribers:
24,000
Published on ● Video Link: https://www.youtube.com/watch?v=m4xDd8nuaFM



Duration: 38:05
72 views
2


Presented by Peter Laird (Salesforce.com, Inc.) at EclipseCon 2022.

This session will cover the interesting highlights of the design and implementation of the Bazel Eclipse Feature. Attendees should have some development experience with Java in Eclipse to get the most out of this session.

Part 1: Bazel basics

What is it and where did it come from
What are the main two selling points
The heart of Bazel - the dependency graph
How are Java projects supported by Bazel
Basic example of a Bazel BUILD file with a Java target

Part 2: Extending Eclipse JDT to support Bazel

This part will be driven by recorded demos of Bazel Eclipse Feature (BEF) to show how major use cases were implemented.

Implementing the Import wizard for Bazel
Modelling Bazel targets and packages as Eclipse Projects
Mapping of the classpath; Bazel has a lot more flexibility than just main/test, how did we handle this - this is the most critical part
Java editor - quick fly by, all the expected features work without issue
Problems View - populated by output from the Bazel build
Implementing Eclipse Launchers for running Bazel built applications and tests (and how nice it is that debug came for free)

Part 3: Interesting Implementation Details

There are a handful of interesting obstacles/solutions in the BEF implementation that I can talk about, as time allows. Such as:

Global type search: explain how BEF supports searching all Java types referenced in the Bazel workspace even when the user has imported just a subset of all projects
Import optimization: Bazel supports a rich query interface for interrogating the project file layout, but is very expensive. Explain some of the solutions for avoiding queries in many cases.
The IDE has to model your build: Bazel is very flexible, to the point that some configurations are impossible to model correctly in JDT. Explain a couple of these cases, with the lesson that these corner cases are easy to avoid. Complexity in your build configuration causes pain for your IDE.