Kotlin
Kotlin ist eine relativ neue JVM -Sprache, und seit 2011 entwickelt sich JetBrains aktiv.
Im Laufe der Jahre hat die Sprache in der Android -Community zunehmend Aufmerksamkeit erhalten und nach der Google IO 2017 -Konferenz zum heißesten Thema in der Android -Entwicklung geworden. Die Konferenz gab bekannt, dass Android Kotlin offiziell unterstützt.
Obwohl es bereits viele Artikel über Kotlin gibt, gibt es zwar nicht viele objektive Informationen, und viele Entwickler denken immer noch darüber nach, ob der Umzug nach Kotlin der richtige Weg ist.
Im Rest dieses Artikels werde ich versuchen, eine vollständigere Liste von Dingen zu erstellen, die bei der Bewertung von Kotlin als Alternative zu Java zu beachten sind.
Subjektiver Vergleich zwischen Kotlin und Java
"Kotlin ist besser als Java", "Kotlin ist lesbarer als Java", "Kotlin -Entwicklungsgeschwindigkeit ist schneller als Java", Aussagen wie diese fehlt die Unterstützung relevanter genauer Daten, sodass sie alle als subjektive Ansichten eingestuft werden.
Eine subjektive Sichtweise wird gebildet, wenn ein einzelner Entwickler ein oder mehrere subjektive Urteile über Themen im Zusammenhang mit Kotlin oder Java fasst.
Es gibt Probleme mit den folgenden subjektiven Urteilen von Entwicklern:
Es gibt keine quantitativen Indikatoren, die mit subjektivem Urteil verbunden sind.
Es gibt große Vorurteile im subjektiven Urteil.
Die Tendenz des subjektiven Urteils variiert von Entwicklern stark.
Da es keine quantitativen Metriken gibt, die mit subjektiven Urteilen verbunden sind, spiegeln die Perspektiven, die auf diesen Urteilen beruhen, nur die Vorurteile wider, die Entwickler zuvor hatten. Unterschiedliche Entwickler haben möglicherweise sehr unterschiedliche Vorurteile, so dass auch andere Entwickler dies auch denken.
Da es keine objektiven Indikatoren gibt, können subjektive Unterschiede nicht objektiv beseitigt werden, was häufig zu "Kriegskrieg" führt.
Irrtum des subjektiven Urteils
Um die Missverständnisse zu veranschaulichen, zu denen subjektive Urteile führen können, sehen wir uns eine sehr häufige subjektive Sichtweise genauer an:
Kotlin ist lesbarer als Java - unzählige Artikel im Web
Theoretisch ist es möglich, ein Experiment zu entwerfen, das den Unterschied in der Lesbarkeit zwischen Kotlin und Java misst, aber soweit ich weiß, macht niemand wirklich ein solches Experiment. Ab sofort hat diese Ansicht keine Datenunterstützung.
Kotlins Syntax ist ein Grund, warum viele Entwickler seine Lesbarkeit loben. Ihre Logik ist wie folgt:
Kotlin hat eine bessere Syntax, es ist also lesbarer - unzählige Artikel im Web
In diesem Satz ist "bessere Grammatik" ein weiteres subjektives Urteil, das selbst umstritten ist, aber um Argumente zu vermeiden, gehen wir davon aus, dass Kotlins Grammatik tatsächlich besser ist. Bedeutet dies jedoch, dass Kotlin lesbarer ist?
Lesen Sie diesen Absatz von "Text", um den Effekt der Syntax auf die Lesbarkeit zu beobachten:
Am Anfang ist dieser "Text" schwer zu verstehen, aber langsam ist es leichter zu lesen. Wenn Sie es zwei- oder dreimal lesen, werden Sie nicht bemerken, dass es aus nicht standardmäßigen Buchstaben besteht. Um genau zu sein, ist der Ersatz von Buchstaben keine syntaktische Veränderung, sondern zeigt, dass das Aussehen selten zu einem Hindernis für die Lesbarkeit für qualifizierte Leser wird.
Wir können dieses Beispiel auch auf die natürliche Sprache erweitern. Ich verstehe drei völlig verschiedene Sprachen. Obwohl sie sich stark unterscheiden, fällt es mir sehr schwierig, Text in einer Sprache zu lesen, wenn ich die im Text verwendeten Wörter nicht verstehe. Als ich die Wörter kannte, die den Text ausmachen und mit dem Kontext vertraut wurden - egal in welcher Sprache es sich befand, es fiel mir nicht schwer, ihn zu lesen.
Daher hat die Wahl der Sprache für mich die Lesbarkeit nicht, sondern nur den Inhalt und den Kontext.
Gleiches gilt für Programmiersprachen.
Wenn wir eine neue Sprache verwenden, haben wir eine Weile Schwierigkeiten, den Quellcode zu verstehen und jede syntaktische Struktur sorgfältig zu verstehen. Wenn wir jedoch immer mehr Code für eine bestimmte Sprache lesen und schreiben, werden wir uns allmählich mit der Syntax dieser Sprache vertraut und irgendwann werden wir nicht mehr auf die syntaktische Struktur achten.
Ich habe diese Erfahrung in mehreren Sprachen selbst gemacht: Verilog, Bash, Perl, TCL, Lisp, Java.
Basierend auf meinen Erfahrungen mit den oben genannten Sprachen kann ich Ihnen sagen: Wenn sich eine Person an den Code von LISP anpasst und keine Klammern mehr merkt, kann die Syntax von Kotlin im Vergleich zu Java keine nicht zuerkennbaren Auswirkungen auf die Lesbarkeit haben, selbst wenn es "besser" ist.
Da wir dieses Thema diskutieren, werde ich mein subjektives Urteil über Faktoren teilen, die die Lesbarkeit des Quellcodes beeinflussen.
Nachdem ich Code von anderen Entwicklern in vielen Sprachen gelesen habe (in den oben genannten Listen nur die Sprachen, in denen ich in einem bestimmten Zeitpunkt beherrscht bin; ich habe mehr Sprachen verwendet als diese), kam ich zu folgender Schlussfolgerung: Wenn Entwickler Code schreiben können, die in einer Sprache sowohl lesbar als auch verständlich sind, können sie normalerweise sowohl in anderen Sprachen lesbar als auch verständlich sind.
Das subjektive Urteil, das ich auf der Grundlage meiner eigenen Erfahrung gemacht habe, ist daher, dass die Lesbarkeit des Quellcodes nichts mit der ausgewählten Sprache zu tun hat und die von den Fähigkeiten des Codeberechers und den Fähigkeiten der Leser abhängt (die Fähigkeiten des Schriftstellers sind wichtiger).
Wenn Sie immer noch der Meinung sind, dass subjektive Ansichten repräsentativ sind, lesen Sie zumindest darüber, was Robert „Onkel Bob“ Martin in diesem Blog -Beitrag denkt.
Objektiver Vergleich zwischen Kotlin und Java
Im Gegensatz zu subjektiven Vergleichen verwenden objektive Vergleiche quantitative Indikatoren, um zu messen oder zu bewerten, wo Kotlin Vorteile gegenüber Java hat.
Die Idee, objektiv zu beweisen, ob eine Programmiersprache mit einem Satz von Standards besser ist als eine andere, ist sehr attraktiv, aber es gibt ein Problem: Soweit ich weiß, gibt es keine allgemeinen objektiven Indikatoren, die sich auf Programmiersprachen beziehen.
Können wir Kotlin und Java objektiv vergleichen, da wir keine präzise und direkten Vergleiche vornehmen können? fähig! Wir können immer noch das Ausmaß der positiven und Messaging -Auswirkungen des Wechsels von Java zu Kotlin bewerten, dann die Ergebnisse vergleichen und ihre Auswirkungen diskutieren.
Um die besten Ergebnisse zu bewerten, die Kotlin erzielen kann, werden wir folgende Annahmen treffen:
Entwickler können sofort zu Kotlin wechseln.
Nach dem Wechsel zu Kotlin verlieren Entwickler keine Fähigkeiten (zum Beispiel können Entwickler mit zwei Jahren Erfahrung in der Java -Entwicklung auf magische Weise zwei Jahre Erfahrung in der Kotlin -Entwicklung sammeln).
Kotlin ist so stabil wie Java;
Kotlin -Tools sind so reif wie Java -Werkzeuge.
Tatsächlich ist keine der oben genannten Annahmen vernünftig, aber zu Beginn gibt es eine ideale Einstellung für eine einfache Erklärung. Dann werden wir diese Annahmen beiseite legen und die Auswirkungen der realen Effekte diskutieren.
Kotlin beste Ergebnisse Schätzungen
Nach dem von Steve McConnell in Code Complete vorgeschlagenen Modell können wir Softwarekonstruktionsaktivitäten in drei Unteraktivität unterteilen: detailliertes Design, Codierung und Debuggen sowie Entwicklung und Tests.
Kotlin hat nur geringe Auswirkungen auf die Konstruktion von Unteraktivität im Detail (diese Aktivität ist normalerweise unabhängig von der spezifischen, objektorientierten Programmiersprache), sodass Kotlin und Java in diesem Abschnitt den gleichen Aufwand unternehmen müssen.
Soweit ich weiß, hat Kotlin nichts revolutionäres an der Unteraktivität des Entwicklungstests vorgeschlagen. Gleiches gilt auch für die Entwicklung von Tests.
Alle Codierungs- und Debugging-Unteraktivität bleiben übrig.
Wenn wir Java durch Kotlin ersetzen, wie viel Arbeit kann ich bei Coding- und Debugging -Aktivitäten sparen? Diese Frage ist schwer zu beantworten, und dieser Wert variiert stark zwischen den Programmierern (einige Programmierer verwenden Java effizienter). Nachdem wir jedoch die beste Situation bewerten, können wir auch davon ausgehen, dass der Umschalten von Java zu Kotlin die Produktivität des Entwicklers während der Codierung und Debugging -Phasen um durchschnittlich 10% erhöhen kann.
Eine Produktivitätssteigerung um 10% ist ein überraschend unrealistischer Wert. Auch wenn wir den gesamten Code manuell in einem Texteditor eingeben, ist das unrealistisch. In Anbetracht der aktuellen Funktionen von IDEs ist dieser Wert noch unrealistischer. In Anbetracht der Tatsache, dass einige Entwickler Java effizienter verwenden, macht dieser Wert keinen Sinn.
Es macht mir nichts aus, einen solchen Wert zu verwenden, der für die Bewertung von Kotlin sowohl unrealistisch als auch günstig ist, da ich weiß, dass die daraus resultierenden negativen Auswirkungen diese positiven Effekte ausgleichen, sobald wir einige der "idealen Annahmen" beiseite gelegt haben, egal wie unrealistisch positiv es sich bei den Bewertungsergebnissen enthält.
In Bezug auf Codierung und Debuggen haben wir also um 10% gestiegen - wie schnell liefern wir unsere Produkte an unsere Kunden?
Das folgende Bild stammt aus dem Buchcode, der den Anteil verschiedener Aktivitäten von Softwareprojekten zeigt:
Das kleine Projekt des Bildes konzentriert sich auf Bauaktivitäten. Größere Projekte erfordern mehr Architektur, Integration und Systemtests, um sicherzustellen, dass das Projekt erfolgreich ist. Dieses Bild zeigt keine Anforderungen, da im Gegensatz zu anderen Aktivitäten keine direkte Programmfunktion ist. (Albrecht 1979; Glass 1982; Boehm, Gray und Sewaldt 1984; Boddie 1987; Card 1987; McGarry, Waligora und McDermott 1989; Brooks 1995; Jones 1998; Jones 2000; Boehm et al. 2000))
Code komplett, zweite Ausgabe
Nach diesem Bild von Code Complete machen in einem größeren Softwareprojekt (mehr als 10 km Zeilen) eine Codierung und Debuggierung von weniger als 20% der gesamten Projekt Workload aus.
In einem größeren Softwareprojekt beträgt die von uns angenommene Codierung und Debugging -Effizienz 10%, wodurch nur die Gesamtarbeitsbelastung reduziert werden kann, die zum Abschluss des Projekts um 2%erforderlich ist.
Beispielsweise ist 2% der gesamten Arbeitsbelastung ein Projekt, bei dem 5 Personen abgeschlossen sind (dies ist ein relativ großes Android -Projekt).
5 Personen - Jahr * 12 * 4 * 5 * 0,02 = 24 (Menschen - Tag)
Wenn wir die Projekt-Arbeitsbelastung wirklich um 24 Tage reduzieren könnten, wäre dies ein guter Grund, von Java nach Kotlin zu wechseln. Wir sollten uns jedoch daran erinnern, dass die obige positive Bewertung in idealen Situationen abgeleitet wurde und auf unrealistischen Annahmen beruhte.
In der realen Welt hat das Umschalten auf eine andere Programmiersprache einen unvermeidlichen Einfluss, den wir bewerten und mit der oben genannten idealisierten Bewertung vergleichen werden.
Entwicklervorbereitung
Um das beste Fall zu bewerten, gehen wir davon aus, dass Entwickler sofort von Java nach Kotlin wechseln können.
Während Kotlin Java sehr ähnlich ist, müssen Entwickler noch einige Zeit damit verbringen, die Entwicklungspraktiken und Tools zu verbringen. Die Vorbereitungszeit variiert von Person zu Person: Einige Entwickler können zwischen drei oder vier Tagen wechseln, während andere 10 Tage oder mehr dauern können.
Seien wir im Durchschnitt optimistisch, dass jeder Entwickler in nur 5 Tagen von Java nach Kotlin wechseln kann.
Ein Projekt, bei dem 5 Personen abgeschlossen sind, wird 3 bis 5 Entwickler haben (im besten Fall). Die durchschnittliche Schaltzeit für jeden Entwickler beträgt 5 Tage, sodass ein Projekt insgesamt 15 bis 25 Personen-Tag-Schaltzeiten benötigt.
Der Aufwand, der durch Wechsel zu Kotlin (optimistische Schätzung) gespeichert ist, scheint den Gesamtaufwand für das Umschalten in etwa dem zu entsprechen.
Entwicklerfähigkeiten Verlust
Die Fähigkeit, in einer bestimmten Programmiersprache effizient zu arbeiten, ist eine Fähigkeit.
Wir haben einen Aspekt dieser Fähigkeit (Code -Lesbarkeit) besprochen, aber es gibt viele andere. Wenn Sie von einer Sprache in eine andere wechseln, können einige Fähigkeiten im Zusammenhang mit der alten Programmiersprache auf die neue Sprache angewendet werden, andere Teile der Fähigkeiten gehen jedoch verloren.
Um die Auswirkungen des Verlusts von Programmiersprachkenntnissen auf die Projektarbeit zu bewerten, werden wir den Faktor "Sprach- und Toolfahrer" verwenden, der aus dem Cocomo2 -Bewertungsmodell abgeleitet wurde:
Sprache und Werkzeuglebnis (LTEX)
Diese Metrik wird verwendet, um die Erfahrung von Projektteams zu messen, die Softwaresysteme oder Subsysteme mithilfe von Programmiersprachen und Softwaretools entwickeln. Die Softwareentwicklung umfasst die Verwendung von Tools, um Anforderungen, Expressionsdesign und -analyse, Konfigurationsmanagement, Dokumentenextraktion, Bibliotheksverwaltung, Programmstil und Formatierung, Konsistenzprüfung, Planung und Kontrolle usw. zu erfüllen. Zusätzlich zur Erfahrung der Projektprogrammiersprache können die Erfahrung von Projektunterstützungs -Toolsets auch die Entwicklungsbemühungen beeinflussen. Die Erfahrung unter 2 Monaten erhalten eine sehr niedrige Bewertung, und die Erfahrung unter 6 Monaten oder Jahren wird eine sehr hohe Bewertung erhalten. Siehe die folgende Tabelle:
Ich weiß nicht, was für ein Rückgang das ist, wie viele Projekte betroffen waren, aber mein Gehirn übersetzte automatisch die Kombination aus "signifikanter Leistungsrückgang" in "viele Stunden Entwicklungszeit".
Wenn Sie die Kommentare zu den Posting -Notizen lesen, werden Sie feststellen, dass viele Personen Migrationsprobleme haben. In den Kommentaren zu Version 1.1.2 wiesen einige sogar darauf hin, dass diese "Patch" -Release destruktive (rückwärts inkompatible) Modifikationen einführte.
Wenn Sie dagegen die Versionshinweise von Oracle JDK8 lesen, werden Sie feststellen, dass es relativ stabil ist. Die meisten Änderungen sind Sicherheitsverbesserungen.
Daher ist Kotlin im Vergleich zu Java eine instabile und unreife Sprache - was hat die Migration nach Kotlin auf das Projekt? Um diese Frage zu beantworten, werde ich den Arbeitsfaktor "Plattformvolatilität" aus dem Cocomo 2 -Bewertungsmodell verwenden:
Platform Volatility (PVOL) Hier bezieht sich der Begriff "Plattform" auf die komplexe Hardware und Software (OS, DBMS usw.), die aufgerufen werden, wenn ein Softwareprodukt Aufgaben ausführt. Wenn die entwickelte Software ein Betriebssystem ist, ist die Plattform Computerhardware. Wenn das Datenbankverwaltungssystem entwickelt wird, ist die Plattform das Hardware- und Betriebssystem. Wenn der Netzwerktextbrowser entwickelt wird, ist die Plattform das Netzwerk, die Computerhardware, das Betriebssystem und die verteilte Informationsbibliothek. Die Plattform umfasst Compiler oder Bauherren, die zur Unterstützung der Entwicklung von Softwaresystemen erforderlich sind. Wie in der folgenden Tabelle gezeigt, ist die Bewertung sehr niedrig, wenn sich die Plattform nur alle 12 Monate ändert, und wenn sich alle 2 Wochen eine große Veränderung vorliegen, ist die Bewertung sehr hoch:
COCOMO2 -Modelldefinitionshandbuch
Möglicherweise haben Sie festgestellt, dass die Programmiersprache nicht direkt in der Beschreibung dieses Arbeitsfaktors angezeigt wird, aber Compiler und Assembler erscheinen. Meiner Meinung nach enthält diese Beschreibung die Programmiersprache nicht explizit, da alle Projekte, die das Cocomo2 -Modell ableiten, eine stabile Sprache verwenden.
Da Compiler und Assembler zu diesem Arbeitsfaktor gehören, können wir auch Programmiersprachen und verwandte Tools schließen.
Basierend auf diesem Bewertungsbereich der Plattformvolatilität sollte Java "sehr) sein, während Kotlin" niedrig "oder höher sein sollte. Kotlin kann eine höhere Bewertung haben, da es intern auf andere Tools angewiesen ist und das Risiko von Kompatibilitätsproblemen erhöht.
Da "SyRlow" keinen Arbeitsfaktor bietet, benötigen wir eine Schätzung.
Wenn wir die abnehmende Regel des Faktors von "sehr hoch" bis "niedrig" betrachten, können wir mit Zuversicht davon ausgehen, dass die Punktzahl von "SEHRLICH" nicht höher als 0,82 ist.
Basierend auf diesen Annahmen (zugunsten von Kotlin), wenn ein Projekt eine bewertete Arbeitsbelastung von 5 Personen pro Jahr erfordert, wird die Verwendung von Kotlin zu 1.044 Personen pro Tag, während die gesamte Arbeitsbelastung der Verwendung von Java 984 Personen pro Tag beträgt.
Die Entscheidung, ein solches Projekt mit Kotlin anstelle von Java zu implementieren, erhöht die gesamte Arbeitsbelastung durch 60 Mitarbeiter.
Die zusätzliche Arbeit, die durch Sprach- und Werkzeuginstabilität verursacht wird, beträgt mehr als doppelt so viel wie die Arbeit, die durch den Umschalten auf Kotlin reduziert wird.
Alle Faktoren kombinieren
Das Projekt, das ich als Beispiel besprochen habe, erfordert eine bewertete Arbeitsbelastung von 5 Personen pro Jahr.
Laut der obigen Bewertung ist die gesamte Arbeitsbelastung:
5 Personenjahre*ltex (Java)*Pvol (Java) = 984 (People-Day)
Wenn das gleiche Projekt von einem Entwickler mit Kotlin mit wenig Erfahrung in der Kotlinentwicklung implementiert wird, lautet die Gesamtarbeitslast:
5 Personenjahre*ltex (kotlin)*pvol (kotlin)*0,98+t_ramp_up = 1115+5*n_developer (menschliche Heaven)
Es wird geschätzt, dass die zusätzliche Arbeitsbelastung, die durch die Auswahl von Kotlin für Java verursacht wird, 131+5*N_Developer (Man-Day) beträgt.
Bewertungsvorkehrungen
Während der Bewertungsdiskussion haben wir einen bequemen Einzelpunktwert für die Arbeitsbelastung im Zusammenhang mit Kotlin und Java entwickelt.
Aber in Wirklichkeit sind Einzelpunktwerte überhaupt keine Schätzungen - sie sind nur Vermutungen. Die tatsächliche Schätzung muss eine damit verbundene Unsicherheit haben. Mit anderen Worten, Schätzungen repräsentieren eher Bereiche von Möglichkeiten als einzelne Punktwerte.
Am Ende haben wir einzelne Punktwerte anstelle von Bereichen verwendet, da ich aus dem Schätzbereich den günstigsten Wert für Kotlin gewählt und alle Schätzungen in Einzelpunktwerte umgewandelt habe.
Wenn ich beispielsweise die Auswirkungen von Kotlin auf Codierung und Debugging-Aktivitäten erörtert, habe ich den maximalen Produktivitätsschubwert von 10%gegenüber dem geschätzten Bereich der Möglichkeiten entschieden [-5%, 10%]. In anderen Fällen, wenn wir über die durchschnittliche Zeit diskutieren, die der Entwickler nach Kotlin wechselt, habe ich die kleinsten 5 Tage aus dem geschätzten Bereich der Möglichkeiten ausgewählt [5 Tage, 21 Tage].
Darüber hinaus verwendeten wir den Arbeitsfaktor, der dem Cocomo2 -Schätzmodell gewidmet ist. Diese Faktoren sind keine universellen Wahrheiten, und im allgemeinsten Fall sollte es auch eine verwandte Unsicherheit geben. Ich habe Kotlin eine höhere Bewertung zugewiesen, als ich es tatsächlich für verdient hielt, und hoffe, diese Unsicherheit auf diese Weise zu entfernen.
Unnötig zu erwähnen, dass der einzelne Punktwert, den wir erhalten, nicht 100% korrekt ist. Um eine vollständigere Schätzung zu erhalten, können wir die tatsächliche Schätzung für die Montecarlo -Simulation verwenden. Durch diese Technik können wir die Verteilung möglicher Ergebnisse beobachten und herausfinden, welche Ergebnisse am wahrscheinlichsten auftreten.
Denken Sie daran, dass, da wir die Schätzungen in den Einzelpunktwert komprimieren, der für Kotlin am günstigsten ist, andere mögliche Ergebnisse einen höheren Kotlin -Schaltaufwand zeigen. Daher ist der oben beschriebene Einzelpunktwert aller möglichen Ergebnisse für Kotlin am günstigsten.
Zusammenfassung
Zu Beginn des Artikels zeigen wir einige subjektive Urteile, die den Vergleich der Programmiersprachen durch Entwickler irreführten.
Als nächstes diskutieren wir die Schwierigkeiten beim objektiven Vergleich von Programmiersprachen und führen eine Reihe von Schätzungen durch, um die Gesamtarbeitslast für den Kotlin Stack und Java Stack zu ermitteln, um das Softwareprojekt abzuschließen. Bei der Durchführung der Schätzung verwenden wir immer den günstigsten Wert von Kotlin im Schätzbereich.
Durch unsere Analyse scheint das Umschalten von Java zu Kotlin zu einer Erhöhung der gesamten Arbeitsbelastung zu führen, die für die Abschluss eines Softwareprojekts erforderlich ist.
Mehr Arbeit bedeutet, dass Unternehmen mehr Geld ausgeben müssen, um zu Kotlin zu wechseln, um die gleichen Funktionen zu erhalten, während Benutzer länger warten müssen, um das Produkt zu erhalten.
Einige Entwickler sind möglicherweise überrascht und finden, dass dieses Ergebnis nicht einfach zu akzeptieren ist.
Nachdem Google alle Situationen in Betracht gezogen hatte, beschloss es schließlich, die Entwicklung der Kotlinanroid zu unterstützen. Google benötigt möglicherweise erhebliche Investitionen in dies - gibt es niemanden im Google Cloud -Plattform -Team, der eine ähnliche Analyse durchführen kann, um die negativen Auswirkungen des Wechsels auf eine neue Sprache zu ermitteln?
Ich denke, Google-Mitarbeiter sind alle sehr kluge Leute und ich glaube, sie haben eine sehr detaillierte Analyse durchgeführt, bevor sie beschlossen, Kotlin zu unterstützen.
Das obige ist der gesamte Inhalt dieses Artikels über den subjektiven und objektiven Vergleich und die Analyse von Kotlin und Java. Ich hoffe, es wird für alle hilfreich sein. Interessierte Freunde können weiterhin auf andere verwandte Themen auf dieser Website verweisen. Wenn es Mängel gibt, hinterlassen Sie bitte eine Nachricht, um darauf hinzuweisen!