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.

 

[Oneixee5]

Dort gibt es oft gewachsene Excel-Flickenteppiche, die eigentlich durch kleine, saubere Anwendungen ersetzt werden könnten.

Ja die könnten abgelöst werden, dass wird aber nicht passieren. Office lernen viele in der Schule oder Ausbildung, dass ist was die Leute kennen und etwas können. Die Hürde, sich als Amateur, in etwas völlig anderes einzuarbeiten ist doch ziemlich hoch. Dabei spielt es nur eine untergeordnete Rolle wie gut die Anwendung ist oder wie schwierig die Umsetzung in Excel.
In Vereinen gibt es auch oft den Druck, etwas zu haben, womit auch ein Vertreter oder Nachfolger klar kommen kann. Also wird man dort fast immer auf Office setzen. Schon der Wechsel zu LibreOffice ist für viele nicht einfach - hier wirkt nur der Kostendruck.
Der nächste Punkt für viele Vereine ist die Angst vor den Lizenzen. In vielen Produkten ist es so, dass man seine Daten nur noch sehr schwierig herausbekommt, wenn diese einmal da drin sind. In dem Moment der höchsten Abhängigkeit werden dann die Lizenzmodelle auf Abos mit horenden Zusatzgebühren umgestellt. Man muss sich gut überlegen ob man so eine Situation ausgleichen kann. Entweder finanziell oder der nötigen Manpower um neu anzufangen.
Der nächste Punkt sind Wartung und Updates. Excel funktioniert immer und auf ganz vielen Geräten. Ein Verein kann sich aber nicht sicher sein, ob ein Programm, welches nur auf einem Vereins-PC vorhanden ist, mit der nächsten Windows-Version noch funktioniert. Dann ist oft die einzige Lösung, eine Fachfirma zu beauftragen - mit den entsprechenden Kosten.
Auch eine OpenSource-Eigenbau-Lösung macht da nichts besser. Diese kann dann nur einer im Verein abändern, anpassen, Fehler beheben oder installieren. Wenn diese Person nach einem Jahr keine Lust mehr hat - dann geht einfach nichts mehr.
Was dann passiert habe ich selber erlebt. Das reicht von Ärger mit dem Finanzamt über verlorene Fördermittel und Aberkennung der Allgemeinützigkeit bis zu teuren Abmahnungen. Man hat im Verein versucht anderen zu helfen und eine schöne Zeit zu haben. Am Ende sind alle zerstritten und man hat nur Frust und Ärger.

 

[TomBombadil]

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


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.


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


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.


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".

Grade zum Punkt hochladen so das es standardkonform ist und Entwickler beitragen können ist für mich auch ein Pain, wo ich schlicht unterstützung brauchen könnte.
ich fände es cool wenn sich vielleicht 2-3 Leute finden, die Bock drauf haben, mit denen ich dann bspw. erstmal via Videokonferenz das ganze besprechen kann und man dann gemeinsam das Ding wuppt.

bei der Stückelung bin ich jetzt im Gespräch mit ChatGPT wie man es aufbauen kann. Abhängigkeiten werde ich haben weil ich bspw. kein gson, sqlite, h2 nachbauen möchte. Hab so die Philosophie "Profis vor Eigenbau".
Die UtilLib soll grade auch Anfängern helfen, durch gute umfassende Doku mit Erklärung des wieso, relativ schnell brauchbare Ergebnisse zu erzielen.

Ich bin als Anfänger oft auf das Problem gestoßen, das ich bspw. in meinem Programm nur mal schnell eine Json einlesen will. Nur dafür ist es extrem mühsam erstmal rauszufinden welche Libs gibt es, wie funktioniert JSON genau, welche Lib ist jetzt für mich die richtige und wie kann ich die nutzen. Das kann für den Anfänger schnell mal sehr lange mühsame Recherche bedeuten nur um eine JSON Datei einzulesen.

"Komplexität nach innen, KISS nach außen"

Genau hier soll die Lib ansetzen, in dem sie die Recherche auf villeich 1 Stunde beschränkt und man kann seine Json Datei einlesen. In der Doku weise ich aber explizit darauf hin das die UtilLib eben genau für sowas gedacht ist sie soll die 20% Funktionen einer professionellen Lib (oder Java SE Komponente) die 80% der Probleme lösen, schnell und einfach verfügbar machen.
Schweizer Taschenmesser eben, es hat Tools für nahezu jede Lebenslage. Wenn ich eine Schraube irgendwo reindrehen muss ist das optimal weil vefügbar und ohne nenneswerte Werkzeugkunde einsetzbar. Wenn ich 100 Schrauben irgendwo rein drehen muss, macht es hingegen Sinn sich mit dem Akkuschrauber vertraut zu machen. Das ist mal so die Abgrenzung.

