Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: anonym 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.
-
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.
-
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.
-
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/
-
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.
-
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.
-
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.
-
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.
-
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ě.
-
- 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.
-
Ja by som tvoj post skratil na 4 slova:
.NET - sloboda
Java - fašizmus
-
- 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
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)
-
- 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.
-
- 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
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.
-
Oprava
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;
...
}
-
Zrovna dll beru jako výhodu, protože se to rychleji načte. Načtení pár desítek knihoven jar trvá jednotky sekund.
-
- 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
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.
Smalltalk:
Firma>>dodaciUdaje: anObject
dodaciUdaje := anObject asDodaciUdaje
DodaciUdaje>>adresa: anObject
adresa := anObject asAdresa
*UndefinedObject>>asDodaciUdaje
^ NullDodaciUdaje new
*UndefinedObject>>asAdresa
^ NullAdresa new
| firma psc |
firma := Firma new.
psc := firma dodaciUdaje adresa psc.
Nekontroluji null ani jednou. Obdobne pro firmu, kdyby byla null.
-
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.
Vsak sam si si odpovedal, v podstate. Ale porovnanie zo skolskych projektov je ale neodborne
-
- 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
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.
Smalltalk:
Firma>>dodaciUdaje: anObject
dodaciUdaje := anObject asDodaciUdaje
DodaciUdaje>>adresa: anObject
adresa := anObject asAdresa
*UndefinedObject>>asDodaciUdaje
^ NullDodaciUdaje new
*UndefinedObject>>asAdresa
^ NullAdresa new
| firma psc |
firma := Firma new.
psc := firma dodaciUdaje adresa psc.
Nekontroluji null ani jednou. Obdobne pro firmu, kdyby byla null.
Kde se dělá ve Smalltalku?! 8)
-
Na roote 😀
-
- 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ý.
V Javě když děláš 3 vrstvou architekturu tak máš celý kód zaneřáděný přinejmenším null checky, gettery a settery.
Zvláštní, null checky, gettery ani settery nemám v PHP ani v Javě. Kdo umí OOP, tak tohle smetí nepotřebuje.
-
- 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ý.
V Javě když děláš 3 vrstvou architekturu tak máš celý kód zaneřáděný přinejmenším null checky, gettery a settery.
Zvláštní, null checky, gettery ani settery nemám v PHP ani v Javě. Kdo umí OOP, tak tohle smetí nepotřebuje.
Tak mi vysvětli, jak bys řešil tu věc s objektem, co ti přijde z RESTu. To by mě fakt zajímalo, jak se vyhneš zběsilým null checkům.
-
Zvláštní, null checky, gettery ani settery nemám v PHP ani v Javě. Kdo umí OOP, tak tohle smetí nepotřebuje.
Tak mi vysvětli, jak bys řešil tu věc s objektem, co ti přijde z RESTu. To by mě fakt zajímalo, jak se vyhneš zběsilým null checkům.
Z RESTu mi do objektu přijde kolekce atributů. Pouze si zjistím, zda požadovaný atribut existuje a zda splňuje vstupní podmínky. Na null ho však testovat nepotřebuji, protože kdyby byl null, vůbec v té kolekci nebude.
-
Jedna laická otázka.
Čo je také zlé na testovaní null hodnoty?
-
Jedna laická otázka.
Čo je také zlé na testovaní null hodnoty?
Špatné ani ne, spíš je to zpravidla zbytečné a zdržuje to.
-
Niekto tu zaspal dobu, na null checky je jave map a flatMap skrz Optional
-
K čemu testovat null, když máme výjimky.
-
V jave ma zmysel vyhybat sa explicitnym null-kontrolam kvoli rychlosti. Vynimka hodena mimo metodu je radovo narocnejsia. Ak je to nutne, mame tu pattern monade. Otazka teraz je: o kolko je v c# syntax s '?' pomalsia pri ne-nullovych hodnotach?
-
K čemu testovat null, když máme výjimky.
ty musis byt "vynimocny" programator. vyhodenie vynimky je ovela narocnejsie ako porovnanie na null.
-
K čemu testovat null, když máme výjimky.
ty musis byt "vynimocny" programator. vyhodenie vynimky je ovela narocnejsie ako porovnanie na null.
Když je v aplikaci běhová chyba, vyhození výjimky je na místě. Obcházení výjimek je mnohem náročnější.
-
takze ked budem volat nejaky webservis, ktory mi ako objekt vrati null, alebo budem robit priamo dotaz do DB, ktory vrati null, tak necham vyhodit radsej vynimku, ked pristupim na ten objekt, radsej ako okontrolovat ci nie je null.
Ty si fakt borec. Ale ja som zabudol, ty si ten Kit, co robi sam, vsetko robi OOP, ale este sa nicim neprezentoval.
-
Proč by měl webservis vracet null? Co je to za nesmysl?
-
Kde se dělá ve Smalltalku?! 8)
V ČSOB? https://pharo.org/success/PharoAtCSOB
-
a preco by nemohol? WCF moze kludne vratit null objekt. Pokial pouzivas nejaky 3rd party webservis, tak asi s tym nic nenarobis.
-
V tom případě je takový 3rd party webservis chybný a neměl by se vůbec používat.
-
ci je to chybne alebo nie, je nepodstatne. podstatne je, ze nechat vyhucat program hodenim vynimky na null objekte, je zly pristup. Nemozem sa predsa spoliehat, ze dostanem ne-nullovy objekt, pokial to nie je uvedene napr. v dokumentacii.
-
Jak z toho null chceš rozpoznat příčinu chyby?
-
@Kit - Zeptám se znovu a jinak. Platí tento tvůj přístup i pro C/C++?
-
@Kit - Zeptám se znovu a jinak. Platí tento tvůj přístup i pro C/C++?
Ne. To jsou jazyky, které jsou zcela odlišné od Javy, C# i PHP.
-
Kit ma pravdu v tom, že např. je zbytečné psát:
zakaznik?.DodaciUdaje?.Adresa?.PSC();
Je správné, že prostě nechá vyhodit vyjímku. Prostě neexistuje, aby něco z toho bylo null, snad kromě toho PSČ. Jenže problém nastane v situaci, když děláš v žumpě, např. někde v korporátu. Tam se prostě prasí a kdybys kokotům řekl, že tvoje aplikace správně vyhodila NULL exception, protože to, co ti vrátila jejich Service, je nekonzistentní stav, tak ti vyčtou, že máš checkovat na null a psát robustně. Obzvláště, když jsou to pitomci ze zemí 3. světa. Oni prostě udělají debilní Service a ty než bys jim psal chain emailů, že ti kurva mají vracet v XMLku prázdný List a ne null, tak tak raději dáš check na null. A to ti zaprasí kód.
-
protože to, co ti vrátila jejich Service, je nekonzistentní stav, tak ti vyčtou, že máš checkovat na null a psát robustně
iny priklad. nedavno som riesil vyhladavanie certifikatov na windows stroji. C# ponuka funkciu X509Certificate2.Find a ked nenajde dany certifikat, tak vrati null. Urobim kontrolu na null, alebo vyhodim exception? Je to zle spravena funkcia, lebo vrati null? Logicky mi vyznieva, ze ked nic nenajde, vrati spravne null, a vyvojar si okontroluje co mu bolo vratene. Nekontrola na null iba poukazuje na amaterizmus, nehovoriac o tom, ze to nechat zajst az do vynimky.
-
protože to, co ti vrátila jejich Service, je nekonzistentní stav, tak ti vyčtou, že máš checkovat na null a psát robustně
iny priklad. nedavno som riesil vyhladavanie certifikatov na windows stroji. C# ponuka funkciu X509Certificate2.Find a ked nenajde dany certifikat, tak vrati null. Urobim kontrolu na null, alebo vyhodim exception? Je to zle spravena funkcia, lebo vrati null? Logicky mi vyznieva, ze ked nic nenajde, vrati spravne null, a vyvojar si okontroluje co mu bolo vratene. Nekontrola na null iba poukazuje na amaterizmus, nehovoriac o tom, ze to nechat zajst az do vynimky.
Je to chybně napsaná funkce, protože se z toho null nedozvíš informaci, proč nebyl certifikát nalezen. Polykání výjimek prostě rád nemám.
-
protože se z toho null nedozvíš informaci, proč nebyl certifikát nalezen.
Dozviem sa to, ze mnou ziadany certifikat neexistuje podla zadanych parametrov.
Je to chybně napsaná funkce
to urcite. Vies kolko je takych funkcii vo frameworku, ci v .NET alebo v nejakom javovskom?
uz by si sa mohol konecne mohol prezentovat svojou pracou, lebo ty zda sa pises ten najdokonalejsi kod na svete, samozrejme vsetko je OOP. :)
-
Co se týče práci s nullem, tak pánové z JezBrians to myslím vyřešili poměrně uspokojivě.
https://kotlinlang.org/docs/reference/null-safety.html
-
Nejsem fanoušek Javy, ale ta má aspoň null jen jeden.
V .Netu nezapomeňte testovat kromě klasického null ještě na DBNull. Ale na to jste jistě zvyklí už z Javascriptu, kde máte null a ještě undefined...
Jestli se null v Kotlinu řeší tak, že se jeho používání nejdříve zakáže, a zavedou se pro práci s ním čtyři další operátory ?, !!, ?., ?:, tak mi to přijde naopak ještě horší...
V Céčku žádné null není, pouze 0, a maximálně NULL jako makro. V C++ také není, od verze C+11 je tam ale typ nullptr_t (http://en.cppreference.com/w/cpp/types/nullptr_t), který lze použít při přetížení (OOP) metod. Tam bych řekl, že se lze porovnávání vyhnout též.
-
V Céčku žádné null není, pouze 0, a maximálně NULL jako makro. V C++ také není, od verze C+11 je tam ale typ nullptr_t (http://en.cppreference.com/w/cpp/types/nullptr_t), který lze použít při přetížení (OOP) metod. Tam bych řekl, že se lze porovnávání vyhnout též.
V Céčku můžeš mít přece null pointer, což je to samé v Javě a .NETu, jako null, vzhledem k tomu, že v těchto jazycích vše, kromě primitivních typů, pracuje přes reference.
-
V Céčku žádné null není, pouze 0, a maximálně NULL jako makro. V C++ také není, od verze C+11 je tam ale typ nullptr_t (http://en.cppreference.com/w/cpp/types/nullptr_t), který lze použít při přetížení (OOP) metod. Tam bych řekl, že se lze porovnávání vyhnout též.
V Céčku můžeš mít přece null pointer, což je to samé v Javě a .NETu, jako null, vzhledem k tomu, že v těchto jazycích vše, kromě primitivních typů, pracuje přes reference.
Jistě že můžu mít null pointer, ale není to definovaný typ v C, ale pouze adresa = 0. Tedy to je číslo. Zatímco v Javě i .Netu to je typ, a není to totéž jako 0. Každopádně to vynechání kontrol na null se týkalo OOP, což C není.
-
V Céčku žádné null není, pouze 0, a maximálně NULL jako makro. V C++ také není, od verze C+11 je tam ale typ nullptr_t (http://en.cppreference.com/w/cpp/types/nullptr_t), který lze použít při přetížení (OOP) metod. Tam bych řekl, že se lze porovnávání vyhnout též.
V Céčku můžeš mít přece null pointer, což je to samé v Javě a .NETu, jako null, vzhledem k tomu, že v těchto jazycích vše, kromě primitivních typů, pracuje přes reference.
Jistě že můžu mít null pointer, ale není to definovaný typ v C, ale pouze adresa = 0. Tedy to je číslo. Zatímco v Javě i .Netu to je typ, a není to totéž jako 0. Každopádně to vynechání kontrol na null se týkalo OOP, což C není.
Přesně. Zatímco v C není možné použít nic jiného, než adresa == 0, v OOP je to naopak nežádoucí. Bohužel zvyk je železnou košilí a programátoři zvyklí na C/C++ si to tahají s sebou do OOP.
Příklady uvedené výše zakaznik?.DodaciUdaje?.Adresa?.PSC(); či zakaznik.DodaciUdaje.Adresa.PSC(); tak či onak odporují zásadám OOP. Porušují totiž Démeteřin zákon.
-
oosobne na porovnani ci je objekt null, alebo nie, nevidim nic zleho. Implementuju to tak aj ini, firmy, ktorych frameworky sa bezne pouzivaju. Urcite lepsie, ako to nechat zajst az do hodeni exception. S Kitom musi byt sranda robit.
-
V Céčku žádné null není, pouze 0, a maximálně NULL jako makro. V C++ také není, od verze C+11 je tam ale typ nullptr_t (http://en.cppreference.com/w/cpp/types/nullptr_t), který lze použít při přetížení (OOP) metod. Tam bych řekl, že se lze porovnávání vyhnout též.
V Céčku můžeš mít přece null pointer, což je to samé v Javě a .NETu, jako null, vzhledem k tomu, že v těchto jazycích vše, kromě primitivních typů, pracuje přes reference.
Jistě že můžu mít null pointer, ale není to definovaný typ v C, ale pouze adresa = 0. Tedy to je číslo. Zatímco v Javě i .Netu to je typ, a není to totéž jako 0. Každopádně to vynechání kontrol na null se týkalo OOP, což C není.
Přesně. Zatímco v C není možné použít nic jiného, než adresa == 0, v OOP je to naopak nežádoucí. Bohužel zvyk je železnou košilí a programátoři zvyklí na C/C++ si to tahají s sebou do OOP.
Příklady uvedené výše zakaznik?.DodaciUdaje?.Adresa?.PSC(); či zakaznik.DodaciUdaje.Adresa.PSC(); tak či onak odporují zásadám OOP. Porušují totiž Démeteřin zákon.
programátoři v C++ mají na výběr mezi ukazateli a referencemi a možná často místo nějakých pouček používají rozum
-
oosobne na porovnani ci je objekt null, alebo nie, nevidim nic zleho. Implementuju to tak aj ini, firmy, ktorych frameworky sa bezne pouzivaju. Urcite lepsie, ako to nechat zajst az do hodeni exception. S Kitom musi byt sranda robit.
Pořád lepší pracovat s výjimkami, než je polykat nebo je měnit za nějaké podivné stavové kódy, jak někdy v poválečných dobách.
Když se podívám na práci s výjimkami v C#, tak se ani nedivím, že je vývojáři nemají rádi. Musí to být fakt opruz.
-
Místo porovnání platforem .NET Core a Java, frameworků atd. se tu opět řeší takový nesmysly.
-
3 zo 4 stran diskusie su doslova zatrolene kitom a tymi co sa nechali chytit, je to vzdy o tom istom.
-
3 zo 4 stran diskusie su doslova zatrolene kitom a tymi co sa nechali chytit, je to vzdy o tom istom.
Koho jsem podle tebe v diskuzi napadal? Pouze odpovídám na všetečné dotazy.
-
Trolení je nadmnožina napadání...
-
Pouze trpělivě vysvětluji, že syntaktický cukr, který má C#, ale Java ne, je zcela zbytečný. Že ho chtějí i programátoři i v Javě a nechávají si kvůli tomu generovat boilerplates, je už jejich problém. Java prostě dala přednost čistějšímu návrhu.
Je to dostatečně seriózní porovnání .NETu a Javy nebo se raději bavíte o mně?
-
Pouze trpělivě vysvětluji, že syntaktický cukr, který má C#, ale Java ne, je zcela zbytečný. Že ho chtějí i programátoři i v Javě a nechávají si kvůli tomu generovat boilerplates, je už jejich problém. Java prostě dala přednost čistějšímu návrhu.
Je to dostatečně seriózní porovnání .NETu a Javy nebo se raději bavíte o mně?
Já programování nerozumím. Nevím, co je .NET, nevím, co je počítač.
Ale nějak tomu nerozumím. Takže máme něco co se jmenuje null. Nevím, co to je, ale v ideálním světě bych to neměl dostávat, takže bych v ideálním světě nepotřeboval testovat, jestli jsem to dostal. A výjimečná situace, kdy to dostanu se řeší výjimečným způsobem.
Ale v reálném světě to dostávám. A často. Částečně proto, že část světa se kterou interaguji, je plná chyb a částečně proto, že jiní odborníci mají jinou představu o ideálním světě a tu věc zvanou null nezavrhují.
Takže je něco, co reálně existuje a způsobuje to komplikace. A ty tvrdíš, že nástroj, který práci s tou věcí usnadňuje je zbytečný. Dokonce zcela zbytečný.
Kluci z vedlejší programátorské vesnice to nemají a někteří to chtějí a protože to nemají, tak to různě obcházejí. Ale v ideálním světě to neexistuje, takže je to zbytečné.
Připadá mi to jako velmi rozporuplná argumentace. Ale to je určitě tím, že programování nerozumím. Kdybys psal, že je to nečisté, nebo proti programátorskému pánuoopbohu, tak bych to chápal. Ale že je to ZCELA zbytečné...
-
Připadá mi to jako velmi rozporuplná argumentace. Ale to je určitě tím, že programování nerozumím. Kdybys psal, že je to nečisté, nebo proti programátorskému pánuoopbohu, tak bych to chápal. Ale že je to ZCELA zbytečné...
Null je v C# i v Javě, o tom teď nebyla řeč.
(https://i.stack.imgur.com/MxLUy.jpg)
Řeč byla o syntaktickém cukru, kterého má Java méně než C#. Podle mne je to správně.
-
Já programování nerozumím. Nevím, co je .NET, nevím, co je počítač.
Ale nějak tomu nerozumím. Takže máme něco co se jmenuje null. Nevím, co to je, ale v ideálním světě bych to neměl dostávat, takže bych v ideálním světě nepotřeboval testovat, jestli jsem to dostal.
Přesně tak, proto je nejlepší používat jazyky, které null nemají - Scala (tam sice je, ale jen kvůli interop s Javou, jinak se nepoužívá), Rust, ...
https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/
-
Pokud to chcete čisté, použijte Optional. IMHO se moc netýká srovnání java vs. .NET.
Jinak už ta formulace dotazu je zavádějící - srovnávejte srovnatelné (jazyk s jazykem, runtime s runtimem, framework s frameworkem). Takže by měla být srovnávána např. java vs. C#.
-
Tak pokud chceš přejít z Javy na .NET, tak je to v zásadě stejné. Zásadní je rozdíl v tom, že .NET je pořád hodně Windows centric, kdežto Java určitě ne a mnohem častěji ji člověk potká na Linuxu/Unixu než Windows. .Net core je sice multiplatformní už z podstaty, ale většina nasazení, se kterými člověk přijde do styku stejně pojedou na Windows.
Další věc je ekosystém knihoven a nástrojů okolo. Toho je v Javě mnohem více, protože zkrátka má za sebou delší historii a silnější a větší komunitu.
Za mě tedy jestli umíš slušně Javu, tak bych vydržel u Javy. Práce jako Java vývojář seženeš minimálně stejně, spíše více jak .NET vývojář a stejně nebo lépe placenou.
Spíš bych se přiučil javascript a trochu FE, protože ten teď jede ze všeho nejvíc, to se hodí mnohem více než přecházet na .NET.
-
protože zkrátka má za sebou delší historii a silnější a větší komunitu.
a uz niekolko rokov nic nove do javy neprislo. oproti tomu, taky .Net sa neustale vyvija, ide dopredu. Vsetko je medzi sebou uzkou previazane (C#, Entity Framework, Azure, MSSQL...)
Spíš bych se přiučil javascript a trochu FE
Pockat, ale on nechcel byt nejaky budiznicema, jeden z mnohych, ktori ovladaju XYZ frameworkov, ale dokopy nic, lebo nemaju sancu stihat sa to ucit.
-
a uz niekolko rokov nic nove do javy neprislo ...
Toto mozes ako povedat? :D Java 8, Java 9 ... nic nove? wtf ... cely ekosystem okolo toho, co by si akoze chcel?
-
Připadá mi to jako velmi rozporuplná argumentace. Ale to je určitě tím, že programování nerozumím. Kdybys psal, že je to nečisté, nebo proti programátorskému pánuoopbohu, tak bych to chápal. Ale že je to ZCELA zbytečné...
Null je v C# i v Javě, o tom teď nebyla řeč.
Řeč byla o syntaktickém cukru, kterého má Java méně než C#. Podle mne je to správně.
Já nemluvil o null jako takovém. Ale o zacházení s ním - a o nástrojích, které mi tu práci s ním ulehčují. Čili přesně o tom syntaktickém cukru - který je podle tebe zcela zbytečný.
Ale vlastně je to logické, pokud svou vlastní argumentaci považuješ za konzistentní, že jsi moje podobenství nepochopil.
-
No ono ta Java 8 zase takové terno není. Přibyly lambdy, streamy a Optional. Lambdy nejsou zase takové terno. Streamy... viděl jsem, jak to vypadalo, když Indové dostali jasně za úkolo používat streamy, protože je to asi velice profesionální. Vznikl z toho solidní nepřehledné běsy.
Optional taky nic moc, protože to má hrozně ukecanou syntax, viz:
// safe, ugly, omission-prone
if (project != null) {
ApplicationType applicationType = project.getApplicationType();
if (applicationType != null) {
String typeDirName = applicationType.getTypeDirName();
if (typeDirName != null) {
System.out.println(typeDirName);
}
}
}
// let's assume you will get this from your model in the future; in the meantime...
Optional<Project> optionalProject = Optional.ofNullable(project);
// safe, java 8, but still ugly and omission-prone
if (optionalProject.isPresent()) {
ApplicationType applicationType = optionalProject.get().getApplicationType();
Optional<ApplicationType> optionalApplicationType = Optional.ofNullable(applicationType);
if (optionalApplicationType.isPresent()) {
String typeDirName = optionalApplicationType.get().getTypeDirName();
Optional<String> optionalTypeDirName = Optional.ofNullable(typeDirName);
if (optionalTypeDirName.isPresent()) {
System.out.println(optionalTypeDirName);
}
}
// safe, prettier
Optional<String> optionalTypeDirName = optionalProject
.flatMap(project -> project.getApplicationTypeOptional())
.flatMap(applicationType -> applicationType.getTypeDirNameOptional());
optionalTypeDirName.ifPresent(typeDirName -> System.out.println(typeDirName));
A ted to same C#:
var typeDirName = project?.ApplicationType?.TypeDirName;
if(typeDirName != null)
System.Console.WriteLine(typeDirName);
Jinak, jestli někomu z Javistu připadá to použití Streamu jako pěknější a přehlednější, než původní klasické checkování na null, tak by si měl zajít k doktorovi nebo najít holku.
-
Já nemluvil o null jako takovém. Ale o zacházení s ním - a o nástrojích, které mi tu práci s ním ulehčují. Čili přesně o tom syntaktickém cukru - který je podle tebe zcela zbytečný.
Ale vlastně je to logické, pokud svou vlastní argumentaci považuješ za konzistentní, že jsi moje podobenství nepochopil.
O souvislosti null se syntaktickým cukrem jsem nepsal. Spojil jsi dva mé příspěvky, které byly o dvou různých aspektech. Jeden byl o podobnosti Javy a C# (nevhodnost používání null v OOP) a druhý byl rozdílech Java vs. C# (boilerplates vs. syntaktický cukr).
-
Jinak, jestli někomu z Javistu připadá to použití Streamu jako pěknější a přehlednější, než původní klasické checkování na null, tak by si měl zajít k doktorovi nebo najít holku.
Tady musím všechny čtenáře upozornit: to co zde anonym předvedl je naprostá pitomost. I když uvážíme že by se dalo napsat méně humpolácky (pravidlo číslo 1: pokud používám isPresent+get, tak to dělám blbě), tak skutečně hromadně nahradit null check pomocí Optional.ofNullable je hovadina (neplatí pro outsourced IT dělníky z Indie i odjinud, kteří jsou placeni od hodiny nebo dokonce LOC).
Jinak ?. operátor je skvělá věc a velmi by se v Javě hodil, stejně jako Elvis operátor ?:
-
Tady musím všechny čtenáře upozornit: to co zde anonym předvedl je naprostá pitomost.
Původní článek:
https://dzone.com/articles/java-8-optional-avoid-null-and
62.10k Views
Comment (22)
Ani jediný kometář neuvadí nic jako: "Ty jsi se dočista zbláznil, jak sis tím streamem proboha pomohl?"
-
Ten článěk je pěkná blbina, protože "vylepšený" kód není sémanticky to samý jako původní krátky kód kde se nekontroloval null. Původní kód mohl vyhučet na NullPointerException, nový kód ale na nepřítomnost daných objetů nijak nereaguje a tiše pokračuje dál jako by se nechumelilo. To už rovnou stačilo udělat eé a obalit původní kód do try-catch bloku a NullPointerException odchytit a ignorovat. Nový kód by tedy měl vyhodit nějakou jinou výjimku, nebo indikovat neúspěch jinak. Pokud existuje rozumný předpoklad, že by null neměl být nikdy vrácen, je nejlepší nekontrolovat nic a v případě chyby nechat kód zhučet, protože to znamená že je asi něco hodně v nepořádku...
-
Pokud existuje rozumný předpoklad, že by null neměl být nikdy vrácen, je nejlepší nekontrolovat nic a v případě chyby nechat kód zhučet, protože to znamená že je asi něco hodně v nepořádku...
Přesně. Odchytávání výjimek s jejich následným ignorováním už nadělalo spoustu škod. Když je nechci zpracovat, což zpravidla nechci, je mnohem lepší je nechat propadnout.
-
Ten článěk je pěkná blbina, protože "vylepšený" kód není sémanticky to samý jako původní krátky kód kde se nekontroloval null. Původní kód mohl vyhučet na NullPointerException, nový kód ale na nepřítomnost daných objetů nijak nereaguje a tiše pokračuje dál jako by se nechumelilo. To už rovnou stačilo udělat eé a obalit původní kód do try-catch bloku a NullPointerException odchytit a ignorovat. Nový kód by tedy měl vyhodit nějakou jinou výjimku, nebo indikovat neúspěch jinak. Pokud existuje rozumný předpoklad, že by null neměl být nikdy vrácen, je nejlepší nekontrolovat nic a v případě chyby nechat kód zhučet, protože to znamená že je asi něco hodně v nepořádku...
https://stackoverflow.com/questions/33287261/null-check-vs-try-catch-when-99-of-the-time-object-is-not-null
https://stackoverflow.com/questions/37960674/null-check-chain-vs-catching-nullpointerexception
https://stackoverflow.com/questions/8621762/java-if-vs-try-catch-overhead
-
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 ...
Mas smolu, je to tvoje zle rozhodnutie.
NET je primarne zamerany na Windows. Lenze Windows sa s kazdou verziou zhorsuje, napr Windows 10 je z hladiska administracie systemu katastrofa - nevhodna na korporatne pouzitie. Kazdy rozumny clovek/firma pouziva na server Linux a na Linuxe nema NET ziadnu buducnost.
Jasna volba pre buducnost je Java (alebo hociso ine - napr. aj COBOL ale nie .NET ) !!!
-
Jasna volba pre buducnost je Java (alebo hociso ine - napr. aj COBOL ale nie .NET ) !!!
Kromě COBOLu ještě Fortran, Lisp, Smalltalk, Python, PHP, Haskell, ...
-
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 ...
Mas smolu, je to tvoje zle rozhodnutie.
NET je primarne zamerany na Windows. Lenze Windows sa s kazdou verziou zhorsuje, napr Windows 10 je z hladiska administracie systemu katastrofa - nevhodna na korporatne pouzitie. Kazdy rozumny clovek/firma pouziva na server Linux a na Linuxe nema NET ziadnu buducnost.
Jasna volba pre buducnost je Java (alebo hociso ine - napr. aj COBOL ale nie .NET ) !!!
To už není úplně pravda, MS vydal .NET Core kompletně opensource.
-
Jasna volba pre buducnost je Java (alebo hociso ine - napr. aj COBOL ale nie .NET ) !!!
Kromě COBOLu ještě Fortran, Lisp, Smalltalk, Python, PHP, Haskell, ...
ano ale ne .NET
-
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 ...
Mas smolu, je to tvoje zle rozhodnutie.
NET je primarne zamerany na Windows. Lenze Windows sa s kazdou verziou zhorsuje, napr Windows 10 je z hladiska administracie systemu katastrofa - nevhodna na korporatne pouzitie. Kazdy rozumny clovek/firma pouziva na server Linux a na Linuxe nema NET ziadnu buducnost.
Jasna volba pre buducnost je Java (alebo hociso ine - napr. aj COBOL ale nie .NET ) !!!
To už není úplně pravda, MS vydal .NET Core kompletně opensource.
OK, nech je NET opensource, ale aj tak si nemyslim, ze to bude niekto niekedy vo velkom pouzivat :D
Kto a naco by sa tu s tym na Linuxu s**l, ked Java je tu overena a bezi tu bez problemu ?
MS technologie - na zaklade mojich skusenosti - dakujem - radsej nie.
Kolko tu toho uz bolo a ukazalo sa to ako zbytocna investicia pretoze to dlho nevydrzalo ?: MFC, COM, Visual Foxpro, ADO, WSH, ... a vsetko MS zmenil/zrusil a teraz je to kazdemu kto do toho investoval a vyvijal v tom na h***o.
To su tie MS technologie - kto sa na tom v minulosti uz poriadne popalil, tak sa dnes tomu radsej vyhyba.
Treba si uvedomit, ze znes vsetko co je pokrokove bezi na aplikaciach, ktore su Linux friendly.
Jednostranna orientacia na taku platformu ako je MS Windows uz fakt nema zmysel.
-
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 ...
Mas smolu, je to tvoje zle rozhodnutie.
NET je primarne zamerany na Windows. Lenze Windows sa s kazdou verziou zhorsuje, napr Windows 10 je z hladiska administracie systemu katastrofa - nevhodna na korporatne pouzitie. Kazdy rozumny clovek/firma pouziva na server Linux a na Linuxe nema NET ziadnu buducnost.
Jasna volba pre buducnost je Java (alebo hociso ine - napr. aj COBOL ale nie .NET ) !!!
To už není úplně pravda, MS vydal .NET Core kompletně opensource.
OK, nech je NET opensource, ale aj tak si nemyslim, ze to bude niekto niekedy vo velkom pouzivat :D
Kto a naco by sa tu s tym na Linuxu s**l, ked Java je tu overena a bezi tu bez problemu ?
MS technologie - na zaklade mojich skusenosti - dakujem - radsej nie.
Kolko tu toho uz bolo a ukazalo sa to ako zbytocna investicia pretoze to dlho nevydrzalo ?: MFC, COM, Visual Foxpro, ADO, WSH, ... a vsetko MS zmenil/zrusil a teraz je to kazdemu kto do toho investoval a vyvijal v tom na h***o.
To su tie MS technologie - kto sa na tom v minulosti uz poriadne popalil, tak sa dnes tomu radsej vyhyba.
Treba si uvedomit, ze znes vsetko co je pokrokove bezi na aplikaciach, ktore su Linux friendly.
Jednostranna orientacia na taku platformu ako je MS Windows uz fakt nema zmysel.
A co Java?
Mrtvé jsou AWS, Swing, teď je Java FX a už jsem zase někde četl, že se to nepoužívá.
Ve Springu jsou verze od verze velké rozdíly a ještě navíc to má bugy. Teď jsem zase četl, že Oracle kašle na Javu EE. Navíc Spring ani Java EE pořád nemá vyřešený redeployment, potřebuješ JRebel. Redeployment má vyřešený: .NET, PHP, Python, Play framework. Všechno, jen ne Java.
Co ty další frameworky? Vaadin, JSF, Struts, GWT, Wicket... boože. X různých aplikačních serverů pro Java EE. Asi 5 různých logovacích frameworků, kdejaká knihovna používá jiný, protože ten ve standardní knihovně je shit.
Proč říkáš že ADO.NET je mrtvý? To je jako kdyby jsi řekl, že JDBC je mrtvý. Nad ADO.NET je postavený Entity Framework. To nechápu, jak někdo může říct, že je ADO.NET mrtvý. Entity Framework je stejně jako Hibernate pomalý, když chceš perfoemance, píšeš SQL ručně.
-
Ako spravne vystihujes aj Java ma svoje problemy ... ale ... furt je to lepsie ako NET.
Nehovorim, ze ADO.NET je mrtvy. Ale predtym tam bol iba ADO a ten je mrtvy. Pouzival sa napr. pri skriptovani z WSH (VBscript, JScript, ...) a bol nahradeny s ADO.NET, ktory je iny.
Trvalo mi urcity cas, kym som si na MS platforme navykol na ich jazyk VBScript a teraz by som mal pouzivat zase ich novy nepodarok PowerShell ?
Preto, prve co urobim, si vzdy na windows nainstalujem MSYS, kde mam bash a ine tooly, aby sa v tom dalo vobec nieco robit.
Rozdiel v Linuxe a vo Windowse je v tom, ze ked si nainstalujes beznu ditribuciu Linux, tak tam mas vsetko, aby sa v tom dalo zmysluplne robit. Naproti tomu ked nainstalujes Windows nemas tam absolutne nic. Par dalsich dni ti zaberie, kym zistis co ti este chyba a nainstalujes si to.
Schvalne, skus si porovnat Windows a Linux ako rychlo na tom rozbehas bezne veci ako git, docker, elastic, ....
Windows uz nema buducnost. NET je pre windows a teda nema tiez buducnost.
-
Ako spravne vystihujes aj Java ma svoje problemy ... ale ... furt je to lepsie ako NET.
Pokud srovnáváte virtuální stroje, tak JVM je z hlediska nabízených featur daleko za CLR.
CLR podporuje generika, hodnotové typy nebo tail call optimalizaci - to vše chybí na JVM a důsledkem je nižší výkon programů na JVM (bohužel to nedoženou ani optimalizace, které JVM dělá lépe než CLR).
Navíc jsou standardní knihovny .NETu a běhové prostředí pod svobodnější licencí než OpenJDK.
Windows uz nema buducnost. NET je pre windows a teda nema tiez buducnost.
.NET Core a Mono jsou i pro jiné systémy.
-
Lenze Windows sa s kazdou verziou zhorsuje, napr Windows 10 je z hladiska administracie systemu katastrofa - nevhodna na korporatne pouzitie.
A hovori on nieco o administracii systemu?
Kazdy rozumny clovek/firma pouziva na server Linux
Podla statistik je potom asi 90% ludi nerozumnych. Takisto firma, ked je ochotna si zaplatit za nastroje od MS, preco nie? Snad firma vie, co potrebuje, k comu to potrebuje a ci jej to vyhovuje. Taketo delenie ze rozumny-nerozumny si strc za klobuk. Jediny nerozumny si tu mozno ty.
Spomenul si tu okrajove technologie od MS. Ale take WinForms su tu od .NET 2.0 a udrziavaju sa stale. WPF je tu od roku 2007. Takisto WCF je dlhorocna technologia. A urcite tomu nic nenasvedcuje, ze to odstrihnu, nakolko v LOB maju tieto technologie velke zastupenie. MS prisiel s .NET Standard a rozsiruju api. Momentalne je tu UWP, uvidi sa, ako sa vyvinie tato technologia. MFC mrtve nie je, stale sa pouziva, ale kto by dnes robil GUI aplikaciu v C++, ked tu ma nastroje na rychlejsi a pohodlnejsi vyvoj.
Nebolo to tak nedavno, kedy zarezali nejaku verziu Angularu. Ochvilu zarezu aj istu verziu Pythonu a ti, ktori ju pouzivali maju teraz plne ruky prace.
Ale predtym tam bol iba ADO a ten je mrtvy
Cudujem sa, ze preco nepouzivas este stale pisaci stroj, ale pises na PC.
Kit:
Odchytávání výjimek s jejich následným ignorováním už nadělalo spoustu škod.
Vo vyspelom svete to funguje tak, ze vynimka sa odchyti, zaloguje sa chyba a posle sa napr. chybovy stav, na ktory nasledne reaguje GUI zobrazenim spravy, alebo pokial ide o webovu aplikaciu, tak sa naviguje na stranku o chybovom stave. A nie, ze sa necha vyhodit exception a padne aplikacia. V pripade vynimky ide o nekontrolovatelny stav, ale urcite to neplati v pripade, ked sa dopytujem na objekt od nejakej funkcie, ktora moze vratit null a ja aj napriek tomu pristupim na objekt bez predosleho overenia na null. To je cisty amatersky pristup a len tvoja blbost (popr. len trollis). Sam resharper, ktory pouzivam ako doplnok vo VS, nasepkava overenie objektu, aby sa predislo NullReferenceException.
-
este doplnim, ze vynimky sa nepouzivaju na kontrolu flow programu. na to je tu prave ten if. taketo veci by mal clovek takych kapacit ako Kit davno ovladat.
-
Kit:
Odchytávání výjimek s jejich následným ignorováním už nadělalo spoustu škod.
Vo vyspelom svete to funguje tak, ze vynimka sa odchyti, zaloguje sa chyba a posle sa napr. chybovy stav, na ktory nasledne reaguje GUI zobrazenim spravy, alebo pokial ide o webovu aplikaciu, tak sa naviguje na stranku o chybovom stave. A nie, ze sa necha vyhodit exception a padne aplikacia. V pripade vynimky ide o nekontrolovatelny stav, ale urcite to neplati v pripade, ked sa dopytujem na objekt od nejakej funkcie, ktora moze vratit null a ja aj napriek tomu pristupim na objekt bez predosleho overenia na null. To je cisty amatersky pristup a len tvoja blbost (popr. len trollis). Sam resharper, ktory pouzivam ako doplnok vo VS, nasepkava overenie objektu, aby sa predislo NullReferenceException.
Metody, které dělám, nikdy nevrací null místo objektu. Pokud tedy od ní očekávám objekt, tak ho dostanu.
-
Aha, tak ty si vsetko robis sam. Ty vynachadzas koleso. A uz si konecne aj nieco naprogramoval, alebo si stale len pri tom kolese?
-
Aha, tak ty si vsetko robis sam. Ty vynachadzas koleso. A uz si konecne aj nieco naprogramoval, alebo si stale len pri tom kolese?
PHP má dostatek koleček už v základní výbavě, takže další kolečka už vynalézat nemusím.
-
Pasuju Kita za trolla. Dokud neukáže nějakou svou aplikaci, třeba jak má napsaný nějaký ten svůj slavný plugin do VIMu, tak na něj doporučuju nereagovat. Říká kraviny jak z nějaké příručky, přitom při jakémkoliv vystavení Kita konkrétní situaci v kódu se začne vytáčet a mlžit a ignorovat. To není poprvé, co se mi to v diskuzi s nim stalo a nejsem na Rootu sám. Naprostá marnost s ním diskutovat.
-
Další nevýhody c#
1. Slabší oodpora pro Enumy
2. Nepodporuje kovariantní návratové typy, to jsem vcelku čuměl, nemůžu odělat override metody a vrátit potomka návratového typu. To je dost velký problém, jak mám udělat abstraktní oop návrh když tohle nejde.
3. Metody nejdou overridnout, pokud nejsou definované jako virtual. Další problém. Budu chtít upravit nějakou třídu v knihovně a nebudu moct, protože nebude mít virtual metody.
4. Visual Studio 2017 sice podporuje Live unit testy, tzn. pouští se mi automaticky unit testy k dané tříďě, ale pořád nemůžu ihned spustit upravovaný unit test. Často potřebuju experimentovat v unit testu s nějakou třídou a potřebuju, aby se ten test spustil okamžitě. V .NETu to trvá a navíc je tam problém s výpisem do outputu: zaprvé klasický Test output okno neumí vypisovat výstup z Trace, to umí Debug okno. Jenže v tom je Trace zase nepožitelný, protože je output zasviněný garbagem z inicializace test framewoku či co to je. Takže tohle je velká pruda.
5. V Javě nemusím řešit verze VM knihovny jako v .net, prostě mám nainstalované poslední jdk a na tom spustím úplně všechno.
-
1. Slabší oodpora pro Enumy
V com konkretne?
2. Nepodporuje kovariantní návratové typy, to jsem vcelku čuměl, nemůžu odělat override metody a vrátit potomka návratového typu. To je dost velký problém, jak mám udělat abstraktní oop návrh když tohle nejde.
Ale podporuje, to co si napisal je polymorfizmus, vies vratit potomka. Ak myslis kovariantne a intravariantne genericke typy, tak tie sa v generiksoch definuju pomocou Foo<in T>, Foo<out T>.
3. Metody nejdou overridnout, pokud nejsou definované jako virtual. Další problém. Budu chtít upravit nějakou třídu v knihovně a nebudu moct, protože nebude mít virtual metody.
Toto je ako .Netista a C++ -kar povazujem za velku vyhodu, hlavne z pohladu navrhu OOP kodu.
5. V Javě nemusím řešit verze VM knihovny jako v .net, prostě mám nainstalované poslední jdk a na tom spustím úplně všechno.
Plny .Net umoznuje referncovat kniznice s nizsou verziou .net frameworku.
pri net core sa pouziva .Net standard, ktory toto riesi.
-
2. Nepodporuje kovariantní návratové typy, to jsem vcelku čuměl, nemůžu odělat override metody a vrátit potomka návratového typu. To je dost velký problém, jak mám udělat abstraktní oop návrh když tohle nejde.
Ale podporuje, to co si napisal je polymorfizmus, vies vratit potomka. Ak myslis kovariantne a intravariantne genericke typy, tak tie sa v generiksoch definuju pomocou Foo<in T>, Foo<out T>.
Skutečně nepodporuje, je na to pouze návrh: Champion "Covariant Return Types" (https://github.com/dotnet/csharplang/issues/49)
-
Co se .NET Core týče, jak Microsoft zajistí, že mu komunita neukrade jeho vlastní platformu, do které valil miliony možná miliardy dolarů? Já teď třeba zkouším JetBrains Rider IDE. S tím nepotřebuju ani Windows. Co bude Microsoft dělat, když to tak uděla ledaskdo? Nějak se mi nechce věřit, že by si nechal ujít zisk.
-
Co se .NET Core týče, jak Microsoft zajistí, že mu komunita neukrade jeho vlastní platformu, do které valil miliony možná miliardy dolarů?
To nevím a nevím, jestli to hrozí. Spíše bych řekl, že na tom MS dost vydělal, protože na některých projektech komunita přispívá větším množstvím kódu než lidé od MS (konkrétně třeba F#), přičemž MS stále všechno řídí.
Díky tomu je rozvoj .NETu a C# otevřenější než rozvoj JVM a Javy.
Já teď třeba zkouším JetBrains Rider IDE. S tím nepotřebuju ani Windows. Co bude Microsoft dělat, když to tak uděla ledaskdo? Nějak se mi nechce věřit, že by si nechal ujít zisk.
IMO, to že člověk nepoužívá Windows, neznamená, že nemůže používat jiné produkty a služby od MS. Koneckonců MS přispívá i do Linuxu, řada jeho produktů je pro Mac. Sám třeba již několik let vyvíjím v F# bez Windows.
-
4. Nemusím pořád testovat na null, můžu použít ?
V Jave môžme (v odôvodnených prípadoch) použiť Optional, Kotlin prináša elvis operátor. Kotlin bude
(s istou pravdepodobnosťou) poračovateľom Javy. Je to v podstate vylepšená Java.
val l: Int = if (b != null) b.length else -1
val l = b?.length ?: -1
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.
To samozrejme nemusia ani Java programátory; right toot for the right job.
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.
Java má componentovo orientované frameworky, medzi najlepšie patrí Vaadin. Tam netreba
prakticky vôbec používať JavaScript, CSS, HTML.
7. Ke všem asp.net frameworkům je pořádná dokumentace, ne jako u Springu v Javě.
Prečo si to myslíš? Exitujú dve rozsiahle biblie Springu, plus ďalšie desiatky špecializovaných kníh.
Rozsiahla referenčá príručka a súbor guides. Ďalej množstvo príkladov na Githube.
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.
Swing patrí medzi najlepšie desktop GUI knižnice vôbec. Problémy boli vtedy, ak boli
Swing aplikácie spúšťané na strojoch s nedostatočnými zdrojmi (Java vo viacerých oblastiach
predbehla dobu) a keď neboli správne programátormi vyriešené dlhotrvajúce úlohy;
t.j. úlohy sa spúšťali v hlavnom vlákne aplikácie. Veľmi silno pochybujem, že C# GUI
knižnice sú rýchlejšie ako Swing. Skôr by som stavil na opak.
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ě.
.NET je z veľkej časti kópiou Javy, samozrejme, oni to tam potom vo viacerých oblastiach
vylepšili. Je to ako keď Japonci rozoberali americké autá a spotrebiče na súčiastky a začali
ich postupne vylepšovať. OK, ľudia sa inšpirujú inými, ale treba UZNAŤ bezpočet inovácií,
ktoré priniesla do sveta Java. Odkiaľ sú Hadoop, ElasticSearch, Maven?
-
Mrtvé jsou AWS, Swing, teď je Java FX a už jsem zase někde četl, že se to nepoužívá.
Swing určite nie je mŕtvy. On ani nikdy nebol príliš na očiach, pretože sa v ňom robia bizniss aplikácie.
Všetky IDE od JetBrains sú napríklad vo Swingu: IntelliJIDEA, PHPStorm, či CLion. Vývoj Swingu bol,
ukončený, ale to neznamená, že sa v ňom neprogramujú aplikácie. Vo svojej oblasti len veľmi ťažko
nájde konkurenta.
Navíc Spring ani Java EE pořád nemá vyřešený redeployment, potřebuješ JRebel. Redeployment má vyřešený: .NET, PHP, Python, Play framework. Všechno, jen ne Java.
Neviem čo sa myslí pod poriadne. Spring má v základnej zostave dev-tools, ktorý má redeployment.
Ďalej tam je Spring loaded, ktorý je robustnejší.
Co ty další frameworky? Vaadin, JSF, Struts, GWT, Wicket... boože. X různých aplikačních serverů pro Java EE.
Struts patril medzi pionerske projekty; v tej dobe sa v PHP varili špagety a Windows tam mal najeké ASP
JScript či čo. V Jave sa už uvažovalo o robustnom vývoji webových aplikácií a práve to priniesol ako prvý Struts.
Naň potom nadväzovali ďalšie Frameworky. JSF, Vaadin, GWT a Wicket sú kompenontovo orientované webové
frameworky, a Stripes, Struts, Spring MVC, chystaný MVC 1.0 sú action-oriented, Jersey, ReastEasy atď sú restové.
Každý z nich vypĺňa nejaký trhový výklenok, resp. vznikol ako vylepšenie predchádzajúceho frameworku.
Isteže je jednoduchšie mať pokope jeden balík. Plne to chápem, tiež mám z toho často veľkú hlavu ale
jedno riešenie sa nedá použiť pre všetky možné situácie v praxi. Ale tam kde sú inovácie, sú aj rôzne alternatívy.
Situácia nie nepodobná Linuxovým distribúciám.
Asi 5 různých logovacích frameworků, kdejaká knihovna používá jiný, protože ten ve standardní knihovně je shit.
Logovanie patrí medzi slabiny Javy. (Ešte horšie je na tom testovanie. Tam dúfam JSpock nahradí celý ten guláš.
Ale to je tak vždy, keď niekto sa púšťa do nových vecí, a nemá od koho kopírovať.
-
a uz niekolko rokov nic nove do javy neprislo. oproti tomu, taky .Net sa neustale vyvija, ide dopredu. Vsetko je medzi sebou uzkou previazane (C#, Entity Framework, Azure, MSSQL...)
Hmm, tak Java už vyše dvadsať rokov žije v znamení prudkého rozvoja a inovácií. Bezpočet knižníc,
frameworkov, ideí pochádzajú z Java. (Z historického hľadiska pravdepodnobne viaceré z nich mali
pôdov v ešte starších technológiách.) Stačí sa pozrieť na Apache Software foundation, koľko je tam
Java technológií. Okrem Javy 8, 9, prináša Java ekostystém v poslednej dobe nový programovací jazyk,
ktorý pravdepodobne nahradí Javu v mnohých oblastiach (Kotlin), vynorilo sa nové špičkové IDE
(IntelliJIDEA), Reaktívne programovanie, Microservices, Spring Cloud, Spring Social, Servlet 4
novinky, všetky možné dátové úložiská ako Cassandra, MongoDB a pod. Je toho požehnane.
-
Ako spravne vystihujes aj Java ma svoje problemy ... ale ... furt je to lepsie ako NET.
Nehovorim, ze ADO.NET je mrtvy. Ale predtym tam bol iba ADO a ten je mrtvy. Pouzival sa napr. pri skriptovani z WSH (VBscript, JScript, ...) a bol nahradeny s ADO.NET, ktory je iny.
Trvalo mi urcity cas, kym som si na MS platforme navykol na ich jazyk VBScript a teraz by som mal pouzivat zase ich novy nepodarok PowerShell ?
Preto, prve co urobim, si vzdy na windows nainstalujem MSYS, kde mam bash a ine tooly, aby sa v tom dalo vobec nieco robit.
Rozdiel v Linuxe a vo Windowse je v tom, ze ked si nainstalujes beznu ditribuciu Linux, tak tam mas vsetko, aby sa v tom dalo zmysluplne robit. Naproti tomu ked nainstalujes Windows nemas tam absolutne nic. Par dalsich dni ti zaberie, kym zistis co ti este chyba a nainstalujes si to.
Schvalne, skus si porovnat Windows a Linux ako rychlo na tom rozbehas bezne veci ako git, docker, elastic, ....
Windows uz nema buducnost. NET je pre windows a teda nema tiez buducnost.
https://developers.redhat.com/topics/dotnet/
Vy jste se vším nějak rychle hotový.
-
2. Nepodporuje kovariantní návratové typy, to jsem vcelku čuměl, nemůžu odělat override metody a vrátit potomka návratového typu. To je dost velký problém, jak mám udělat abstraktní oop návrh když tohle nejde.
Ale podporuje, to co si napisal je polymorfizmus, vies vratit potomka. Ak myslis kovariantne a intravariantne genericke typy, tak tie sa v generiksoch definuju pomocou Foo<in T>, Foo<out T>.
Ne, to co popsal, jsou skutečně kovariantní návratové typy. Nejde o to, že metoda vrací instanci potomka, ale o to, že metoda na zděděné třídě deklaruje, že bude vždy vracet potomka. Takhle:
class Mlade {
}
class Stene extends Mlade {
}
class Samice{
Mlade porod() {return null;};
}
class Fena extends Matka {
@Override
Stene porod() {return null;};
//tohle bez kovariantních návratových typů nejde, bez nich musí být návratový typ překryté metody shodný s návratovým typem překrývané metody
}
Kontrakt předka je zachován, ale když někde použijete přímo třídu potomka, máte přesnější definici návratového typu.
-
vynorilo sa nové špičkové IDE
(IntelliJIDEA), Reaktívne programovanie
No ved hovorim, java zaspala dobu. Reactive extension ma .net uz davno, spickove IDE ala Visual Studio tu je uz dlho.
Veľmi silno pochybujem, že C# GUI
knižnice sú rýchlejšie ako Swing. Skôr by som stavil na opak.
Asi mate pravdu, a preto sa LOB aplikacie povacsine pisu vo WPF. Nehovoriac o tom, ze PWF vyuziva directx. Ktory cvok by sahal po springu, ked by si mohol vybrat wpf.
-
spickove IDE ala Visual Studio tu je uz dlho
A proto existuje ReSharper, aby se to špičkové Visual Studio alespoň přiblížilo IntelliJ Idea? Mimochodem, IntelliJ Idea se „vynořila“ už v roce 2001, to možná někteří zdejší diskutující ani nebyli na světě…
-
no pozor na to. Ani ten resharper nie je vsemocny nastroj :). Visual Studio je pouzitelne je aj bez neho. To, ze nastava chyba medzi stolickou a klavesnicou, za to uz VS nemoze ;).
-
Ale jo, použitelné je kde co. Třeba jehličí místo lopuchu. Ale zrovna srovnání IntelliJ Idea a Visual Studia je jednoznačně ve prospěch Idey, i když VS je použitelné, možná i docela slušně použitelné.
-
vsetko je to o prioritach a preferenciach.
-
Ale jo, použitelné je kde co. Třeba jehličí místo lopuchu. Ale zrovna srovnání IntelliJ Idea a Visual Studia je jednoznačně ve prospěch Idey, i když VS je použitelné, možná i docela slušně použitelné.
Idea je dobra, ale až zase tak? Narazil jsem u ni v praci 3 zasadni problemy:
1. Dokazala si pokazit fungujici Make u velkeho Maven projektu. Proste se ji nejak samovolne kazily interne resolvnuté zavislosti z Mavenu a musel se udelat Clean cache, po kterem nasledovalo asi 20min zotavování. Dopady Clean cache and restart asi znáš.
2. Má naprd životně důležitou utilitku pro hledání Call hierarchíí. Je blbě udělaná a proto je pomalá jako prase a umí se i zacyklit. Strávil jsem týden psaním své vlastní utility pro hledání call hierarchíí kvůli tomu. Na githubu byly jen samé polofunkční řešení.
3. Má bug v podoře gitu, který umí pokazit merge. Celý jeden tým kvůli tomu musel ze strachu používat Tortoise git.
Ale jinak je Ide super, asi nejlepší ide co jsem měl, leč existuje JetBrains Rider a to je idea pro c# ;)
-
Swing patrí medzi najlepšie desktop GUI knižnice vôbec. Problémy boli vtedy, ak boli
Swing aplikácie spúšťané na strojoch s nedostatočnými zdrojmi (Java vo viacerých oblastiach
predbehla dobu) a keď neboli správne programátormi vyriešené dlhotrvajúce úlohy;
t.j. úlohy sa spúšťali v hlavnom vlákne aplikácie. Veľmi silno pochybujem, že C# GUI
knižnice sú rýchlejšie ako Swing. Skôr by som stavil na opak.
To, ze mala dektop aaplikacia zozrala celu ramku nepovazujem za predbehnutie dobry :D
Swing mozno vtdy bol super, no ked prislo WPF, tak to bol ako iny svet, kodenie UI zrazu zacalo byt deklarativne a bola to radost.
spickove IDE ala Visual Studio tu je uz dlho
A proto existuje ReSharper, aby se to špičkové Visual Studio alespoň přiblížilo IntelliJ Idea? Mimochodem, IntelliJ Idea se „vynořila“ už v roce 2001, to možná někteří zdejší diskutující ani nebyli na světě…
ReSharper hlavne zral systemove zdroje, to na co ste pred par rokmi potrebovali reSharper, dnes zvlada Visual Studio vo free verzii nativne. Niektore veci mi tam chybali, no na to sa daju najst pluginy. Povezdme, ze Roslin ako "compiler as a service" bol genialny napad.
2. Nepodporuje kovariantní návratové typy, to jsem vcelku čuměl, nemůžu odělat override metody a vrátit potomka návratového typu. To je dost velký problém, jak mám udělat abstraktní oop návrh když tohle nejde.
Ale podporuje, to co si napisal je polymorfizmus, vies vratit potomka. Ak myslis kovariantne a intravariantne genericke typy, tak tie sa v generiksoch definuju pomocou Foo<in T>, Foo<out T>.
Ne, to co popsal, jsou skutečně kovariantní návratové typy. Nejde o to, že metoda vrací instanci potomka, ale o to, že metoda na zděděné třídě deklaruje, že bude vždy vracet potomka. Takhle:
class Mlade {
}
class Stene extends Mlade {
}
class Samice{
Mlade porod() {return null;};
}
class Fena extends Matka {
@Override
Stene porod() {return null;};
//tohle bez kovariantních návratových typů nejde, bez nich musí být návratový typ překryté metody shodný s návratovým typem překrývané metody
}
Kontrakt předka je zachován, ale když někde použijete přímo třídu potomka, máte přesnější definici návratového typu.
Podobneh chovanie viem v C# dosiahnut pomocou implementacie kovariantneho generickeho interface.
S tym vysie uvedenym som sa v praxy este nestretol, ake to ma vyuzitie a prakticke dopady?
AKo mne osobne by v Jave chabli skutocne genericke typy (ak pisete infrastrukturny kod zo skutocnou generikou je svet ovela lahsi) a tiez som v nej mal neskutocny posit neslobody a kod v nej bol vzdy dlhsi a ukecanjsi.
-
to na co ste pred par rokmi potrebovali reSharper, dnes zvlada Visual Studio vo free verzii nativne. Niektore veci mi tam chybali, no na to sa daju najst pluginy. Povezdme, ze Roslin ako "compiler as a service" bol genialny napad.
Vím, že se VS za poslední dobu docela zlepšilo. Šlo mi o to, že to není tak, jak to bylo původně formulováno – že VS je skvělé IDE, které teď Idea dohání. Je to přesně naopak, Idea je špička už spoustu let, a VS se tomu v poslední době přibližuje.
Podobneh chovanie viem v C# dosiahnut pomocou implementacie kovariantneho generickeho interface.
S tím ale musí počítat i ten předek, ne?
S tym vysie uvedenym som sa v praxy este nestretol, ake to ma vyuzitie a prakticke dopady?
AKo mne osobne by v Jave chabli skutocne genericke typy (ak pisete infrastrukturny kod zo skutocnou generikou je svet ovela lahsi)
Souhlasím a vadí mi, že to (pokud vím) není mezi změnami, o kterých by se reálně uvažovalo.
tiez som v nej mal neskutocny posit neslobody a kod v nej bol vzdy dlhsi a ukecanjsi.
Podle mne svoboda do zdrojových kódů nepatří. To není umělecké dílo, kde se bude někdo kochat, co originálního tam kdo vymyslel. Mně vadí, když vidím v Groovy 10. způsob zápisu volání metody a musím nad tím přemýšlet a uvědomit si, že tohle je také volání metody.
-
No ved hovorim, java zaspala dobu. Reactive extension ma .net uz davno, spickove IDE ala Visual Studio tu je uz dlho.
Spring a Java EE nedávno zakomponovali reaktívne programovanie do svojich knižníc; ale RxJava je tu už
dlho ako externý modul. Asi tak dlho, ako ten .NET. Takže určite Java nazaspala dobu.
Asi mate pravdu, a preto sa LOB aplikacie povacsine pisu vo WPF. Nehovoriac o tom, ze PWF vyuziva directx. Ktory cvok by sahal po springu, ked by si mohol vybrat wpf.
Predpokladám, že bolo myslené Swing, nie Spring. Ktorý cvok? Všetci tí, ktorí nechcú customer lock-in,
ktorí potrebujú ozajstnú multiplatformovú GUI desktop aplikáciu. Ďalej vývojári z krajín ako sú Čína,
Rusko, Brazília, kde sa strategicky prechádza na open-source kvôli špionáži.
Bez netriviálnych zásahov nie sú WPF aplikácie portabilné ani na Windows systémoch; čo som si letmo pozeral,
tak layout manažéry natvrdo v pixeloch nastavujú vzdialenosti medzi komponentami. Skúste si spustiť komplexnejší
layout vytvorený vo WPF na malom rozlíšení, strednom a potom veľkom.
To, ze mala dektop aaplikacia zozrala celu ramku nepovazujem za predbehnutie dobry :D
Swing mozno vtdy bol super, no ked prislo WPF, tak to bol ako iny svet, kodenie UI zrazu zacalo byt deklarativne a bola to radost.
Swing bol vytvorený okolo roku 1997! Na vtedajších PC to proste nešlo. V Sun to vyvýjali na
svojich silných pracovných staniciach. Muselo prejsť viac rokov, kým boli všeobecne dostupné PC, ktoré
mali dostatok prostriedkov na Java desktop aplikácie. Windows 7, 10 tiež nepustíte na starších počítačoch,
ten moloch zvaný Visual Studio duplom nie. Ja si za chvíľu stiahnem NetBeans, naprogramovaný vo Swingu,
hneď to bez cavykov spustím na hociktorom OS, a hneď môžem kódiť. A aplikácia vo Swingu mi pôjde na všetkých platformách.
Swing je to špičková technológia, ktorá má strmú krvivku učenia. Kto dobre pozná Swing, nepotrebuje
barličky vo forme klikacích nástrojov.
-
No ved hovorim, java zaspala dobu. Reactive extension ma .net uz davno, spickove IDE ala Visual Studio tu je uz dlho.
Spring a Java EE nedávno zakomponovali reaktívne programovanie do svojich knižníc; ale RxJava je tu už
dlho ako externý modul. Asi tak dlho, ako ten .NET. Takže určite Java nazaspala dobu.
Asi mate pravdu, a preto sa LOB aplikacie povacsine pisu vo WPF. Nehovoriac o tom, ze PWF vyuziva directx. Ktory cvok by sahal po springu, ked by si mohol vybrat wpf.
Predpokladám, že bolo myslené Swing, nie Spring. Ktorý cvok? Všetci tí, ktorí nechcú customer lock-in,
ktorí potrebujú ozajstnú multiplatformovú GUI desktop aplikáciu. Ďalej vývojári z krajín ako sú Čína,
Rusko, Brazília, kde sa strategicky prechádza na open-source kvôli špionáži.
Bez netriviálnych zásahov nie sú WPF aplikácie portabilné ani na Windows systémoch; čo som si letmo pozeral,
tak layout manažéry natvrdo v pixeloch nastavujú vzdialenosti medzi komponentami. Skúste si spustiť komplexnejší
layout vytvorený vo WPF na malom rozlíšení, strednom a potom veľkom.
To, ze mala dektop aaplikacia zozrala celu ramku nepovazujem za predbehnutie dobry :D
Swing mozno vtdy bol super, no ked prislo WPF, tak to bol ako iny svet, kodenie UI zrazu zacalo byt deklarativne a bola to radost.
Swing bol vytvorený okolo roku 1997! Na vtedajších PC to proste nešlo. V Sun to vyvýjali na
svojich silných pracovných staniciach. Muselo prejsť viac rokov, kým boli všeobecne dostupné PC, ktoré
mali dostatok prostriedkov na Java desktop aplikácie. Windows 7, 10 tiež nepustíte na starších počítačoch,
ten moloch zvaný Visual Studio duplom nie. Ja si za chvíľu stiahnem NetBeans, naprogramovaný vo Swingu,
hneď to bez cavykov spustím na hociktorom OS, a hneď môžem kódiť. A aplikácia vo Swingu mi pôjde na všetkých platformách.
Swing je to špičková technológia, ktorá má strmú krvivku učenia. Kto dobre pozná Swing, nepotrebuje
barličky vo forme klikacích nástrojov.
Klikací nástroje ale nejsou žádná berlička nebo ostuda je používat; ulehčují práci, stejně jako ta vaše Swing aplikace, nebo jí také říkáte berlička?
-
Zaprvé Swing má pokud vím problémy s tím, aby udělal na všech platformách úplně stejný grafický výstup. Další problém jsou zastaralé prvky, např. okno na procházení souborového systému je nic moc. Swing taky trpí problémy s výkonem, jednak se to v obecnosti píše jako jeho vlastnost, druhak jsem měl tu čest vyzkoušet tŕeba populární Jzy3d knihovnu na vykreslování grafu - je zo ve Swingu a seká se to opravdu dost i na silném stroji. Jednou v práci jsem pracoval na Swing aplikaci pro účetnictví a setkal jsem se touto nehorázností: potřeboval jsem do prvku tabulky (nevím jak se te komponentě říká) dát jiný prvek, checkbox. Klasická věc, která ve windorms je na 1 kliknutí, je naprostý nehorázný opruz ve Swingu, protože tam prostě nejdee do tabulky libolnou jinou komponentu přidat. Je to hnusná chyba návrhu a jak tady někdo psal, že Swing je z roku 1997, tak prosím, jde to vidět.
-
Spring a Java EE nedávno zakomponovali reaktívne programovanie do svojich knižníc; ale RxJava je tu už
dlho ako externý modul. Asi tak dlho, ako ten .NET. Takže určite Java nazaspala dobu.
...
Swing je to špičková technológia, ktorá má strmú krvivku učenia. Kto dobre pozná Swing, nepotrebuje
barličky vo forme klikacích nástrojov.
RxJava je docela dobrá, řekl bych, že lepší než Rx.NET, především umí řešit backpressure, což může být dost kritické.
Já dělal ve Swingu appky několik let, a myslím, že už je vidět, jak je ta technologie letitá. Velmi nepříjemné je např. nepodporování multitouch, v roce 2018 WTF? Oracle už na vývoj Swingu prdí a doporučuje přejít na JavaFX, s tím mám zkušeností minimum...
Líbil by se mi nějaký reaktivní Java GUI framework (takový React pro JavaFX, třeba), ale když jsem hledal před dvěmi lety naposledy, nic pořádného aktivně vyvíjeného jsem nenašel :(
-
Zaprvé Swing má pokud vím problémy s tím, aby udělal na všech platformách úplně stejný grafický výstup. Další problém jsou zastaralé prvky, např. okno na procházení souborového systému je nic moc. Swing taky trpí problémy s výkonem, jednak se to v obecnosti píše jako jeho vlastnost, druhak jsem měl tu čest vyzkoušet tŕeba populární Jzy3d knihovnu na vykreslování grafu - je zo ve Swingu a seká se to opravdu dost i na silném stroji. Jednou v práci jsem pracoval na Swing aplikaci pro účetnictví a setkal jsem se touto nehorázností: potřeboval jsem do prvku tabulky (nevím jak se te komponentě říká) dát jiný prvek, checkbox. Klasická věc, která ve windorms je na 1 kliknutí, je naprostý nehorázný opruz ve Swingu, protože tam prostě nejdee do tabulky libolnou jinou komponentu přidat. Je to hnusná chyba návrhu a jak tady někdo psal, že Swing je z roku 1997, tak prosím, jde to vidět.
Swing default look and feel (Metal look and feel) je skvelý, jeden z mála skutočne čistých dizajnov.
Ak je potreba, môžu sa vytvoriť vlastné look and feels. Stačí si pozrieť IDE od JetBrains; oni si sami vytvorili
svoje vlastné vizuály.
Čo sa týka výkonu, tak ak niekto zle naprogramuje aplikáciu v C, tak to neznamená, že C je pomalé.
Swing bol úspešne využívaný pri komplexných, zložitých aplikáciách, takže nejaký trápny graf mu určite nerobí
problémy.
Komponenta sa volá JTable.
Pre pridanie JComboBox komponenty potrebujeme nasledovný kód (nič zložité):
private JTable createTable() {
model = new DefaultTableModel(new Object[] {"Brands"}, 5);
table = new JTable(model);
table.setRowHeight(25);
JComboBox box = new JComboBox();
box.addItem("Nokia");
box.addItem("Apple");
box.addItem("Mercedes");
box.addItem("Pepsi");
box.addItem("Lenovo");
TableColumn tc = table.getColumn("Brands");
tc.setCellEditor(new DefaultCellEditor(box));
return table;
}
Vyzerá to takto:
(https://i.imgur.com/PhWwAg3.png)
Swing je veľmi flexibilný a prepracovaný. Za dva týždne sa ho nenaučíte.
-
Predpokladám, že bolo myslené Swing, nie Spring. Ktorý cvok? Všetci tí, ktorí nechcú customer lock-in,
ktorí potrebujú ozajstnú multiplatformovú GUI desktop aplikáciu. Ďalej vývojári z krajín ako sú Čína,
Rusko, Brazília, kde sa strategicky prechádza na open-source kvôli špionáži.
Tu si treba uvedomit jednu vec. Bavime sa o desktope, ano? A pokial mi dobre sluzia vsetky zmysly, tak na desktopoch je najviac rozsireny windows, takze nejaku multiplatformovost netreba riesit, ak budu vsetci uzivatelia windows-oriented. Pretlacat niekde mjltiplatformovost a argumentovat tym, to je asi dnes taky modny hit :)
-
Tu si treba uvedomit jednu vec. Bavime sa o desktope, ano? A pokial mi dobre sluzia vsetky zmysly, tak na desktopoch je najviac rozsireny windows, takze nejaku multiplatformovost netreba riesit, ak budu vsetci uzivatelia windows-oriented. Pretlacat niekde mjltiplatformovost a argumentovat tym, to je asi dnes taky modny hit :)
„Nejvíc rozšířený“ je pěkný nesmysl. „Nejvíc rozšířený“ prohlížeč je Chrome, který má 60 % uživatelů. Opravdu hodíte 40 % uživatelů přes palubu? Windows mají na desktopu podíl okolo 85 %, Mac má kolem 10 %. Ani to není rozložení, nad kterým by bylo možné mávnout rukou a dělat vše Windows only. Zvlášť když klesá podíl desktopu jako takového.
-
Tu si treba uvedomit jednu vec. Bavime sa o desktope, ano? A pokial mi dobre sluzia vsetky zmysly, tak na desktopoch je najviac rozsireny windows, takze nejaku multiplatformovost netreba riesit, ak budu vsetci uzivatelia windows-oriented. Pretlacat niekde mjltiplatformovost a argumentovat tym, to je asi dnes taky modny hit :)
„Nejvíc rozšířený“ je pěkný nesmysl. „Nejvíc rozšířený“ prohlížeč je Chrome, který má 60 % uživatelů. Opravdu hodíte 40 % uživatelů přes palubu? Windows mají na desktopu podíl okolo 85 %, Mac má kolem 10 %. Ani to není rozložení, nad kterým by bylo možné mávnout rukou a dělat vše Windows only. Zvlášť když klesá podíl desktopu jako takového.
Jenže na desktopu hodíš přes palubu jen 10%, né 40%. Záleží na zastoupení OS v oboru, pro kterej je aplikace určená, ale dost často to neni problém. Namátkou se koukni, kolik třeba existuje multiplatformních učetních systémů..
Co se týče GUI na desktopu, Java má oproti .NET opravdu výhodu v multiplatformnosti. Ale mrzí mě, že na JavaFX Oracle docela sere. A všechny známý aplikace běží na starym Swingu.
-
Tu si treba uvedomit jednu vec. Bavime sa o desktope, ano? A pokial mi dobre sluzia vsetky zmysly, tak na desktopoch je najviac rozsireny windows, takze nejaku multiplatformovost netreba riesit, ak budu vsetci uzivatelia windows-oriented. Pretlacat niekde mjltiplatformovost a argumentovat tym, to je asi dnes taky modny hit :)
„Nejvíc rozšířený“ je pěkný nesmysl. „Nejvíc rozšířený“ prohlížeč je Chrome, který má 60 % uživatelů. Opravdu hodíte 40 % uživatelů přes palubu? Windows mají na desktopu podíl okolo 85 %, Mac má kolem 10 %. Ani to není rozložení, nad kterým by bylo možné mávnout rukou a dělat vše Windows only. Zvlášť když klesá podíl desktopu jako takového.
Presne tak. Treba tiež vziať do úvahy, kto sú tí 10%. Trebárs vezmime si štatistiky podielu server-side
jazykov. PHP 83.1%, ASP.NET 14.1%, Java 2.4%, static files 1.5%, ColdFusion 0.6%, Ruby 0.5%,
JavaScript 0.4%, Perl 0.3%, Python 0.2%, Erlang 0.1%.
https://w3techs.com/technologies/overview/programming_language/all (https://w3techs.com/technologies/overview/programming_language/all)
Java má minimálny podiel na celkovom trhu, točia sa však tam najväčšie peniaze. Odráža sa to aj
tým, že Java vývojári majú vo všeobecnosti vyššie mzdy ako majú PHP programátori.
Multiplatformovosť je dôležitá; z Windows MFC prešli v segmente grafických a animačných softwérov
mnohí na Qt knižnicu. Pretože v ich branži sa často pracuje s Mac a Unix systémami.
-
Presne tak. Treba tiež vziať do úvahy, kto sú tí 10%. Trebárs vezmime si štatistiky podielu server-side
jazykov. PHP 83.1%, ASP.NET 14.1%, Java 2.4%, static files 1.5%, ColdFusion 0.6%, Ruby 0.5%,
JavaScript 0.4%, Perl 0.3%, Python 0.2%, Erlang 0.1%.
https://w3techs.com/technologies/overview/programming_language/all (https://w3techs.com/technologies/overview/programming_language/all)
Java má minimálny podiel na celkovom trhu, točia sa však tam najväčšie peniaze. Odráža sa to aj
tým, že Java vývojári majú vo všeobecnosti vyššie mzdy ako majú PHP programátori.
Multiplatformovosť je dôležitá; z Windows MFC prešli v segmente grafických a animačných softwérov
mnohí na Qt knižnicu. Pretože v ich branži sa často pracuje s Mac a Unix systémami.
To jste ovšem zatajil takovou drobnost, že jde o statistiku programovacích jazyků webových stránek. Na aplikačních serverech bude nejspíš Java převládat. To dělá tu většinu podílu na celkovém trhu, ne nějaké webové stránky.
-
riesit multiplatformovost, ked aplikacia je urcena pre windows uzivatelov? To je co za nezmysel. Ak budem vlastnit IT firmu, kde budu kvalitni C#/WPF programatori a budeme mat riesit desktop aplikaciu, tak samozrejme nepojdeme cestou javy, lebo to bude drahsie a riesit "co ak mozno o 20 rokov ta appka bude nutna aj na linuxe", bude pre firmu nepodstatne. Ja nie som proti multiplatformovosti, ale nadobudam pocit, ze dnes to zacina byt nejaky buzzword.
-
riesit multiplatformovost, ked aplikacia je urcena pre windows uzivatelov? To je co za nezmysel. Ak budem vlastnit IT firmu, kde budu kvalitni C#/WPF programatori a budeme mat riesit desktop aplikaciu, tak samozrejme nepojdeme cestou javy, lebo to bude drahsie a riesit "co ak mozno o 20 rokov ta appka bude nutna aj na linuxe", bude pre firmu nepodstatne. Ja nie som proti multiplatformovosti, ale nadobudam pocit, ze dnes to zacina byt nejaky buzzword.
IMHO moc aplikací, které by měly smysl jen na windows, nebude
-
riesit multiplatformovost, ked aplikacia je urcena pre windows uzivatelov? To je co za nezmysel. Ak budem vlastnit IT firmu, kde budu kvalitni C#/WPF programatori a budeme mat riesit desktop aplikaciu, tak samozrejme nepojdeme cestou javy, lebo to bude drahsie a riesit "co ak mozno o 20 rokov ta appka bude nutna aj na linuxe", bude pre firmu nepodstatne. Ja nie som proti multiplatformovosti, ale nadobudam pocit, ze dnes to zacina byt nejaky buzzword.
IMHO moc aplikací, které by měly smysl jen na windows, nebude
Ber to tak, že dělat aplikace i pro další platformy se jim z krátkodobého hlediska prostě nevyplatí.
-
Ja si tiez myslim, ze na strane klienta je multiplatfromovost precenovana.
Hlavne sa mi paci to neustale vyzdvihovanie multiplatformovosti, no ked ju uz .Net Core dosiahol, zas fnukaju nad dacim inym.
-
riesit multiplatformovost, ked aplikacia je urcena pre windows uzivatelov?
Otázka je, jak jste přišel na to, že je aplikace určená pro uživatele Windows.
Ja si tiez myslim, ze na strane klienta je multiplatfromovost precenovana.
Hlavne sa mi paci to neustale vyzdvihovanie multiplatformovosti, no ked ju uz .Net Core dosiahol, zas fnukaju nad dacim inym.
Já si zase myslím, že je přeceňované .NET Core, pokud jde o aplikace na straně klienta, zejména o aplikace pro desktop.
-
Přenositelnost je dobrá jen pro plážová lehátka. Programy je třeba psát na míru platformě, jinak vznikne slabý hybrid.
-
Já si zase myslím, že je přeceňované .NET Core, pokud jde o aplikace na straně klienta, zejména o aplikace pro desktop.
.Net core je primarne urcene pre servrove aplikacie, na dektop sa netlaci.
Imho java na dektope tiez nejde ako teple rozky, ked vidim nejaku shcopnu OSS aplikaciu pre dektop a je multiplatformova je to vzdy v Qt.
-
riesit multiplatformovost, ked aplikacia je urcena pre windows uzivatelov?
Otázka je, jak jste přišel na to, že je aplikace určená pro uživatele Windows.
Pockat, co to melete? Ja vravim, ze to posudi firma. Oni vedia, pre koho je ta aplikacia primarne urcena. Verim, ze keby povie sef, 100% nasich uzivatelov pouziva windows, tak vy mu poviete, a co multiplatformovost, podme to pisat v Jave alebo Qt.
-
Dneska se dělají hlavně informační systémy a .NET Core a tudiž Linux na to nemůžeš použít, protože tam nejede WCF. Toť k multiplatformosti.
-
Udělal jsem další větev diskuze o .NET Core a jeho reálném použití na Linuxu při vývoji informačních systémů.
https://forum.root.cz/index.php?topic=17514.0
-
.Net core je primarne urcene pre servrove aplikacie, na dektop sa netlaci.
Ano, to jsem se vám snažil naznačit, že v souvislosti s desktopovými aplikacemi nemá smysl psát o .NET Core.
-
riesit multiplatformovost, ked aplikacia je urcena pre windows uzivatelov?
Otázka je, jak jste přišel na to, že je aplikace určená pro uživatele Windows.
Pockat, co to melete? Ja vravim, ze to posudi firma.
Hlavně že jste to citoval, že? Já v tom tučném tedy „posoudí to firma“ nevidím.
-
neviem o co vam ide. Chytanie za slovicka? jednoducho, ak pojde o desktop linux aplikaciu, volim javu alebo qt, ak pojde o windows tak wpf. ak ma ist o multiplatformovu tak asi Qt. Co je na tom tazke pochopit?
-
.Net core je primarne urcene pre servrove aplikacie, na dektop sa netlaci.
Imho java na dektope tiez nejde ako teple rozky, ked vidim nejaku shcopnu OSS aplikaciu pre dektop a je multiplatformova je to vzdy v Qt.
Nuž Swing nikdy nebol na očiach a nerobili sa v ňom aplikácie pre bežného užívateľa.
Medzi najžiarivejšie príklady úspešného využitia Swingu sú IDE od JetBrains. Swing
bol stavaný pre tvorbu komplexných biznis aplikácií, aj preto má takú strmú krivku učenia.
Swing treba hľadať na miestach ako sú letové prevádzky, výskum a vývoj, burzy, finančné inštitúcie,
zbraňovné systémy a pod.
Na Slovensku som si všimol, že v tom majú vytvorený softvér Slovenské železnice a niekoľko informačných systémov,
napr. http://www.htsolution.sk/informacny-system.html (http://www.htsolution.sk/informacny-system.html).
-
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.
-
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 je multiplatformní, ale ne všeplatformní. V jistém smyslu je multiplatformní i C++.
-
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.
Nemyslím, že by byla java dožívající. Žije to mimo jiné o díky novým jazykům nad jvm a ekosystému okolo, takže se celé to prostředí naopak spíš posouvá a vyvíjí dál, nikoli na úkor javy ale v symbióze s ní.
Místo swingu je tu javafx, která vypadá dost současně a dobře se používá. Divím se, že není víc vidět.
-
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.
Takových prostředí, které fungují stejně od roku 2001 a jsou podporované na platformách, které tehdy ani neexistovaly, moc nenajdete (čest vyjímkám). Na druhou stranu, se spuštěním java aplikace z roku 2001 budete mít na současném počítači pravděpodobně méně problémů než při spuštění aplikace v jiném jazyce. Běhové prostředí je samo o sobě i docela dobře definováno (takže těžko vyčítat javě že na mobilu nespustíte aplikaci pro desktop).
Zkuste si spustit normální C nebo C++ program z roku 2001 a budete docela zápolit - se starou distribucí na současném hardwaru nebo se starším toolchainem na současné distribuci. Nejsnáze byste to asi vyřešil virtualizací, což by ale nevypovídalo nic o přenositelnosti a neměnnosti vývojové platformy jako takové.
-
Teda to je maso tato diskuse :)
Tak jsme si prošli pojmy jako JAR/DLL, svoboda/fašismus, null/výjimky, syntaktický cukr/smetí, Windows/Linux, elvis operátor, kovariantní návratové typy, jehličí/lopuch, multiplatformnost/slabý hybrid, pak jsem se naštěstí už nechytal.
Mám pocit, jako by byly zmíněny skoro všechny existující platformy, jazyky, frameworky, postupy...
K dokonalosti už mi tu chybí jen 2 slova - a právě proto jsem tady - ATARI a Postscript.
Hezký večer všem :-*
-
RxJava je docela dobrá, řekl bych, že lepší než Rx.NET, především umí řešit backpressure, což může být dost kritické.
Cim to je, ze su dnes vsetci priposrati z backpressure? Do roku 2018 sa neprogramovalo?
Este lepsie su vyroky, ze FRP a Rx ulahcuje viacvlaknove programovanie.
A najlepsi je PublishSubject.serialize(). Bravo, ake genialne, to by urcite nikoho nenapadlo!
Ale seriozne, este som nestretol cloveka, ktory by vysypal z rukava rozdiely medzi hot/cold, finite/infinite, single/multivalue, subscribeOn/observeOn/subscribe, reactive pull...
Ale hlavne, ze sa pise v Rx, ktore vyriesi aj hladomor... keby len netflix vedel, kolko svetovych problemov vyriesili!
-
V Javě je to vždy JAR soubor a je jedno, jestli je to knihovna nebo spustitelný JAR.
Ne, neni to vzdy jar. Ale je fakt, ze mam zkusenosti jen s Java EE a Springem. Muze to byt jar, war, ear...
-
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.
-
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.
-
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á.
-
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.
-
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 :)
-
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.
-
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.
-
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.
-
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)
-
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.
-
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.
-
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.
-
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.
-
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.
(https://i.imgur.com/335i9G8.png)
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é.
-
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.
-
Ale já už se o tomhletom s javistama přít nebudu. Jdu teď pracovat na ičo, SW budu mít svůj a JRebel si koupím, takže už nebudu muset přemlouvat blbce ve frimě, že ono ten JRebel je opravdu potřeba a má mi ho koupit, protože všechna ostatní řešení jsou nahovno. Takže ať si kdo v Javě bastlí jak chce, mě už je to jedno. Tím líp pro mě, já mit budu, ty ne ;)