Explore 2027 alpha

[nlaverdure]

• Create a new main-2027 branch
• Import the project into WPILib 2027 alpha
• Update all the vendordeps to 2027 alpha
• Begin exploring breaking changes
• Update from Commands v2 to v3
• Implement OpModes

WPILib 2027 alpha:
https://github.com/wpilibsuite/SystemcoreTesting

Documentation:
https://docs.wpilib.org/en/2027/

[nlaverdure]

Progress so far (branch `main-2027`)

Three commits landed, merging the WPILib import-wizard's regenerated 2027.0.0-alpha-6 / Systemcore scaffolding into this repo (preserving history rather than starting from the wizard's fresh output folder):

1. Build scaffolding — `org.wpilib.GradleRIO 2027.0.0-alpha-6`, Gradle 9.4.1 wrapper, Systemcore deploy target, `shadowJar`, Java 25, new `first.Main` entry point, `CommandsV2.json` vendordep added (replacing `WPILibNewCommands.json`). Kept Biocore-specific customizations (gversion, spotless, AdvantageKit annotation processor, sim GUI default-disabled).
2. Package rename — `edu.wpi.first.` → `org.wpilib.` across all 46 source files (227 occurrences), with `edu.wpi.first.wpilibj2.command.` → `org.wpilib.commandsv2.`.
3. Vendordep bumps — REVLib → 2027.0.0-alpha-3, photonlib → v2027.0.0-alpha-2, AdvantageKit → 27.0.0-alpha-3, ReduxLib → 2027.0.0-alpha-2 (renamed file to drop the old version-suffixed name).

Current blocker

`./gradlew build` fails during plugin application:

Vendor Dependency ReduxLib has invalid year null. Expected to be 2027_alpha5.

GradleRIO 2027-alpha-6 requires every vendordep's `wpilibYear` field to equal `2027_alpha5`. 5 of 8 vendordeps fail this check:

• AdvantageKit (27.0.0-alpha-3) and ReduxLib (2027.0.0-alpha-2) still ship the old `frcYear: "2027_alpha1"` field name/value — alpha-1-era builds, ABI compatibility with alpha-6 unverified.
• Phoenix6, PathplannerLib, ChoreoLib are still on 2026 builds (`edu.wpi.first.*`-based) — no 2027-alpha-compatible release exists yet for any of the three.

This is a vendor-availability gap, not something we can configure around — patching the `wpilibYear` field ourselves would be an unsupported workaround per WPILib's own warning in the vendordep JSON.

Next steps once blockers clear

• Re-check vendor release feeds (vendor-json-repo, each vendor's own GitHub releases / maven) for `2027_alpha5`/alpha-6-compatible builds of Phoenix6, PathplannerLib, ChoreoLib, and updated AdvantageKit/ReduxLib.
• Resolve an open question in `Robot.java`: `org.wpilib.wpilibj.RobotBase` vs `org.wpilib.framework.RobotBase` (the new `first.Main` template uses the latter).
• Run `spotlessApply` to fix import ordering after the mechanical package rename.
• Attempt a full `./gradlew build`, fix any remaining compile errors, then proceed to the "explore breaking changes / new features" checklist item.
• Separately, see Reorganize frc.lib and frc.robot.util into cohesive packages #12 for a proposed `frc.lib`/`frc.robot.util` repackaging — flagged as follow-up cleanup, not blocking this issue.

[nlaverdure]

main-2027-alpha2 sandbox — build now passing ✅

While main-2027 remains blocked on vendor availability (see previous comment), I created a parallel branch targeting the earlier WPILib 2027.0.0-alpha-2 tier, where all 8 vendordeps already have compatible builds. All compile errors are now resolved.

What was fixed (13 commits)

Breaking change	Fix
@AutoLog codegen — javapoet missing from annotationProcessor classpath	Added explicit annotationProcessor "com.squareup:javapoet:1.13.0" + pre-generated *AutoLogged classes
SwerveModulePosition.distanceMeters / SwerveModuleState.speedMetersPerSecond renamed	→ .distance / .speed
ChassisSpeeds.discretize() / fromFieldRelativeSpeeds() static → instance methods	→ speeds.discretize(dt) / speeds.toRobotRelative(rot)
FRCNetComm package removed	→ HAL.reportUsage("RobotDrive", "SwerveAdvantageKit")
DCMotor.freeSpeedRadPerSec renamed	→ .freeSpeed
AprilTagFields.k2026RebuiltAndymark removed	→ kDefaultField
DriverStation.getStickPOV() returns POVDirection enum	→ .name() for string logging
LiveWindow.disableAllTelemetry() removed	Deleted call
AddressableLED.start() removed	setData() now auto-activates; removed start()/startAll()
PowerDistribution/Compressor constructor changes	Added busId parameter to LoggedPowerDistribution and LoggedCompressor
CAN bus reorganization for SystemCore	Renamed CAN2→SC0, CANHD→SC1; replaced CANBus.roboRIO() / new CANBus("canivore") with CANBus.systemCore(int)
DCMotorSim getter renames	getAngularPositionRad() → getAngularPosition(), etc.
Commands.waitSeconds() removed	→ Commands.waitTime(Seconds.of(...))
Command.schedule() deprecated-for-removal	→ CommandScheduler.getInstance().schedule()

Toolchain changes

The ReduxLib 2027.0.0-alpha-2 JAR was compiled for Java 21, which required a JDK upgrade. The bundled WPILib 2026 JDK (Java 17) was insufficient. The solution:

• Gradle wrapper: 8.11 → 9.4.1 (matches WPILib 2027_alpha5 toolchain; required for JDK 25 support)
• JDK: WPILib 2027_alpha5 bundle (JDK 25) at C:\Users\Public\wpilib\2027_alpha5\jdk
• google-java-format: explicit version 1.28.0 (the spotless default crashes on JDK 25 due to a removed internal JDK API)

Build command: JAVA_HOME="C:/Users/Public/wpilib/2027_alpha5/jdk" ./gradlew compileJava

What's next

The alpha-2 branch serves as a sim-only sandbox to explore 2027 API patterns. Known remaining gaps (not blocking sim):

• main-2027 (alpha-6) remains blocked on Phoenix6 / PathPlannerLib / ChoreoLib vendor availability
• Commands v2 → v3 migration (alpha-5+ only)
• New OpMode framework adoption

[nlaverdure]

Thoughts about OpModes

WPILib design document

• Question: Can OpModes be used in place of feature flags? i.e. If inheritance is allowed between OpModes, we could make an OpMode that adds controls or behaviors to a more basic OpMode.
• Places where OpModes could be useful:
  • for verbose logging to NT, e.g. during at-home testing
  • for testing specific subsystems/behaviors in isolation, e.g. for tuning via dashboards, characterization routines (SysID)
  • for automated testing in pit
  • for public demos, i.e. with reduced speeds
• Reminder: Make sure all non-competition OpModes are designated as "Utility" modes so that they cannot be selected for a match.

ChiefDelphi discussion