.NET Core 5 bude open source a s oficiální podporou Linuxu

Microsoft uvolní .NET Core, odlehčenou verzi .NETu, pod licencí MIT. .NET Core obsahuje malé běhové prostředí pro .NET aplikace a základní knihovnu tříd. Na rozdíl od .NET Frameworku, jenž podporuje pouze Windows, bude .NET Core navíc podporovat i Linux a Mac. Zdrojové kódy projektu .NET Core jsou dostupné na GitHubu.

12.11.2014 21:50 | Radek Miček | Nová verze

Komentáře

[Harvie.CZ]

Děkujeme pěkně a zas táhněte. Možná se s váma bude kamarádit mono...

[odin]

Zajimave. Musim se podivat, jaka podmnozina .net frameworku bude takto uvolnena. Kez by to pomohlo a mono bylo posunuto dale.

[odin]

Aha, tak se jedna jen o malou podmnozinu.

[Lol Phirae]

Doporučuju zasunout do análu MdI.

[kralyk z abclinuxu]

Že by fáze "then you win"?

[Josef Kufner]

Vypadá to tak

[Roslav]

Aby to nebola faza "extend"!

[kralyk z abclinuxu]

Jestli začně být .NET na linuxovém serveru zajímavou možností, pak by fázi extend mohl udělat projekt Mono

[frdrx]

A protože to neuvolnili pod GPLv3, hrozí leckomu, že Microsoftu může kohokoli kdo ten kód využije vydírat kvůli patentům.

[unicode]

We are releasing the source under the MIT open source license and are also issuing an explicit patent promise to clarify users patent rights to .NET.

[frdrx]

IANAL, ale ten slib mi přijde dost omezený. Vypadá to, že se to nevztahuje třeba na tvorbu a distribuci pozměněného kódu, ale nevím.

Microsoft Corporation and its affiliates ("Microsoft") promise not to assert any .NET Patents against you for making, using, selling, offering for sale, importing, or distributing Covered Code, as part of either a .NET Runtime or as part of any application designed to run on a .NET Runtime.

[Kvakor]

Microsoftu by se takovýto typ vydírání nevyplatil, zaprvé si mnohem více peněz vydělají vydíráním velkých firem za používání Linux/Androidu (nevím, jak teď v době po Win8, ale svého času za to měli víc pěněz než byl zisk divize mobilních Windows), zadruhé by tím odehnalů potenciální vývojáře. Osobně bych to typoval spíš akci cílenou proti Oraclu a Javě, hlavně Javě ME.

[frdrx]

To zní rozumně.

[...]

ani ne. to by pak vypadalo, ze proti jave bojuje kazdy -- viz treba go(lang) od google -- a tak dulezity oracle zdaleka neni.

[unicode]

Souhlas, až na tu "Java ME" - ta je podle mě dead. Pro mě je nejzajímavější asi RyuJIT, ale i tak si myslím, že Java konkurenci potřebuje a budou z toho profitovat obě strany.

[pc2005]

Tak mě napadá, že teďka přepíšou minecraft do .NETu a bude hotovo :-/ .

[odin]

Java me? Ani omylem, ta uz je pekne out par let

[xkucf03]

Těch důvodů bude pravděpodobně víc:

• Microsoft si je vědom toho, že prohrál – pravda a morální převaha je na straně svobodného softwaru – tak se MS bude chtít postavit na stranu vítězů a tvářit se, že není taková svině a že vlastně taky dělá ten open source. BTW: jednu dobu se MS snažil ostatní přesvědčit, že to on vynalezl Internet. Někteří pak prorokolali, že jednou bude MS tvrdit, že vynalezl open source. Zdá se, že ta doba právě přichází. Ale ani s tím Internetem mu na to lidi neskočili.
• MS nevydal celý framework, ale jen zlomek, „odlehčenou“ verzi. To se dá dobře využít ke klamání lidí – slovo „Core“ se dá přehlédnout, navíc novináři ledasco překroutí, takže se bude mluvit o tom, že „.NET je open source“.
• MS se to bude snažit využít k tomu, aby nalákal uživatele a pak je stáhl zase do bahna proprietárního softwaru – dříve či později ti jeho obchodníci začnou tvrdit, jak ti „Core“ verze nestačí a jak potřebuješ tu „plnou“, která už je ale proprietární a placená. Bude se snažit navodit iluzi toho, že open source je něco méněcenného – jen na hraní, pro začátečníky, malé firmy… zatímco pro seriózní použití je potřeba jejich proprietární verze. Duální licencování je v pořádku, stejně tak je v pořádku účtovat si za svoje služby peníze, ale tahle asymetrie ve funkčnosti/vlastnostech mezi otevřenou a uzavřenou verzí je zlo – snaží se vyvolat zcela nesprávný dojem – ve skutečnosti je to ale naopak: ta otevřená/svobodná verze je ta nejvyšší verze, jaká může být, protože ti dává nezávislost a plnou kontrolu nad tím softwarem – zatímco méněcenná je ta uzavřená, protože je záměrně zmrzačená a uživatel nedostává vše, co by dostat měl.

MS patří na černou listinu, ne mezi obchodní partnery a do slušné společnosti. U Adolfa Hitlera byste asi taky nenakupovali, kdyby si po Válce otevřel pekařství.

[frdrx]

j

[pavlix]

tak se MS bude chtít postavit na stranu vítězů a tvářit se, že není taková svině a že vlastně taky dělá ten open source.

A že to nebude poprvé. Ale jak to vypadalo, to víme.

MS patří na černou listinu, ne mezi obchodní partnery a do slušné společnosti.

Ve skutečnosti MS mezi obchodní partnery patří, protože je lze jen těžko ignorovat.

U Adolfa Hitlera byste asi taky nenakupovali, kdyby si po Válce otevřel pekařství.

Docela zajímavé přirovnání. Jednak si myslím, že kdyby to bylo jediné pekařství nebo by něčím jiným vynikalo (i kdyby jenom cenou), tak by nemělo o zákazníky nouzi. Ze zásady tam nenakupovat by představovalo nepříjemné stigma, které by se projevilo například ve chvíli, kdy tě kamarád požádá, ať mu tam pro něco skočíš. Většina zásadových by to vydržela jen nějakou dobu a pak by si prostě na situaci zvykli.

[Rezza]

Microsoft a obecne cely svet proprietarniho softwaru ma oproti nam velkou vyhodu v tom, ze muzou byt ciste pragmaticti. Kdyz se ukaze, ze neco dava smysl otevrit, tak to proste muzou udelat. My jsme si na sebe dobrovolne usili bic a branime se proprietarnimu softwaru a sluzbam. Nekdy je to slozitejsi, nemuzeme byt pragmaticti (oba svety existuji soucasne a nekdy proste je vyber tezky). Ale zase nas hreji na srdci idealy :))).

Jako je jasne videt, kam ti otevrenim MS miri - uz jsem to tu psal. Na ty nudisty. A odpovida to i jejich nove strategii - nez si hrat na vlastnim pisecku, lepsi je byt videt vsude.

[Grunt]

MS se to bude snažit využít k tomu, aby nalákal uživatele a pak je stáhl zase do bahna proprietárního softwaru – dříve či později ti jeho obchodníci začnou tvrdit, jak ti „Core“ verze nestačí a jak potřebuješ tu „plnou“, která už je ale proprietární a placená. Bude se snažit navodit iluzi toho, že open source je něco méněcenného – jen na hraní, pro začátečníky, malé firmy… zatímco pro seriózní použití je potřeba jejich proprietární verze. Duální licencování je v pořádku, stejně tak je v pořádku účtovat si za svoje služby peníze, ale tahle asymetrie ve funkčnosti/vlastnostech mezi otevřenou a uzavřenou verzí je zlo – snaží se vyvolat zcela nesprávný dojem – ve skutečnosti je to ale naopak: ta otevřená/svobodná verze je ta nejvyšší verze, jaká může být, protože ti dává nezávislost a plnou kontrolu nad tím softwarem – zatímco méněcenná je ta uzavřená, protože je záměrně zmrzačená a uživatel nedostává vše, co by dostat měl.

No popravdě řečeno, takhle dopadají všechny jazyky či technologie, které se snaží vyvinout a uzurpovat nějaká komerční firma. Tolik bahna jako když se člověk snaží pracovat s Javou jsem ještě nikdá neviděl a to Java patří rozhodně mezi ty lepší.

[xkucf03]

Můžeš to nějak rozvést? Používám OpenJDK, otevřené IDE, otevřené frameworky a knihovny, aplikační servery… v čem je problém?

[Grunt]

Přesně v tomhle. Rád bych dodal, že k OpenJDK tak jak ho známe dnes to trvalo kolik? 15 let od uvedení Javy? Máme tak 50 různých implementací JVM, některé proprietární, některé méně, 3 kompilátory, 3 různé edice včetně jakýchsi komunitních procesů, všelijaké (nepovedené) implementace, frameworky a bůh ví co. A to ještě nemluvím o tom, že se vlastně vede spor o to co to ta Java je podle toho kdo zrovna drží patenty a na specifikaci se radši snad ani neptám. Jako WTF? A kde to sme? Otevřený inkrementálně aktualizovaný standard, otevřená referenční implementace a hotovo. Bohatě by stačilo doplnit GNU Classpath do kompletnosti, zprovoznit GCJ (resp. GIJ pro nekompilující lidi), uživatel si doinstaluje libgcj (stejně jako si musí nainstalovat libc) a o že je v pozadí nějaká Java nebo kráva ani nemusí vědět. A všichni se s nějakýma implmentacema a edicema můžou jít bodnout. A to ještě jednou opakuju, že se furt bavíme o tom lepším. Jako některé koncepty fakt dobré, ale implementace teda pokulhává jak prase. Na takový bordel nejsem zvyklý. Ale co já vím, třeba jsem prostě moc rozmlsaný z OSS já. Platformy prostě nemám rád, protože víc než co jiného jsou to platformy pro biznis než co jiného.

[kralyk z abclinuxu]

+moc

[xkucf03]

Rád bych dodal, že k OpenJDK tak jak ho známe dnes to trvalo kolik? 15 let od uvedení Javy?

Patnáct ne. Java 1.0 vyšla v roce 1996, Sun vydal JVM pod GNU GPL v roce 2006, zbytek JDK pak v roce 2007.

RMS k tomu tehdy řekl:

I think Sun has contributed more than any other company to the free software community in the form of software. It shows leadership. It's an example I hope others will follow.