Die Idee zum Storage kam mir aus einer kleinen Bastelei herraus. Ich hatte mal so als Fingerübung die ArrayList von Java selbst nachgebaut und dann ist mir aufgefallen, das man das doch auch vereinfachen kann warum soll der User sich mit ArrayList, Hashset usw. rumschlagen müssen. Ergebenis war die MagicCollection die diese entscheidungen abstrahiert. (hab ich mal angehängt). Und Storage ist im grunde die weiterführung des Gedankens. das der User nur noch sagen muss was er will, und sich um das wie nicht mehr kümmern braucht.

 

[TomBombadil]

Ja die könnten abgelöst werden, dass wird aber nicht passieren. Office lernen viele in der Schule oder Ausbildung, dass ist was die Leute kennen und etwas können. Die Hürde, sich als Amateur, in etwas völlig anderes einzuarbeiten ist doch ziemlich hoch. Dabei spielt es nur eine untergeordnete Rolle wie gut die Anwendung ist oder wie schwierig die Umsetzung in Excel.
In Vereinen gibt es auch oft den Druck, etwas zu haben, womit auch ein Vertreter oder Nachfolger klar kommen kann. Also wird man dort fast immer auf Office setzen. Schon der Wechsel zu LibreOffice ist für viele nicht einfach - hier wirkt nur der Kostendruck.
Der nächste Punkt für viele Vereine ist die Angst vor den Lizenzen. In vielen Produkten ist es so, dass man seine Daten nur noch sehr schwierig herausbekommt, wenn diese einmal da drin sind. In dem Moment der höchsten Abhängigkeit werden dann die Lizenzmodelle auf Abos mit horenden Zusatzgebühren umgestellt. Man muss sich gut überlegen ob man so eine Situation ausgleichen kann. Entweder finanziell oder der nötigen Manpower um neu anzufangen.
Der nächste Punkt sind Wartung und Updates. Excel funktioniert immer und auf ganz vielen Geräten. Ein Verein kann sich aber nicht sicher sein, ob ein Programm, welches nur auf einem Vereins-PC vorhanden ist, mit der nächsten Windows-Version noch funktioniert. Dann ist oft die einzige Lösung, eine Fachfirma zu beauftragen - mit den entsprechenden Kosten.
Auch eine OpenSource-Eigenbau-Lösung macht da nichts besser. Diese kann dann nur einer im Verein abändern, anpassen, Fehler beheben oder installieren. Wenn diese Person nach einem Jahr keine Lust mehr hat - dann geht einfach nichts mehr.
Was dann passiert habe ich selber erlebt. Das reicht von Ärger mit dem Finanzamt über verlorene Fördermittel und Aberkennung der Allgemeinützigkeit bis zu teuren Abmahnungen. Man hat im Verein versucht anderen zu helfen und eine schöne Zeit zu haben. Am Ende sind alle zerstritten und man hat nur Frust und Ärger.

Danke für die Einschätzung!

Die Idee wäre Praktisch die das bspw. ein Verein oder kleines Unternehmen einen Freelancer oder auch eine kleine Softwarefirma beauftragen kann, die Ihnen ihren Excel Flickenteppich durch ein sauberes Programm ersetzt. Und durch die vorarbeit der UtiLib kostet das Programm dann statt 10 000€ nur erschwingliche 1000€, oder wenn es als Branchensoftware entwickelt wird dann villeicht nur noch 100-200€.

Der Benefit wäre das Branchenkenner mit geringen bis mittleren Programmierkenntnissen relativ leicht was entwickeln können.

Durch die Senkung der Herstellungskosten für Programme für kleine Vereine und Unternehmen, kann es auch schneller zu einer gößeren Vielfalt an Programmen kommen, so das der Vogelzüchterverin der jetzt schlicht kein Angebot hat plötzlich aus drei Angeboten wählen kann.

