Caute,
vela programujem v Jave a v poslednom case som sa prichytil pri tom, ze som zacal preferovat komponenty a libky ktore su v Jave samotnej. Dlho som napriklad pouzival Jackson a ekosystem okolo na JSON alebo Apache HTTP libky na HTTP klientov ale uz celkom dlho existuje JSON-B / JSON-P a Java ma v sebe HttpClient-a ... Najprv som sa bal ze to nebude vela vediet ale cuduj sa svete, ono to ani nie je treba. Co zacinam nove projekty tak zamerne programujem uplne jednoducho v cistej Jave takze som zavisly na minime externych veci a ono to na pocudovanie aj celkom funguje. Zahodil som cely Spring a zacal som pouzivat Guice a Javalin. Na JWT tokeny java-jwt z com.auth0 a tiez to uplne v pohode fici jak ma ... raketovo sa v tom programuje.
Já moc nechápu, o čem vlastně chcete diskutovat. V titulku máte „komplikovanost“, ale v samotné otázce k ní pak není ani čárka.
Co se týče knihoven, samozřejmě nemá smysl používat externí knihovnu, pokud vašim potřebám vyhovuje i vestavěná runtime knihovna.
Knihoven pro JSON vzniklo několik, Jackson je mezi nim i asi nejrozšířenější. Používá ho i spousta dalších knihoven, takže občas jste k jeho použití donucen jinou knihovnou. Na druhou stranu to, jak je ta knihovna navržená, není žádná sláva. JSON-P je dobře navržené API, bylo to standardizováno, doufám, že postupně převezme roli toho standardního API pro JSON v Javě, že ho bude implementovat i Jackson a další. JSON-B je jiný případ, sice také snaha o standardní API, ale to API je nešťastně navržené a špatně zdokumentované. Referenční implementaci jsem naposledy zkoušel krátce před verzí 1.0 a bylo to docela dobrodružné – v jednom případě se něco špatně přetypovávalo a vyhazovalo o výjimku, v druhém případě dokonce bylo evidentní, že to nikdo nikdy neotestoval na mapě s více než jedním klíčem, protože zbytek mapy se prostě zahodil.
Původní HTTP klient v Javě byla tragédie a nemohl ho použít nikdo, kdo alespoň z rychlíku zaslechl něco o tom, jak má vypadat programování síťové komunikace. Nešlo tam nastavit nic, ani tak základní věc, jako timeouty. Proto se používaly externí knihovny. Teď už má Java HTTP klienta, který vypadá podstatně lépe, ale abych pravdu řekl, je to snad jediná věc z nových vlastností Javy, na kterou jsem se ještě víc nedíval – protože ta původní implementace byla opravdu tragédie, a být „podstatně lepší“ než to pořád ještě nezaručuje, že to bude alespoň dobré. Ale pokud už má vlastnosti, které potřebujete, a nepotřebujete podporu starších verzí Javy, proč to nepoužít?
To samé se týká i Springu – pokud ho nepotřebujete, tak proč ho používat? Spring spoustu věcí také implementuje tak, že akorát zabalí nějakou externí knihovnu tak, aby se používala stejně, jako ostatní komponenty Springu. Tak pokud potřebuju jenom funkcionalitu dané knihovny, použiju tu knihovnu a ne celý Spring.
Pouzivate externe libky aj ked nemusite? Zacal som to brat z uplne ineho konca, co najmenej externalit a vyuzit platformu na 100% a zatial sa mi nestalo, ze by mi tam nieco chybalo. Podla mna sa da vela krat dosiahnut ten isty ciel aj jednoduchsie, vsetky tie frameworky su vela krat len uplne zbytocne nadstavby.
Ta zbytečnost není vlastností frameworku ale jeho použití. Mne by spíš zajímalo, jak se vám stalo, že používáte externí knihovnu, i když nemusíte, nebo používáte zbytečně nějaký framework. Já se s takovými případy nesetkávám a moc si nedovedu představit, jak to vznikne.