Using Kotlin instead of Java

Technical Programming
1

Has any team ever had issues with Kotlin?
Is it easy to gradually or completely implement Kotlin into projects?
What can I expect from using Kotlin?

Thank you.

2 Likes
2

Team 9432 decided to use Kotlin over java. Feel free to take a look at our robot code on GitHub.

It is quite easy to make the switch from Java to Kotlin as all the java libs work with kotlin. You should be able to start dropping .kt files into your existing robot project and it should still build without many issues (maybe some build.gradle changes required, but if so, not many.) We have had no issues with it. We did build an offseason robot before this year started so that our students could become familiar with the FRC world, and what it is like to design/build/program an FRC robot, and we programmed that in kotlin, I would advises doing the same if moving to kotlin is something you are interested in.

We are planning on cleaning up our code and documenting it better after Champs ends. But feel free to reach out with any questions and I will see if any of our students can answer your questions.

1 Like
3

Responding as someone who previously worked almost entirely in Kotlin on a software developer at Amazon, but has never used Kotlin for FRC. I wouldn’t bother switching. Kotlin is a great language and is absolutely better than Java in a vacuum, but it’s not what is predominantly used in FRC. Any example code online is going to be written in java, and WPILib makes it super easy to build your java code without messing with the gradle build system at all. The only real advantage Kotlin has over java for FRC is the conciseness of the language, but that’s such a small time save compared to the time you will spend converting some java code snippets you got online into kotlin. You can use a mix of the two languages and slowly switch over, but I would just stick with Java. Kotlin may be the future, but Java is still much more common, both in FRC and in the software development industry.

4 Likes
4

I personally haven’t used Kotlin for FRC related stuff, but it is pretty easy to drop into your code. Last year in 4290s code we had a single Kotlin file for a subsystem and it worked great. Just be prepared to have to “translate” anything coming from WPILib or most documentation

5

This year my team switched to Kotlin and it was a breeze, we used a prexisting template and used IntelliJ’s Java to Kotlin tool to convert our code and then started developing. Using Kotlin means you also stick to using the same libraries and (almost) the same Gradle build configuration as any other Java team. For native Kotlin support we used IntelliJ IDEA for native support and utilities for refactoring, but Visual Studio Code also works well with a extension.

The major reason why we chose it was for the nicer syntax, utilities, null safety and that I was realistically the only one programming the robot, and I had already knew the language from learning KTOR. We also had some Java code in the project too, but its recommended to make all your subsystems as Kotlin objects so there can only ever be one instance of the subsystem (so Commands and Utilities in Java are just fine).

If you have a team of Java programmers I would not switch unless the whole team is willing to take time to learn, but if you are building from the ground up its a really good option. We also won the Judges award from our implementation of Kotlin in robot code, and overall code cleanliness was great this year, so its certainly not just a gimmick and helped our performance overall this year.

4 Likes
6

What’s the process of using Kotlin? Does it really just work like any .java class? Can you use the Java imports as-is? What changes do you have to make to Gradle? Also, I tried Kotlin for a couple weeks for personal projects and I found that the Kotlin compiler took a lot longer than Java on my computer. (This may have been an individual issue I didn’t investigate at all) Is this the case for WPILib?

7

You will first need to add org.jetbrains.kotlin.jvm as a plugin in Gradle, as well as the org.jetbrains.kotlin:kotlin-stdlib-jdk8 dependency (reference code here). You may also need to change the JVM Toolchain in Gradle depending on your dependencies. IntelliJ does all of this automatically when converting a Java class to Kotlin.

image
image640Ă—1219 80.5 KB

Kotlin is a separate process in Gradle for compilation, but my bet is you were using Kotlin Native for your personal project. Kotlin is a multiplatform language, it can compile to WebAssembly, Native x86 Binary’s, Mobile Platforms and the Java Virtual Machine platform (which is used for robot programming). All of these platforms have varying compile times. Kotlin in the JVM only takes 2 seconds for me to compile with a reasonably sized project, so thats my best guess.

Kotlin exports back to a .class file like Java, so Java code can import Kotlin code and vise versa, so adopting it into a project isn’t hard. Code between Kotlin and Java after compilation is almost identical.