Und Java ist meines Erachtens hier optimal weil es umfangreiche Bibliotheken hat, sehr hoch entwickelt ist und besonders Plattformunabhängig! Von daher sehe ich bei Java anwendungen kein Problem darin wegen Systemen und Systemversionen.

Es geht mir darum eine Plattform bereitzustellen die letztlich mehr Wettbewerb ermöglicht. Wenn Verein/Unternehmen X sagt wir bleiben bei Excel, ok. Aber die UtlilLib schafft die möglichkeit das Verein/Unternehmen Y sagen kann: "wir ziehen die alternative in Betracht"

Das wäre mal so Grob die Vision. Ich kenne auch viele Kleinunternehmer die unter ihrer Excel last leiden, weil ihnen aber auch das KnowHow und die Mittel fehlen was anderes zu machen. Wenn hier ein Kleiner Freelancer der die Branche kennt schnell was für 1000€ zusammenzimmern kann das die Bürozeit im Unternehmen aber drastich reduziert würden viel Unternehmer das liebend gerne Zahlen.

 

[TomBombadil]

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.

Deine argumentation zu Swing ist extrem spannend. Für mich ist GUI entwicklung ein rotes Tuch grade deswegen kann es auch hier sinn machen in der UtilLib vereinfachungen anzubieten. Hab das grade mit ChatGPT analysiert, man könnte bausteine zusammenfassen und vereinfacht bereitstellen.

Beispiel

Form.create()
    .text("Name")
    .text("Vorname")
    .number("PLZ")
    .text("Ort")
    .buttons("Speichern", "Abbrechen");

Das liest sich dann schon fast wie ein natülicher satz in dem der User beschreiben kann was er möchte und sich nicht mit den Imprementierungsdetails rumschlagen muss.

 

[KonradN2]

Danke für die Einschätzung!

Die Idee wäre Praktisch die das bspw. ein Verein oder kleines Unternehmen einen Freelancer oder auch eine kleine Softwarefirma beauftragen kann, die Ihnen ihren Excel Flickenteppich durch ein sauberes Programm ersetzt. Und durch die vorarbeit der UtiLib kostet das Programm dann statt 10 000€ nur erschwingliche 1000€, oder wenn es als Branchensoftware entwickelt wird dann villeicht nur noch 100-200€.

Der Benefit wäre das Branchenkenner mit geringen bis mittleren Programmierkenntnissen relativ leicht was entwickeln können.

Durch die Senkung der Herstellungskosten für Programme für kleine Vereine und Unternehmen, kann es auch schneller zu einer gößeren Vielfalt an Programmen kommen, so das der Vogelzüchterverin der jetzt schlicht kein Angebot hat plötzlich aus drei Angeboten wählen kann.

Und Java ist meines Erachtens hier optimal weil es umfangreiche Bibliotheken hat, sehr hoch entwickelt ist und besonders Plattformunabhängig! Von daher sehe ich bei Java anwendungen kein Problem darin wegen Systemen und Systemversionen.

Es geht mir darum eine Plattform bereitzustellen die letztlich mehr Wettbewerb ermöglicht. Wenn Verein/Unternehmen X sagt wir bleiben bei Excel, ok. Aber die UtlilLib schafft die möglichkeit das Verein/Unternehmen Y sagen kann: "wir ziehen die alternative in Betracht"

Das wäre mal so Grob die Vision. Ich kenne auch viele Kleinunternehmer die unter ihrer Excel last leiden, weil ihnen aber auch das KnowHow und die Mittel fehlen was anderes zu machen. Wenn hier ein Kleiner Freelancer der die Branche kennt schnell was für 1000€ zusammenzimmern kann das die Bürozeit im Unternehmen aber drastich reduziert würden viel Unternehmer das liebend gerne Zahlen.

Ich habe da gerade Probleme, dies nachzuvollziehen.

Freelancer / kleine Softwarefirma: Wo siehst Du hier den Vorteil Deiner Library? Wer beruflich mit Java Software entwickelt, der wird zwangsläufig ein Framework wie Spring Boot oder Quarkus kennen und nutzen. Ggf. auch darauf aufsetzende Lösungen wie Vaadin.

Und auch die Kosten sehen etwas aus der Luft gegriffen aus. Wie kommst Du auf so Zahlen wie 1.000 oder 100 EUR?