Ale hlavně: to že byl nějaký svobodný software kdysi uzavřený snad není jeho vada, ne? S tímto přístupem bys musel zavrhnout spoustu softwaru. Je naopak dobře, že se otevírají i dříve uzavřené věci – ne jen, že vznikají nové otevřené od samého začátku.

Díval bych se na to pozitivně: už přes osm let a přes tři hlavní verze je Java otevřená + OpenJDK je referenční implementace. Není to nějaká omezená edice nebo verze pro chudáky a začátečníky. U Javy je otevřené všechno – i ty nejvíc „enterprise“ věci, třeba aplikační servery nebo frameworky používané v bankách a telekomunikacích.

3 kompilátory, 3 různé edice včetně jakýchsi komunitních procesů, všelijaké (nepovedené) implementace

To přirozeně souvisí s tou otevřeností – stejně tak máme spousty GNU/Linuxových distribucí a mnohé z nich jsou nepovedené.

frameworky a bůh ví co.

A pro C, C++, Python, Perl a další nemáme nepřeberné množství knihoven a frameworků?

Otevřený inkrementálně aktualizovaný standard

Vždycky je potřeba nějaká autorita, která ten standard nakonec vydá, nemůže v tom být anarchie, protože potřebujeme jeden společný jazyk. Java má Java Community Process a tvorba tohoto standardu nefunguje vůbec špatně ve srovnání s procesem tvorby jiných standardů.

otevřená referenční implementace

Přesně to je OpenJDK.

a hotovo

Jak hotovo? Co si kdo napíše nad tím, jaké knihovny, frameworky, aplikace… to už je jeho věc – autoři jazyka/platformy to nemůžou nijak omezovat nebo regulovat.

Bohatě by stačilo doplnit GNU Classpath do kompletnosti, zprovoznit GCJ (resp. GIJ pro nekompilující lidi), uživatel si doinstaluje libgcj (stejně jako si musí nainstalovat libc) a o že je v pozadí nějaká Java nebo kráva ani nemusí vědět.

VM má svoje výhody. Ale souhlasím, že by bylo fajn dotáhnout i tu možnost kompilace do nativního kódu.

A všichni se s nějakýma implmentacema a edicema můžou jít bodnout.

Takže na klasickém „nechytrém“ mobilu s pár kilobajty paměti nebo dokonce na čipové kartě má běžet totéž, co na výkonných desktopech nebo na serverech? Desktopová platforma má mít podporu pro enterprise aplikace, když to vůbec není potřeba? Když si chci spustit jednoduchý CLI nebo desktopový program a nepotřebuji tam věci, které se používají na serverech?

Na takový bordel nejsem zvyklý. Ale co já vím, třeba jsem prostě moc rozmlsaný z OSS já.

Java ale je součástí toho OSS. Co tedy používáš? C, C++, Python, Perl, PHP…? Tam snad nejsou spousty knihoven a modulů?

[kralyk z abclinuxu]

Ale hlavně: to že byl nějaký svobodný software kdysi uzavřený snad není jeho vada, ne? S tímto přístupem bys musel zavrhnout spoustu softwaru. Je naopak dobře, že se otevírají i dříve uzavřené věci – ne jen, že vznikají nové otevřené od samého začátku.

...a přitom jsi výše přirovnal MS k Hitlerovi... Tyhle komentáře moc nechápu.

[xkucf03]

Ano, mezi tím, co dělal Sun a Microsoft, je velký rozdíl.

[Radek Miček]

A to?

[Grunt]

I think Sun has contributed more than any other company to the free software community in the form of software. It shows leadership. It's an example I hope others will follow.

Znovu opakuju, že Java je ještě ten lepší příklad. Jak musí vypadat .NET se radši ani neptam.

Ale hlavně: to že byl nějaký svobodný software kdysi uzavřený snad není jeho vada, ne? S tímto přístupem bys musel zavrhnout spoustu softwaru. Je naopak dobře, že se otevírají i dříve uzavřené věci – ne jen, že vznikají nové otevřené od samého začátku.

Já to jen a pouze porovnávám s věcma, které byly standardizovány a vyvíjeny jako otevřené už od počátku. Prostě v nich není tolik bordelu.

Přesně to je OpenJDK.

Jo. OpenJDK je fajn. Ale porovnej to třeba (bohužel s nekompletním) GNU Classpath. Tak to mělo vypadat.

Takže na klasickém „nechytrém“ mobilu s pár kilobajty paměti nebo dokonce na čipové kartě má běžet totéž, co na výkonných desktopech nebo na serverech?

A včil to porovnej s Linuxovým jádrem. To má také své edice (třeba uClinux, nevím jestli se pro Enterprise používá něco jiného než vanika), ale vdžycky je u něj ta snaha ty „edice“ asimilovat do mainline tak aby hlavní větev byla co nejuniverzálnější. Ono dokud člověk nevidí jak to dělají ostatní, tak si ani neuvědomuje jak dobře některé věci jsou implementované (jako třeba to Linuxové jádro). Si představ že by si měl Linux ME, Linux SE, Linux EE a každé by mělo své vlastní verze. A nebo si představ že by si měl ještě v kadžé verzi nějaké GUI implementované v podobě AWT, Swingu, Java FX – ježišku, ještě zlaté Qt/GTK.

Java ale je součástí toho OSS. Co tedy používáš?

Bohužel. A možná to má taky důvod, že se jí každý snaží vyhýbat co to jde.

[kralyk z abclinuxu]

Vzhledem k tomu, jaký je Java svět sám pro sebe, se hrozně divím, že si Javisti už dávno nenapsali nějaký svůj Java OS založený na filosofii Javy, ve kterém by si mohli všechny ty své věci provozovat. Protože v podstatě v každým OS je Java takový vetřelec (nejde moc dokupy se zbytkem systému), snad vyjma Androidu, kde si ale vše dělají po svém celkem nezávisle na zbytku světa Javy...

Zajímalo by mě, jestli na tom bude .NET/Mono v tomhle ohledu dobudoucna lépe, ale zatím mi přijde, že to tak vypadá. C++/CLI je sice takový trochu prasopes, ale stále mi to přijde příjemnější než JNI. Velmi slibně vypadá také CXXI.

[xkucf03]

Sice to není OS, jen desktopové prostředí, ale napsali – viz projekt Looking Glass. Steve Jobs kvůli tomu tehdy volal Jonathanovi Schwartzovi a vyhrožoval Sunu soudním sporem.

Koukni taky na JNode a JX. Případně Jazelle (spouštění javovského bajtkódu přímo na ARMových procesorech).

[Grunt]

Přesně tak. Looking Glass. Ale za sebe musím říct, že když jsem to zkoušel (má to LiveCD a běží to nad Linuxem), tak to vypadalo docela dobře.

Případně Jazelle

Jo a to mi pije krev. Proč sakra na x86 musím tu binární ludru emulovat ve VM? Tfuj tajcl, hnus zeleený jakýsi.

[pc2005]

Původní Jazelle byl pouze pro některé verze a byl značně uzavřený. Novější Jazelle (ThumbEE?) je obecný a vypadá to, že v AMRv8 už není. Myslím ale, že většina pozdějších ARMů ten java bytekód stejně emulovala přes softwarové rutiny (což je VM taky, ale o trochu víc lowlevel, asi jako když hypervizor emuluje zakázané instrukce).

BTW Co transmeta crusoe?

[petr_p]

To by dopadlo jako Smalltalk a Squeak. Jeden obrovský proces v kterém máte vše od dat přes aplikaci až po vývojové prostředí.

[mirec]

Hmm, Squeak je náhodou super. Skvelá hračka na odreagovanie sa a vyskúšanie si niečoho nového.

[petr_p]

Nového? Vždyť to je přes dvacet let stará věc. Mně se na tom právě nelíbí ta svázanost. Vývojář udělá změnu a uživateli dá celé zmražené prostředí, které si uživatel u sebe pustí. Nápadně mi to připomíná dnes tak oblíbený Docker. Je to jako, když si s javovou aplikací táhnete v instalátoru všechny závislé knihovny a navrch ještě celé JRE. Akorát že se Squeakem je to dotažené ještě dál – tam máte uvnitř i data. Vím, že tam je nějaký mechanismus pro přenos rozdílů mezi snímky virtuálního stroje, a zaznamenal jsem nějaké pokusy o jakési verzovací systémy, aby bylo možné šířit „patche“, ale moc v to nemám důvěru. Pro mne, jakožto člověka vyrostlého na linuxových distribucích, mi to přijde jako jeden velký nespravovatelný bundle. (Ostatně i dockerové obrazy se v seriózním provozu neřeší děděním, ale regenerováním z dockerfilu.)

[xkucf03]

+1

[mirec]

Nového pre mňa, nie nového v zmysle veku technológie. Samozrejme taký smalltalk je pomerne starý ale pre niekoho môže byť takýto prístup k OOP "nový".

[Grunt]

Protože v podstatě v každým OS je Java takový vetřelec

Myslím si že přirováním Javy k vetřelcovi naprosto v každém systému si to popsal naprosto dokonale. Aneb „nuff said“. A přitom by to vůbec nebylo nutné.

[mich]

Protože v podstatě v každým OS je Java takový vetřelec

Myslím si že přirováním Javy k vetřelcovi naprosto v každém systému si to popsal naprosto dokonale. Aneb „nuff said“. A přitom by to vůbec nebylo nutné.

Nemůžete kdyžtak rozebrat proč vám Java připadá v každém systému jako vetřelec? Oběma vám to přijde přesné, ale žádné argumenty jste k tomu nedali...Není to jen takový pocit lidí, co Javu vlastně ani neznají?

[pavlix]

Není pocit nejavistů v tomto ohledu mnohem relevantnější než pocit javistů?

[mich]

Řekl bych, že pocity obou tábotů jsou irelevantní. Argumenty, třeba nějaké příklady, by mi přišli zajímavější. Momentálně totiž ani nevím, o co vlastně kralykovi a Gruntovi jde.

[pavlix]

Řekl bych, že pocity obou tábotů jsou irelevantní.

Divné, když je to hlavní téma tvého příspěvku.

Argumenty, třeba nějaké příklady, by mi přišli zajímavější.

Nač plýtvat argumenty na něco tak očividného?

[mich]

Díky za věcnou diskusi pavlixi

[pavlix]

Poděkuj hlavně sobě ;).

[xkucf03]

Argumenty, třeba nějaké příklady, by mi přišli zajímavější.

