This open source library is intended for implementing bots on Discord using the real-time gateway and REST API. It provides event based functionality to implement bots of any kind, allowing for effective and scalable applications.
The core concepts of JDA have been developed to make building scalable apps easy:
- Event System
Providing simplified events from the gateway API, to respond to any platform events in real-time without much hassle. - Rest Actions
Easy to use and scalable implementation of REST API functionality, letting you choose between callbacks with combinators, futures, and blocking. The library also handles rate-limits imposed by Discord automatically, while still offering ways to replace the default implementation. - Customizable Cache
Trading memory usage for better performance where necessary, with sane default presets to choose from and customize.
You can learn more by visiting our wiki or referencing our Javadocs.
This library is available on maven central. The latest version is always shown in the GitHub Release.
The minimum java version supported by JDA is Java SE 8. JDA also uses JSR 305 to support solid interoperability with Kotlin out of the box.
repositories {
mavenCentral()
}
dependencies {
implementation("net.dv8tion:JDA:$version") { // replace $version with the latest version
// Optionally disable audio natives to reduce jar size by excluding `opus-java`
// Gradle DSL:
// exclude module: 'opus-java'
// Kotlin DSL:
// exclude(module="opus-java")
}
}<dependency>
<groupId>net.dv8tion</groupId>
<artifactId>JDA</artifactId>
<version>$version</version> <!-- replace $version with the latest version -->
<!-- Optionally disable audio natives to reduce jar size by excluding `opus-java`
<exclusions>
<exclusion>
<groupId>club.minnced</groupId>
<artifactId>opus-java</artifactId>
</exclusion>
</exclusions>
-->
</dependency>To use this library, you have to create an Application in the Discord Application Dashboard and grab your bot token. You can find a step-by-step guide for this in our wiki page Creating a Discord Bot.
We provide a number of examples to introduce you to JDA. You can also take a look at our official Wiki, Documentation, and FAQ.
Every bot implemented by JDA starts out using the JDABuilder or DefaultShardManagerBuilder. Both builders provide a set of default presets for cache usage and events it wants to receive:
createDefault- Enables cache for users who are active in voice channels and all cache flagscreateLight- Disables all user cache and cache flagscreate- Enables member chunking, caches all users, and enables all cache flags
We recommend reading the guide on caching and intents to get a feel for configuring your bot properly. Here are some possible use-cases:
Note
The following example makes use of the privileged intent GatewayIntent.MESSAGE_CONTENT, which must be explicitly enabled in your application dashboard. You can find out more about intents in our wiki guide.
Simply logging messages to the console. Making use of JDABuilder, the intended entry point for smaller bots that don't intend to grow to thousands of guilds.
Starting your bot and attaching an event listener, using the right intents:
public static void main(String[] args) {
JDABuilder.createLight(token, EnumSet.of(GatewayIntent.GUILD_MESSAGES, GatewayIntent.MESSAGE_CONTENT))
.addEventListeners(new MessageReceiveListener())
.build();
}Your event listener could look like this:
public class MessageReceiveListener extends ListenerAdapter {
@Override
public void onMessageReceived(MessageReceivedEvent event) {
System.out.printf("[%s] %#s: %s\n",
event.getChannel(),
event.getAuthor(),
event.getMessage().getContentDisplay());
}
}You can find a more thorough example with the MessageLoggerExample class.
This is a bot that makes use of interactions to respond to user commands. Unlike the message logging bot, this bot can work without any enabled intents, since interactions are always available.
public static void main(String[] args) {
JDA jda = JDABuilder.createLight(token, Collections.emptyList())
.addEventListeners(new SlashCommandListener())
.build();
// Register your commands to make them visible globally on Discord:
CommandListUpdateAction commands = jda.updateCommands();
// Add all your commands on this action instance
commands.addCommands(
Commands.slash("say", "Makes the bot say what you tell it to")
.addOption(STRING, "content", "What the bot should say", true), // Accepting a user input
Commands.slash("leave", "Makes the bot leave the server")
.setGuildOnly(true) // this doesn't make sense in DMs
.setDefaultPermissions(DefaultMemberPermissions.DISABLED) // only admins should be able to use this command.
);
// Then finally send your commands to discord using the API
commands.queue();
}An event listener that responds to commands could look like this:
public class SlashCommandListener extends ListenerAdapter {
@Override
public void onSlashCommandInteraction(SlashCommandInteractionEvent event) {
switch (event.getName()) {
case "say" -> {
String content = event.getOption("content", OptionMapping::getAsString);
event.reply(content).queue();
};
case "leave" -> {
event.reply("I'm leaving the server now!")
.setEphemeral(true) // this message is only visible to the command user
.flatMap(m -> event.getGuild().leave()) // append a follow-up action using flatMap
.queue(); // enqueue both actions to run in sequence (send message -> leave guild)
};
default -> return;
}
}
}You can find a more thorough example with the SlashBotExample class.
In this library, the RestAction interface is used as a request builder for all API endpoints. This interface represents a lazy request builder, as shown in this simple example:
channel.sendMessage("Hello Friend!")
.addFiles(FileUpload.fromData(greetImage)) // Chain builder methods to configure the request
.queue() // Send the request asynchronouslyImportant
The final call to queue() sends the request.
You can also send the request synchronously or using futures, check out our extended guide in the RestAction Wiki.
The RestAction interface also supports a number of operators to avoid callback hell:
map
Convert the result of theRestActionto a different valueflatMap
Chain anotherRestActionon the resultdelay
Delay the element of the previous step
As well as combinators like:
and
Require another RestAction to complete successfully, running in parallelallOf
Accumulate a list of many actions into one (see alsomapToResult)zip
Similar toand, but combines the results into a list
And configurators like:
timeoutanddeadline
Configure how long the action is allowed to be in queue, cancelling if it takes too longsetCheck
Running some checks right before the request is sent, this can be helpful when it is in queue for a whilereason
The audit log reason for an action
Example:
public RestAction<Void> selfDestruct(MessageChannel channel, String content) {
return channel.sendMessage("The following message will destroy itself in 1 minute!")
.addActionRow(Button.danger("delete", "Delete now")) // further amend message before sending
.delay(10, SECONDS, scheduler) // after sending, wait 10 seconds
.flatMap((it) -> it.editMessage(content)) // then edit the message
.delay(1, MINUTES, scheduler) // wait another minute
.flatMap(Message::delete); // then delete
}This could then be used in code:
selfDestruct(channel, "Hello friend, this is my secret message").queue();Created and maintained by MinnDevelopment.
Provides Kotlin extensions for RestAction and events that provide a more idiomatic Kotlin experience.
fun main() {
val jda = light(BOT_TOKEN)
jda.onCommand("ping") { event ->
val time = measureTime {
event.reply("Pong!").await() // suspending
}.inWholeMilliseconds
event.hook.editOriginal("Pong: $time ms").queue()
}
}There are a number of examples available in the README.
Created by sedmelluq and now maintained by the lavalink community
Lavaplayer is the most popular library used by Music Bots created in Java.
It is highly compatible with JDA and Discord4J and allows playing audio from
YouTube, Soundcloud, Twitch, Bandcamp and more providers.
The library can easily be expanded to more services by implementing your own AudioSourceManager and registering it.
We recommend to also use udpqueue in addition to lavaplayer, to avoid stuttering issues caused by GC pauses.
It is recommended to read the Usage section of Lavaplayer
to understand a proper implementation.
Sedmelluq provided a demo in his repository which presents an example implementation for JDA:
https://github.com/lavalink-devs/lavaplayer/tree/master/demo-jda
Created and maintained by sedmelluq and extended by MinnDevelopment
Provides a native implementation for the JDA Audio Send-System to avoid GC pauses potentially causing problems with continuous audio playback.
Note that this send-system creates an extra UDP-Client which causes audio receive to no longer function properly, since Discord identifies the sending UDP-Client as the receiver.
JDABuilder builder = JDABuilder.createDefault(BOT_TOKEN)
.setAudioSendFactory(new NativeAudioSendFactory());Created by Freya Arbjerg and now maintained by the lavalink community.
Lavalink is a popular standalone audio sending node based on Lavaplayer. Lavalink was built with scalability in mind, and allows streaming music via many servers. It supports most of Lavaplayer's features.
Lavalink is used by many large bots, as well as bot developers who can not use a Java library like Lavaplayer. If you plan on serving music on a smaller scale with JDA, it is often preferable to just use Lavaplayer directly as it is easier.
Lavalink-Client is the official Lavalink client for JDA.
If you want to contribute to JDA, make sure to base your branch off of our master branch (or a feature-branch) and create your PR into that same branch.
Please follow our Contributing Guidelines.
Do not expect your pull request to get immediate attention, sometimes it will take a long time to get a response. You can join our discord server and ask in #lib-dev before starting to work on a new PR, to get more immediate feedback from our community members.
Due to the nature of the Discord API, the library will regularly introduce breaking changes to allow for a quick adoption of newer features. We try to keep these breaking changes minimal, but cannot avoid them entirely.
Most breaking changes will result in a minor version bump (5.1.2 → 5.2.0).