Und ist es denn wirklich eine Alternative? Der Vorteil von Excel ist ja eben, dass es jederzeit angepasst werden kann von den Leuten, die es nutzen. Eine neue Spalte? Kein Problem. Ein Wert hat sich geändert? Dann passt man den in der Formel an. Schnell und einfach. Diese Flexibilität geht halt direkt verloren.

Davon ganz abgesehen macht die Softwareentwicklung derzeit einen ganz massiven Wandel mit - Jetzt wird das Coding mit Agenten gemacht was alles deutlich vereinfacht und beschleunigt.

Bezüglich Ablösen von Excel-Sheets in Unternehmen gibt es ansonsten auch viele andere Ansätze. Diese gehen dann aber mehr in den Bereich Low Code und No Code und hier haben dann die Anbieter von Workspace Angeboten wie Office 365 und GSuite auch jeweils eigene Produkte im Angebot, die dann halt auch noch viele Dinge mit berücksichtigen wie z.B. die ganzen Sicherheitsaspekte incl. Anwender authentifizieren und gezielt autorisieren für einzelne Dinge.

In der Richtung hatte ich schon ein paar Ideen, denn hier kann man tatsächlich einiges aufbauen. Dann hat man eine Basis von Spring Boot oder Quarkus als Basis aber man hat halt bereits den ganzen Kern bereits drumherum (Vieles hätte Spring Boot z.B. bereits).
Dann würde man gezielt einzelne Agenten / Skills / Rules bereit stellen:

• Anlegen und Verwalten von Daten (Entitäten, externe Systeme, ...)
• Definieren der Business-Logik. Diese wird teilweise aus den Entitäten abgeleitet da dort ja Relationen festgelegt wurden aber alles drumherum wird hier auch definiert)
• Definieren von UseCases
• Darauf dann die Definition eines Frontends

Aber was dagegen spricht, ist einfach, dass die Komplexität nur minimal abnimmt und dadurch automatisch Restriktionen mitkommen. Es braucht also nicht einmal eine Library oder so - es gibt bereits alles und alles was es braucht sind die Agenten.

Deine argumentation zu Swing ist extrem spannend. Für mich ist GUI entwicklung ein rotes Tuch grade deswegen kann es auch hier sinn machen in der UtilLib vereinfachungen anzubieten. Hab das grade mit ChatGPT analysiert, man könnte bausteine zusammenfassen und vereinfacht bereitstellen.

Beispiel

Form.create()
    .text("Name")
    .text("Vorname")
    .number("PLZ")
    .text("Ort")
    .buttons("Speichern", "Abbrechen");

Das liest sich dann schon fast wie ein natülicher satz in dem der User beschreiben kann was er möchte und sich nicht mit den Imprementierungsdetails rumschlagen muss.

Das ist garantiert ein legitimer Ansatz, so lange es keine wirklichen Ansprüche an das Aussehen gibt. Die Anforderungen werden aber auch früher oder später kommen und dann hat man ein direktes Problem.

Ich erinnere mich hier an eine Erfahrung die inzwischen ca. 20 Jahren her ist. Es gab diverse Anbieter / Lösungen wo eben geworben wurde mit Slogans: Mal eben schnell vor dem Mittagessen noch so eine Business Anwendung fertig machen. Und ja: Das ging!

Wir waren als Entwicklungsteam hoffnungslos ausgelastet und es gab eine Anforderung: Eine Datenbank brauchte dringend ein Frontend. Das Frontend habe ich an einem halben Arbeitstag gebaut, die zweite Hälfte diente dazu, es in Produktion zu bringen. Absolut genial - bis hier hin.

Es kamen dann aber diverse Probleme aus:

• Zum einen gan es dann Anforderungen, die so nicht mit dem Tool umzusetzen waren. Es gab dann zwar noch paar Lösungsansätze: Ein spezielles 3rd Party Grid wurde angeschafft was vieles verbesserte aber gewisse Dinge erforderten tiefe Änderungen, die so nicht möglich waren.
• Probleme, die irgendwo tief im Inneren auftraten. Da hat man eine Fehlermeldung, die einem nichts sagt und man hat keine Chance, den Fehler zu finden. (Damals hat mir dann die Community geholfen - ich hatte etwas genau so gemacht, wie es der Hersteller auch vorgeschlagen hatte, was aber zu timing Problemen führen konnte... )

