Ja, das Verfahren hatte ich damals allerdings per Suche im Netz als “macht man so” gefunden und seitdem beibehalten. Durch den Umbau der JDK/JRE-Struktur mit Java 9 fiel diese Möglichkeit weg (was ja gut ist, wenn das nicht der richtige Weg ist).
Jetzt klappt es auf die “richtige” Weise.
Nur um es nochmals zu verdeutlichen, falls mal jemand anders ebenfalls hier liest.
Wenn man Jars zur JRE/JDK in lib/ext packt, dann hat man eine angepasste Java-Installation. Die Probleme die daraus erfolgen sind dann immer wieder, dass man vergisst diese zusätzlichen Abhängigkeiten mitzuliefern, wenn man etwas programmiert. Ein Kunde bekommt dann zum Beispiel eine ClassNotFoundException.
Bei verschiedenen Projekten, die inkompatible Versionen eines Jars benötigen, bekommt man Versionskonflikte. Möchte man Feature X einer neuen Version nutzen, muss man gegebenenfalls andere Projekte ebenfalls auf eine neue API-Version migrieren. Möchte man so auch nicht immer haben.
Führt man fremde, Java Programme auf seinem Rechner aus, dann hat man damit auch immer die Abhängigkeiten aus lib/ext im Classpath. Dies kann dann zu unschönen Seiteneffekten führen, wenn dann die falsche Version einer Lib verwendet wird die an anderer Stelle inkompatibel oder fehlerhaft/veraltet ist.
Aber ich muss zugeben, in meiner Anfangszeit hab ich auch das ein oder andere mal jars nach lib/ext kopiert.
Diese ekligen Probleme bin ich zum Glück dadurch entgangen, dass auf dem Ort wo die Programme verwendet wurde, ein anderes Java zum Einsatz kam, ohne irgendwas im lib/ext-Verzeichnis.
Dort habe ich die benötigten Jars zu meiner eigenen gelegt und hatte dadurch auch keine Probleme mit nicht gefundenen Klassen oder dergleichen.
Bis auf die ClassNotFoundException sind das allerdings alles Probleme, die auf deinem Entwicklungsrechner auftreten, und nicht nur auf dem Rechner, auf dem es letztendlich läuft 
Ich hab doch gar keine Probleme mehr?