Seriozní porovnání .NETu a Javy

anonym

Seriozní porovnání .NETu a Javy
« kdy: 27. 01. 2018, 20:01:21 »
Dělal jsem poslední 2 roky profesně v Javě a předtím na VŠ v :NETu. Teď uvažuju přejít na .NET a dělám takový zkušební projekt. Napíšu tady nějaká porovnání těchto 2 platforem a snad se do této diskuze někdo další přidá a napíše své postřehy.

1. C# a Java. C#má značně bohatší syntax, ale trošku za Javou pokulhává ve filozofii výstupních artefaktů. V Javě je to vždy JAR soubor a je jedno, jestli je to knihovna nebo spustitelný JAR. Z toho plyne snadnost získání knihovny do Java aplikace: prostě získám JAR. U .NETu je to složitější, protože musím zkompilovat DLL knihovnu.

2. Každý JAR soubor může oproti DLL knihovně obsahovat i zdrojové souboury. Zkrátka v něm může být zabalený celý projekt se vším všudy. Navíc, ikdyž zdrojové soubory neobsahuje, každé IDE mi bytecode umí převést do Tříd a já si tak můžu AdHoc v IDEčku proklikávat zdrojový kód libovolné třídy z načteného JARka. Navíc i zkompilovaný kód si v Javě drží původní adresářovou strukturu a názvy souborů.

3. Příje mi, že C# je místy překomplikovaný. Např. můžu do 1 souboru dát více než 1 třídu a název souboru s touto třídou ani nemusí korespodnovat. Příjde mi to trochu nešťastné, protože se musím manuálně starat o to, aby to bylo dodrženo. S tím souvisí i Namespacy, které vůbec nemusí dodržovat adresářovou strukturu v projektu. Systém balíčků v Javě a pravidlo, že jméno Package s tečkovou notací musí dodržovat umístění v adresáři a název souboru musí korespondovat s názvem třídy mi přijde lepší.

4. Zkoušel jsem i .NET Core a Java jednoznačně válí s Mavenem. .NET má několik jakýchsi konfiguračních souborů projektu, Javě stačí jen pom.xml a v něm nastavím nejen závislosti na další JARka, ale taky můžu řešit build management.

5. Je to zvláštní, ale v .NET znatelně déle trvá, než se spustí nějaký jednoduchý Unit Test. Než se ten projekt zkompiluje, tak to prostě zabere čas. Příjde mi, že v Javě se Unit test spustí prostě adhoc, na nic se nečeká. Je to důležité, protože když nějakou třidu upravuju, chci si neustále pouštět průběžně unit testy a chci, ať se pustí prostě ihned. Jestli ono to není tím, že v .NETu se musí sestavit EXE soubor i při editaci jediné třídy, zatímco v Javě se vždy uplatní inkrementální build.

6. Celková uzvřenost kódu v .NET platformě. Nejen, že .NET knihovna je closed source a vy si nemůžete projít zdrojový kód a prostě upravit standardní knihovnu zděděním nějaké třídy, ale vy si nemůžete ani takto procházet naimportované DLL knihovny, protože i v nich budou chybět těla metod. V Javě si můžu jakoukoliv třídu z jakéhokoliv zdroje rozkliknout a podívat se, jak je naimplementovaná. Dost mi to teď chybělo v .NETu u XMLSerialize, který jsem potřeboval upravit pro línou deserializaci XML souboru - no way.



Tomas2

  • ****
  • 310
    • Zobrazit profil
    • E-mail
Re:Seriozní porovnání .NETu a Javy
« Odpověď #1 kdy: 27. 01. 2018, 20:40:13 »
seriózní porovnání můžeš udělat tak po deseti letech v obou jazycích. .NET vyčítáš hlavně to, že je pro tebe složitá a že tě nevede za ručičku.