Taky si myslím, že by nějaký argument neuškodil. Třeba proč je Java někde větší vetřelec než pythonovský/perlovský atd. program v OS/prostředí napsaném v C. Nebo třeba než GTK aplikace v Qt prostředí.

[Grunt]

No nic. Pod tíhou argumentů musím přiznat že od teď už mi Java jako vetřelec v každém systému nepřijde, že je to naprosto perfektně integrovaná součást. Přesvědčili jste mě. Není o čem diskutovat.

[mich]

Sarkasmus, výborně. Takže ty a kralyk přijdete s tvrzením: "Java je vetřelec", nevysvětlíte proč, a druhá strana má přijít s argumenty? Neměli yste nám spíš osvětlit co je na Javě tak vetřelcoidního? Samozřejmě stále předpokládám, že se snažíme rozumně diskutovat. Pokud ne, tak: PYTHON JE TELETUBBIES!

[Grunt]

Yup. Python je Teletubbies. Dospěli jsme ke konsenzu. Šťastní to lidé jsme.

[pavlix]

Třeba proč je Java někde větší vetřelec než pythonovský/perlovský atd. program v OS/prostředí napsaném v C.

V takovém prostředí (například OpenWRT) by se jistě dalo uvažovat o Pythonu jako o „vetřelci“.

Nebo třeba než GTK aplikace v Qt prostředí.

V takovém prostředí se GTK aplikace za „vetřelce“ pokud vím běžně považuje.

[Grunt]

V OpenWRT se běžně používá LUA a doinstalovat si interpret Pythonu a používat ho není nejmenší problém. Zkus to s Javou. Teoreticky by to mělo jít taky

[pavlix]

Dobře, Java by asi na OpenWRT byla větší vetřelec než Python, už jenom proto, že je to pořád ještě linuxová distribuce a ten Python se na ní používá (kdyby nic jiného, tak Turris je odvozenina s UI postaveným na Pythonu). Ale o to tu přece nešlo, že, mistr mich, po nás chce argumenty pro určitý subjektivní dojem a my jsme zcela selhali v povinnosti mu je poskytnout. Mistr xkucf k tomu zaregistroval klíčové slovo Java a na jeho základě se přepnul do věrozvěstného režimu a taky po nás chce ty argumenty. A my opět selháváme.

[xkucf03]

Hlavně že neselhává trh

[xkucf03]

Otázka byla: „proč je Java větší vetřelec než třeba…“

[Grunt]

Však říkám že Java není vůbec větší vetřelec než třeba Python, Perl, C++. Protože když použiju jakoukoliv aplikaci napsanou ve zmíněných jazicích, tak o tom hned vim. Prostě do systému nepasují, potřebují tahat půl tuny nenainstalovaných krámů, nepoužívají to co jim nabízejí standardní knihovny a tak se jim vyhíbám. To ale neplatí u Javy.

[pavlix]

Otázka byla: „proč je Java větší vetřelec než třeba…“

Reakce, že větší vetřelec nutně nemusí být, ti nepřijde dostatečně relevantní?

[kralyk z abclinuxu]

Otázka byla: „proč je Java větší vetřelec než třeba…“

