Unit 1: Introduction
Unit 1 · Lesson 2
Introduction to Java
Before writing a single line, you need to understand what Java actually is, how it runs, and why FRC chose it. The five minutes you spend here will make every lesson in Unit 2 make more sense.
By the end of this lesson, you will:
- Explain what Java is and its three defining characteristics
- Describe what the JDK, JRE, and JVM are and how they relate to each other
- Trace the path from a
.javasource file to code running on the roboRIO - Explain why FRC uses Java rather than C++ or LabVIEW
- Identify the basic structural elements of a Java class
What Java Is
Java is a general-purpose programming language first released by Sun Microsystems in 1995. It was designed around three ideas that still define it today: it is object-oriented, statically typed, and compiled to platform-independent bytecode.
Each of those three characteristics matters specifically for FRC:
- Object-oriented means that code is organized into classes and objects. A
TalonFXis an object. ASwerveModuleis an object. ADriveSubsystemis an object. WPILib is built entirely around this model, so understanding OOP (Unit 4) is not optional — it is the language WPILib speaks. - Statically typed means every variable has a declared type, and the compiler enforces this at build time. If you try to put a motor speed (
double) where an encoder ID (int) is expected, the build fails with a clear error — before the robot ever sees the code. This is a feature, not a limitation. - Compiled to bytecode means Java source code is not compiled directly to machine instructions for a specific processor. Instead, it's compiled to bytecode — an intermediate format that a Java Virtual Machine (JVM) executes. Your laptop runs an x86 JVM. The roboRIO runs an ARM JVM. The same compiled code runs on both.
💡 "Write once, run anywhere"
This was Java's original marketing tagline — and it's directly relevant to FRC. Your robot code compiles on your Windows or Mac laptop, and the resulting .jar file runs unchanged on the roboRIO's ARM processor. Gradle and WPILib handle all the packaging automatically. You never have to think about cross-compilation — unless you're writing C++, which is one reason most teams choose Java.
JDK, JRE, and JVM
These three acronyms appear constantly in Java documentation and error messages. They're related but distinct — and confusing them leads to real debugging headaches. Click each card to learn the difference.
👇 Click each card to flip itJDK
Java Development Kit — tap to learn
What you use to write code
The full toolkit for Java development: the compiler (javac), debugging tools, documentation generators, and the JRE. WPILib bundles JDK 17 — this is the version your robot code must use. Never replace it with a system JDK.
JRE
Java Runtime Environment — tap to learn
What runs compiled code
Everything needed to execute Java programs: the JVM plus the standard class libraries. The roboRIO has a JRE installed as part of its OS image — that's what runs your FRCUserProgram.jar during a match. You can't write new code with a JRE alone.
JVM
Java Virtual Machine — tap to learn
The engine underneath
The layer that actually executes bytecode on a specific physical processor. There's an x86 JVM on your laptop and an ARM JVM on the roboRIO. JVM startup time is why the robot program takes a few seconds to appear in Driver Station after a deploy restarts it.
From Keystrokes to Robot Motion
Every time you press Deploy, your Java source code travels through a four-step pipeline before it controls any hardware. Click each stage below to understand what happens at that step.
Write
.java files
→
Compile
javac → .class
→
Package
Gradle → .jar
→
Deploy
SSH → roboRIO
→
Execute
JVM → hardware
← click a stage to learn what happens there
🔍 Event Note: Reading errors by pipeline stage
When something goes wrong during a deploy, the pipeline stage tells you exactly where to look. A red underline in VS Code is a Write failure. compileJava FAILED is a Compile failure. No robot found is a Deploy failure. Robot Code red in Driver Station after a confirmed deploy is an Execute failure. Teams that understand the pipeline diagnose these in seconds; teams that don't spend half their pit time looking in the wrong place.
Why FRC Uses Java
FRC supports three programming languages: Java, C++, and LabVIEW. Each has its place. Understanding why we're using Java — rather than just accepting it — makes you a more thoughtful programmer.
Java is the language of this course and the language used by most Championship-level FRC teams, including Team 2910, 6328, 1678, and 3015.
- Best community resources. Chief Delphi, WPILib Discord, and most open-source team code is Java. When you're stuck, the answer is almost always already out there in Java.
- WPILib's richest feature set. Some advanced WPILib features (like AdvantageKit integration and certain simulation tools) work best or exclusively in Java.
- Garbage collected. You don't manage memory manually — the JVM handles it. This removes an entire class of bugs that C++ programmers have to actively guard against.
- Good balance of power and accessibility. Java is statically typed (catches errors early) but doesn't require the low-level thinking C++ demands.
- Industry-standard. Java knowledge transfers directly to Android development, enterprise software, and backend systems — useful well beyond FRC.
C++ is the other major FRC language, used by some elite teams who need maximum performance or prefer direct memory control.
- Faster execution. C++ compiles directly to native machine code. For most FRC code, this difference is unmeasurable — but in computationally intensive algorithms (vision processing, state estimation), it can matter.
- Manual memory management. C++ gives you full control over memory — which means you can also corrupt it. Segmentation faults, memory leaks, and undefined behavior are real concerns that Java's garbage collector eliminates.
- Higher ceiling, steeper floor. Everything you can do in Java, you can do in C++ — and then some. But the path there is harder, and mistakes are less forgiving.
- Smaller FRC community. Fewer Chief Delphi threads, fewer public repos in C++. Finding help is harder.
- When to use it: If your team has experienced C++ engineers who can mentor students, or if you're working on systems that genuinely require native performance.
LabVIEW is National Instruments' graphical programming environment — the same tool used on the original FRC control system. You write code by connecting blocks visually rather than typing text.
- No typing required. Programming is done by dragging and connecting visual elements. Some students find this more intuitive initially.
- Tightly integrated with NI hardware. LabVIEW was designed around the NI ecosystem that the roboRIO originated from — some low-level hardware access is more direct.
- Very limited community. The FRC LabVIEW community is small and has shrunk significantly over the past decade. Finding help, examples, or open-source code is difficult.
- Hard to scale. LabVIEW code becomes difficult to organize and maintain as robot complexity grows. Large, multi-developer LabVIEW projects are challenging.
- No version control story. LabVIEW files are binary — they don't diff cleanly in Git, making collaboration and code review much harder.
- When to use it: Almost never for new programs. If your team has legacy LabVIEW code and no Java experience, a migration plan is worth considering.
| Java | C++ | LabVIEW | |
|---|---|---|---|
| Memory | Garbage collected | Manual | Managed by NI |
| Speed | Fast (JIT-compiled) | Fastest (native) | Slower |
| Error catching | Compile time | Compile + runtime | Runtime |
| Community resources | Largest | Medium | Small |
| Version control | ✓ Excellent | ✓ Excellent | ✗ Difficult |
| This course | ✓ Yes | — | — |
Your First Look at Java Code
You won't write this yet — that starts in Unit 2. But seeing the structure now, with an explanation of each piece, means Unit 2's syntax won't feel arbitrary. Click any highlighted element below to learn what it does.
Robot.java
// A minimal FRC robot class
package frc.robot;
import edu.wpi.first.wpilibj.TimedRobot;
import edu.wpi.first.wpilibj.XboxController;
public class Robot extends TimedRobot {
// A field: shared across all methods
private XboxController controller;
// Called once when the robot program starts
public void robotInit() {
controller = new XboxController(0);
}
// Called 50 times per second during TeleOp
public void teleopPeriodic() {
double speed = controller.getLeftY();
// use speed to drive motors (Unit 5)
}
}
package frc.robot;
import edu.wpi.first.wpilibj.TimedRobot;
import edu.wpi.first.wpilibj.XboxController;
public class Robot extends TimedRobot {
// A field: shared across all methods
private XboxController controller;
// Called once when the robot program starts
public void robotInit() {
controller = new XboxController(0);
}
// Called 50 times per second during TeleOp
public void teleopPeriodic() {
double speed = controller.getLeftY();
// use speed to drive motors (Unit 5)
}
}
← click any highlighted element to learn what it does
💡 Don't worry about understanding all of this yet
This code is here to show you the shape of Java, not to teach you every piece right now. By the end of Unit 2 you'll understand every line. By the end of Unit 4 you'll understand the design decisions behind it. By the end of Unit 5, you'll have written something like it yourself — except it'll actually move a robot.
Java on the roboRIO
The roboRIO is a real Linux computer running a real JVM. That JVM executes your code inside a tightly controlled loop — by default, once every 20 milliseconds (50 times per second). This loop timing is not a software choice you make; it's an architectural constraint of the WPILib runtime.
Everything you write in teleopPeriodic(), autonomousPeriodic(), and other periodic methods has to complete within that 20 ms window. If it doesn't, WPILib's watchdog fires, the Driver Station logs a warning, and in severe cases the robot disables itself. This is the hardware context that makes Java timing constraints real in a way that web or desktop development never does.
💡 JVM startup time
After a deploy, the roboRIO restarts the robot program service. The JVM takes 2–4 seconds to initialize before your code starts running — you'll see the Driver Station's Robot Code light go red, then green again. This is normal. What's not normal is if the Robot Code light never comes back green: that means your code crashed during initialization, typically a NullPointerException in robotInit(). The JVM startup delay is also why you should never rely on precise timing during the first seconds after enable — the JVM's JIT compiler is still warming up.
🔌 System Check
⚙️ No Hardware Required — But Verify Your Environment
This lesson is conceptual — no robot needed. But before Unit 2 begins, confirm your development environment is set up correctly from Unit 0:
- WPILib VS Code is installed and opens correctly. You should see the WPILib FRC icon in the sidebar Activity Bar.
- Java version is correct. Open a terminal inside WPILib VS Code and run
java -version. It should report openjdk 17. Any other version means you're using the wrong Java installation — your builds may silently use the wrong JDK. - A project exists from Unit 0. You need at least one TimedRobot project to reference in Unit 2. If you haven't created one yet, go back to Unit 0, Lesson 3 and do the Practice Prompt.
- The project builds successfully. Run WPILib: Build Robot Code on your Unit 0 project and confirm
BUILD SUCCESSFUL. A clean build confirms your JDK, Gradle, and vendor libraries are all correctly configured.
Knowledge Check
Click an answer to check your understanding.
You deploy your robot code successfully, but after the program restarts, the Driver Station's Robot Code light stays red for 4 seconds before turning green. What is the most likely explanation?
Why does the same compiled Java
.jar file run on your x86 laptop during simulation and on the roboRIO's ARM processor during competition, without any recompilation?A teammate argues that your team should switch to C++ because "it's faster." What is the most accurate response?
💪 Practice Prompt
Explore the Java Pipeline
- Open your TimedRobot project from Unit 0 in WPILib VS Code. Find
Robot.javain thesrc/main/java/frc/robot/folder. Compare it to the example in this lesson — what's different? What's the same? - Open a terminal in WPILib VS Code. Run
java -versionandjavac -version. Confirm both report version 17. If they don't, something is wrong with your environment — revisit Unit 0, Lesson 1. - Run WPILib: Build Robot Code. After a successful build, look in the
build/libs/folder of your project. Find the.jarfile that was created. This is the artifact that gets deployed to the roboRIO. How large is it in kilobytes? - In
Robot.java, find therobotInit()method. Add this single line inside it:System.out.println("Robot initialized!");. Build and deploy to your robot. Open the Driver Station's Messages tab. Do you see the printed message? This is your first Java program producing observable output on a real robot. - Bonus: Look up the WPILib Java API reference (from Unit 0, Lesson 5 resources). Find the
TimedRobotclass. What does the documentation say about the default loop period? What method would you call to change it?