Jinak pěkné porovnání, donutilo mě se nad tím zamyslet a uvědomit si, že snad ani jeden bod pro mě není důležitý. Soubory a třídy mám raději pod kontrolou sám a volím podle projektu, maven je ostřesný, sbt nad ním vyhrává, ne všechny jarka lze přečíst, nemám potřebu po každé změně spouštět testy, raději si hodin nerušeně programuji a až pak jdu testovat, nemám rád, když mě IDE s čímkoliv rozpyluje, kecá mi do života, bere mi pozornost a snaží se napovídat, to nechci.

Za mě je třeba propastný rozdíl ve správě paměti, .NET s CLR a LOH, který lépe uvolňuje dealokaci zpátky do OS naproti tomu tvrdohlavé JVM GC.

Kit

Re:Seriozní porovnání .NETu a Javy
« Odpověď #2 kdy: 27. 01. 2018, 20:51:34 »
Evidentně ti Java vyhovuje víc a nedivím se ti.

1. Bohatost syntaxe je dle mého názoru spíše na škodu. Dokonalosti je dosaženo tehdy, když se nedá nic ubrat.
2. JAR je na rozdíl od DLL poměrně obecný soubor, vnitřně ne nepodobný ZIPu. Dá se do něj zabalit cokoli. Opět jednoduchost. Jednotlivé třídy jsou v něm uloženy ve formě souborů .class, na kterých se dá udělat potřebná reflexe.
3. Povinná shoda názvu veřejné třídy s názvem souborů je opět ve znamení jednoduchosti. Podle názvu třídy bezpečně poznám, ve kterém souboru ji mám hledat.
4. Maven je vlastně uživatelským zjednodušením Antu, který má podobnou filozofii jako Make. Otevřený formát opět přispívá k jednoduchosti.
5. V Javě se dají snadno kompilovat a spouštět jednotlivé třídy, proto ta rychlost. S tím souvisí i rychlost jednotkových testů pro tu třídu.
6. V .NET máš ještě možnost si tu třídu obalit adaptérem. V Javě to můžeš udělat úplně stejně, ale navíc máš ještě možnost využít dědičnost, pokud ta třída není finální. Je otázkou, co je v daném případě lepší. Obvykle volím spíš kompozici, abych zeštíhlel rozhraní. Adaptér mi pak lépe pasuje k mému kódu a při záměně XML např. za INI jen vyměním adaptér.

Re:Seriozní porovnání .NETu a Javy
« Odpověď #3 kdy: 27. 01. 2018, 20:59:26 »
Ad 1) asi jsem nepochopil, co je myšleno nutností kompilovat DLL :)
Ad 3) rozumný vývojář dodržuje strukturu víceméně stejnou jako v Javě, jedna classa na soubor a adresářová struktura odpovídá namespace; ale je fakt, že ho k tomu vůbec nic nenutí
Ad 6) zdrojáky jsou už docela dlouho dostupné zde: https://referencesource.microsoft.com/

anonym

Re:Seriozní porovnání .NETu a Javy
« Odpověď #4 kdy: 27. 01. 2018, 21:02:17 »
seriózní porovnání můžeš udělat tak po deseti letech v obou jazycích. .NET vyčítáš hlavně to, že je pro tebe složitá a že tě nevede za ručičku.

Jinak pěkné porovnání, donutilo mě se nad tím zamyslet a uvědomit si, že snad ani jeden bod pro mě není důležitý. Soubory a třídy mám raději pod kontrolou sám a volím podle projektu, maven je ostřesný, sbt nad ním vyhrává, ne všechny jarka lze přečíst, nemám potřebu po každé změně spouštět testy, raději si hodin nerušeně programuji a až pak jdu testovat, nemám rád, když mě IDE s čímkoliv rozpyluje, kecá mi do života, bere mi pozornost a snaží se napovídat, to nechci.

Za mě je třeba propastný rozdíl ve správě paměti, .NET s CLR a LOH, který lépe uvolňuje dealokaci zpátky do OS naproti tomu tvrdohlavé JVM GC.

1. V čem ti příjde otřesný Maven? pom.xml je vhodný k ruční editaci bez asistence IDE. V .NETu vidím tyto soubory:

packages.config
Datafeeds.csproj
project.assets.json - tohle je v Obj od Nugetu, nevím přesně o co jde

Když si je otevřu, jsou tak rozsáhlé, že v podstatě manuální správu projektu znemožňují, tlačí tě tím do IDE. Nic proti IDE, stejně v něm děláš pořád, ale přecijen možnost ruční editaci v přehledných konfiguračních souborech není úplně od věci.

2. Maven ti umožní do pom.xml dát různé pluginy, např. nahrání JARka do Maven repozitáře a plugin pro kontrolu kódu, třeba zda-li je dostatečné pokrytí testy. Obojí je důležité pro Continuous integration. Jak by jsi to udělal v .NET?

3. Java rozhodně za ručičku nevede, to mi přijde jako docela hloupý argument, je to spíše naopak.

4. Říkáš že hodinu programuješ a pak jdeš testovat, ale co když budeš chtít dělat Test driven development? Já si např. potřeboval otestovat, že správně používám knihovnu pro parsování argumentů z konzole. Namísto abych zas a znovu pouštěl aplikaci, prostě jsem si pouštěl unit test.



Re:Seriozní porovnání .NETu a Javy
« Odpověď #5 kdy: 27. 01. 2018, 21:09:23 »
2. JAR je na rozdíl od DLL poměrně obecný soubor, vnitřně ne nepodobný ZIPu.
JAR je ZIP.

4. Maven je vlastně uživatelským zjednodušením Antu, který má podobnou filozofii jako Make. Otevřený formát opět přispívá k jednoduchosti.
Ant je skript popisující způsob buildu, je to stejný princip, jako Make. Maven přišel s úplně jiným principem – popíše se struktura projektu, a Maven už bude vědět, jak takovou strukturu sestavit. Nápad to byl perfektní, pak by se stejným popisem projektu mohlo pracovat třeba IDE. Bohužel se toho sám Maven pak nedržel, takže místo popisu, jak projekt vypadá, se pak stejně popisovalo, jak se má sestavovat – poměrně nepohodlně konfigurací pluginů v XML. Dneska se prosazuje Gradle, který se vrátil znovu k tomu, že build je popsaný skriptem – ale spoustu běžných věcí tam stačí jen nakonfigurovat.

harrison314

Re:Seriozní porovnání .NETu a Javy
« Odpověď #6 kdy: 27. 01. 2018, 21:12:03 »
1, Do dll vies napchat aj ine subory ako resourses, na pribalene zdrojaky mas zas pdb-cka, plus .Net Core ma vsteko ako dll-ka.

2, Na to su PDB-cka, ktore byvaju sucatov Nuget balickov, alebo si len vo Visualku nastvis PDB server a vysledok je rovnaky.

3, Je to vec zvyku,prave toto ma na Jave neuveritelne stvalo. No v C# je to tiez zvyk dodrzovat, no nemusi s tym byt obmedzeny, hlavne ak mas 5 tried z rovankym nazvom ale inymi generickymi parametrami.

4, .Net core ma zas vstekov subore *.csproj (v stabilnom toolingu, ty si mal asi preview). Plus balicky su Nugety, tie zvladnu  toho ovela viac ako ant, nemusia byt v nich iba dll-ka, ale vsteko co ta len npadne.

5, Tiez sa to uz zmenilo, Visual Studio umoznuje live unit testing, osobne ale aj tak radcej dlhsie kodim a az potom pustim testy.

6, Nie je to pravda, kompletne zdrojaky .Net frameworku su volne dostupne, ku standardnym knizniciam mas PDB-cka zo zdrojakmi, .Net Core je uplne open sourse na githube. Ak mas nasinstalovany DotPeek, tiez sa vies hocikedy pozriet na zdrojaky kniznic (vdaka PDB serveru, alebo dekompilacii) jednym klikom.

Kit