1. GUI. Jednoznačně největší důvod. GTK i Qt považuju na linuxu v podstatě za nativní GUI frameworky a většina (i) non-nativních platforem má stejný názor (třeba python nebo ten zmiňovaný .NET (viz GtkSharp). Qt a GTK spolupracují mezi sebou celkem dobře a dají se nastavit tak, že vypadají stejně/skoro stejně. Aplikace v Javě obvykle vypadají jako prdel celkem bez ohledu na to, jestli autor zvolil AWT nebo Swing. Bindingy pro GTK a Qt AFAIK existují, ale málokdo je používá. Na nějakou konzistenci v barvách, ikonách, fontech, dialozích a DPI může člověk ve většině případů zapomenout.
2. Knihovny - nativní dependence se nenosí, Javovské programy si obvykle všechno přinesou s sebou v Javě.
3. Jiné technologie - příkladem budiž Java key store.
4. JVM je moloch - já vím, že to je hodně omletý argument, ale ona to je stále pravda. Štve mě, že kvůli asi 3 programům v Javě, které aktuálně potřebuju, musim mít nainstalováno >5 balíků Javy a že jednoduchý GUI prográmek startuje buhvíjak dlouho a zabere si přitom 150MB RAM. U CLI prográmků to je taky utrpení, třeba yui-compressor. Jako kdyby byl takový problém to napsat v něčem jiným...

[petr_p]

Rozdíl mezi pythonem/perlem a javou je, že z javy si nepošlete nebo nepřijmete posixový signál. Ostatně neuděláte skoro nic (kromě pár vyvolených síťových protokolů), co se týče nativní (z hlediska operačního systému) meziprocesové komunikace. Ostatní jazyky poskytují pohodlnou abstrakci, ale pořád máte přístup k operačnímu systému. (Ne že by tam problémy nebyly, třeba v Perlu nejsou doteď dořešené signály mezi posixovými vlákny, ale v principu operační systém je považován za vlastnost, ne za chybu.)

[xkucf03]

Ostatní jazyky poskytují pohodlnou abstrakci

Takže i na ne-POSIXových systémech to bude nabízet všechny POSIXové funkce? To asi ne.

ale pořád máte přístup k operačnímu systému

V Javě mám JNI a JNA. Díky tomu jde udělat v Javě cokoli. Tohle je spíš otázka, co bude ve standardní knihovně a co bude v knihovnách třetích stran. Java jde tou cestou, že standardní knihovna je spíš jednodušší a obsahuje to, co jsou její autoři schopní podporovat na všech platformách. To ostatní jde v Javě taky, jen to prostě není ve standardní knihovně.

V Javě můžu mít i třeba nativní Qt GUI…

Abych mohl volat nativní funkce, stačí mi v Javě díky JNA definovat rozhraní:

public interface POSIX extends Library {
    public int chdir(String filename);
    public int chmod(String filename, int mode);
    public int chown(String filename, int user, int group);
    public int rename(String oldpath, String newpath);
    public int kill(int pid, int signal);
    public int link(String oldpath, String newpath);
    public int mkdir(String path, int mode);
    public int rmdir(String path);
}

A pak ho napojit a použít:

POSIX posix = (POSIX) Native.loadLibrary("c", POSIX.class);
posix.chdir("/tmp");

[petr_p]

A právě proto je Java vetřelec.

Třeba se signály vám žádné JNI nepomůže, protože obsluhu signálů si uzurpuje JVM pro vlastní potřebu. Dokážu si představit, že existují knihovny, které vyrobí nový proces a přes něj budou používat signály, ale to jaksi už není ten samý proces, že.

[kralyk z abclinuxu]

Hm, to asi není úplně dobře, ale na druhou stranu na co signály? Ty jsou dobré max. tak na posílání ^C a ^Z v konzoli (nebo třeba sigusr1 v dd), ale na cokoli jiného - nedejbože třeba IPC - jsou celkem k ničemu.

Jinak ono přes to JNI by nejspíš šlo používat POSIX API a všelijaká další API, jen kdyby to v Javě někdo používal

[deda.jabko]

Jinak ono přes to JNI by nejspíš šlo používat POSIX API a všelijaká další API, jen kdyby to v Javě někdo používal

Proc by to nekdo pouzival, kdyz to do Javy nepatri? Tim, ze budes mit pres JNI prilinkovane POSIXove API, prichazis o prenositelnost... a ze zkusnosti mohu rict, ze casto i o doprednou kompatibilitu. Uz mockrat jsem videl, ze projekty pouzivajici JNI po par letech nesly prelozit, protoze prekladace C++ a souvisejici knihovny se za tu dobu vyvinuly v neco nekompatibilniho s puvodnim kodem.

[kralyk z abclinuxu]

Proc by to nekdo pouzival, kdyz to do Javy nepatri?

Tahle věta hezky podtrhuje toho "vetřelce". Non-Java věci se nepoužívají, protože "to do Javy nepatří"...

Tim, ze budes mit pres JNI prilinkovane POSIXove API, prichazis o prenositelnost...

Přenositelnost nemusí být priorita nebo se může nahradit multiplatformitou, což bývá někdy případ i Java aplikací. Jinak POSIX API je jen příklad, obecně jde o jakékoli non-Java API.

a ze zkusnosti mohu rict, ze casto i o doprednou kompatibilitu. Uz mockrat jsem videl, ze projekty pouzivajici JNI po par letech nesly prelozit, protoze prekladace C++ a souvisejici knihovny se za tu dobu vyvinuly v neco nekompatibilniho s puvodnim kodem.

Problémy s dopřednou kompatibilitou se týkají více či méně v podstatě čehokoli, vč. čistě Java projektů...

[deda.jabko]

Přenositelnost nemusí být priorita

A co kdyz je?

Problémy s dopřednou kompatibilitou se týkají více či méně v podstatě čehokoli, vč. čistě Java projektů...

Java je zpetne/dopredne kompatibilni az v to nekterych ohledech neni hezke, protoze v zajmu zachovani zpetne kompatibility musela byt udelana rada kompromisu v novych verzich. Programy, ktere byly psane pro Javu 1.2, 1.3 mi dneska v pohode bezi na Jave 1.8 a neni problem je zaclenit jako soucast do dnesnich programu s tim, ze prekladac pouze rve warningy. Na druhou stranu programy, co byly napsany s vyuzitim JNI, kvuli primemu pristup k OS, mi dnes vetsinou ani nejdou prelozit, protoze C++ a souvisejici knihovny se vyvinuly v neco nekompatibilniho.

[kralyk z abclinuxu]

A co kdyz je?

Pak dočti větu do konce?

Programy, ktere byly psane pro Javu 1.2, 1.3 mi dneska v pohode bezi na Jave 1.8 a neni problem je zaclenit jako soucast do dnesnich programu s tim, ze prekladac pouze rve warningy.

O tom to ale není. Nejnovější GCC nebo Clang ti taky přeloží C++98. Problém je v dependencích. I v Javě se mi stávalo, že jsem musel patchnout kód, protože se změnila nějaká závislost. Tomu se nevyhneš nikde.

Na druhou stranu programy, co byly napsany s vyuzitim JNI, kvuli primemu pristup k OS, mi dnes vetsinou ani nejdou prelozit, protoze C++ a souvisejici knihovny se vyvinuly v neco nekompatibilniho.

C++ se v "něco nekompatibilního" nevyvinulo už hezkou řádku let, zhruba od doby, kdy má standard. Jestli ono se spíš nevyvinulo JNI, OS nebo nějaké 3rd party knihovny.

[Radek Miček]

C++ se v "něco nekompatibilního" nevyvinulo už hezkou řádku let, zhruba od doby, kdy má standard.

Viz třeba What breaking changes are introduced in C++11?

Navíc ani různé C++ překladače nemusí být vzájemně kompatibilní, tudíž používat nativní C++ knihovny nemusí být snadné ani z C++.

[kralyk z abclinuxu]

C++ se v "něco nekompatibilního" nevyvinulo už hezkou řádku let, zhruba od doby, kdy má standard.

Viz třeba What breaking changes are introduced in C++11?

Ok, díky za info. Je fakt, že ty keywordy mě měly napadnout, to je celkem zjevná změna.

Nicméně třeba u GCC nebo Clang je přepínač -std=..., že, s kterým by tohle neměl být problém...

Navíc ani různé C++ překladače nemusí být vzájemně kompatibilní, tudíž používat nativní C++ knihovny nemusí být snadné ani z C++.

To je pravda, když lidi používaj všlijaká nestandardní rozšíření, je problém. Dále problémy s ABI, že...

Btw. různé překladače/VM Javy kompatibilní jsou?

[deda.jabko]

Btw. různé překladače/VM Javy kompatibilní jsou?

Naprosto bezne a bez problemu. (Napr. Eclipse ma svuj vlastni prekladac a vygerenovany JBC jde pouzit na libovolnem JVM s kodem prelozenym jinymi prekladaci.)

Java ma vcelku rozsahlou sadu testu (JCK), kterou musi implementace projit, aby dostala certifikaci. Coz u ostatnich jazyku je vcelku rarita.

[radix]

AFAIK Eclipsi prekladac je normalni javac z OpenJDK s nejakou sadou patchu - jedinou zmenu jsem videl v tom, ze Eclipsi prekladac je schopen castecne prelozit i tridy, kde jsou chyby, kdezto normalni javac neprelozi nic.

[deda.jabko]

AFAIK Eclipsi prekladac je normalni javac z OpenJDK s nejakou sadou patchu

Neni. Schvalne jsem se ted dival do zdrojaku ECJ a vsude je tam puvodni copyright IBM, nic od SUNu/Oraclu. Logicky to dava smysl, kdyz Eclipse tu byl spoustu let pred otevrenou Javou a Eclipse je pod EPL a ne GPL.

[radix]

Mea culpa, mas pravdu. Tak nevim, kde jsem tuhle famu slysel/cetl. Nicmene to pekne ukazuje, ze ejc a javac jsou velmi dobre kompatibilni.

[kralyk z abclinuxu]

gcj je kompatibilní s javac?

[radix]

To nevim. S novymi verzemi Javy urcite ne. Nastesti to neni problem, protoze gcj *nikdo* nepouziva.

[xkucf03]

Ty jsou dobré max. tak na posílání ^C a ^Z v konzoli

Na Ctrl+C můžeš zareagovat takto:

Runtime.getRuntime().addShutdownHook(new Thread() {
    @Override
    public void run() {
        System.out.println("Uživatel stiskl Ctrl+C / končí program");
    }
});

A Ctrl+Z uspí javovský program jako kterýkoli jiný.

[petr_p]

Kdyby SIGINT se řešil stejně, jako níže uvedený SIGHUP, tak budu zticha. Tento kód ale vůbec neobsluhuje SIGINT. To je právě ta vetřelecká technika, která dělá z javové aplikace aplikaci druhé třídy, která nemá stejné možnosti, jako nativní aplikace.

Já chápu, že každý virtuální stroj více či méně staví hráz mezi aplikaci a systém a že výsledné možnosti jsou kompromis. V tomto směru každá nenativní aplikace je menší nebo větší vetřelec. Java mi ale ve srovnání s Perlem nebo Pythonem přijde jako mnohem větší vetřelec.

[xkucf03]

A právě proto je Java vetřelec.

Nějak mi není jasné, co v mém komentáři je to „právě proto“…

Nicméně signály můžeš zpracovávat v Javě takto:

SignalHandler sh = new SignalHandler() {
	@Override
	public void handle(Signal sig) {
		System.out.println("Zachycen signál: " + sig);
	}
};

Signal.handle(new Signal("HUP"), sh);
Signal.handle(new Signal("USR2"), sh);

A co se týče volání nativních funkcí – jaký pohodlnější způsob by sis představoval? Nemuset deklarovat ani to rozhraní? Jasně, šlo by jen někam napsat název volané funkce bez jakékoli přípravy a dynamicky to spustit. Ale v Javě prostě není zvykem střílet od boku a doufat, že na sebe nějaké dva textové řetězce budou pasovat. A to je podle mého dobře a přispívá to ke spolehlivějším programům a efektivnějšímu vývoji.

[Delaunay]

Je to sice již poměrně dlouho co jsem SignalHandler použil, ale zřetelně si pamatuji, že byl umístěn v balíku sun.misc, tzn. nejednalo se nikdy o oficiálně podporovanou ani povinnou součást JVM.

[xkucf03]

Ano, tyhle konkrétní třídy jsou bohužel v sun.misc a třeba pomocí GCJ to přeložit nejde, ale už to, že tyto třídy existují dokládá, že zpracování signálů v Javě možné je – když nemůžeš použít sun.misc, tak si ty nativní funkce můžeš zavolat sám pomocí JNI, nebude v tom žádná magie, nic, co by nešlo. Resp. stačí zavolat z nativního kódu metodu v Javě, což lze.

[xkucf03]

A včil to porovnej s Linuxovým jádrem. To má také své edice (třeba uClinux, nevím jestli se pro Enterprise používá něco jiného než vanika)

Moc ne – v běžném „enterprise“ se používá běžné jádro, třeba nějaké standardní z RedHatu nebo jiné distribuce. Pokud má někdo farmu o tisících serverech nebo speciální HW, tak si tam asi přeloží něco vlastního a optimalizuje. Nebo nějaké RT… ale většina pojede na standardních distribučních jádrech.

ale vdžycky je u něj ta snaha ty „edice“ asimilovat do mainline tak aby hlavní větev byla co nejuniverzálnější.

Co se týče Javy SE a Javy EE, tak tady v tom není problém. Java EE je soubor API předepsaný specifikací, které má poskytovat aplikační server (JBoss, GlassFish atd.), ale celé to běží nad úplně standardní Java SE JRE. Tzn. zjednodušeně řečeno Java EE = Java SE + nějaké API a knihovny navíc. A smysl je v přenositelnosti – píšeš enterprise aplikaci pro platformu Java EE a ta pak bude chodit na všech aplikačních serverech, které vyhovují specifikaci. Tenhle princip je v Javě obecně dost silný: specifikace/rozhraní + jedna nebo víc implementací. A ty implementace můžeš měnit jen pomocí konfigurace a aplikace zůstávají stejné, protože pracují s tím rozhraním, abstraktním API.

Něco jiného je Java ME a JavaCard, ty jsou hodně osekané a dost jiné – ty věci z Javy SE/EE těžko nacpeš do starého mobilu nebo na malou kartičku (třeba SIMku – i když dneska možná i ano, na SIMce se dneska dá provozovat i webový server…) a na druhou stranu: stylem jakým se programují ty karty bys asi nechtěl psát na plnohodnotném počítači.

Si představ že by si měl Linux ME, Linux SE, Linux EE a každé by mělo své vlastní verze.

Linux je jen jádro, to je více méně stejné, ale když se budeme bavit o celém operačním systému, tak něco takového tu už dávno je. Můžeš mít holý Linux a uvnitř něj spustit jeden program, třeba Emacs. Nebo můžeš mít Linux + Busybox. Nebo Linux + GNU (nejčastější varianta). Nebo GNU/Linux a nad ním třeba systemd, nebo ještě KDE nebo Gnome, nebo Enlightenment. Můžeš tam mít zakompilované různé moduly, třeba pro podporu různých FS. Různé POSIX věci, všelijaké API a služby, šifrovací algoritmy, plánovače, různé démony…. Ta variabilita je… nekonečná. Oproti tomu je volba Java SE vs. Java EE (případně ME, JavaCard) ještě zlatá.

A nebo si představ že by si měl ještě v kadžé verzi nějaké GUI implementované v podobě AWT, Swingu, Java FX – ježišku, ještě zlaté Qt/GTK.

Java je tu osmnáct let, změnit za tu dobu jednou API pro GUI, to není zase taková tragédie. Ono aplikace psané pro staré Qt nebo staré GTK na tom dnešním taky jen tak nerozchodíš a musíš je portovat. Java FX je spíš něco jako QML vůči Qt.

Tady je taky vidět odlišný přístup – Qt se jmenuje pořád Qt, GTK se jmenuje pořád GTK, i když jsou oproti starým verzím hodně jiné a nekompatibilní. Kdežto v Javě se stará verze jmenuje AWT a nová Swing. Ale zase ti i dneska bude chodit aplikace, kterou jsi napsal před patnácti lety.

A možná to má taky důvod, že se jí každý snaží vyhýbat co to jde.

Každý ne, ale jsou takoví, to připouštím. Za tohle můžou jednak autoři aplikací a jednak si za to může Java taky trochu sama – pomalejším startem VM. Je to v zásadě už minulost, ale hodně lidí si toho ještě nestihlo všimnout. Moje javovské aplikace se dokáží za 300 ms spustit, udělat něco užitečného a ukončit proces. To je celkem slušné. Mohlo by to být lepší, ale tyhle časy jsou už přijatelné i pro interaktivně spouštěné příkazy v konsoli.

[Lol Phirae]

píšeš enterprise aplikaci pro platformu Java EE a ta pak bude chodit na všech aplikačních serverech, které vyhovují specifikaci.

Tak určitě...

[xkucf03]

a) aplikace neodpovídá specifikaci b) aplikační server neodpovídá specifikaci

Ale jestli máš nějakou variantu c), tak jsi ji klidně mohl napsat místo těch smajlíků.

[Lol Phirae]

a) aplikace neodpovídá specifikaci b) aplikační server neodpovídá specifikaci

Ano, jistě. Přičemž a) a/nebo b) nastane cca v 99,9999% reálných příkladů, takže je to celé k hovnu, ale jinak teoreticky určitě výtečně vymyšlené.

[xkucf03]

Pokud nastane b), měl by aplikační server přijít o certifikaci nebo rychle vydat opravu. Pokud nastane a) může si za to programátor aplikace sám, nemá se vymlouvat na Javu. Je to asi jako když někdo píše bashismy a pak se diví, že jeho skripty nefungují s libovolným /bin/sh.

