SMILE: eine ML-Bibliothek für die JVM, die Java 25 voraussetzt

Welche Lücke SMILE im JVM-Ökosystem füllt

Wer in Java oder Scala ein Modell trainieren will, landet schnell bei einem Bruch in der Toolchain: Datenzugriff und Service laufen in der JVM, das Training läuft in Python. SMILE setzt genau dort an. Das Repository beschreibt das Projekt als umfassendes Machine-Learning-Framework für die JVM und liefert idiomatische APIs für Scala und Kotlin zusätzlich zur Java-Oberfläche. Der Anspruch ist nicht, ein einzelnes Verfahren bereitzustellen, sondern die Kette von der Datenaufnahme bis zur Auswertung im selben Prozess zu halten. Dazu gehören Leser und Schreiber für CSV, JSON, Parquet, Arrow, JDBC und Avro, ein DataFrame-Modul, Feature-Transformationen und die Modellalgorithmen selbst. Die Zielgruppe ist entsprechend eng umrissen: Entwicklerinnen und Entwickler, die Klassifikation, Regression, Clustering oder Dimensionsreduktion in einer bestehenden JVM-Anwendung brauchen und dafür keine zweite Laufzeit einführen wollen. Für explorative Arbeit in Notebooks mit schnellem Wechsel zwischen Bibliotheken ist SMILE nicht der bequemste Weg; dafür ist der Umfang der einzelnen Module zu groß und die API zu stark typisiert.

Module statt Monolith: base und core als Fundament

Das Repository gliedert sich in Module, jedes mit eigenem README und teils eigenen Themendokumenten. Das Modul base/ enthält laut Modulübersicht Datenstrukturen, Mathematik, lineare Algebra, statistische Utilities und I/O. Dazu zählen laut Dokumentenliste unter anderem DATA_FRAME.md für die DataFrame-API, DATA_IO.md für die Ein- und Ausgabeformate, FORMULA.md für eine Formelsprache im R-Stil zur Erzeugung von Modellmatrizen, DISTRIBUTIONS.md für Wahrscheinlichkeitsverteilungen, HYPOTHESIS_TESTING.md für t-Test, Chi-Quadrat, ANOVA und KS-Test sowie NEAREST_NEIGHBOR.md für KD-Tree, Cover Tree, BK-Tree und LSH. Das Modul core/ trägt die Lernverfahren: CLASSIFICATION.md, REGRESSION.md, CLUSTERING.md, MANIFOLD.md, ANOMALY_DETECTION.md, ASSOCIATION_RULE_MINING.md, SEQUENCE.md und TIME_SERIES.md, dazu TRAINING.md für Cross-Validation und Hyperparametersuche sowie VALIDATION_METRICS.md für Accuracy, AUC, F1, RMSE, MAE und Konfusionsmatrix. Diese Aufteilung ist praktisch relevant, weil sie die Abhängigkeiten begrenzt: Wer nur Numerik und Datenrahmen braucht, muss nicht das gesamte Lernverfahrenspaket mitziehen. Die Trennung ist allerdings nicht kostenlos. Zwischen base und core liegt eine Schicht, die man verstehen muss, bevor man eigene Transformer oder Distanzfunktionen einhängt.

Der eigentliche Bruch: Java 25 und die Native-Libraries

Die wichtigste Einschränkung steht im README und ist keine Kleinigkeit. SMILE v5 und neuer setzt Java 25 voraus, v4.x verlangt Java 21, alle früheren Versionen Java 8. Ein Team, das auf Java 17 oder 21 standardisiert ist, kann die aktuelle Version nicht ohne Weiteres einsetzen. Das ist eine harte Grenze, keine Empfehlung. Dazu kommt die Native-Frage: Das README führt einen eigenen Abschnitt Native Libraries (BLAS / LAPACK), was bedeutet, dass ein Teil der linearen Algebra über native Bibliotheken läuft und nicht rein in Java. Die Dokumentation im vorliegenden Material benennt diesen Abschnitt, aber nicht, welche Plattformen und Architekturen abgedeckt sind. Wer auf einer exotischen Architektur oder in einem Container mit strikten Binary-Restriktionen deployt, muss das vor der Evaluierung klären. Ein reiner Java-Fallback ist nicht belegt. Für Build-Umgebungen, in denen nur signierte Artefakte aus dem eigenen Repository zugelassen sind, ist das ein Prüfpunkt, kein Nebensatz.

Installation über Maven, SBT und Gradle

Das README nennt drei Wege. Für Maven ist das Artefakt com.github.haifengl/smile-core über Maven Central referenziert, wie das Maven-Central-Badge im README zeigt. Für Scala ist ein SBT-Abschnitt vorhanden, für Kotlin ein Gradle-Abschnitt. Die konkreten Versionsnummern und Abhängigkeitsblöcke stehen in den jeweiligen Abschnitten des README; das vorliegende Material gibt sie nicht im Wortlaut wieder, daher hier keine erfundenen Snippets. Klar ist: Der Einstiegspunkt ist das Artefakt smile-core, und weitere Module kommen als zusätzliche Abhängigkeiten dazu. Wer nur einen Teil braucht, sollte nicht blind alles einbinden, sondern die Modulübersicht als Einkaufsliste lesen. Die Versionsstände im Repository zeigen den Pflegezyklus: v6.3.0 vom 18. August 2026, davor v6.2.5 vom 2. August 2026 und v6.2.4 vom 13. Juli 2026. Zwischen den beiden letztgenannten Releases liegen elf Tage. Das ist ein Rhythmus, der auf häufige Patch-Releases hindeutet, und genau deshalb sollte die Version im Build festgenagelt werden statt über einen Versionsbereich aufgelöst zu werden.

Was das Paket inhaltlich abdeckt

Die Feature-Tabelle im README listet für Klassifikation unter anderem SVM, Decision Trees, Random Forest, AdaBoost, Gradient Boosting, Logistic Regression, Neural Networks, RBF Networks, MaxEnt, KNN, Naïve Bayes sowie LDA, QDA und RDA. Bei Regression stehen SVR, Gaussian Process, Regression Trees, GBDT, Random Forest, RBF, OLS, LASSO, ElasticNet und Ridge. Beim Clustering reicht die Liste von BIRCH und CLARANS über DBSCAN, DENCLUE, Deterministic Annealing, K-Means, X-Means, G-Means, Neural Gas, Growing Neural Gas, Hierarchical, SIB, SOM und Spectral bis Min-Entropy. Beim Manifold Learning sind IsoMap, LLE, Laplacian Eigenmap, t-SNE, UMAP, PCA, Kernel PCA, Probabilistic PCA, GHA, Random Projection und ICA genannt. Dazu kommen Bereiche, die in ML-Bibliotheken oft fehlen: Association Rules über FP-growth, Sequenzlernen mit Hidden Markov Model und Conditional Random Field, Zeitreihen mit ARIMA sowie Numerik mit BFGS und L-BFGS, Interpolation, Wavelets, RBF und Hypothesentests. Die Breite ist der eigentliche Verkaufsargumentpunkt und zugleich die Schwierigkeit: Ein so großer Umfang bedeutet, dass nicht jedes Verfahren dieselbe Reife und Dokumentationstiefe haben dürfte. Das README belegt die Existenz der Verfahren, nicht deren Qualität im Einzelfall.

LLM-Inferenz und Deep Learning im selben Artefakt

Bemerkenswert für eine klassische Statistik- und ML-Bibliothek ist der LLM-Block in der Feature-Tabelle: LLaMA-3-Inferenz, ein tiktoken-BPE-Tokenizer, ein OpenAI-kompatibler REST-Server und SSE-Chat-Streaming. Dazu ein Deep-Learning-Bereich mit LibTorch/GPU-Backend, EfficientNet-V2 für Bildklassifikation und einer API für eigene Layer. Das verschiebt die Positionierung. SMILE tritt damit nicht nur gegen Statistikpakete an, sondern gegen Werkzeuge, die Inferenz serverseitig in der JVM betreiben wollen, ohne einen Python-Prozess daneben zu stellen. Ob das in der Praxis trägt, lässt sich aus dem README nicht ableiten: Es nennt die Fähigkeiten, aber keine Angaben zu Durchsatz, Speicherbedarf oder unterstützten Modellformaten jenseits von LLaMA-3. Wer LLM-Inferenz als Auswahlkriterium hat, sollte diesen Punkt gesondert prüfen und nicht aus der Feature-Liste auf Produktionsreife schließen. Der GPU-Pfad über LibTorch bringt außerdem eine zweite native Abhängigkeit ins Spiel, die neben BLAS/LAPACK zu verwalten ist.

Serialisierung, Visualisierung und der Studio-Teil

Das README enthält eigene Abschnitte zu Model Serialization und Visualization. Bei der Visualisierung nennt es Swing-Diagramme für Scatter, Line, Bar, Box, Histogram, Surface, Heatmap und Contour sowie deklarative Vega-Lite-Charts. Das ist eine ungewöhnliche Kombination: Swing-Plots laufen im Desktop-Kontext, Vega-Lite erzeugt deklarative Spezifikationen, die sich in Weboberflächen rendern lassen. Für serverseitige Pipelines ist der Swing-Teil irrelevant, der Vega-Lite-Teil dagegen brauchbar. Ein weiterer Punkt ist SMILE Studio, im README als agentische IDE für Data Science mit Python, Java oder Scala beschrieben, mit Verweis auf studio/README.md. Das ist ein separates Produkt im selben Repository und kein Bestandteil der Bibliothek. Wer SMILE nur als Abhängigkeit einbindet, bekommt Studio nicht mit. Umgekehrt bedeutet die Existenz von Studio, dass das Repository mehr als eine Bibliothek pflegt, was den Wartungsaufwand für das Projekt insgesamt erhöht.

Wo SMILE die falsche Wahl ist

SMILE ist kein Ersatz für scikit-learn in einem Python-zentrierten Team. Die Algorithmen mögen sich überschneiden, aber der Wechsel kostet die gesamte Notebook-Kultur, die Ökosystemintegration und die Gewohnheiten der Beteiligten. Wer schnell Prototypen braucht und die Produktion später ohnehin in Python läuft, gewinnt durch SMILE nichts. Ein zweiter Fall: Wer nur ein einzelnes Verfahren braucht, etwa eine logistische Regression oder ein Random Forest, ist mit einer kleinen spezialisierten Bibliothek besser bedient als mit einem Framework, das Clustering, Wavelets, Graphen, Kompression und LLM-Inferenz mitbringt. Der dritte Fall ist die Plattformbindung. Wenn die Zielumgebung kein Java 25 zulässt und der 4.x-Zweig mit Java 21 nicht alle benötigten Module in der gewünschten Version enthält, ist SMILE schlicht nicht verfügbar, unabhängig von der Qualität der Algorithmen. Der vierte Fall betrifft die Native-Abhängigkeiten: In Umgebungen, in denen nur reine JVM-Artefakte zugelassen sind, ist der BLAS/LAPACK-Pfad ein Problem, dessen Tragweite sich aus dem vorliegenden Material nicht abschätzen lässt.

Alternative: DJL für Inferenz, Tribuo für Klassifikation

Wer SMILE wegen der Deep-Learning- und LLM-Fähigkeiten ins Auge fasst, sollte den Ansatz von Deep Java Library (DJL) vergleichen. DJL ist auf Modellinferenz und Training mit austauschbaren Engines ausgelegt, also auf die Anbindung unterschiedlicher Backends, während SMILE die Verfahren selbst implementiert und LibTorch als eines von mehreren Backends nutzt. Der Unterschied liegt in der Erweiterbarkeit: Bei DJL ist die Engine eine Konfigurationsfrage, bei SMILE ist der Algorithmus Teil der Bibliothek. Für reine Klassifikation und Regression auf tabellarischen Daten ist Tribuo von Oracle der nähere Vergleich. Tribuo stellt Klassifikation, Regression, Clustering und Anomalieerkennung bereit und legt Wert auf reproduzierbare Auswertung und Provenienz der Modelle. SMILE ist breiter aufgestellt und deckt zusätzlich Numerik, Wavelets, Graphen, Interpolation und Manifold-Learning ab. Wer diese Randbereiche braucht, findet sie bei Tribuo nicht in vergleichbarem Umfang. Wer dagegen vor allem Modelle trainieren, versionieren und deren Herkunft nachvollziehen will, sollte Tribuo ernsthaft prüfen, bevor er sich an SMILE bindet.

Pflegeaufwand, Lizenz und was vor dem Einsatz zu klären ist

Die Release-Historie zeigt einen aktiven Zyklus: v6.3.0 im August 2026, davor zwei Patch-Releases im Juli und August 2026. Der letzte Push liegt laut Repository-Metadaten auf dem 9. September 2026. Das Repository ist nicht archiviert. Für Anwender heißt das: Die Version im Build sollte fixiert werden, und ein Upgrade-Pfad muss eingeplant werden, weil Patch-Releases in kurzen Abständen erscheinen. Die Lizenz ist im vorliegenden Material als NOASSERTION angegeben. Das ist keine Lizenzangabe, sondern das Fehlen einer maschinenlesbaren Zuordnung durch die Plattform. Wer SMILE in einem kommerziellen Produkt einsetzen will, muss den LICENSE-Text im Repository selbst lesen und ihn von der Rechtsabteilung bewerten lassen. Aus dem Material lässt sich nicht ableiten, ob es sich um eine permissive oder eine Copyleft-Lizenz handelt, und das ist ein Unterschied, der die Weitergabe von abgeleitetem Code betrifft. Vor dem ersten Commit sind drei Dinge zu prüfen: die Java-Version in der Zielumgebung, die Verfügbarkeit der Native-BLAS/LAPACK-Binaries für die Zielplattform und der tatsächliche Lizenztext im Repository.

Redaktionelles Fazit

SMILE passt zu Teams, die ihre Datenverarbeitung ohnehin in Java, Scala oder Kotlin betreiben und keine Python-Laufzeit danebenstellen wollen. Wer Java 25 nicht einführen kann, bleibt auf dem 4.x-Zweig mit Java 21 oder wartet. Vor dem ersten Commit ist zu prüfen, ob die eigene Plattform von den Native-BLAS/LAPACK-Binaries abgedeckt wird, welcher Lizenztext im LICENSE-File des Repositorys steht und ob das Modul, das man braucht, in der eigenen Version bereits enthalten ist.

Offizielle Quellen

1. haifengl/smile on GitHub
2. Issues
3. Project website
4. README
5. Releases