Seriozní porovnání .NETu a Javy

[Jano7]

Když někdo tvrdí, že Java je multiplatformní, tak má asi dost nízké požadavky na multiplatformní aplikaci.
Ono je i otázka, co to tedy přesně je. Například bych čekal, že pokud mám JavaAplet z roku 2001, který mi běžel i v prohlížeči, tak dneska ho spustím i na Androidu. To je přece taky Java, není? Třeba. A přitom už tenkrát to nebeželo v Nokii, kde taky byla Java... Taky nevím, co budou dělat se Swingem v tabletu... zvlášť když v něm bude třeba iOS.

Java applety boli slepou vývinovou vetvou. Nikdy sa nepresadili, tak ako sa nepresadil ani Silverlight. Flash nakoniec tiež šiel do kytek. Java nikdy nebola o appletoch. Java sú predovšetkých webové aplikácie, enterprise applikácie,
rôzne priemyselné zariadenia.

Čo by mal robiť Swing na tabletoch? Však tam má Java natívne API. Swing je určený pre biznis aplikácie na desktopoch.

[Reklama]

[MarSik]

Například bych čekal, že pokud mám JavaAplet z roku 2001, který mi běžel i v prohlížeči, tak dneska ho spustím i na Androidu. To je přece taky Java, není?

Není. Je to skoro Java, ale neodpovídá žádnému Java profilu. Taky ten způsob distribuce je jiný (DEX).

A přitom už tenkrát to nebeželo v Nokii, kde taky byla Java...

Java má několik profilů - třeba J2ME, J2SE, J2EE. V té Nokii byla určitě jen J2ME a ten applet byl pro J2SE. Každý ten profil garantuje určitá API.

Taky nevím, co budou dělat se Swingem v tabletu... zvlášť když v něm bude třeba iOS.

No co by. Pokud existuje JRE pro iOS, tak to tam normálně poběží. Jenže ono není.. a WPF taky ne, pro rýpaly.

[anonym]

Napadla mě taková věc, kterou si neumím představit jak bych to dělal v .NETu.

Konkrétní situace. Pracuju na projektu, kde moje aplikace používá knihovny z jiných projektů kolem mě. Tzn. mám v aplikaci dependency v Mavenu na nějaká JARka sousedních projektů. A jak známo, v SW jsou bugy. V Javě si můžu kdy chci rozkliknout nějakou meotdu volanou z cizího JARka a podívat se, jak funguje a navíc můžu k tomu mít i plný servis, tzn. to jarko bude obsahovat i zdrojové kódy. Tzn. já mám vlastně díky tomuto systému JARek v Javě k dispozici kompletní zdrojové kódy ke všemu. Jestli ono tohle není jeden z velkých důvodů, proč se Java na velkých projektch používá.

[Radek Miček]

Tzn. já mám vlastně díky tomuto systému JARek v Javě k dispozici kompletní zdrojové kódy ke všemu. Jestli ono tohle není jeden z velkých důvodů, proč se Java na velkých projektch používá.

AFAIK, aby tohle fungovalo, musíte explicitně nastavit build a ne všechny projekty to mají. Jinak jde samozřejmě použít decompiler, což jde i v .NETu.

[jpu]

Napadla mě taková věc, kterou si neumím představit jak bych to dělal v .NETu.

Konkrétní situace. Pracuju na projektu, kde moje aplikace používá knihovny z jiných projektů kolem mě. Tzn. mám v aplikaci dependency v Mavenu na nějaká JARka sousedních projektů. A jak známo, v SW jsou bugy. V Javě si můžu kdy chci rozkliknout nějakou meotdu volanou z cizího JARka a podívat se, jak funguje a navíc můžu k tomu mít i plný servis, tzn. to jarko bude obsahovat i zdrojové kódy. Tzn. já mám vlastně díky tomuto systému JARek v Javě k dispozici kompletní zdrojové kódy ke všemu. Jestli ono tohle není jeden z velkých důvodů, proč se Java na velkých projektch používá.

ILDASM.exe a naspat ILASM.exe

[Reklama]

[FrantaPepa1]

Ve Swingu dělá i třeba Lokel který spadá pod Škodovku, nebo URC Systems co dělají pro armádu. Bohužel, zatím 2 firmy ze 2 u kterých jsem pracoval nebo o nich slyšel, že dělají ve Swingu, tak jsou to staré zaprášené dožívající firmy. Docela by mě zajímalo, jestli teď, nyní, by někdo začínal fungl nový projekt nebo firmu a postavil to na Swingu.  Dneska i armáda nebo industry používá tablety, tak co tam s tím Swingem budete dělat? To už mi příjde lepší použít ten Xamarin když už, a to je .NET. Mám prostě víc a víc dojem, že Java celkově je dožívající technologie.