[Lol Phirae]

Pokud nastane b), měl by aplikační server přijít o certifikaci nebo rychle vydat opravu. Pokud nastane a) může si za to programátor aplikace sám, nemá se vymlouvat na Javu.

A mezi tím nám jak hadr na holí lítá uživatel (zákazník), kterého střídavě posílají do zadele jak autoři JRE/aplikačního serveru, tak autor aplikace. První s tím, že si má nainstalovat novou verzi, že stará je už nepodporovaná, druhý s tím, že nová verze je moc nová a proto nepodporovaná. Opravdu skvělé. A mimochodem, čo si tak predstavujete pod takým termínom "standardní Java SE JRE", Kefalín? Nic takového neznám, a jinak ten "standard" rozbíjí v poslední době prakticky každá bezpečnostní záplata toho děravého monstra.

[xkucf03]

Java Language and Virtual Machine Specifications

[Lol Phirae]

Java Language and Virtual Machine Specifications

Hmmm, a co s tímhle mám jako zákazník/uživatel pendlující mezi děravou Javou a nefunkční aplikací dělat?

[xkucf03]

Přejít na COBOL, ten už moc děravý není, nebo je děravý pořád stejně a moc aktualizací pro něj nevychází.

[pc2005]

Třeba VHDL, vyvinula ho armáda USA .

[Peter Fodrek]

To si vyaduje doplnenie

Microsoft shocker: Open-source .NET, free Visual Studio, support for Linux, Mac, Android and iOS

by Todd Bishop on November 12, 2014 at 7:32 amNovember 12, 2014 at 3:59 pm

In a major strategy change designed to expand its horizons in the cloud, Microsoft will take its key software development technologies into areas that the company has long considered enemy territory — giving developers new ways to use .NET and

Visual Studio to make software not just for Windows but also for Linux, Mac OS X, iOS and Android. http://www.geekwire.com/2014/net-visual-studio-microsoft-open-source-cross-platform/

[Rezza]

Hodne tim asi miri na ruzne rubisty, railist, nodisty a dalsi. Protoze rikaji, ze podpora Macu je tam hlavne pro vyvojare, ne jako cilova platforma :).

[KOLEGA]

Já už četl ... "nudisty" :D

[Rezza]

Ty taky!

[zatkowich]

videl uz niekto horsiu sadu kniznic? u mna tato to vyhrava v tom, ze pre beh 1 programu o velkosti 2mb je potrebne mat nainstalovane asi 4gb hnoja, a mal som "stastie" chvilu robit v tych zgrcnutych MS jazykoch, ako C#, C++ a "managed" code - nikdy viac, stalo ma to tolko nervov, ako obycajny program za polroka

[skunkOS]

Specifikace C# jako taková je IMHO velmi, velmi povedená, syntakticky to zkrátka dává smysl. Zabalastěnost API a objemnost knihoven je věc jiná.

[zatkowich]

s tym suhlasim. lenze v praxi to je nanic ;)

[BigBoss]

IM Hovno?

[deda.jabko]

Specifikace C# jako taková je IMHO velmi, velmi povedená, syntakticky to zkrátka dává smysl.

To platilo tak do verze C# 2.0. Pak se urvali z retezu a zacali pridavat kde co. Hlavne ,,vychytavky'' kvuli Linq docela zprznily cely jazyk.

[j]

Mno a to jeste pak zjistis, ze neni .NET jako .NET ... treba kdyz chces, aby tvoje appka chodila na win ce ...

[zatkowich]

to uz nastastie nezistim

[maras]

Komentáře zase stojí za to, co vlastně chcete? Nejdřív búúú, MS kašle na linux, pak když už se něco začne dít (a je jedno v jakém rozsahu), tak zase búúúú, ať jde MS k šípku, stejně jejich technologie za nic a na linuxu o ně nikdo nestojí, což je mmj v kontrastu vůči existenci Mono projektu). MS evidentně není tak zabedněný, podporou linuxu nesleduje nic jiného, než zvýšení tržního podílu (proč podporuje office na iOS a MACOS, proč se zabývá podporou linuxu v Azure?), a obávám se, že to místní prskalové budou muset akceptovat.

[skunkOS]

A já to akceptuju. Co mě sere je fakt, že každý novinář z toho udělá mega událost ".NET bude open source". Hovno! Zveřejnili ubohý zlomek .NET. Ale sdělovacím prostředkům stačí i to hovno, aby z toho udělali message of the year.

[Rezza]

No ale i ta cast muze byt pro spoustu lidi uzitecna.

[pavlix]

Komentáře zase stojí za to, co vlastně chcete?

Chceme aby šel MS k šípku, vždyť jsi to sám napsal.

obávám se, že to místní prskalové budou muset akceptovat.

Nejenom místní, nejenom prskalové a nejenom pozici a chování microsoftu ;).

[frdrx]

IMHO jde Microsoft celkem zřetelně nejen k šípku, ale i pod šípek.

[pavlix]

Tím lépe.

[odin]

Jak se to prosim v praxi projevuje? Nejsem zadny zastance microsoftu a svobodny software pouzivam a mam celkem rad, ale opravdu jsem si nevsiml, ze by mel microsoft nejake problemy. To, ze racionalizuji naklady a optimalizuji lidske zdroje, nepovazuji za problem, ale za rozumny a nutny krok, ke kteremu obcas dojde u kazde vetsi spolecnosti, protoze pokud by nedoslo, tak by teprve nastaly problemy.

[frdrx]

Třeba na mobilním poli drsně zaspal a jeho snahy zatím nikam nevedly. Office stagnuje zatímco LibreOffice drsně dotahuje. S Windows to jde od 9 k 5. Vázaný prodej počítačů s licencí na Windows je v ohrožení, minimálně v EU. Stejně tak je v ohrožení výše příjmů Microsoftu z Androidu. Málokterá ze snah Microsoftu přinést na trh něco nového svého, třeba Bing, Zune nebo telefonní OS, má kýžený efekt. Firmy která Microsoft koupí zpravidla začnou klesat na významu, namátkou Nokia nebo Skype. Nejsem odborník na Microsoft, ale z toho co se ke mně dostalo mám pocit, že se postupně jeho význam vytrácí.

[Václav "Darm" Novák]

S Azure se jim naskočit do rozjetého vlaku povedlo. Skype možná nemá už takový význam v normální komunikaci, ale zdá se že MS ty techlogie používá v další verzi Lincu, který je ve svém oboru dost populární.

[frdrx]

Dílčí úspěchy, které zašlou slávu MS neobnoví.

[David Jaša]

Tak nějak. IMHO Microsoft směřuje k tomu, aby se stal normální firmou - jednou z mnoha.

[frdrx]

Třeba mu to prospěje.

[Rezza]

A aktualne jim to prospiva, staci se podivat vedle do sloupecku piseme jinde: "Microsoft sesadil Exxon z pozice druhe nejvetsi firmy v USA". Zatim to vypada, ze meli stastnou ruku s vyberem CEO a dalo se to cekat, ze to bude nekdo presne opacny Ballmerovy.

[frdrx]

No to ale bylo tím, že Exxon klesnul, ne tím, že by Microsoft povyrostl. Podle mě jejich pozici už ani nový CEO nedokáže udržet.

[xkucf03]

Nejdřív búúú, MS kašle na linux

Na to si fakt někdo někdy stěžoval? Od MS Windows jsem přešel dobrovolně a za lepším, nestojím o to, aby se mi MS programy cpaly i do mého operačního systému, natož abych se o ně doprošoval.

MS evidentně není tak zabedněný

Zabedněný, nezabedněný, dokud měli svojí pozici jistou a zákazníky pevně v hrsti, tak se na nikoho jiného neohlíželi. Naopak se všechny ostatní snažili zadupat do země a poškodit.

