Was für Unsinns-Argumente sind denn das? 'Mit AS entwickelt ja jeder falsch und wenn er Spring benutzen würde, würde er es besser machen'.
Wer mit AS riesige, unhaltbare Monolithen entwickelt, macht das mit Spring nicht anders. Wer mit Spring sauber entwickelt, macht das auch mit AS.
Wenn du mit AS keine saubere Trennung von Domänen hinbekommst, schaffst du das mit Spring auch nicht.
Und ernsthaft? AS "zwingen Dir eine Codebasis auf, die verschimmelt und beim Lebensende in Gänze fortgeworfen wird.", aber die Spring-Anwendung ist gut, weil "Die werfe ich dort weg, wenn sie mir an einer Stelle nicht gefällt"
Der argumentiert einseitig. (Wolff auch. Ich auch ;-)) Aber der zeigt auf seinen Talks Microservices, die er in 700MB Dockercontainer mit Wildfly packt und findet das toll.
Microservices darf man natürlich nur toll finden, wenn sie in 573MB 700MB mit Spring umgesetzt sind
Ziemlich viele. Ist eben deutlich einfacher, als Microservices.
Release-Zyklen von 3 Jahren vs. 3 Monaten?
Vom Wildfly gibts alle 3 Monate 'ne neue Version
Oder beziehst du dich wirklich auf den EE-Standard? Was ist denn das für ein Unsinns-Argument, weil der Standard über mehrere Jahre Stabil ist und nicht alle drei Monate in einer inkompatiblen Version released wird, ist das schlecht?
Das kann man kaum vergleichen: Server runterfahren und JARs in einen Modulpfad kopieren, xml-Descriptor anpassen und alles hochfahren? Bei Spring Versionsnummer im VCS ändern, releasen und ausrollen. Wenn verteilt, sogar ohne Downtime. Und vor allem dies direkt im Quellcode. Ohne ein einen Server in einem Configuration Management zu konfektionieren.
Also, AS ist schlecht, weil man Server unterfahren muss, Spring aber gut, weil man Server nur beenden muss?
AS schlecht, weil man das Modul updaten muss (was sich Skripten lässt), aber Spring gut, weil man nur Dependance updaten muss.
Und AS schlecht, weil man den Server starten muss, aber Spring gut, weil man nur Server starten muss?
(BTW, deinen Spring-Weg kann mit mit AS genauso fahren, mach ich auch so...)
Das ist eine Milchmädchenrechnung: Spring Anwendungen laufen auch "nach Jahren" noch. Nur ohne aufgezwungenes Produkt, das nicht mehr gepflegt wird.
Ja, laufen noch, aber lassen sich halt nicht mehr updaten - und, Luft anhalten, Spring ist dabei das aufgezwungenes Produkt.
Das "aufgezwungene Produkt" bei AS ist ein
offener Standard, gegen den man entwickelt. Die Anwendung kann man ohne große Änderungen auf einen neuen AS verschieben und es läuft weiter, und alles ist geupdated, ohne die eigentliche Anwendung angefasst zu haben. (Ja, man muss u.U. die Config des AS anpassen, bei Spring musst du das aber ebenso).
Jetzt widersprichst Du dir: Du kannst nicht mit"Update" argumentieren und im Satz davor sagen, dass alles noch nach Jahren läuft. Das, was da "nach Jahren läuft", ist nie geupdatet worden. Sondern verschimmelt. ;-)
Ne, das liegt an deinem Verständnis von Update
Eine .war, die vor X Jahren gegen den Standard entwickelt und seit dem nicht angefasst wurde, ist auch mit dem aktuellem Standard kompatibel und läuft entsprechend auch auf kompatiblen AS.
Die Fat-Jar, die man vor X Jahren entwickelt und seit dem nicht angefasst hat, ist nicht mehr mit der aktuellen Version kompatiblen und jetzt wirklich verschimmelt, da kann man nicht mal einfach alte Libs updaten.
Ernsthaft, deine ganze Argumentation beruht darauf, das alle mit AS entwickelten Anwendungen grottenschlecht von völlig unfähigen Entwicklern entgegen allen Best-Practices umgesetzt sind, aber alle Spring-Boot-Anwendungen von fähigen Entwicklern nach allen Best-Practices mit perfekter Codebasis entwickelt sind. Die Realität sieht aber anders aus...
Den ganzen Prozess, der bei Spring laut dir so wunderbar ist, kann man nahezu identisch mit AS umsetzen. Und genauso kann man alles, was man laut dir immer mit AS falsch macht, genauso mit Spring falsch machen.
Und, Überraschung, beides passiert. Weder mit mit Spring alles gut, noch mit AS alles schlecht, in der Realität ist das ziemlich ausgeglichen...