Taky by mě to zajímalo, v JavaFX jsem viděl jen pár osobních projektů a několik aplikací, co zmiňuje tady http://dlsc.com/blog/ (doporučuju kouknout). Všechny ostatní známý aplikace jsou starý a používaj Swing.

Každopádně co .NET Core vs Java mimo desktop? Mě ASP.NET MVC/DotVVM přijde víc lightweight než nějakej Spring.

[Jano7]

Každopádně co .NET Core vs Java mimo desktop? Mě ASP.NET MVC/DotVVM přijde víc lightweight než nějakej Spring.

To si môže dovoliť zrejme iba firma, ktorá má na účtoch niekoľko desiatok miliárd dolárov.
Zahodiť všetko a spraviť zbrusu nový framework.

Čo je to „nějakej Spring”? Spring je najrozsiahlejší ekosystém na tvorbu enterprise aplikácií, aký existuje. Je to webový framework, aplikačný framewok, a integračný framework. Ak z nejakého dôvodu chcete mať Jersey, Vaadin, JSF namiesto Spring MVC, tak si to tam nakonfigurujete a používate to. Nepáči sa vám Tomcat? Zvolíte si Jetty alebo Undertow.
V Java máme okrem toho na výber ďalšie množstvo knižníc/frameworkov, JavaLite na lightweight programovanie, NinjaFramework, Play, Grails ako fullstack frameworky, Vaadin na programovanie bez nutnosti tvorby frontendu.
Ďalej si môžte poskladať projekt, podľa vlastnej ľubovôle; trebárs Tomcat, Java MVC 1.0, Freemarker, JDBI/MyBatis, PostgreSQL...

Mne sa páči PHP Laravel, ako je krásne všetko zladené v jednom balíku. Čo sa však týka flexibility, komplexnosti, dostupnosti nástrojov, tak sa Jave nič ani len nepribližuje.

[FrantaPepa1]

To si môže dovoliť zrejme iba firma, ktorá má na účtoch niekoľko desiatok miliárd dolárov.
Zahodiť všetko a spraviť zbrusu nový framework.

Já nic o vytváření novýho FW nepsal.

[anonym]

Nepáči sa vám Tomcat? Zvolíte si Jetty alebo Undertow

Co to je za logiku toto, nelíbí se mi Tomcat, tak můžu použít jetty nebo Undertow. Proč by se ti neměl líbit Tomcat? Tahle mentalita mě fakt strašně štve, protože kvůli toho jsou v Javě dva zadky frameworků typu "blbý a blbější".

Co se Springu a J EE týče, tak tam bych zmínil nevýhodu ústavičného redeploymentu. ASP.NET to má zmáknuté, stejně tak Play, nebo ty frameworky v Pythonu. Navíc 8 z 10 korporátních Java programátorů ani neví, co je to Hot Swap a neumí ho používat. Mě osobně by to nevadilo, já to vím, o to rychleji bych měl hotové své úkoly, ale setkal jsem se s projektem, který měl strašně zabordelované dependency a Idea prostě nebyla schopná dělat Make ani Hot Swap. Nikdo z programátorů se o to nezajímal a neudržoval správnou funkci, protože všichni psali maven clean install. (Ještě je rovněž možné, že to byl bug v Idei)

[anonym]

Teda redeployment máš, pokud koupíš JRebel. Pár lidí psalo, že ho nepotřebuje, ale podle mě je to blbost, JRebel je důležitý. Redeploy s ním je za 1 vteřinu, to tě nevyhodí z programátorského tranzu, do kterého se budeš dostávat dalších 15 minut. 20 sekund redeployment už je moc.

[Filip Jirsák]

Co to je za logiku toto, nelíbí se mi Tomcat, tak můžu použít jetty nebo Undertow. Proč by se ti neměl líbit Tomcat? Tahle mentalita mě fakt strašně štve, protože kvůli toho jsou v Javě dva zadky frameworků typu "blbý a blbější".

Tomcat se vám třeba nemusí líbit proto, že neposkytuje nějakou funkci, kterou jiný server poskytuje. To, že máte na výběr z různých variant, je výhoda, můžete si vybrat to, co vám vyhovuje nejlépe.

[asdfasdf]

Teda redeployment máš, pokud koupíš JRebel. Pár lidí psalo, že ho nepotřebuje, ale podle mě je to blbost, JRebel je důležitý. Redeploy s ním je za 1 vteřinu, to tě nevyhodí z programátorského tranzu, do kterého se budeš dostávat dalších 15 minut. 20 sekund redeployment už je moc.

Jsou pokusy aby to šlo i bez JRebel. Jak dříve zmíněno Spring má dev-tools, který toto řeší. Kromě toho je i projekt http://hotswapagent.org/. Sám jsem jej na některých projektech používal. Fungoval dobře a JRebel nebylo potřeba.

Co to je za logiku toto, nelíbí se mi Tomcat, tak můžu použít jetty nebo Undertow. Proč by se ti neměl líbit Tomcat? Tahle mentalita mě fakt strašně štve, protože kvůli toho jsou v Javě dva zadky frameworků typu "blbý a blbější".

