UtilLib: Java-Werkzeugkasten für kleine Projekte – Mitstreiter gesucht

[TomBombadil]

Hallo zusammen,

ich möchte hier mein Projekt UtilLib vorstellen und suche dafür interessierte Java-Entwickler, die Lust haben, Feedback zu geben oder langfristig mitzuwirken.

Der Download liegt hier, weil das Paket für einen direkten Upload im Forum zu groß ist:

https://my.hidrive.com/share/n39d-jnx8c

Was ist UtilLib?​

UtilLib ist eine leichtgewichtige Java-Bibliothek für kleine und mittlere Softwareprojekte.

Die Idee ist nicht, Spring, Hibernate, Jakarta EE oder andere große Frameworks zu ersetzen. UtilLib soll eher die Lücke schließen zwischen:

• „Ich schreibe alles mit Java SE selbst“
• und
• „Ich ziehe direkt ein großes Framework ins Projekt“

Ziel ist ein pragmatischer Werkzeugkasten für typische Aufgaben, die in kleinen Anwendungen ständig wiederkommen:

• sichere Fehlerbehandlung
• Textverarbeitung
• einfache Collections
• Konfiguration und Parameterverwaltung
• Datenbankzugriff
• ObjectStore / einfache Objektpersistenz
• Tabellenmodelle
• später auch Druckausgabe, PDF und weitere Alltagsbausteine

Der Gedanke dahinter ist: Ein Einzelentwickler soll mit möglichst wenig Infrastruktur schnell eine brauchbare Anwendung bauen können.

Warum das Ganze?​

Ich sehe in der Praxis oft kleine Betriebe, Vereine oder Privatpersonen, die sich mit Excel-Tabellen, halb manuellen Abläufen und viel Bürokratie behelfen müssen.

Da geht schnell viel Zeit verloren. Nicht, weil die eigentliche Aufgabe kompliziert wäre, sondern weil passende kleine Software fehlt oder zu teuer ist.

Meine Vision ist, dass ein Entwickler mit UtilLib schneller kleine Fachanwendungen bauen kann, zum Beispiel:

• Adressverwaltung für einen Verein
• Mitgliederverwaltung
• einfache Lager- oder Inventarlisten
• Import und Validierung gewachsener Excel-/CSV-Daten
• kleine Datenbankanwendungen
• Text- und Berichtsgeneratoren
• einfache Verwaltungswerkzeuge für Kleinbetriebe

Also Software, die nicht riesig ist, aber im Alltag echte Entlastung bringt.

Zielgruppe der Bibliothek​

UtilLib richtet sich vor allem an:

• Einzelentwickler
• kleine Teams
• Lernende mit Java-Grundkenntnissen
• Entwickler, die kleine Desktop- oder Tool-Anwendungen bauen
• Vereinssoftware
• kleine Betriebe
• interne Verwaltungssoftware
• Prototypen

Die Bibliothek soll bewusst auch für weniger erfahrene Java-Entwickler verständlich sein. Deshalb ist Dokumentation ein wichtiger Teil des Projekts. Es geht nicht nur darum, Methoden aufzulisten, sondern auch zu erklären, warum etwas so gebaut ist.

Grundprinzipien​

Einige Prinzipien sind mir besonders wichtig:

1. Einfach nach außen, sauber nach innen
   Die API soll möglichst einfach nutzbar sein. Die interne Umsetzung darf komplexer sein, wenn dadurch die Benutzung einfacher wird.
2. Keine unnötigen Eigenentwicklungen
   Wo etablierte Bibliotheken sinnvoll sind, sollen sie genutzt werden. UtilLib soll eher eine verständliche Fassade über bewährte Technik bieten, nicht alles neu erfinden.
3. Explizite Fehlerbehandlung
   Statt überall null oder ungefangene Exceptions zu verwenden, gibt es eine eigene Result<T>-Klasse. Eine Methode kann damit sauber ausdrücken: erfolgreich oder fehlgeschlagen.
4. Einsteigerfreundliche Dokumentation
   Die Dokumentation soll auch erklären, was Java-Standards wie Generics, Mapper, Prepared Statements oder Lambdas bedeuten, wenn sie in den Beispielen vorkommen.
5. Pragmatisch bleiben
   Kein Over-Engineering. Die Bibliothek soll für reale kleine Projekte nützlich sein.

Aktueller Stand​

Es gibt bereits mehrere Module, unter anderem:

• Result<T> für sichere Fehlerbehandlung
• TextProcessor für Text- und Dateioperationen
• MagicCollection als komfortable Collection
• SimpleParamManager für einfache Parameter und Konfigurationen
• Datenbankmodul mit H2/SQLite-Ansatz
• ObjectStore als Komfortschicht zum Speichern von Java-Objekten
• Tabellenmodelle
• erste Metrik-/Analysewerkzeuge

Ein Teil ist schon nutzbar, ein Teil ist noch klar Baustelle.

Insbesondere der Storage-Bereich ist aktuell noch eine komplexere Architekturbaustelle. Genau dort wäre fachlicher Input sehr willkommen.

Eine Idee: PDF-basierter Druckdialog​

Ein Bereich, den ich langfristig spannend finde, ist ein einfacher Druckbaustein für typische Verwaltungssoftware.

Die Idee wäre ein PDF-basierter Druckdialog, umgesetzt mit JavaFX oder Swing:

• Anwendung erzeugt intern ein PDF
• Vorschau im Dialog
• Drucken über Systemdrucker
• Speichern als PDF
• geeignet für Briefe, Listen, Etiketten, Umschläge, Zweckform-Bögen usw.

Gerade für Vereinssoftware oder kleine Bürosoftware wäre das sehr praktisch. Viele kleine Anwendungen scheitern nicht an der Datenhaltung, sondern an sauberer Ausgabe: Briefe, Adressetiketten, Listen, Formulare.

Hier wäre Input von erfahrenen Java-Entwicklern besonders interessant:

• JavaFX oder Swing?
• PDF-Vorschau über vorhandene Bibliothek oder externe Komponente?
• Druckdialog als eigenes Modul?
• sinnvolle API für Entwickler?
• Trennung zwischen Layout, Daten und Ausgabe?

Zu mir​

Ich bin nicht der große Coder im klassischen Sinn und mein Englisch ist auch nicht besonders gut. Deshalb wäre die Projektsprache zunächst Deutsch.

Ich sehe meine Stärke eher als Ideengeber und Architekt: Ich erkenne praktische Probleme, denke gern in Systemen und möchte daraus eine Bibliothek bauen, die anderen Entwicklern echte Arbeit abnimmt.

Gerade deshalb suche ich Mitstreiter, die technisch stärker sind, kritisch auf Architektur und Code schauen und eigene Ideen einbringen möchten.

Was ich suche​

Ich suche keine reine Zustimmung, sondern ehrliches Feedback:

• Ist die Grundidee sinnvoll?
• Ist die API verständlich?
• Wo ist die Architektur zu kompliziert?
• Wo ist sie zu naiv?
• Welche Module wären wirklich nützlich?
• Welche Teile sollte man besser streichen?
• Wo sollte man stärker auf bestehende Bibliotheken setzen?
• Wie könnte man Storage sauberer aufbauen?
• Welche Fehler sieht man im Design?

Auch neue Ideen sind ausdrücklich willkommen, solange sie zur Grundidee passen: kleine und mittlere Softwareprojekte schneller, robuster und verständlicher umsetzen.

Einordnung​

Das Projekt ist noch keine fertige, stabile Library. Eher eine aufgeräumte Basisversion mit Doku, an der man jetzt sinnvoll weiterarbeiten kann.

Ich würde mich freuen, wenn ein paar erfahrene Java-Entwickler Lust haben, reinzuschauen und Feedback zu geben.

Viele Grüße
Jan

 

[Robert Zenz]

Ist die Grundidee sinnvoll?

Jein? Es ist schwierig ein Schweizer Taschenmesser als Bibliothek anzubieten weil es vieles nicht zusammenhaengende hat. Das ist wie quasi wie die Apache/Guave/Google Bibliotheken wo man versucht so viel wie moeglich hineinzupacken. Das fuehrt am Ende dann aber eher dazu dass Entwickler die ganze Bibliothek mit hineinziehen um nur eine Klasse zu verwenden. Ob das gut ist oder nicht ist die Frage. Was aber definitiv schlecht ist, sind die Abhaengigkeiten die die Bibliothek "einfach so" mit hinein zieht in das Projekt. Wenn ich jetzt die Datenbank-Sachen nicht verwenden will, muss ich sie dann explizit in meinem pom exkludieren. Und da ist man dann auch schon mitten drin in dem Problem wenn man versucht alles in einer "Util-Bibliothek" zu loesen, man hat zwar viele moegliche Anwendungsfaelle abgedeckt, aber um sie dann nur fuer einen davon zu verwenden ist die Bibliothek selbst wieder zu grosz. Und Nein, die Loesung ist nicht die von den JavaScript-Heinis jede Funktion in ein eigenes Paket zu packen.

Auf die Schnelle aufgefallen ist mit die Verwendung von System.out und System.err. Bibliotheken sollten immer ueber Logger gehen um den verwendenden Applikationen die Moeglichkeit zu geben Log-Ausgaben anders Hand zuhaben. Das waere das Mindeste der Java Logger. SYSOFile koennte zum Beispiel komplett ueber ein Logger-Framework abgewickelt werden.

Aber auch die Benamung. Die Namen sind nicht immer wirklich gut, zum Beispiel CheckFileLanguage ist eine Aktion, kein Objekt. Besser waere LanguageAwareFile oder LanguageNamedFile oder aehnliches. Base64Decoder luegt, es ist sowohl Encoder als auch Decoder.

Ein paar der Funktionen, zumindest bei dem Time-Sachen, sind naiv implementiert. Duration waere da die bessere Wahl um Zeitspannen zu berechnen. Das begruendet sich schlicht und ergreifend darin dass es sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr, sehr viele Eckfaelle und Sonderfaelle beim berechnen von Zeit gibt. Da sind Schalttage das geringste, das geht ueber Schaltsekunden, direkt zu Sommer/Winterzeit zu Kalendaranpassungen wo dann Monate fehlen.

Etwas viel, viel wichtigeres ist das die Bibliothek keine Lizenz hat. Ohne Lizenz ist alles "Alle Rechte Vorbehalten", oder um es salopp auszudruecken: "no looky no touchy". Und du hast bereits durch die Abhaengigkeiten ein recht guten Dschungel an Lizenzen eingesammelt. Das waere das erste was passieren muss.

 

[TomBombadil]

Danke dir, das sind sehr hilfreiche Punkte.

SYSOFile ist tatsächlich kein Ersatz für Logging. Die Klasse ist eher als kleines Hilfswerkzeug entstanden: schnell System.out-ähnliche Ausgaben in eine Datei schreiben, ohne direkt ein komplettes Logging-Setup aufzusetzen. Ich finde so etwas in manchen Situationen praktisch. Aber ja: Für echte Bibliotheksausgaben sollte natürlich kein System.out/System.err verwendet werden, sondern ein Logger.

Beim Thema Lizenz bin ich noch unsicher. Die Bibliothek soll sowohl für Open-Source-Projekte als auch für kommerzielle Projekte geeignet sein. Vermutlich läuft es auf eine permissive Lizenz wie Apache 2.0 oder MIT hinaus. Das muss ich sauber klären, inklusive der Lizenzen der verwendeten Abhängigkeiten.

Die alten Util-Klassen kann man sicher überdenken. Die sind im Wesentlichen zwischen 2014 und 2016 entstanden. Vieles davon ist historisch gewachsen, und damals hatte ich einige Dinge noch nicht so verstanden wie heute. Mein Ziel ist nicht, diese Altlasten zu verteidigen, sondern das Projekt nach und nach auf ein professionelleres Niveau zu heben.

Auch bei den Abhängigkeiten sehe ich den Punkt. Langfristig sollte es eine Lösung geben, bei der man nicht alle externen Bibliotheken mitzieht, sondern nur die Module und Dependencies, die man wirklich verwendet. Der eigentliche UtilLib-Code ist bisher relativ klein; problematisch wird es eher durch die gebündelten Abhängigkeiten.

Was die Benennung angeht, bin ich für konkrete Vorschläge offen. Viele Klassen sind aus praktischem Eigenbedarf entstanden: Datei einlesen, Text analysieren, Strings manipulieren, einfache Datenbankanbindung, Parameter speichern usw. Da sind sicher Namen dabei, die historisch gewachsen und nicht optimal sind.

System.out und System.err sind noch Altlasten, die ich noch nicht vollständig entfernt habe.

Eine nächste praktische Baustelle ist aus meiner Sicht der Storage-Teil.

Die Vision wäre, dass man später zum Beispiel so etwas schreiben kann:

Storage keyValue = Storage.persist()
        .keyValue()
        .filter()
        .create();


Storage list = Storage.inMemory()
        .list()
        .unique()
        .create();

Man beschreibt über eine Fluent API nur noch, was man fachlich haben will. Das Framework entscheidet dann im Hintergrund, welche Technologie sinnvoll ist.

Kurz gesagt: UtilLib soll ständig wiederkehrende Aufgaben abstrahieren, die in sehr vielen Programmen vorkommen: Textverarbeitung, Parameter, Datenhaltung, Dateien, einfache Datenbankzugriffe usw.

Die langfristige Vision ist ein Toolkit, mit dem auch weniger erfahrene Entwickler relativ schnell einfache Programme bauen können, die zum Beispiel in Vereinen oder kleinen bis mittleren Unternehmen eingesetzt werden. Dort gibt es oft gewachsene Excel-Flickenteppiche, die eigentlich durch kleine, saubere Anwendungen ersetzt werden könnten. Das soll möglichst ohne lange Einarbeitung und ohne große Framework-Kenntnisse möglich sein.

 

[KonradN2]

Ich muss gestehen, dass ich so eine Library relativ skeptisch sehe, denn im Augenblick sehe ich nicht wirklich, wieso jemand so eine Library nutzen sollte.

Viele Dinge hat Java bereits (Der Gedanke ist vor allem über die Collections getriggert), so dass der Sinn sich nicht wirklich ergibt. Und ich sehe da auch direkt massive Begrenzungen.

Ein weiterer ganz großer Punkt ist: Wer soll diese Library in Zukunft nutzen? Die Entwicklung zukünftig immer mehr durch KI erfolgen. Und in dem Bereich sehe ich keinen Sinn in solchen Libraries. Da sind Libraries wie Spring Boot sinnvoller, weil sie Code (und damit Token) reduzieren. Das ist etwas, das mir deutlich wurde, als ich mit KI diverse Go Projekte umgesetzt habe. Bei Gedanken zu Infrastruktur und Architektur wurde dann vieles an Libraries einfach links liegen gelassen, da der Einsatz so nicht mehr wirklich sinnvoll schien. (Was etwas ungewohnt war als Java Entwickler, da man hier ja wirklich deutlich stärker auf Libraries wie Spring Boot oder Quarkus zurück greift)

ABER: Das ist meine Sicht. Nur weil ich da etwas nicht sehe, muss das nicht so sein! Gerade im Open Source Bereich habe ich mich schon massiv über so manche Entwickler-Sichtweise aufgeregt, wo gnadenlos gesagt wurde: Diese Anforderung ist Unsinn - die gibt es so nicht. (Wenn man dann aus berechtigten Gründen so eine Anforderung hat, dann steht man da und fragt sich: Was stimmt denn da nicht.....)

Was die Umsetzung angeht: Die beste Unterstützung kann die KI sein. Bei dem Umfang, den ich da aktuell sehe, kann die KI das vermutlich deutlich schneller und besser erledigen, als wenn Du etwas mit einer Gruppe abstimmen würdest. Die Hauptarbeit wäre dann also mehr im Bereich der Agenten (Wobei es da bestimmt auch Repositories mit ausgeklügelten Agenten geben dürfte, die man nutzen kann. Man muss sowas ja nicht selbst aufbauen.)

Deine Storage Idee: Das sehe ich so nicht wirklich als sinnvoll an:

• Bei dem Beispiel: Wo ist die Typsicherheit? Und wie kann diese aussehen? Aus meiner Sicht ist das extrem wichtig, d.h. es müsste hier auch Generics geben. Aber wie soll das funktionieren? Die list will andere Interfaces als keyValue (List will einfach Elemente von Typ <V> und keyValue bräuchte doch <K,V>).
• Limitierungen wenn du die Daten als eine Art Datenbank ablegst (.persist()), dann wäre die Frage doch, wie Du da vernünftige Zugriffe implementieren kannst. Du legst da Rechnungen ab. Das kannst Du dann von mir aus als key/value ablegen, so dass Du nach Rechnungsnummer schnell zugreifen kannst. Aber jetzt brauchst Du alle Rechnungen eines Kunden? Wie bildest Du diese Relationen überhaupt ab? Im Hauptspeicher hast Du einfache Referenzen, aber wenn Du es speichern sollst? Das einfach nur zwei Dinge, die ich direkt sehe im Bereich Limitierungen.