podporou linuxu nesleduje nic jiného, než zvýšení tržního podílu (proč podporuje office na iOS a MACOS, proč se zabývá podporou linuxu v Azure?

To, co se v MS děje teď, není nějaké dobro nebo prozření, ale jen důsledek toho že jim ujel vlak, jejich byznys model se zhroutil a na mrtvém koni už nejde jet, ani když se o jeho oživení bude snažit sto padesát obchodníků. Tohle jsou už jen dojezdy (i když v takových janouškových republikách, jako je ČR, můžou státní správu dojíždět ještě pár let). Chování Microsoftu nápadně připomíná převlékání kabátů po různých revolucích a převratech. Ale převléknutím kabátu se člověk ještě nestane demokratem, árijcem, komunistou nebo antikomunistou… jen se tak bude snažit vypadat.

[marek]

Nechápem prečo sa tu niektorí tak rozčulujú. Či tam už OpenSource nie je zaujiamvé? Podľa mňa je to výborná správa. .NET framework je dobre popísaný, C# je zdá sa dosť popredu voči Jave: (http://www.wikiwand.com/en/Comparison_of_C_Sharp_and_Java).
Aha, ale to je od Microsoftu, tak to musí byť zlé, už len preto že je to Microsoft??

Podľa mňa to Microsoft urobil preto, aby získal väčšie percento v mobilnej sfére. (Zapadá mi to ďalších krokov v tej istej línii):

- Sprístupnenie Visual Studia 2013 Community pre malé firmy a nezávislých vývojárov.
- Zrušenie ročného platenia za držanie aplikácie vo Windows Store
- premenovanie niektorých Nokia telefónov na Microsoft telefóny

Postupne sa možno otvorí aj celá časť .NET et Java bude mať konečne konkurenciu. A namiesto patentového trollovania sa začne Oracle viac starať o zdedené vajíčko Sunu.

[pavlix]

Nechápem prečo sa tu niektorí tak rozčulujú. Či tam už OpenSource nie je zaujiamvé? Podľa mňa je to výborná správa. .NET framework je dobre popísaný, C# je zdá sa dosť popredu voči Jave: (http://www.wikiwand.com/en/Comparison_of_C_Sharp_and_Java). Aha, ale to je od Microsoftu, tak to musí byť zlé, už len preto že je to Microsoft??

Co to je zase za kecy. Ne každý musí milovat Javu a tedy ne každý musí milovat něco, co je (údajně) napřed. Stejně jako ne každý musí milovat všechno, co je (údajně) open source, ale ani všechno, co vypadne z Microsoftu. Dotnet je jistě velmi zajímavá platforma, která navíc měla už dlouhou dobu alternativní linuxovou implementaci a lidem, kteří ji chtějí používat opensourcování jakékoli části jistě pomůže, ale to přece neznamená, že se všichi posadíme na prdel z toho, že někdo vydal nějaký open source kód.

[odin]

která navíc měla už dlouhou dobu alternativní linuxovou implementaci

Uff. To myslite vazne? Kdyz o necem reknu, ze je to alternativa, predpokladal bych, ze obe moznosti budou rovnocenne. Staci se podivat na to, co mono neumi a ani neplanuje implementovat. Nejsem zadny zastance .netu, to ani omylem, ale nechci si nalhavat, ze je zde open source alternativa, protoze jednoduse neni.

[pavlix]

Podle toho, co tu píšou někteří jiní, dost možná není opensourcovaná část dotnetu naopak v tomto smyslu alternativou Mono.

[odin]

To je klidne mozne, ale pokud se bavime o klasickem .net vs mono, tak je vitez bohuzel jasny a to bez debat :(

[pavlix]

Musím říct, že je mi to upřímně dost jedno, obojímu jsem se dosud dokázal úspěšně vyhýbat.

[jdsulin2]

Zde bych vinil Javu. Kdyby byla Java kdysi davno otevrena, tak MS by .Net nepotreboval. Vemte si jake problemy mel (a mozna jeste ma) soucasny Android s patenty Javy :)

[xkucf03]

To jsou spíš problémy způsobené americkým právním řádem a soudnictvím – v zemi neomezených možností se pořád někdo s někým soudí a armády právníků jsou vysílány do bitev.

[Honza Jaroš]

To že se tehdy Sun bránil proti microsoftím úpravám JVM, které by vedly k omezení přenositelnosti aplikací mezi platformami, považuji za prospěšné a divím se, že zrovna na tomto portálu to někdo kritizuje.

[Ovoce]

Android nemá problém s patenty na Javu.

IIRC je to to tom, že Android sám o sobě nepoužívá Javu, ale cosi jako její nekompatibilní fork. Zároveň ale obšlehl její API, a proto se proti tomu Oracle soudí (jde o copyrightový, ne patentový spor).

[Honza Jaroš]

Mono tu je už nějakých 13 let určitě a nevím jak teď, ale v době vydání jedničkové verze ta centrální část fungovala jakž takž dobře (z mého pohledu vydali první "ostrou" verzi předčasně, ale pak na opravách docela zamakali). Co fungovalo hůř byly funkce pro GUI apod. protože nebyly nezávislé na platformě, takže se to flikovalo jinými způsoby.

Pokud dobře chápu zprávičku, Microsoft nyní vydal to, co už dávno dělalo Mono a ty části, s nimiž mělo Mono problémy, jsou zase uzavřené. Čili pokud se C# v Linuxu dosud nechytlo, docela by mě překvapilo, pokud by tomu najednou bylo jinak...

Podtrženo a sečteno: tohle vydání konkurenci pro Javu vcelku nijak nezvýší. Jo, pokud by to otevřeli celé, byla by to jiná...

[odin]

Java, podle mne bohuzel, za .net celkem zaostava. A o monu se rozhodne neda rict, ze by bylo pouzitelne pro komercni veci. Snazil jste se pod nim nekdy rozjet neco serveroveho? Vzdyt delat tam jen obycejne wcf je totalni opruz. O podpore wsdl ani radeji nemluvim. Mono opravdu nemuze ms .netu konkurovat, zatim.

[Honza Jaroš]

Hmm, podíval jsem se na ten odkazovaný článek a zprávička mi připadá poněkud zavádějící, protože slovy .NET Core obsahuje malé běhové prostředí pro .NET aplikace a základní knihovnu tříd si určitě nepředstavím ASP.NET, o které ve skutečnosti jde. V tom případě je to jiná, sice jsem se naposledy pokoušel něco dělat s Monem někdy před deseti lety, ale souhlasím, že minimálně tehdy bylo ASPčko děs a hrůza.

[Honza Jaroš]

Před slovy mi vypadlo pod, ale to je asi zřejmé.

[radix]

C# je dnes lepsi jazyk nez Java, to jo. Ale jako platforma mne Java pripada stale silnejsi ...

[xkucf03]

C# je dnes lepsi jazyk…

Vážně? AFAIK tam pořád nemají ani kontrolované výjimky.

[radix]

Coz je dobre. Checked exceptions prasi kod, dokonce nekolik zpusoby:

- vsechny metody "throws Exception". Vyznam checked exception 0

- metody "throws IOException, JsonProcessingException, ParseException" - typicky zmena implementace meni signaturu (kontrakt) metody. Vyznam 0, praseni interface 100.

- implementace metod checked vyjimky chyta, zaloguje, a vyhodi vys, typicky jako jinou checked exception - spousta kodu na nic, vicenasobne logovani

- implementace metod opet chyta vyjimky a zabaluje je to RuntimeException a vyhazuje dal - to pouzivam ja, kdyz musim s checked exceptions pracovat

Vyjimky se obecne deli na dva druhy - ty, ktere se zachytavat nemaji - casto programatorska chyba nebo proste rozumne neosetritelny stav (krome zapisu do logu, vyhozeni chyby uzivateli apod.) Takove vyjimky obecne nechytame (az na nejake globalnejsi exception handlery)

Druhy typ jsou osetritelne vyjimky - pro tyto vyjimky mame nejake osetreni - vime, jak na to reagovat. Takove vyjimky chytame nekde pomerne blizko k misto, kde se vyhazuji.

Problem ale je, ze to jestli je vyjimka osetritelna nebo ne, nema rozhodovat jeji autor, ale klient toho API. Kdyz volam IO operace, tak vim, ze muze dojit k nejakemu IO problemu, ale jedine co v takovem pripade chci delat je, aby aplikace spadla, protoze nemam jak na to jinak reagovat. Ale IOException mne nuti, abych psal X radku naprosto boilerplate kodu, ktery vysledek jen zneprehlednuje.

[deda.jabko]

vsechny metody "throws Exception". Vyznam checked exception 0

Jo, to jsem si taky myslel, do te doby, nez mi pri predavani program v C# spadl na exotickou vyjimku, ktera se mohla objevit jen za urcitych okolnosti pri zapisu na sitove disky, a ktera byla ocekavana zhruba asi jako spanelska inkvizice.

typicky zmena implementace meni signaturu (kontrakt) metody

Pokud nechas probublat ven interni problemy je to tvuj problem.

implementace metod checked vyjimky chyta, zaloguje, a vyhodi vys

Tohle nechapu. Toto jako s unchecked vyjimkama nejde nebo se nedela?

Druhy typ jsou osetritelne vyjimky - pro tyto vyjimky mame nejake osetreni - vime, jak na to reagovat. Takove vyjimky chytame nekde pomerne blizko k misto, kde se vyhazuji.

A na to jsou prave checked vyjimky. Je to zpusob, jak manifestovat, ze metoda muze skoncit jinak nez ocekavanou navratovou hodnotou.

Kdyz volam IO operace, tak vim, ze muze dojit k nejakemu IO problemu

Ono je to jen malinko jinak... protoze ty jen tusis, ze muze dojit k nejakemu problemu, unchecked vyjimky ti udavaji, ze k tomu problemu opravdu muze dojit a vnitrni kod vyvola vyjimku.

Teoreticky protipriklad: ono se totiz mohlo stat, ze nekdo IO naprogramoval tak chytre, ze vsechny operace problem tise ignoruji a tys mohl s timto resenim pocitat.

[kralyk z abclinuxu]

Jo, to jsem si taky myslel, do te doby, nez mi pri predavani program v C# spadl na exotickou vyjimku, ktera se mohla objevit jen za urcitych okolnosti pri zapisu na sitove disky, a ktera byla ocekavana zhruba asi jako spanelska inkvizice.

Hmm, takže s checked exceptions se ti nemůže stát, že ti do té funkce odněkud probublá nějaká jiná výjimka?

[deda.jabko]

Muze, ale takto vim, ze ji mam cekat a muzu ji osetrit.

[kralyk z abclinuxu]

Já měl na mysli někde odspod z nižších vrstev stacku. Dejme tomu, že máš funkci void foo() throws EA, EB , která vevnitř volá x dalších funkcí na y dalších objektech, třeba. Je možný, aby jedno z těch volání vyhodilo EC? A co by se stalo, pokud ano?

[deda.jabko]

Pokud je EC checked vyjimka, tak takovy kod nepujde prelozit, protoze pak i foo() musi mit deklarovane throws EC.

Pokud je EC unchecked vyjimka, dedici z RuntimeException, pak ji neni potreba deklarovat. To je typ vyjimek, ze kterych se bezne nezotavuje, protoze jsou vysledkem nejake chyby v programu, napr. NPE.

[kralyk z abclinuxu]

Pokud je EC checked vyjimka, tak takovy kod nepujde prelozit, protoze pak i foo() musi mit deklarovane throws EC.

To mi moc nejde dohromady s tou diskusí o generikách níže (kompilátor nezná generický typ) + tuším má Java nějakou reflexi (vzpomínám se, že jsme v jakémsi školním projektu někde vytvářeli novou třídu z jejího jména)... Ale dobře dejme tomu, že to asi není moc pravděpodobné...

Ok, takže shrnutí: Při posuzování čistě z definice funkce, funkce bez specifikace výjimek může a nemusí vyhodit jakoukoli exception. Funkce se specifikací může a nemusí vyhodit jakoukoli unchecked exception, kteroukoli checked exception ze seznamu, ale dost pravděpodobně nevyhodí jinou checked exception (tj. zejména jestliže nepoužívá generika a není vevnitř nějak zprasená reflexí nebo nějak jinak).

Jestli to je užitečné, ať si posoudí každý sám, jednoznačný objektivní benefit tam ale nevidím. Stejně si člověk musí vždycky přečíst dokumentaci k cizím rozhraním včetně toho, kdy mohou nastat neplatné stavy a co se pak děje...

[deda.jabko]

To mi moc nejde dohromady s tou diskusí o generikách níže (kompilátor nezná generický typ)

Kompilator typovy parametr u genericky trid zna! Behove prostredi jej nezna.

tuším má Java nějakou reflexi

Ano, Java reflexi ma, ale nevim, jakou to tu hraje roli...

funkce bez specifikace výjimek může a nemusí vyhodit jakoukoli exception

Ne, funkce bez specifikace vyjimek muze vyhodit pouze unchecked vyjimky.

ale dost pravděpodobně nevyhodí jinou checked exception

Ne, nevyhodi na 100% zadnou jinou checked exception, nez tu, ktera je ve vyctu. Pokud bys tam pouzil reflexi bude i checked vyjimka zabalena do unchecked.

Generika na to nemaji zadny vliv, tam jsou vyjimky odvozene z typoveho parametru.

Stejně si člověk musí vždycky přečíst dokumentaci k cizím rozhraním včetně toho, kdy mohou nastat neplatné stavy a co se pak děje...

Ten benefit je v tom, ze prekladac te upozorni napripadne chybove stavy, i kdyz to v dokumentaci nenajdes (protoze napr. neexistuje, je nekompletni) nebo kdyz to prehlednes.

[kralyk z abclinuxu]

Viz tady.

Ne, nevyhodi na 100% zadnou jinou checked exception, nez tu, ktera je ve vyctu. Pokud bys tam pouzil reflexi bude i checked vyjimka zabalena do unchecked.

Ok, oprava, jiné checked exceptions jsou přeměněny na unchecked

Ten benefit je v tom, ze prekladac te upozorni napripadne chybove stavy, i kdyz to v dokumentaci nenajdes (protoze napr. neexistuje, je nekompletni) nebo kdyz to prehlednes.

Upozorní tě na některé chybové stavy (jiné stavy mohou vyvolat unchecked exception nebo se nemusí projevit výjimkou), navíc bez dokumentace (a pozorného čtení ) stejně nevíš, kdy jaký stav nastane.

Vzhledem k tomu, že ten kompilátor stejně musí procházet call tree a kontrolovat seznam možných výjimek, by bylo dost možná lepší, kdyby prostě umožnil vypsat seznam výjimek, které mohou v nějakém bodě vybublat. Nemusely by se tím zanášet dependence do kódu.

[deda.jabko]

Viz tady

Uznavam, pokud zacnes prasit s Unsafe, apod. opravdu muzes mit takovou vyjimku... ale to te pravdepodobne cekaji jeste desivejsi veci.

Upozorní tě na některé chybové stavy

Porad lepsi nez nic. Je potreba si uvedomit, ze Java byl navrzeny jako jazyk s ohledem na bezpecnost a prekladac, te z toho duvodu nuti explicitne resit vyjimecne stavy.

[radix]

vsechny metody "throws Exception". Vyznam checked exception 0

Jo, to jsem si taky myslel, do te doby, nez mi pri predavani program v C# spadl na exotickou vyjimku, ktera se mohla objevit jen za urcitych okolnosti pri zapisu na sitove disky, a ktera byla ocekavana zhruba asi jako spanelska inkvizice.

Jde mi o to, ze pokud vsechny metody "throws Exception", pak je informacni hodnota tohoto statementu 0. Zaroven vyznam checked exceptions pada, protoze vas to nenuti je osetrovat (prave kvuli tomu, ze i klientsky kod deklaruje "throws Exception"). Cele je to pak jen sarada bez jakehokoli vyznamu.

typicky zmena implementace meni signaturu (kontrakt) metody

Pokud nechas probublat ven interni problemy je to tvuj problem.

Z mych zkusenosti je to hlavne problem lidi, kteri kod prebiraji. Jeste horsi je to v tom, ze lidi si pak mysli, ze pomoci tech IOException a JsonProcessingException muzou ridit chod programu. Jakoze odchyti IOException a rikaji si - jo, to je urcite vyjimka vyhozena z toho a toho mista, ale ona je ve skutecnosti vyhozena uplne jinde. Vyjimky (obzvlast checked) jsou soucasti kontraktu, to ale lidi dost casto ignoruji.

implementace metod checked vyjimky chyta, zaloguje, a vyhodi vys

Tohle nechapu. Toto jako s unchecked vyjimkama nejde nebo se nedela?

Samozrejme jde, jen tento antipattern vidim temer vyhradne u checked exceptions.

Druhy typ jsou osetritelne vyjimky - pro tyto vyjimky mame nejake osetreni - vime, jak na to reagovat. Takove vyjimky chytame nekde pomerne blizko k misto, kde se vyhazuji.

A na to jsou prave checked vyjimky. Je to zpusob, jak manifestovat, ze metoda muze skoncit jinak nez ocekavanou navratovou hodnotou.

Ale to prece muzete manifestovat i bez checked vyjimek. Do "throws" muzete klidne pridat i RuntimeException. Rozdil je v tom, ze checked exceptions vas nuti ke zbytecnym try-catch boiler plate kodu, kdyz se rozhodnete vyjimku neosetrovat.

Kdyz volam IO operace, tak vim, ze muze dojit k nejakemu IO problemu

Ono je to jen malinko jinak... protoze ty jen tusis, ze muze dojit k nejakemu problemu, unchecked vyjimky ti udavaji, ze k tomu problemu opravdu muze dojit a vnitrni kod vyvola vyjimku.

Teoreticky protipriklad: ono se totiz mohlo stat, ze nekdo IO naprogramoval tak chytre, ze vsechny operace problem tise ignoruji a tys mohl s timto resenim pocitat.

Opet, ja jsem rad, kdyz metody popisuji svuj kompletni API kontrakt, tj. vcetne vyjimek. Jsem ale nerad, kdyz si vynucuji specialni osetreni i kdyz ho nepotrebuji.

[deda.jabko]

Jde mi o to, ze pokud vsechny metody "throws Exception", pak je informacni hodnota tohoto statementu 0

Aha, takze ono to bylo mysleno doslova... tak to je pak jina... Pokud nekdo cpe do kodu doslova "throws Exception" tak je to prase a dalsi diskuze je bez predmetna, protoze za to programovaci jazyky ani checked vyjimky opravdu nemohou.

Z mych zkusenosti je to hlavne problem lidi, kteri kod prebiraji. Jeste horsi je to v tom, ze lidi si pak mysli, ze pomoci tech IOException a JsonProcessingException muzou ridit chod programu. Jakoze odchyti IOException a rikaji si - jo, to je urcite vyjimka vyhozena z toho a toho mista, ale ona je ve skutecnosti vyhozena uplne jinde. Vyjimky (obzvlast checked) jsou soucasti kontraktu, to ale lidi dost casto ignoruji.

Ale to je chyba tech programatoru, ze nedokazi pouzivat vyjimky spravnym zpusobem a nehraje roli jestli je to unchecked nebo checked exception.

Rozdil je v tom, ze checked exceptions vas nuti ke zbytecnym try-catch boiler plate kodu

Toto fakt nechapu. Nikdo te nenuti. Bud tu vyjimku odchytis a pak to mas to same jako s RuntimeException nebo ji delegujes dal a pak to mas stejne, jako by tam byla RutimeException, jen to deklarujes jako soucast metody.

Jsem ale nerad, kdyz si vynucuji specialni osetreni i kdyz ho nepotrebuji.

Nevynucuje, kdyz tu vyjimku v dane metode neumis zpracovat, predas ji volajicimu. V takovem pripade, ale musis brat v potaz, ze metoda nemusi skoncit vracenim hodnoty, ale vyjimkou a tudiz je nutne to uvest do kontraktu.

[radix]

Toto fakt nechapu. Nikdo te nenuti. Bud tu vyjimku odchytis a pak to mas to same jako s RuntimeException nebo ji delegujes dal a pak to mas stejne, jako by tam byla RutimeException, jen to deklarujes jako soucast metody.

Bud napisu kus boiler-plate kodu nebo musim menit interface svych metod. Pokud se rozhodnu zmenit interface, musim to same rozhodnuti resit na vyssich vrstvach. Navic se mi vubec nelibi, ze by nejaka metoda z business logiky mela deklarovat, ze "throws JsonProcessingException" - kdo ma co vedet, ze tam delam neco s JSONem. Jeste to budou chapat jako soucast publikovaneho kontraktu a zacnou to nejak specificky osetrovat. Samozrejme to muzu skryt boiler-plate kodem, ale cele se mi to zda strasne zbytecne ...

To cele kvuli vyjimce, ktera me totalne vubec nezajima.

S tim API kontraktem je to slozitejsi. Pokud delam nejake API, tak v JavaDocu (pripadne v throws) popisuju, ktere relevantni vyjimky kdy vyhazuju. Implicitne z povahy jazyka je taky jasne, ze se z te metody muzou vyhazovat i jine vyjimky. Ty ale nepopisuju (nepublikuju), protoze jsou spis dane implementacnimi detaily a klient tohoto API by je mel bez rozdilu chapat jako "neco se posralo, nemuzu pokracovat". Pokud implementaci zmenim, budu asi vyhazovat jine Runtime vyjimky - proto se k nim nechci zavazovat.

A ted si predstavim, ze jsem klient API. Toto API deklaruje, ze vyhazuje ty a ty vyjimky. Oka, to je fajn - v mem pripade je ale nechci osetrovat, protoze nevim co s nimi. Nechci je ale pridavat do throws meho interface, protoze tim je vystavuju (a zaroven se k nim zavazuju), i kdyz z hlediska meho kontraktu jsou spis implementacnim detailem a chtel bych, aby je klient chapal jako "neco se posralo, nemuzu pokracovat". Nemuzu tedy delat nic jineho nez je obalit naprosto zbytecnym try-catch blokem.

V takovem pripade, ale musis brat v potaz, ze metoda nemusi skoncit vracenim hodnoty, ale vyjimkou a tudiz je nutne to uvest do kontraktu.

To je ale prece implicitni soucast kontraktu vsech metod - kazda metoda (i s prazdnou implementaci) muze vyhodit vyjimku. Nechci ji uvadet do kontraktu, protoze z hlediska kontraktu meho API neni relevantni (je to spis implementacni detail). Da se to vyresit pres "throws Exception" (skryji konkretni typ vyjimky), ale to zase rika "Krome Error a Runtime mozna vyhodim i Exception", coz pro klienty je tak jako tak nulova informace.

Mimochodem, nasel jsem clanek s Andersem Hejlsbergem, ktery pekne vystihuje nektere z mych vyhrad proti checked exceptions: http://www.artima.com/intv/handcuffs.html

[deda.jabko]

Bud napisu kus boiler-plate kodu

Ano, protoze tak das explicitne najevo, co chces udelat v pripade chyby.

Navic se mi vubec nelibi, ze by nejaka metoda z business logiky mela deklarovat, ze "throws JsonProcessingException" - kdo ma co vedet, ze tam delam neco s JSONem

Takze je pro tebe pritazlivejsi predstava, ze zavolas metodu foo() ... ktera v sobe vola, bar(), baz(), qux() a quux() a libovolna z tech metod muze vyhodit cokoliv od JsonProcessingException po SpanishInquisitionException.... a libi se ti i predstava, ze ty nevis, zda nejakou takovou vyjimku kod muze vyvolat? Nebo mas kazde volani foo() v try-catch?

Pokud delam nejake API, tak v JavaDocu (pripadne v throws) popisuju, ktere relevantni vyjimky kdy vyhazuju.

Okay, dejme tomu, ze jsi s tim smireny, a ze jsi smireny s tim, ze proste metoda qux() muze vyhodit vyjimku QuxException dedici z RuntimeException, a ze tuto informaci si udrzujes v dokumentaci. Rozhodnes se zmenit metodu qux() a reknes si, ze v nekterych situacich bude jeste navic vyhazovat YetAnotherQuxException. V takovem pripade jednak musis rucne dohledat vsechna volani qux(), vsechna volani techto volani, atd. abys tam opravil dokumentaci o vyhozeni nove vyjimky, ale navic se vystavujes riziku, ze to nekde prehlednes neosetris a tise si do kodu zavedes chybu.

Oka, to je fajn - v mem pripade je ale nechci osetrovat, protoze nevim co s nimi. Nechci je ale pridavat do throws meho interface, protoze tim je vystavuju (a zaroven se k nim zavazuju), i kdyz z hlediska meho kontraktu jsou spis implementacnim detailem a chtel bych, aby je klient chapal jako "neco se posralo, nemuzu pokracovat".

V takovem pripade je spravne vyhodit vlastni NecoSePosraloException

Mimochodem, nasel jsem clanek s Andersem Hejlsbergem, ktery pekne vystihuje nektere z mych vyhrad proti checked exceptions: http://www.artima.com/intv/handcuffs.html

No, because in a lot of cases, people don't care. They're not going to handle any of these exceptions. There's a bottom level exception handler around their message loop.

To je presne ono, ze lidi jsou hovada a neresi poradne chybove stavy, je jejich problem ne tech vyjimek. Tato argumentace mi pripomina jednoho mojeho byvaleho spoluzaka, ktery mel rocnikovy projekt obaleny jednim velkym try-catch a kdyz mu to spadlo, tak se cely program restartoval a on mohl tvrdit, ze mu aplikace prece nespadla...

Da se to vyresit pres "throws Exception" (skryji konkretni typ vyjimky),

Nojo:

people do ridiculous things. For example, they decorate every method with, "throws Exception."

[kralyk z abclinuxu]

Takze je pro tebe pritazlivejsi predstava, ze zavolas metodu foo() ... ktera v sobe vola, bar(), baz(), qux() a quux() a libovolna z tech metod muze vyhodit cokoliv od JsonProcessingException po SpanishInquisitionException.... a libi se ti i predstava, ze ty nevis, zda nejakou takovou vyjimku kod muze vyvolat?

Tohle je ale přece celá pointa výjimek, že probublávají krz funkce, aniž by s nimi musely vůbec nějak interagovat nebo aniž by o tom ty fukce vůbec věděly. To je přesně důvod, proč byly výjimky vůbec vynalezeny. Jestliže ti tohle vadí, je na zvážení, jestli jsou pro tebe vůbec výjimky přínosem (což je mimochodem naprosto validní otázka, osobně už teď nevidím výjimky jako tak skvělou věc jako dřív).

[deda.jabko]

Tohle je ale přece celá pointa výjimek, že probublávají krz funkce,

Toto neni pointa vyjimek, ale dusledek toho, jak jsou implementovany.

Vyjimky byly navrzeny, k tomu, aby osetrovaly chybove stavy. Kdyz si vezmu jeden prvni z paperu o vyjimkach hned tam vidim:

Of the conditions detected while attempting to perform some operation, exception conditions are those brought to the attention of the operation's invoker. The invoker is then permitted (or required) to respond to the condition.

Jak ale ma "invoker" vedet, ze ma nejake vyjimky osetrovat, kdyz mu podle tveho idealniho reseni, muze vybublat kdekoliv cokoliv?

Jestliže ti tohle vadí, je na zvážení, jestli jsou pro tebe vůbec výjimky přínosem

Jak jsi prisel na to, tohle vadi? Nevim, co se mi snazis podsunout. S probublavanim vyjimek nemam nejmensi problem, ale vadi mi, kdyz se mi muze zniceho nic objevit po zavolani metody jakokoliv vyjimka!

Mam-li metodu int foo(), vim, ze je to metoda, ktera mi vzdy vrati hodnotu typu "int". Mam-li metodu int foo() throws MyException, vim, ze je to metoda, ktera mi vrati hodnotu typu "int" nebo, ze muze skoncit vyjimkou typu MyException a ja se podle toho muzu zachovat.

[kralyk z abclinuxu]

Of the conditions detected while attempting to perform some operation, exception conditions are those brought to the attention of the operation's invoker. The invoker is then permitted (or required) to respond to the condition.

To je natolik obecně řečeno, že to sedí všechny možné error handling mechanismy...

Jak ale ma "invoker" vedet, ze ma nejake vyjimky osetrovat, kdyz mu podle tveho idealniho reseni, muze vybublat kdekoliv cokoliv?

Invoker ošetřuje ty výjimky, které ošetřovat má - jsou pro něj relevantní. Ostatní výjimky můžou být buď výsledkem chyby (někdo někde vyhodil něco, co vyhodit neměl), s čímž invoker stejně nemůže nic dělat, nebo jsou relevantní pro jiného invokera někde výš.

ale vadi mi, kdyz se mi muze zniceho nic objevit po zavolani metody jakokoliv vyjimka!

To jsem měl na mysli. Tohohle se totiž obecně s výjimkama nemůžeš zbavit, a to dokonce ani v té Javě, kde je všeobecně statickou analýzou možné zjistit hodně.

Mam-li metodu int foo(), vim, ze je to metoda, ktera mi vzdy vrati hodnotu typu "int". Mam-li metodu int foo() throws MyException, vim, ze je to metoda, ktera mi vrati hodnotu typu "int" nebo, ze muze skoncit vyjimkou typu MyException a ja se podle toho muzu zachovat.

Tak z vlákna výše plyne, že tohle (v Javě) není tak úplně 100% pravda. Ale to je vedlejší, z mého pohledu je problém hlavně to, že když nastane někde pod foo() potřeba přidat nebo ubrat exception, musí se upravit každá metoda mezi vznikem oné exception a bodem jejího chycení.

Pro tu filosofii, že 'dobrá' návratová hodnota i chybové stavy jsou součástí definice funkce je IMHO spíš než výjimky lepší použít něco jako rustí Result. Samozřejmě vše má svoje pro a proti...

[kralyk z abclinuxu]

+1. (Z podobných důvodů byly v C++11 deprecated exceptions specification (viz) a přidán noexcept).

[Radek Miček]

Ale jako platforma mne Java pripada stale silnejsi ...

Pár důvodů, proč by CLR mohlo být pokročilejší než JVM:

• CLR podporuje optimalizaci tail volání (JVM ne a je to velký problém při implementaci funkcionálních jazyků).
• CLR povoluje delší metody než JVM (na tento limit JVM lze narazit např. v jazycích s makry).
• CLR má reifikovaná generika (jejich absence v JVM komplikuje Javu).

[radix]

Platformou jsem nemyslel jen jazyk a behove prostredi, ale i ekosystem okolo - knihovny, frameworky, (vyvojove) nastroje, prenositelnost ...

Jinak jsem se setkal s nazorem, ze type erasure vlastne neni az tak spatne, protoze umoznuje vyssi statickou verifikovatelnost kodu.

[Radek Miček]

Jinak jsem se setkal s nazorem, ze type erasure vlastne neni az tak spatne, protoze umoznuje vyssi statickou verifikovatelnost kodu.

Nerozumím, jak by to mělo pomoci. Kdybych ověřoval nějakou vlastnost a generika mi tam vadila, tak je přeci mohu vymazat dodatečně (možná bych pak kvůli overloadingu musel nějaké metody přejmenovat), ne?

[radix]

Jde o to, ze type erasure nas omezuje na ciste staticke pouziti typu. Nemuzeme udelat new T() a to je z tohoto pohledu vlastne dobre.

Uz si nevzpominam, kde jsem to cetl, ale zkusil jsem zagooglit a vypadla trochu podobna diskuse - http://stackoverflow.com/questions/20918650/are-there-benefits-to-javas-type-erasure

[kralyk z abclinuxu]

Wtf? Kód typu new T() by přece mělo být možné čistě staticky ověřit. Přijde mi, že ten komentář na SO moc nedává smysl; pokud by dané T nemělo default constructor, tak kompilátor prostě danou instanciaci odmítne přeložit, nesnad?

[radix]

Jak staticky overis, ze T ma defaultni konstruktor, kdyz nevis co je T?

(Mozna si pletes tridy a generika, T je konvencni oznaceni generickeho typu)

[kralyk z abclinuxu]

Jak staticky overis, ze T ma defaultni konstruktor, kdyz nevis co je T?

Jsou různé přístupy. V C++ mají templaty taková omezení, že kompilátor vždy ví, co je T, tj. ví i jestli má/nemá default constructor (export templates se nikdy pořádně neujaly a export keyword byl afaik vyřazen z C++11). V Javě by imho bylo možné mít template funkce s podobnými omezeními. Další možnost jsou traits, např. v jazyce Rust existuje pro tuhle situaci trait Default.

[radix]

V Jave takove omezeni neni - jednoduse proto, ze generika jdou pouzivat normalne z vne zkompilovaneho .jaru. V case kompilace prekladac nemuze vedet, ktere vsechny tridy muzou byt pouzity. To, ze to nejde v C++ mne prijde dost omezujici, ale chapu to vzhledem k tomu, jak jsou templaty v C++ typicky implementovane.

V Jave je mozne omezit, ze T musi byt subtypem (pripadne supertypem) nejake konkretni tridy/interface, ale to ti stale nezarucuje existenci konstruktoru (konstruktory se v Jave nededi).

[Radek Miček]

Myslím, že chápu, o co autorovi odpovědi na SO jde. Ale vymazat generika tomu příliš nepomůže.

Například z typu <A> List<A> flatten(List<List<A>> nestedList) rozhodně nejde v Javě vyvodit ekvivalenci

flatten(nestedList.map(l -> l.map(any_function))) ≡ flatten(nestedList).map(any_function)

Může to pokazit obyčejný toString. Navíc Java má reflexi, vedlejší efekty, což znemožňuje tento styl uvažování (nestačí se dívat na typ, ale musíme se dívat i na implementaci).

Nemyslím si tedy, že by výmaz generik v tomto ohledu k něčemu přispěl.