Also ja: ganz am Anfang hat uns das super viel Zeit abgenommen. Später hat es aber ein vielfaches an Zeit gekostet. (Und heute wäre es kein Thema - da wäre es nach unserem 08/15 Schema gemacht worden, die viele Schreibarbeit macht die KI und man ist auch nach 1 Tag fertig nur eben ist es wartbar und man hat keine versteckte Komplexität. Und genau das stösst mir auf, wenn Du sagst, dass Du KISS nach aussen aber innen dann gewisse Komplexität haben willst .... Wieso? Damit ich nicht entscheiden muss, ob ich eine List oder ein Set nutzen sollte?)

 

[TomBombadil]

Ich habe da gerade Probleme, dies nachzuvollziehen.

Freelancer / kleine Softwarefirma: Wo siehst Du hier den Vorteil Deiner Library? Wer beruflich mit Java Software entwickelt, der wird zwangsläufig ein Framework wie Spring Boot oder Quarkus kennen und nutzen. Ggf. auch darauf aufsetzende Lösungen wie Vaadin.

Und auch die Kosten sehen etwas aus der Luft gegriffen aus. Wie kommst Du auf so Zahlen wie 1.000 oder 100 EUR?

Und ist es denn wirklich eine Alternative? Der Vorteil von Excel ist ja eben, dass es jederzeit angepasst werden kann von den Leuten, die es nutzen. Eine neue Spalte? Kein Problem. Ein Wert hat sich geändert? Dann passt man den in der Formel an. Schnell und einfach. Diese Flexibilität geht halt direkt verloren.

Davon ganz abgesehen macht die Softwareentwicklung derzeit einen ganz massiven Wandel mit - Jetzt wird das Coding mit Agenten gemacht was alles deutlich vereinfacht und beschleunigt.

Bezüglich Ablösen von Excel-Sheets in Unternehmen gibt es ansonsten auch viele andere Ansätze. Diese gehen dann aber mehr in den Bereich Low Code und No Code und hier haben dann die Anbieter von Workspace Angeboten wie Office 365 und GSuite auch jeweils eigene Produkte im Angebot, die dann halt auch noch viele Dinge mit berücksichtigen wie z.B. die ganzen Sicherheitsaspekte incl. Anwender authentifizieren und gezielt autorisieren für einzelne Dinge.

In der Richtung hatte ich schon ein paar Ideen, denn hier kann man tatsächlich einiges aufbauen. Dann hat man eine Basis von Spring Boot oder Quarkus als Basis aber man hat halt bereits den ganzen Kern bereits drumherum (Vieles hätte Spring Boot z.B. bereits).
Dann würde man gezielt einzelne Agenten / Skills / Rules bereit stellen:

• Anlegen und Verwalten von Daten (Entitäten, externe Systeme, ...)
• Definieren der Business-Logik. Diese wird teilweise aus den Entitäten abgeleitet da dort ja Relationen festgelegt wurden aber alles drumherum wird hier auch definiert)
• Definieren von UseCases
• Darauf dann die Definition eines Frontends

Aber was dagegen spricht, ist einfach, dass die Komplexität nur minimal abnimmt und dadurch automatisch Restriktionen mitkommen. Es braucht also nicht einmal eine Library oder so - es gibt bereits alles und alles was es braucht sind die Agenten.


Das ist garantiert ein legitimer Ansatz, so lange es keine wirklichen Ansprüche an das Aussehen gibt. Die Anforderungen werden aber auch früher oder später kommen und dann hat man ein direktes Problem.

Ich erinnere mich hier an eine Erfahrung die inzwischen ca. 20 Jahren her ist. Es gab diverse Anbieter / Lösungen wo eben geworben wurde mit Slogans: Mal eben schnell vor dem Mittagessen noch so eine Business Anwendung fertig machen. Und ja: Das ging!

Wir waren als Entwicklungsteam hoffnungslos ausgelastet und es gab eine Anforderung: Eine Datenbank brauchte dringend ein Frontend. Das Frontend habe ich an einem halben Arbeitstag gebaut, die zweite Hälfte diente dazu, es in Produktion zu bringen. Absolut genial - bis hier hin.

Es kamen dann aber diverse Probleme aus:

