We are still using some of the “deprecated” features in WPILib, such as the PIDController. Our use of these features results in a whole bunch of “… has been deprecated …” warnings when compiling our code.
We’d like to silence these specific warnings in our build, so that they don’t “mask” other warnings that we’d like to see. The problem with having about 30 of the “deprecated” warnings is that it leads to bad programming practice of just ignoring all the warnings. It also makes it harder to find the “real errors” in the compile output logs.
Does anybody know how to silence or quiet these warnings? We seem to have two distinct types of these, some that mention 2020, and some that do not. A short except of some of these is shown below.
I’ve tried to use @SuppressWarnings to quiet these, but clearly haven’t found the right way to do so, as we always get either compiler errors or no helpful effect from doing so. Does anybody have a sample piece of code which quiets these warnings?
The type PIDController has been deprecated since version 2020 and marked for removal Java(16778626) [30,10]
The type PIDController has been deprecated since version 2020 and marked for removal Java(16778626) [96,22]
The method setInputRange(double, double) from the type PIDBase has been deprecated and marked for removal Java(67110265) [98,16]
...
Usually “Deprecated” means that there is a better alternative to do the same thing. This is, for example, the case with PIDController. There are currently two versions of the PIDController in WPILib. One is the one you were using in the edu.wpi.first.wpilibj package, which is deprecated. The new, improved version is located in the edu.wpi.first.wpilibj.controller package, which is now the recommended way. You just have to change the import statement, and the warning should be gone.
Other “deprecated” warnings should be very similar to this. In the documentation it usually says what to replace deprecated features with.
That will suppress all deprecation warnings in the compilation. We don’t recommend doing then unless you understand the connotations, but as long as you understand those classes might not be there next year, you can suppress the warnings.
Thanks for the tip. I don’t know if I put it in the wrong place, but it doesn’t seem to be having the desired effect – I’m still getting all the same deprecation warnings (a couple dozen of them) indicated in VS Code in the “Problems” section when I do a build.
Below is the build.gradle that we’re using.
plugins {
id "java"
id "edu.wpi.first.GradleRIO" version "2020.2.2"
}
sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11
def ROBOT_MAIN_CLASS = "frc.robot.Main"
// Define my targets (RoboRIO) and artifacts (deployable files)
// This is added by GradleRIO's backing project EmbeddedTools.
deploy {
targets {
roboRIO("roborio") {
// Team number is loaded either from the .wpilib/wpilib_preferences.json
// or from command line. If not found an exception will be thrown.
// You can use getTeamOrDefault(team) instead of getTeamNumber if you
// want to store a team number in this file.
team = frc.getTeamNumber()
}
}
artifacts {
frcJavaArtifact('frcJava') {
targets << "roborio"
// Debug can be overridden by command line, for use with VSCode
debug = frc.getDebugOrDefault(false)
}
// Built in artifact to deploy arbitrary files to the roboRIO.
fileTreeArtifact('frcStaticFileDeploy') {
// The directory below is the local directory to deploy
files = fileTree(dir: 'src/main/deploy')
// Deploy to RoboRIO target, into /home/lvuser/deploy
targets << "roborio"
directory = '/home/lvuser/deploy'
}
}
// Added by KBS on 22 Feb 2020 to turn off all deprecation warnings, as
// provided by Thad House. Should take out after 2020 competition season,
// and fix deprecated classes before 2021 kickoff
tasks.withType(JavaCompile) {
options.compilerArgs << '-Xlint:-deprecation'
}
}
// Set this to true to enable desktop support.
def includeDesktopSupport = false
// Defining my dependencies. In this case, WPILib (+ friends), and vendor libraries.
// Also defines JUnit 4.
dependencies {
implementation wpi.deps.wpilib()
nativeZip wpi.deps.wpilibJni(wpi.platforms.roborio)
nativeDesktopZip wpi.deps.wpilibJni(wpi.platforms.desktop)
implementation wpi.deps.vendor.java()
nativeZip wpi.deps.vendor.jni(wpi.platforms.roborio)
nativeDesktopZip wpi.deps.vendor.jni(wpi.platforms.desktop)
testImplementation 'junit:junit:4.12'
// Enable simulation gui support. Must check the box in vscode to enable support
// upon debugging
simulation wpi.deps.sim.gui(wpi.platforms.desktop, false)
}
// Setting up my Jar File. In this case, adding all libraries into the main jar ('fat jar')
// in order to make them all available at runtime. Also adding the manifest so WPILib
// knows where to look for our Robot Class.
jar {
from { configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) } }
manifest edu.wpi.first.gradlerio.GradleRIOPlugin.javaManifest(ROBOT_MAIN_CLASS)
}
It needs to be at the root level. It’s not part of the deploy setup, so it will do nothing in there.
That will not fix vscode, it will only fix the build itself. Suppressing the warnings in vscode is harder, and I’d have to dig in on how to make it happen.
Thanks, Thad, for the tip. I had originally had the new lines at the root level, but I didn’t think they weren’t working there. Turns out that they weren’t actually working there (see Joe’s addition below), but it also turns out that the “Problems” indicated in VS code window don’t come from the gradle build, but some sort of pre-processing build done in VS code, at least as far as I can tell.
Thanks, Joe, for the tip on adding “,-removal” to the options.compilerArgs field.
That seems to have fixed the issue in the gradle build when I invoke the build manually from the command line.
However, as you or Thad anticipated, it doesn’t seem to have had any effect on what is reported as “Problems” in VS Code. I’m afraid I don’t know enough about what is going on to understand. Are the VS Code “Problems” being generated from something other than the gradle build output? Seems like VS Code is doing some sort of separate pre-compilation?
That turned out to be the trick. The warnings coming from WPILib aren’t in the “deprecation” class of warnings, but in the “removal” class of warnings.
Turns out that putting
@SuppressWarnings("removal")
in front of class declarations has turned off the warnings for us in VSCode so that they don’t show up in our “Problems” frame.
PS: I also added a “TODO: Address all deprecated code masked by @SuppressWarnings(“removal”) annotations” so that we don’t forget about fixing these when we have some spare time and aren’t in a frenzy getting ready for our 1st event!
Vscode intellisense and the problem window are completely independent from the Gradle build. They don’t talk to each other and can do vastly different things (most ides are like this). So to suppress those warnings in vscode, you either need to suppress them in the source code, or configure the intellisense engine with those options as well. That happens with the props file in the .settings folder. You can look up the syntax for this by searching for eclipse buildship, which is the intellisense engine, but suppressing in code is a better option.
Thanks. I wish there were a way to have the @SuppressWarnings be even more specialized – that is, only pertaining to one line of code (rather than a whole class) or for only a specific error, but I couldn’t figure out how to do that.
Does anybody know what the long number on the warning line is? (i.e. 16778626 or 67110265) in my original posting (also see below). I’m presuming that is some sort of unique identifier for the warning – it seems to me there must be a way to suppress only that specific warning ID, but I can’t find it.
The type PIDController has been deprecated since version 2020 and marked for removal Java(16778626) [30,10]
The type PIDController has been deprecated since version 2020 and marked for removal Java(16778626) [96,22]
The method setInputRange(double, double) from the type PIDBase has been deprecated and marked for removal Java(67110265) [98,16]
The problem with method level suppression (for FRC code) is that you likely have a lot of methods to add the suppression to. (or the suppression is for the superclass and has to be on the class level)