2026-02-20 18:31:33 -05:00
|
|
|
[versions]
|
2026-06-11 02:50:01 -04:00
|
|
|
avaje = "3.14"
|
2026-02-20 18:31:33 -05:00
|
|
|
ejml = "0.44.0"
|
|
|
|
|
jmh = "1.37"
|
2026-04-27 01:31:14 -04:00
|
|
|
opencv = "2027-4.13.0-3"
|
2026-02-20 18:31:33 -05:00
|
|
|
quickbuf = "1.4"
|
|
|
|
|
|
|
|
|
|
[libraries]
|
|
|
|
|
# General runtime dependencies
|
Change Java JSON to Avaje Jsonb (#8721)
Jackson is a very heavy library; it supports loads of features that we
don't need, and historically has caused issues due to long class loading
times (a little over 2 seconds to load AprilTagFieldLayout). This often
manifests as a help request in the form of "my robot disables when I do
X, but doesn't disable when doing X in subsequent attempts until code
restart." While SC has brought down Jackson loading times significantly,
with AprilTagFieldLayout loads taking only 330 milliseconds, that's
still a rather long delay, and while libraries should handle any JSON
loading ahead of time to prevent delays in auto/teleop, it would still
be good to make the worst case better to reduce user frustration.
Benchmarks indicate using [Avaje
Jsonb](https://github.com/avaje/avaje-jsonb) to load AprilTagFieldLayout
only takes ~70 ms, a fair chunk of which isn't actually in Avaje Jsonb
(~4 ms is spent on using getResourceAsStream to retrieve the JSON file,
~8 ms is spent on just loading the AprilTag class and its dependencies).
Note that all times listed are end-to-end, meaning nothing else was done
except for the operation being benchmarked, and doing arithmetic on them
can be flawed due to some classes being loaded twice, i.e.,
getResourceAsStream and `new AprilTag()` likely load some of the same
JDK classes and so subtracting both from the Avaje Jsonb load time is
likely slightly incorrect because class loading is being double counted.
For our purposes, it's likely accurate enough and is mostly just for
contextualization.
Benchmarks were run on a Raspberry Pi CM5 with 2 GB of RAM. Source code
for the
[results](https://github.com/user-attachments/files/26471452/benchmark.txt)
can be found in the "Fastjson2" commit
(2456d15ca8ebd17635e607cd40bf8816e77869a1).
Avaje Jsonb uses code generation via annotation processors to generate
the classes needed to do JSON serde and uses service providers to find
them, which will require downstream changes in robot projects, as the
different service providers in each library must be merged together for
Avaje Jsonb to function. We will use the Gradle shadow plugin, as its
already used by the installer and therefore adds zero additional
dependencies.
2026-04-11 02:21:00 -04:00
|
|
|
avaje-jsonb = { module = "io.avaje:avaje-jsonb", version.ref = "avaje" }
|
|
|
|
|
avaje-jsonb-generator = { module = "io.avaje:avaje-jsonb-generator", version.ref = "avaje" }
|
2026-02-20 18:31:33 -05:00
|
|
|
ejml-simple = { module = "org.ejml:ejml-simple", version.ref = "ejml" } # also pulls in other EJML modules as transitive dependencies
|
|
|
|
|
gson = { module = "com.google.code.gson:gson", version = "2.13.1" }
|
|
|
|
|
quickbuf-runtime = { module = "us.hebi.quickbuf:quickbuf-runtime", version.ref = "quickbuf" }
|
2026-04-27 01:31:14 -04:00
|
|
|
thirdparty-opencv = { module = "org.wpilib.thirdparty.opencv:opencv-java", version.ref = "opencv" }
|
2026-02-20 18:31:33 -05:00
|
|
|
|
|
|
|
|
# General test dependencies
|
|
|
|
|
compile-testing = { module = "com.google.testing.compile:compile-testing", version = "0.23.0" }
|
|
|
|
|
jmh-annotationprocessor = { module = "org.openjdk.jmh:jmh-generator-annprocess", version.ref = "jmh" }
|
|
|
|
|
jmh-core = { module = "org.openjdk.jmh:jmh-core", version.ref = "jmh" }
|
|
|
|
|
junit-api = { module = "org.junit.jupiter:junit-jupiter", version = "5.13.4" }
|
|
|
|
|
junit-launcher = { module = "org.junit.platform:junit-platform-launcher", version = "1.10.1" }
|
|
|
|
|
mockito-core = { module = "org.mockito:mockito-core", version = "4.1.0" }
|
|
|
|
|
|
|
|
|
|
# buildsrc dependencies
|
|
|
|
|
# Note that these are also Gradle plugins and cannot be used with the plugin specification
|
|
|
|
|
# due to their presence on the classpath without version information.
|
|
|
|
|
wpilib-gradle-vscode = { module = "org.wpilib:gradle-cpp-vscode", version = "2027.0.0" }
|
2026-06-08 19:21:33 -07:00
|
|
|
wpilib-native-utils = { module = "org.wpilib:native-utils", version = "2027.8.2" }
|
2026-02-20 18:31:33 -05:00
|
|
|
|
|
|
|
|
[bundles]
|
|
|
|
|
ejml = ["ejml-simple"]
|
|
|
|
|
mockito = ["mockito-core"]
|
|
|
|
|
# junit api and launcher artifacts are different dependency types (implementation and runtime, respectively),
|
|
|
|
|
# so it doesn't make sense to bundle them in a single "junit" bundle
|
|
|
|
|
# Similar logic applies for JMH
|
|
|
|
|
|
|
|
|
|
[plugins]
|
2026-04-12 22:03:50 -07:00
|
|
|
build-shadow = { id = "com.gradleup.shadow", version = "9.4.1" }
|
|
|
|
|
lint-errorprone = { id = "net.ltgt.errorprone", version = "5.1.0" }
|
|
|
|
|
lint-spotbugs = { id = "com.github.spotbugs", version = "6.4.12" }
|
|
|
|
|
lint-spotless = { id = "com.diffplug.spotless", version = "8.4.0" }
|
2026-02-20 18:31:33 -05:00
|
|
|
|
|
|
|
|
wpilib-gradle-jni = { id = "org.wpilib.GradleJni", version = "2027.0.0" }
|
|
|
|
|
# Note: these plugins can't be used. Their JARs are on the classpath for buildSrc,
|
|
|
|
|
# which doesn't retain version information.
|
|
|
|
|
# wpilib-gradle-vscode = { id = "org.wpilib.GradleVsCode", version = "2027.0.0" }
|
2026-06-08 19:21:33 -07:00
|
|
|
# wpilib-native-utils = { id = "org.wpilib.NativeUtils", version = "2027.8.2" }
|
2026-02-20 18:31:33 -05:00
|
|
|
wpilib-repositories = { id = "org.wpilib.WPILibRepositoriesPlugin", version = "2027.0.0" }
|
|
|
|
|
wpilib-versioning = { id = "org.wpilib.WPILibVersioningPlugin", version = "2027.0.1" }
|