Re:Seriozní porovnání .NETu a Javy
« Odpověď #7 kdy: 27. 01. 2018, 22:39:51 »
4. Říkáš že hodinu programuješ a pak jdeš testovat, ale co když budeš chtít dělat Test driven development? Já si např. potřeboval otestovat, že správně používám knihovnu pro parsování argumentů z konzole. Namísto abych zas a znovu pouštěl aplikaci, prostě jsem si pouštěl unit test.

Někdy spouším testy jednotky i 3× za minutu. Nelíbilo by se mi, kdyby to nějaký kompilátor s linkerem zdržovaly.

anonym

Re:Seriozní porovnání .NETu a Javy
« Odpověď #8 kdy: 27. 01. 2018, 23:26:42 »
Ale asi prěcijen víc věcí mi hraje pro .NET:

1. yield return to je prostě lahoda, dá se s tím krásně streamovat bez zaneřádění tříd implementací iterátoru
2. eventy - sice je nahradí snadno handlery, ale i tak je kód hezčí
3. LINQ
4. Nemusím pořád testovat na null, můžu použít ?
5. Nemusím umět X různých backendových a frontendových frameworků, stačí mi komponentový Asp.net a .net mvc Restový, k tomu WCF, kde mám pod jednou střechou security, soap, rest a dalšiˇ věci. V Javě je to katastrofa kolik tam toho je.
6. S ASP.NET a visualkem můžu i já, který se moc neorientuju ve frontendu, udělat z templatu pěkný frontend. V Javě jsem odsouzený k tomu používat Bootstrap a podobné věci.
7. Ke všem asp.net frameworkům je pořádná dokumentace, ne jako u Springu v Javě.
8. Můžu dělat pořádné desktop aplikace. V Javě měl Swing problémy s performance, nevím jak je na tom Java FX.
9. Nutit zákazníka mít nainstalované JRE, které ho bude pořád otravovat s updaty, to je sebevražda.
9b. Možnost dobrého propojení s MS office. Ono je kolikrát lepší na řadu věcí použít excel a případně nějaký kód k tomu. Dělal jsem několik let s OpenOfficem a to je oproti MS Office bohužel velká bolest.


Na druhou stranu:

10. .NET Core je tu jen díky tomu, že je tu Java. Jinak by to MS sám od sebe nikdy jako open source nevydal.
11. Pokud neuvolní MS WCF i pro Mono, tak je to stejně prakticky vendor lock na Windows.
12. Ty Live unit testy ve VS 2017, které umí pustit unit testy ihned, delaji vendor lock na Visual Studio a tudíž i na Windows.
13. Docela by mě zajímalo, jaké jsou možnosti realtime deploje při vývoji web aplikací v jiném IDE, než je VS. To že se to deploynutá appka umí updatovat za běhu je funkce visual studia. Tady je opět potencionálni vendor lock na Win a visualko. Nicméně v Javě stejně nikdo 10000,- ročně za JRebel, který umí to samé, nedá.

Ale celkově prostě mi ten .NET příjde podstatně dál. Já vlastně už nevím žádný pořádný důvod, proč dělat v Javě.

Kit

Re:Seriozní porovnání .NETu a Javy
« Odpověď #9 kdy: 28. 01. 2018, 01:05:55 »
- Program by se měl psát tak, aby se v něm nedělaly testy na null. Otazník jako syntaktický cukr je tedy zbytečný.
- Je vcelku jedno, jestli zákazník musí mít nainstalované JRE nebo .NET. Na linuxovém serveru je JRE výhodou.
- Propojení s Office je záležitostí Windows desktopu. Pokud píšeš jen pro tuto skupinu, je jistě výhodnější .NET.
- Ten vendor lock mi připadá jako dost zásadní problém.

heretik

Re:Seriozní porovnání .NETu a Javy
« Odpověď #10 kdy: 28. 01. 2018, 01:27:55 »
Ja by som tvoj post skratil na 4 slova:

.NET - sloboda
Java - fašizmus

Re:Seriozní porovnání .NETu a Javy
« Odpověď #11 kdy: 28. 01. 2018, 03:55:29 »
- Program by se měl psát tak, aby se v něm nedělaly testy na null. Otazník jako syntaktický cukr je tedy zbytečný.