Hope that helps

1 Like
8

Yep, that’s pretty helpful, thanks! I’m not sure we’re going to use it but we’ll look into it and try it out.

2 Likes
9

This is super helpful, thanks. I tried it and ran into issues with mixing Kotlin and Java though. Would you be able to help?


I made a simple Kotlin class to test. `KtSubsystem.kt`: 
package frc.robot.subsystems;

import edu.wpi.first.wpilibj2.command.SubsystemBase
import edu.wpi.first.wpilibj.DutyCycleEncoder
import edu.wpi.first.wpilibj.smartdashboard.SmartDashboard

class KtSubsystem() : SubsystemBase() {
    private val encoder = DutyCycleEncoder(0)
    
    init {
        encoder.setDistancePerRotation(4.0)    
    }

    override fun periodic() {
        SmartDashboard.putNumber("Encoder value",encoder.get())
        SmartDashboard.putData(this)
    }
}

In `RobotContainer.java`: 
import frc.robot.subsystems.KtSubsystem;
...
public class RobotContainer {
    private final KtSubsystem m_ktSubsystem = new KtSubsystem();
    ...
}

It builds fine, but when I try to run the simulation, "KtSubsystem cannot be resolved to a type"
10

I took the time to understand and research more about Kotlin. I was able to successfully translate this year’s robot code from Java to Kotlin. Not only did I see more appealing syntax, the synthetic sugar for creating lambda expressions/using functional interfaces really caught my attention as well. However, I have classmates that are starting out for next year and they have been accustomed to Java in the past. I feel like teaching them FRC concepts and Kotlin at the same time would overwhelm them too much. I’m gonna discuss this with our sponsor and programmers and come to a conclusion whether to use Kotlin or not. We’ll see.

2 Likes
11

Can you upload your project on Github and send a link? It would be easier for me to debug from there.

12

Yep, here:

13

Team 3268’s been using Kotlin since 2023. Our experience has mostly been good, mostly due to the cleaner syntax + null safety. Much less boilerplate than Java or C++. On the other hand, there have been some hiccups with regards to the tooling for Kotlin, I think we had some issues updating to the 2024 version of WPILIB at the start of the 2024 season. VsCode has a “Kotlin for FRC” extension, though, which can generate a skeleton for a Kotlin FRC project. Once that’s done, you can work in the project as you would in Java.

1 Like
14

It works for me, what Java version are you running? JDK 17 just seems to work.

15 
$ java -version
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Debian-1deb12u1)
OpenJDK 64-Bit Server VM (build 17.0.10+7-Debian-1deb12u1, mixed mode, sharing)

The build looks like it works fine (all green, 100%, no errors), but when it tries to launch Sim GUI it fails. I added this from your code too:

kotlin {
    jvmToolchain(17)
}

Now it still says BUILD SUCCESSFUL but also Path for java installation '/usr/lib/jvm/openjdk-17' (Common Linux Locations) does not contain a java executable. Java is installed by default by Debian, and the path to it is /usr/bin/java.

16

We switched from Java to Kotlin right when the 2023 season ended. At first we struggled to get it to work in VSCode, but after we realized we could use IntelliJ IDEA instead, everything was a breeze. The switch was quite easy since Java and Kotlin are 100% compatible, and can use code written in the other language pretty seamlessly. This season (2024) we used Kotlin and it was great!

In my opinion Kotlin is a lot nicer to write in than Java. It’s more concise and readable, it’s null-safe, it has better support for functional programming than Java, and it has plenty of cool features that you can choose to use.

Our 2024 code is a little messy by my standards, but you’re welcome to take a look:

17

thank you so much

18

I’ve (mentor) tried to push kotlin (jvm) for 2022 after a few off season tests, but the team pushed back. We end up switching in 2023, as I have a lot of experience with kotlin it was a breeze.

We have our own template (which demands a lot of manual configuration because we are using kotlin script instead of groovy).

I really want to do a CoroutineRobot and a Compose based dashboard (perhaps a ComposeRobot?).

FYI there are tradeoffs. Kotlin will generate more code behind your back and will likely be less performant than Java.

repos for reference: