Establish the Java Evidence Boundary

This bridge assumes you already know how to write, compile, and run Java. Week 1 is not a second Java introduction. Its job is to establish what Java evidence can prove before we compare it with WPILib, ROS 2, simulation, and physical robot evidence.

Use a minimal application:

public class RobotStatus {
  public static void main(String[] args) {
    int batteryPercent = 42;
    System.out.println("battery=" + batteryPercent);
  }
}

Compile and run it in a real Java environment:

javac RobotStatus.java
java RobotStatus

Expected output:

battery=42

What each artifact proves

Treat the execution path as separate evidence boundaries:

source
→ compiler acceptance
→ bytecode
→ JVM execution
→ observed process output

A successful compile supports this claim:

The compiler accepted this source under the Java environment used for the test.

A successful run supports this stronger but still bounded claim:

The JVM executed the compiled application and the process emitted battery=42.

Neither result proves that a robot battery is physically at 42 percent.

The number was assigned in source code. No sensor, WPILib hardware abstraction, ROS 2 node, DDS endpoint, or physical controller produced it.

Separate software state from robot state

This statement is defensible:

The Java process stored integer 42 and printed it.

This statement is not:

The robot battery is at 42%.

The second claim crosses from application evidence into physical-system evidence without an observed interface.

That distinction governs the rest of the course.

Four evidence layers you will keep separate

Java / JVM evidence

Examples:

• compiler result;
• JUnit result;
• exception or stack trace;
• application log;
• deterministic object state.

Java robotics framework evidence

Examples:

• WPILib project build;
• subsystem or command behavior;
• HAL/simulation result;
• WPILib data log;
• framework lifecycle observation.

ROS 2 runtime evidence

Examples:

• node discovery;
• topic type/endpoints;
• QoS profiles;
• service/action availability;
• package/launch/runtime inspection.

Physical robot evidence

Examples:

• measured sensor state;
• controller telemetry;
• actuator response;
• wiring/power observation;
• physical motion under a defined test.

Evidence from one layer does not automatically promote a claim into another.

Boundary exercise

Classify each claim by the strongest evidence layer required:

1. RobotStatus.java compiled successfully.
2. ObstacleGuardTest passed for 0.49, 0.50, and 0.51 m.
3. A WPILib subsystem entered the expected simulated state.
4. /scan has one publisher using sensor_msgs/msg/LaserScan.
5. A Java process and a ROS 2 node exchanged data through an implemented bridge.
6. A motor physically stopped after an obstacle entered the caution zone.

For each claim, name the observation that would justify it.

Evidence record

Create a small table:

Add at least three more rows using WPILib, ROS 2, integration, or physical-system claims.

Exit criterion

You are ready for the next lesson when you can explain this sentence without hand-waving:

A successful Java program run proves something about that Java execution. It does not prove that WPILib, ROS 2, a bridge between them, or physical robot hardware behaved unless those layers were directly observed.

The rest of the bridge is an exercise in preserving that boundary while the system becomes more complicated.