JavaFX oder Swing: Ich sehe hier viel pro/contra. JavaFX ist das modernere, aber das sehe ich als tot an. Libraries, die es da gibt, werden teilweise nicht weiter entwickelt. Und so toll es ist: Die Entwicklung stoppte einfach zu früh. (Ich hatte mir mal überlegt, was man da bauen kann, um es wirklich nutzbar zu machen: Binding System überarbeiten, eine Art Komponenten-basierte Lösung, MVVM mit generiertem VM, ...
Aber es ist aus meiner Sicht einfach tot und so eine Entwicklung macht wenig bis keinen Sinn.
Daher wäre mein Tipp: Swing nutzen. Schau dabei aber darauf, was vorhandene Projekte nutzen (Bei JavaFX sehe ich da nicht wirklich was. Aber JetBrains nutzt auch Swing und man könnte da auch schauen, was sie da an Libraries nutzen, um damit so eine IDE zu bauen.)

 

[Robert Zenz]

Was dann natuerlich noch waere, ist das Projekt irgendwo hochzuladen wo andere tatsaechlich etwas dazu beitragen koennen. Da wuerde sich zum Beispiel Codeberg anbieten.

SYSOFile ist tatsächlich kein Ersatz für Logging. Die Klasse ist eher als kleines Hilfswerkzeug entstanden: schnell System.out-ähnliche Ausgaben in eine Datei schreiben, ohne direkt ein komplettes Logging-Setup aufzusetzen. Ich finde so etwas in manchen Situationen praktisch. Aber ja: Für echte Bibliotheksausgaben sollte natürlich kein System.out/System.err verwendet werden, sondern ein Logger.

Ich muss ehrlich sagen, ich kann die meisten Logger-Frameworks auch nicht leiden. Aber eigentlich muesste das zusaetzliche umleiten in eigene Datei, zumindest mit dem Java Logger, einfach sein.

Beim Thema Lizenz bin ich noch unsicher. Die Bibliothek soll sowohl für Open-Source-Projekte als auch für kommerzielle Projekte geeignet sein. Vermutlich läuft es auf eine permissive Lizenz wie Apache 2.0 oder MIT hinaus. Das muss ich sauber klären, inklusive der Lizenzen der verwendeten Abhängigkeiten.

Das ist richtig, das ist immer das schwierige und wird gerne uebersehen.

Auch bei den Abhängigkeiten sehe ich den Punkt. Langfristig sollte es eine Lösung geben, bei der man nicht alle externen Bibliotheken mitzieht, sondern nur die Module und Dependencies, die man wirklich verwendet. Der eigentliche UtilLib-Code ist bisher relativ klein; problematisch wird es eher durch die gebündelten Abhängigkeiten.

Das wird eventuell zu einer sehr feinen Stueckelung der Bibliothek fuehren, wie ich bereits angesprochen habe, was dann natuerlich an einigen Ecken wieder unpraktisch wird. Wenn moeglich ideal waere es Abhaengigkeiten zu vermeiden.

Eine nächste praktische Baustelle ist aus meiner Sicht der Storage-Teil.

Die wirklich, wirklich, wirklich wichtige Frage ist: Welcher Nutzungsfall? Also nicht nur "so kann man es verwenden" sondern "so wird es in diesem konkreten Szenario verwendet".

 

[Robert Zenz]

JavaFX oder Swing: Ich sehe hier viel pro/contra. JavaFX ist das modernere, aber das sehe ich als tot an. Libraries, die es da gibt, werden teilweise nicht weiter entwickelt. Und so toll es ist: Die Entwicklung stoppte einfach zu früh. (Ich hatte mir mal überlegt, was man da bauen kann, um es wirklich nutzbar zu machen: Binding System überarbeiten, eine Art Komponenten-basierte Lösung, MVVM mit generiertem VM, ...
Aber es ist aus meiner Sicht einfach tot und so eine Entwicklung macht wenig bis keinen Sinn.

Sehe ich genauso. Seitdem JavaFX von Oracle an die Gemeinschaft "gespendet" wurde, ist anscheinend nur noch Gluon daran interessiert, und die machen Mobile Dinge.

Swing hingegen funktioniert, ist bei jeder Java Installation dabei, und mit LaFs kann man auch die "Aber Swing sieht schlecht aus" Leute ausknicken. Swing hat den vollkommen richtig Ansatz verfolgt, naemlich einfach in der JRE dabei sein, alles andere is Murks oder Mehraufwand fuer alle.