• Zum einen gan es dann Anforderungen, die so nicht mit dem Tool umzusetzen waren. Es gab dann zwar noch paar Lösungsansätze: Ein spezielles 3rd Party Grid wurde angeschafft was vieles verbesserte aber gewisse Dinge erforderten tiefe Änderungen, die so nicht möglich waren.
• Probleme, die irgendwo tief im Inneren auftraten. Da hat man eine Fehlermeldung, die einem nichts sagt und man hat keine Chance, den Fehler zu finden. (Damals hat mir dann die Community geholfen - ich hatte etwas genau so gemacht, wie es der Hersteller auch vorgeschlagen hatte, was aber zu timing Problemen führen konnte... )

Also ja: ganz am Anfang hat uns das super viel Zeit abgenommen. Später hat es aber ein vielfaches an Zeit gekostet. (Und heute wäre es kein Thema - da wäre es nach unserem 08/15 Schema gemacht worden, die viele Schreibarbeit macht die KI und man ist auch nach 1 Tag fertig nur eben ist es wartbar und man hat keine versteckte Komplexität. Und genau das stösst mir auf, wenn Du sagst, dass Du KISS nach aussen aber innen dann gewisse Komplexität haben willst .... Wieso? Damit ich nicht entscheiden muss, ob ich eine List oder ein Set nutzen sollte?)

Danke dir noch einmal für deinen ausführlichen Kommentar.

Ich habe den tatsächlich nicht einfach nur als „Gegenmeinung“ gelesen, sondern als Prüfstein genommen. Ich habe die Fragestellung danach noch einmal recht ausführlich mit mehreren KI-Systemen durchgespielt, unter anderem mit ChatGPT, Grok und Euria. Die Vorgabe war dabei ausdrücklich nicht: „Verteidige meine Idee“, sondern: „Prüfe kritisch, ob diese Bibliothek im KI-Zeitalter überhaupt noch eine Daseinsberechtigung hat.“

Ein Teil dieser Antwort ist deshalb auch KI-gestützt formuliert. Inhaltlich entspricht sie aber meiner aktuellen, durch die Diskussion geschärften Sicht.

Der wichtigste Punkt, bei dem du aus meiner Sicht recht hast:

„Weniger Boilerplate“ ist im KI-Zeitalter kein besonders starkes Argument mehr.

Wenn eine KI heute Spring Boot, Quarkus, Hibernate, Vaadin, Jackson, Flyway usw. erzeugen kann, dann ist das bloße Argument „man muss weniger Code schreiben“ deutlich schwächer als noch vor ein paar Jahren. Die KI schreibt Boilerplate sehr schnell. Und Spring/Quarkus sind erprobt, dokumentiert, weit verbreitet und der KI sehr gut bekannt.

Das war für mich tatsächlich ein wichtiger Realitätscheck.

Die Schlussfolgerung daraus ist aber nicht zwingend: „UtilLib ist sinnlos.“

Die Schlussfolgerung ist eher:

UtilLib darf nicht als Spring-Ersatz gedacht werden.

Wenn es um größere Web-Anwendungen, Authentifizierung, Rollen/Rechte, REST-APIs, Skalierung, Cloud-Deployment, Transaktionen über komplexe Datenmodelle oder Team-Entwicklung geht, dann wäre Spring Boot oder Quarkus sehr wahrscheinlich die bessere Wahl.

Da sollte UtilLib nicht konkurrieren.

Wo ich nach der Analyse aber weiterhin eine mögliche Nische sehe, ist ein anderer Bereich:

Local-First, kleine Fachanwendungen, interne Tools, Desktop-Programme, Vereinssoftware, Excel-Ablösung und schnelle Prototypen.

Also nicht:

„Wir bauen das nächste Enterprise-Framework.“

Sondern eher:

„Wir bauen kleine, robuste Java-Fachanwendungen mit lokaler Datenhaltung, wenig Setup und möglichst geringer kognitiver Komplexität.“

Der entscheidende Punkt ist für mich inzwischen nicht mehr primär „weniger Code“, sondern:

weniger kognitive Komplexität.

Denn auch wenn die KI den Code schreibt, muss ein Mensch ihn am Ende verstehen, prüfen, debuggen, anpassen und verantworten können.

Eine KI kann mir eine Spring-Anwendung generieren. Aber wenn dann ein Problem mit Bean-Scanning, Proxies, Lazy Loading, Transaktionen, Session-Kontext, Security-Konfiguration oder Build-Konfiguration auftritt, brauche ich trotzdem Framework-Wissen, um den Fix beurteilen zu können.

Für einen erfahrenen Spring-Entwickler ist das kein Problem.

