[epilogue] Sporadic runtime errors

[BR88C]

Generated Epilogue logging classes unpredictably throw runtime errors.

Project setup

Robot.java

```java @Logged public final class Robot extends TimedRobot { private final ExampleSubsystem exampleSubsystem; public Robot() { exampleSubsystem = new ExampleSubsystem(); } @Override public void robotPeriodic() { Epilogue.update(this); } } ```

ExampleSubsystem.java

```java @Logged public class ExampleSubsystem extends SubsystemBase { private int foo = 0; public void setFoo(int newFoo) { foo = newFoo; } public int getFoo() { return foo; } } ```

robot/
  subsystems/
    ExampleSubsystem.java
  Main.java
  Robot.java

This example when run in simulation typically throws an error at startup.

Error at org.team340.robot.RobotLogger.update(RobotLogger.java:32): Unhandled exception: java.lang.Error: Unresolved compilation problem: 
        exampleSubsystemLogger cannot be resolved or is not a field

        at org.team340.robot.RobotLogger.update(RobotLogger.java:32)
        at org.team340.robot.RobotLogger.update(RobotLogger.java:1)
        at edu.wpi.first.epilogue.logging.ClassSpecificLogger.tryUpdate(ClassSpecificLogger.java:64)
        at edu.wpi.first.epilogue.Epilogue.update(Epilogue.java:35)
        at org.team340.robot.Robot.robotPeriodic(Robot.java:70)
        at edu.wpi.first.wpilibj.IterativeRobotBase.loopFunc(IterativeRobotBase.java:400)
        at edu.wpi.first.wpilibj.TimedRobot.startCompetition(TimedRobot.java:131)
        at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:350)
        at edu.wpi.first.wpilibj.RobotBase.lambda$startRobot$0(RobotBase.java:418)
        at java.base/java.lang.Thread.run(Thread.java:842)

The behavior is sporadic; making a code change and rebuilding + restarting the simulation will occasionally fix the issue temporarily. ./gradlew clean has also occasionally solved it, at worst I have gone as far as manually purging all build directories (.gradle/, bin/, build/) to resolve runtime errors. Repeatedly rebuilding without any intervention does not mitigate the issue. If ExampleSubsystem is excluded, issues are much more seldom but still occur. Runtime errors are sensibly reflected in bin/generated-sources/, but interestingly artifacts in build/generated/sources/ never have problems. I'm not an expert on how annotation processors and gradle interact in the slightest, however my blind intuition is that there exists a race condition between Epilogue finishing logger generation and gradle compiling.

Desktop

• OS: Windows 11
  • build.gradle:

    
    plugins {
    id "java"
    id "edu.wpi.first.GradleRIO" version "2025.0.0-alpha-2"
    }

wpi.maven.useLocal = false wpi.maven.useDevelopment = true wpi.versions.wpilibVersion = '2025.+' wpi.versions.wpimathVersion = '2025.+'

// ...

dependencies { annotationProcessor wpi.java.deps.wpilibAnnotations() implementation wpi.java.deps.wpilib() implementation wpi.java.vendor.java() // ... }

 - Project Information:

Project Version: 2025.0.0-alpha-2 VS Code Version: 1.85.1 WPILib Extension Version: 2024.3.2 C++ Extension Version: 1.20.0 Java Extension Version: 1.26.2023121408 Java Debug Extension Version: 0.55.2023121302 Java Dependencies Extension Version 0.23.2023120100 Java Version: 17 Java Location: C:\Users\Public\wpilib\2024\jdk Vendor Libraries: WPILib-New-Commands (1.0.0)

*(Note that this behavior is also seen when using GradleRIO 2024.3.2)*

[SamCarlberg]

bin/generated-sources/

This is not a directory generated by Gradle. Generated sources are in build/generated/sources, which you report are correct. I don't know what would be generating this bin directory, nor why it would be included in the build and apparently overriding the correct files

[ThadHouse]

Thats the folder where the redhat Java extension compiles into. When running the debugger, it uses those files, and not the Jar compiled by gradle. We don't control that behavior.

[rzblue]

potential related issue: https://github.com/redhat-developer/vscode-java/issues/2981