Je pravda, že v Javě je spousta FW a knihoven/produktů, které se funkcionalitou překrývají. Ale dost často každá knihovna/fw mají něco jiného než ten druhý a člověk si může vybrat přesně ten který potřebuje (ať už funkcionalitou tak třeba i licencí, dostupností dokumentace, velikostí komunity, ...).

Je pravda, že některé knihovny/fw se postupně vývojem utrhli z řetězu. Asi nejvíce je to vidět právě na Springu. Starší verze byla poměrně jednoduchá knihovna, která usnadnila životní cyklus komponent v JEE aplikacích (která v té době byl ve standardu totální pain in the ass a JEE to vlastně pak od Springu tak trochu opsalo, ale zase dost debilním způsobem (ano mluvím o CDI)). Poslední verze Springu mi přijdou jak z jiného světa, kdy jednoduchý úkol, dříve řešen pár XML a anotacemi mi přijde zbytečně tahaný do black magic anotací typu @EnableJpaRepository. Bohužel tutorialy a dokumentace ke nejnovějšímu Springu je pro mě na hodně špatné úrovni, jsou to vlastně návody kam napsat jakou anotaci, která provede tu magii. Starší dokumentace Springu nebyly jenom o tom FW, ale i o tom proč se to tak děla a člověk dostal i dobrou nalejvárnu o principech jak navrhovat aplikaci. Jsem strašně rád, že jsem s Javou začínal právě v době, kdy se začal objevovat a hodně propagovat Spring.

[anonym]

dev-tools umí udělat jen to, že se spring znovu nastartuje, nemusíš dělat kompletní redeploy celého Springu na tomcat. Ale o moc rychlejší to teda rozhodně není. Hot Swap Agent je dost nedodělaný, funguje jen na nějakých knihovnách, jen někdy, a ještě se musí tak složitě konfigurovat, že bych se na něj úplně vyprd. To žádná náhrada za JRebel opravdu není. Spring Boot ačkoliv je to magic, tak je to první Spring, který má předkonfigurované závislosti nějakým standardním způsobem. Díky tomu je zde konečně potenciál pro redeploy, protože jakmile máš standardní způsob definování třeba MyBatis beany, tak máš i cestu, jak automatizovaně přenačíst editovaná XMLka s sql dotazy.

[Jano7]

Já nic o vytváření novýho FW nepsal.

Asi som sa zle vyjadril. Zahadiť dlhodobú prácu na svojom frameworku a vytvoriť zbrusu
nový; to si hádam môže dovoliť len Microsoft. Keby niečo také spravil Pivotal, ktorý vyvíja
Spring, asi by ich to položilo.



ASP.NET Core by sa mal volať úplne ináč; je to z 2/3 úplne iný framework.

Co se Springu a J EE týče, tak tam bych zmínil nevýhodu ústavičného redeploymentu.

Časť z toho rieši IDE, časť Spring dev-tools a potom spring-loaded.

Poslední verze Springu mi přijdou jak z jiného světa, kdy jednoduchý úkol, dříve řešen pár XML a anotacemi mi přijde zbytečně tahaný do black magic anotací typu @EnableJpaRepository. Bohužel tutorialy a dokumentace ke nejnovějšímu Springu je pro mě na hodně špatné úrovni, jsou to vlastně návody kam napsat jakou anotaci, která provede tu magii.

Spring black magic výrazne zjednodušuje prácu programátora. Ale je treba veľa naštudovať. Spring je
ako Boeing 747, nato aby sme ho riadili, potrebujeme kvantum znalostí. Tie tutoriály k Spring Boot obyčajne
nechcú opakovať, čo už bolo v staršej dokumentácii spomínané.

[anonym]

Co se Springu a J EE týče, tak tam bych zmínil nevýhodu ústavičného redeploymentu.

Časť z toho rieši IDE, časť Spring dev-tools a potom spring-loaded.

Tohle diskutuju už poněkolikáté a toto co jsi napsal je argument, který mě pokaždé vytočí. Takže znovu. dev-tools ti redeplou skoro nezrychlí, odpadne s tím jen načítání celého springu, ale všechny beany atd. se musí načíst znovu. Spring-loaded je postavený na Hot Swap Agentovi. Je to polofunkční věc. A IDE s tím už nemá společného nic. Jde vidět, že nmáš vůbec tušení, co to pravý update deploye je. Nainstaluj si JRebel, uprav si třeba XMLko od MyBatis a uvidíš, co to znamená. Rozjetou aplikaci máš aktualizovanou v průběhu 1 vteřiny. ASP.NET tohle normálně umí.

Zkráceně řečeno. Pokud nemáš ve Springu komplet update deploynuté aplikace za 1 vteřinu, tak žádný auto redeloy či jak to nazvat nemáš. Tečka.