Versionshinweise finden Sie hier.
Referenz- und API-Dokumentation für den Java-Treiber finden Sie hier.
Referenz- und API-Dokumentation für den Kotlin-Treiber finden Sie hier.
Referenz- und API-Dokumentation für den Scala-Treiber finden Sie hier.
Tutorials zur Verwendung der MongoDB-JVM-Treiber finden Sie unter MongoDB University. Weitere Tutorials, Videos und Codebeispiele zur Verwendung des Java-Treibers und des Kotlin-Treibers finden Sie auch im MongoDB Developer Center.
Bei Problemen mit, Fragen oder Feedback zu den MongoDB Java-, Kotlin- und Scala-Treibern schauen Sie bitte in unsere Supportkanäle. Bitte senden Sie keine E-Mails direkt an einen der Treiberentwickler, wenn Sie Probleme oder Fragen haben. Die Wahrscheinlichkeit ist höher, dass Sie eine Antwort in den MongoDB-Community-Foren oder bei StackOverflow erhalten.
Bitte geben Sie in Ihrer Beschreibung mindestens die genaue Version des Treibers an, den Sie verwenden. Wenn Sie Verbindungsprobleme haben, ist es oft auch sinnvoll, die Codezeile, in der Sie die MongoClient-Instanz erstellen, zusammen mit den Werten aller Parameter einzufügen, die Sie an den Konstruktor übergeben. Sie sollten auch Ihre Anwendungsprotokolle auf konnektivitätsbezogene Ausnahmen überprüfen und diese ebenfalls veröffentlichen.
Denken Sie, Sie haben einen Fehler in den Java-, Kotlin- oder Scala-Treibern gefunden? Möchten Sie eine neue Funktion in den Treibern sehen? Bitte eröffnen Sie einen Fall in unserem Issue-Management-Tool JIRA:
Fehlerberichte in JIRA für den Treiber und das Core Server-Projekt (d. h. SERVER) sind öffentlich .
Wenn Sie eine Sicherheitslücke in einem Treiber oder einem anderen MongoDB-Projekt festgestellt haben, melden Sie diese bitte gemäß den Anweisungen hier.
Größere Inkremente (z. B. 4.x -> 5.x) werden auftreten, wenn wichtige Änderungen an der öffentlichen API vorgenommen werden. Alle in einer Hauptversion entfernten Methoden und Klassen sind in einer früheren Version des vorherigen Hauptversionszweigs veraltet und/oder werden in den Versionshinweisen anderweitig erwähnt.
Kleinere 5.x-Inkremente (z. B. 5.1, 5.2 usw.) werden auftreten, wenn nicht triviale neue Funktionen hinzugefügt werden oder wesentliche Verbesserungen oder Fehlerbehebungen vorgenommen werden, die zu Verhaltensänderungen führen können, die sich auf einige Randfälle auswirken können (z. B. die Abhängigkeit vom Verhalten, die sich daraus ergibt). ein Fehler). Ein Beispiel für eine Erweiterung ist eine Methode oder Klasse, die hinzugefügt wurde, um neue Funktionen zu unterstützen, die dem MongoDB-Server hinzugefügt wurden. Nebenversionen sind fast immer binärkompatibel mit früheren Nebenversionen desselben Hauptversionszweigs, außer wie unten angegeben.
Patch 5.xy-Inkrementierungen (z. B. 5.0.0 -> 5.0.1, 5.1.1 -> 5.1.2 usw.) erfolgen nur für Fehlerbehebungen und sind immer binärkompatibel mit früheren Patch-Versionen desselben Nebenversionszweigs .
APIs, die mit der @Alpha
-Annotation gekennzeichnet sind, befinden sich in einem frühen Entwicklungsstadium, können in einer zukünftigen Version inkompatible Änderungen erfahren oder sogar entfernt werden und möglicherweise fehlen einige beabsichtigte Funktionen. Eine API mit @Alpha
-Annotation kann bekannte Probleme enthalten, die sich auf Funktionalität, Leistung und Stabilität auswirken. Sie sind außerdem von jeglichen Kompatibilitätsgarantien der enthaltenen Bibliothek ausgenommen.
Es ist nicht ratsam, dass Anwendungen Alpha-APIs in Produktionsumgebungen verwenden oder dass Bibliotheken (die außerhalb der Kontrolle der Bibliotheksentwickler in die CLASSPATHs der Benutzer aufgenommen werden) von diesen APIs abhängig sind. Alpha-APIs sind nur für experimentelle Zwecke gedacht.
APIs, die auf Klassen- oder Methodenebene mit der Annotation @Beta
gekennzeichnet sind, können geändert werden. Sie können jederzeit beliebig geändert oder sogar entfernt werden. Wenn Ihr Code selbst eine Bibliothek ist (d. h. er wird im CLASSPATH von Benutzern außerhalb Ihrer eigenen Kontrolle verwendet), sollten Sie keine Beta-APIs verwenden, es sei denn, Sie packen sie neu (z. B. durch Verwendung von Schattierungen usw.).
APIs, die auf Klassen- oder Methodenebene mit der Annotation @Deprecated
gekennzeichnet sind, bleiben bis zur nächsten Hauptversion unterstützt, es wird jedoch empfohlen, sie nicht mehr zu verwenden.
Der gesamte Code in den com.mongodb.internal.*
Paketen gilt als private API und sollte überhaupt nicht als verlässlich angesehen werden. Es kann sich jederzeit ändern.
Informationen zu Binärdateien und Abhängigkeiten für Maven, Gradle, Ivy und andere finden Sie unter http://search.maven.org.
Beispiel für Maven:
< dependency >
< groupId >org.mongodb</ groupId >
< artifactId >mongodb-driver-sync</ artifactId >
< version >x.y.z</ version >
</ dependency >
Snapshot-Builds werden auch regelmäßig über Sonatype veröffentlicht.
Beispiel für Maven:
< repositories >
< repository >
< id >sonatype-snapshot</ id >
< url >https://oss.sonatype.org/content/repositories/snapshots/</ url >
</ repository >
</ repositories >
Zum Erstellen und Kompilieren der Quelle sind Java 17+ und Git erforderlich. So erstellen und testen Sie den Treiber:
$ git clone https://github.com/mongodb/mongo-java-driver.git
$ cd mongo-java-driver
$ ./gradlew check
Für die Testsuite muss Mongod mit enableTestCommands
ausgeführt werden, was mit dem Befehlszeilenparameter --setParameter enableTestCommands=1
festgelegt werden kann:
$ mkdir -p data/db
$ mongod --dbpath ./data/db --logpath ./data/mongod.log --port 27017 --logappend --fork --setParameter enableTestCommands=1
Wenn beim Ausführen der Tests die Fehlermeldung "Too many open files"
auftritt, müssen Sie die Anzahl der verfügbaren Dateideskriptoren erhöhen, bevor Sie mongod starten, wie unter https://www.mongodb.com/docs/manual/reference/ulimit beschrieben /
Um den Code in IntelliJ auszuführen, sind einige manuelle Konfigurationsschritte erforderlich:
Zum Erstellen und Kompilieren der Quelle ist Java 17+ erforderlich.
Fehler: java: cannot find symbol: class SNIHostName location: package javax.net.ssl
Fix: Einstellungen/Einstellungen > Build, Ausführung, Bereitstellung > Compiler > Java-Compiler – deaktivieren Sie „Option ‚--release‘ für Cross-Compilation verwenden (Java 9 und höher)“
Fehler: java: package com.mongodb.internal.build does not exist
Korrekturen: Eines der folgenden:
generateBuildConfig
aus: z. B.: ./gradlew generateBuildConfig
oder über Gradle > Driver-Core > Tasks > Buildconfig > GenerateBuildConfiggenerateBuildConfig
so ein, dass es vor dem Build ausgeführt wird. über Gradle > Aufgaben > Buildconfig > Rechtsklick auf „GenerateBuildConfig“ – klicken Sie auf „Vor Build ausführen“