Für einen kleinen Freelancer, einen Nebenbei-Entwickler, einen Vereinsmenschen mit Java-Grundkenntnissen oder jemanden, der ein internes Tool bauen will, kann das aber eine erhebliche Hürde sein.

Dort könnte UtilLib ihren Platz haben:

• einfache lokale Speicherung über SQLite, H2, JSON oder CSV
• einheitliche Fehlerbehandlung über Result2
• einfache Konfiguration
• CSV/Excel-ähnliche Importe und Exporte
• Validierung von Daten
• einfache Berichte als CSV, Markdown, HTML oder PDF
• kleine GUI-Helfer für Standardfälle
• klare Doku, die auch als KI-Kontext funktioniert

Also eher eine Art:

KI-freundliches Local-First Rapid-Application-Toolkit für kleine Java-Fachanwendungen.

Nicht als Konkurrenz zu Spring, sondern als Alternative für Fälle, in denen Spring schlicht überdimensioniert wäre.

Dein Excel-Einwand ist ebenfalls berechtigt. Excel ist so stark, weil es flexibel ist. Eine neue Spalte, eine geänderte Formel, eine kleine Anpassung: Das kann der Nutzer direkt machen.

Das verliert man bei klassischer Software tatsächlich teilweise.

Aber genau dort liegt auch das Problem: Viele Excel-Lösungen bleiben nicht bei „ein paar Spalten“. Sie wachsen über Jahre zu Flickenteppichen aus Tabellen, Formeln, Kopien, Makros und implizitem Wissen. Irgendwann ist das nicht mehr Flexibilität, sondern technische Schuld.

Mein Ziel wäre nicht, Excel überall zu ersetzen.

Mein Ziel wäre eher, für Fälle, in denen Excel bereits sichtbar weh tut, eine realistische Zwischenlösung zu ermöglichen.

Also nicht:

„Jeder Verein braucht Individualsoftware.“

Sondern:

„Wenn der Excel-Flickenteppich zum echten Arbeitszeit- und Fehlerproblem wird, soll eine kleine, bezahlbare Fachanwendung überhaupt erst als Option denkbar werden.“

Auch bei meinen genannten Zahlen wie 1.000 Euro oder 100–200 Euro für Branchensoftware hast du recht: Das sind keine belastbaren Marktpreise, sondern eher Zielbilder beziehungsweise Hypothesen. Ob das realistisch ist, müsste man messen.

Daraus ergibt sich für mich ein sinnvoller nächster Schritt:

Man müsste dieselbe kleine Anwendung tatsächlich vergleichen.

Zum Beispiel:

Mitgliederverwaltung mit Beitragsberechnung, CSV-Import, lokaler Speicherung und Export.

Einmal mit:

• Spring Boot / Quarkus plus etablierte Libraries

und einmal mit:

• UtilLib als Local-First-Toolkit

Dann könnte man ehrlich messen:

• Wie viele Dateien entstehen?
• Wie viel Projektsetup ist nötig?
• Wie lange dauert es bis zum ersten funktionierenden Stand?
• Wie gut kann eine KI den Code später ändern?
• Wie gut versteht ein weniger erfahrener Java-Entwickler den Code?
• Wie gut lassen sich Fehler finden?
• Wo wird es wartbarer?
• Wo wird es durch eigene Abstraktion schlechter?

Wenn UtilLib dort nur minimal besser ist, dann wäre das kein starkes Argument.

Wenn UtilLib aber für diese kleinen Fachanwendungen deutlich weniger Reibung erzeugt, dann wäre das eine echte Nische.

Durch deinen Kommentar ist für mich deshalb die Positionierung klarer geworden:

UtilLib sollte kein allgemeiner Spring-Ersatz werden.
UtilLib sollte kein weiteres Sammelsurium beliebiger Helper-Klassen werden.
UtilLib sollte sich auf kleine, lokale, verständliche Fachanwendungen konzentrieren.

Der stärkste mögliche Nutzen wäre dann nicht:

„Die KI muss weniger tippen.“

Sondern:

„Mensch und KI müssen weniger unterschiedliche Konzepte gleichzeitig verstehen.“

Das ist für mich inzwischen der eigentliche Kern.

Ob das reicht, muss sich zeigen. Aber deine Kritik hat geholfen, die Idee deutlich realistischer einzugrenzen.