Šlo by to nějak vysvětlit? Respektive asi nerozumím, co si představit pod testy na null... Takovému

Kód: [Vybrat]
if (ptr == NULL)
se člověk asi těžko vyhne, takže předpokládám, že jde o něco jiného...? (.NET neznám)

harrison314

Re:Seriozní porovnání .NETu a Javy
« Odpověď #12 kdy: 28. 01. 2018, 08:46:08 »
- Program by se měl psát tak, aby se v něm nedělaly testy na null. Otazník jako syntaktický cukr je tedy zbytečný.
- Je vcelku jedno, jestli zákazník musí mít nainstalované JRE nebo .NET. Na linuxovém serveru je JRE výhodou.
- Propojení s Office je záležitostí Windows desktopu. Pokud píšeš jen pro tuto skupinu, je jistě výhodnější .NET.
- Ten vendor lock mi připadá jako dost zásadní problém.
Prvy bod, to je tvoj klasicky folklor, stale si neukazal tvoje kody, kde to testovat nemusis... IMHO. C# 8 prinensie not-null typy.
- preco by malo byt nainstalovane JRE  vyhodou? A .Net Core aplikacie mozu byt self contained. Takze, .Net nainstalovany mat nemusis.
- ..
- vendor lock, ono slusne editory pre Javu ako Jrebel a IdeaJ su platene, Eclipse je naozaj tragedia, bol som par mesiacov v nom nuteny robit profesionalne. Imho nemas vendor lock jestvuje Visual Studio for Mac, mas multiplatformove Visual Studio Code, aj ked to je viac pre fronedakov ale zo spravnymi pluginmi je to viac ako Eclipse (porovnaval som to na PHP, tam som vyvjal a ubuntu), mas multiplatfromovy Rider od JetBarinsu.
.Net Core tooling mas mimo visual studia, a ma jednoduche cli rozhranie, nie je problem ho vyvjat ani vo vime.
tam vendor lock nie je, len by si si o tom musel nieco zistit.

anonym

Re:Seriozní porovnání .NETu a Javy
« Odpověď #13 kdy: 28. 01. 2018, 09:14:29 »
- Program by se měl psát tak, aby se v něm nedělaly testy na null. Otazník jako syntaktický cukr je tedy zbytečný.

To ale prakticky nejde, uz jen treba Rest metoda, do ktere ti framework rozparsuje http parametry. Musis testovat na null. Stejne tak ORM mapovani, nebo Modelyy neceho, taktez by mely mit moznost mit null a ty to pak budes testovat. Jak by jsi napr. u tridy AutaXMLModel resil, ze proste Auto nemelo zadany treba VIN? Jak to chces udelat jinak nez pres null?

Takze rekneme, ze ti prijde do rest metody

Kód: [Vybrat]
JAVA

getDistance(Firma z) {
  int psc;
  if( z != null && z.getDodaciUdaje() && z.getDodaciUdaje().getAdresa() != null) {
    psc = z.getAdresa().getDodaciUdaje().getPSC();
  }
}

C#

zpracujZakazky(Firma z) {
  int psc = z?.Adresa?.DodaciUdaje?.PSC;
}


V Javě když děláš 3 vrstvou architekturu tak máš celý kód zaneřáděný přinejmenším null checky, gettery a settery.

anonym

Re:Seriozní porovnání .NETu a Javy
« Odpověď #14 kdy: 28. 01. 2018, 09:25:59 »
Oprava

Kód: [Vybrat]
JAVA

getDistance(Firma z) {
  Integer psc;
  if( z != null && z.getDodaciUdaje() != null && z.getDodaciUdaje().getAdresa() != null) {
    psc = z.getDodaciUdaje().getAdresa().getPSC();
  }

  ...
}

C#

getDistance(Firma z) {
  int? psc = z?.DodaciUdaje?.Adresa?.PSC;

  ...
}