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.