Java pod GPL

5. 12. 2006 | Lukáš Jelínek | Různé | 5524×

O plánovaném otevření zdrojových kódů Javy se hovořilo už dlouho. Nedávno bylo konečně oficiálně oznámeno. A i když se původně spekulovalo spíš o použití licence CDDL, padla nakonec volba na GNU GPL verze 2 (čisté i s Classpath výjimkou). Podívejme se na to, co všechno to bude znamenat - pro vývojáře aplikací, zájemce o samotný kód Javy a samozřejmě pro uživatele.

GPL - překvapivá volba?

Firma Sun Microsystems, ačkoliv je dlouhodobě známá svou podporou svobodného softwaru, neměla dosud licenci GNU GPL příliš v oblibě. Je to vidět i na tom, že například Solaris nebo Netbeans jsou poskytovány pod licencí CDDL (dřív se místo ní používala Sun Public License; obě jsou podobné licenci MPL) a OpenOffice.org (sice v podstatě komunitní projekt, ale výrazně podporován Sunem) nebo třeba SwingLayout pod LGPL. Proto se obecně očekávalo, že pro Javu, když už k otevření dojde, bude zvolena nějaká jiná licence, nejspíš CDDL.

Jenže ono to zase až tolik překvapivé není. Jestliže jedním z původních argumentů proti GPL byla snaha zamezit rozštěpení Javy, právě tento důvod se paradoxně stal naopak argumentem pro použití této licence. Protože totiž již nějakou dobu vzniká svobodná implementace Javy (byť pod jiným názvem; důvodem vzniku bylo především to, aby svobodné programy nebyly závislé na nesvobodném prostředí), mohlo by to dříve či později vést k takovým odlišnostem, které by výrazně komplikovaly používání javovských programů.

Za zmínku ale stojí hlavně načasování události. Zanedlouho bude vydána Java 6 - a nová licence bude jedním z důležitých faktorů, které by mohly rozhodnout o rozšíření této verze. Tím spíš, že Microsoft oznámil brzké vydání .NET Framework 3.0. Protože je Java do značné míry konkurenční technologií, mohla by nová licence pomoci Sunu čelit této hrozbě. Penetrace Javy v oblasti linuxových serverů není zdaleka taková, jaká by mohla být, proto by zejména větší firmy mohly dávat přednost technologiím od Microsoftu.

Co bude pod GNU GPL

V prvním kroku je pod GPL k dispozici kompilátor (javac) a virtuální stroj (Java HotSpot VM). Brzy (pravděpodobně současně s vydáním nové verze) bude pod GPL poskytován skoro celý balík Java Platform, Standard Edition (SE). Pouze některé malé části nebudou (kvůli patentům) takto dostupné.

Java Platform, Micro Edition (ME), je v současné době početně nejrozšířenější edicí Javy (obsahuje ji drtivá většina dnešních mobilních telefonů). Bude též uvolněna pod GPL, a to včetně frameworků TCK (Technology Compatibility Kit) a JDT (Java Device Test).

Poslední věcí, které se přechod na GPL týká, je Java Platform, Enterprise Edition (EE). Tato část je již od poloviny roku 2005 dostupná pod licencí CDDL. Nyní je vyvíjena v rámci open-source projektu GlassFish.

Důležitou věcí je, že ve většině případů se nejedná o "čistou" GNU GPL verze 2, nýbrž o tuto licenci s Classpath výjimkou. Na samotný zdrojový kód se tedy vztahují veškeré pravidla stanovená GPL. Odlišnost je pouze v tom, že programy, které příslušné knihovny používají, mohou být šířeny pod jinými licencemi (zde to bude mít jen omezený vliv, brzy vysvětlím proč). Odvozená díla (modifikované verze knihovny) lze šířit jak pod touto modifikovanou, tak i pod normální GPL.

GPL s výjimkou budou používat všechny knihovny Javy kromě Micro Edition (viz dále). Znamená to nejen možnost vytvářet odlišně licencované programy, ale hlavně možnost společné distribuce knihoven (SE a EE) s programy.

Pro "mobilní" (ME) verzi byla zvolena normální GPL, bez výjimky. Někdo by z toho mohl mít obavy, že javovské programy pro ME budou muset být jen pod GPL, ale tyto obavy jsou zbytečné. Pod GPL se totiž zde ve všech případech poskytuje pouze implementace knihoven, nikoliv jejich API nebo dokonce specifikace jazyka atd. Na programy jako takové to nebude mít vliv. Jediné, co by vyžadovalo použití GPL u programu, by bylo šíření v rámci jednoho balíku s Javou ME - ale to je vzhledem k typickému použití této Javy nepravděpodobný případ.

Ještě se zmíním o současném stavu. K javovským balíkům ve standardních knihovnách Javy jsou již dlouho dostupné zdrojové kódy - člověk je získá automaticky instalací JDK. Lze tedy studovat fungování implementace, lze zdrojáky využít při ladění. Ale to je tak všechno - nelze vzít kus kódu a použít ho jinde, nelze ani něco upravit (či opravit, pokud je tam chyba) a používat tuto pozměněnou verzi. Tato omezení nyní v podstatě padnou. Implementace bude ovšem dále dostupná i pod původní proprietární licencí, pro ty, jimž by se GPL z nějakých důvodů nezamlouvala.

Změny pro vývojáře

Kdo dosud tvořil v Javě nějaké programy, ať už pod jakoukoli licencí, může tak činit nerušeně dál. Co bude ovšem nově moci, bude společná distribuce programu a Javy (JVM a knihoven). Program se tak může dostat i k uživatelům, kteří by si Javu jinak nenainstalovali.

Zaradovat se mohou též skalní příznivci svobodného softwaru. Konečně budou mít možnost tvořit v Javě programy, které nebudou závislé na nesvobodném prostředí. Dosud byly na výběr dvě možnosti - buď se spokojit s Javou od Sunu, příp. IBM nebo Blackdown (a tedy nemít svobodné prostředí), nebo se spolehnout na svobodné nástroje, jako GCJ a GNU Classpath (a přijít tak o část funkcionality a stability).

Přínos tu bude i pro ty, kdo chtějí z nějakého důvodu v javovských knihovnách, případně kompilátoru nebo JVM něco upravit. Nyní už jim nebude stát nic v cestě. Neobávám se hrozby štěpení Javy, zajímavé změny se mohou uplatnit v rámci projektu OpenJDK.

Změny pro zájemce o kód

Kdyby někdo chtěl vzít nějaký kus kódu z knihovny a použít ho ve svém (GPL-licencovaném) programu, může tak bez problémů učinit. V mnoha případech by to mohlo pomoci kvalitě programů psaných v Javě, nebo dokonce i v jiných jazycích. Převzít něco hotového, odladěného, kvalitního, je vždy lepší než to psát úplně od začátku.

Netřeba se snad zmiňovat o tom, že naprosto bezproblémové bude zkoumání kódu. U knihoven (resp. jejich části) tu určitá možnost byla již dřív, nyní to půjde i u JVM a kompilátoru (a také u nativních částí knihoven).

Změny pro uživatele

Uživatelé jsou ti, kdo na tom vydělá nejvíc. Lze očekávat podstatně více nových programů v Javě, zkvalitnění těch stávajících, a také jednodušší distribuci. Odpadne složité stahování JRE, explicitní potvrzování souhlasu s licencí atd. Bude stačit, když instalátor zkontroluje přítomnost Javy v systému, a pokud ji nenalezne, nainstaluje přibalenou verzi.

Určitou drobnou změnou je i to, že zatímco původní licence v podstatě zakazovala (i když ne zcela striktně) použití JDK v souvislosti s jakýmkoli jaderným zařízením, GPL samozřejmě žádné takové omezení neobsahuje. Nelze to samozřejmě chápat tak, že by se nyní začaly objevovat jaderné reaktory řízené programy v Javě, ale někteří uživatelé mohli při spatření takové klauzule pochybovat o spolehlivosti Javy a z principu ji odmítat.

Java a distribuce GNU/Linuxu

Tohle byl dlouhodobý problém, který jednak komplikoval život uživatelům a současně bránil většímu rozšíření Javy na Linuxu. Dosavadní licence neumožňovala, aby byly JRE a JDK obsaženy přímo v distribucích. Každý uživatel si je tak musel ručně stahovat a instalovat, což nebylo pohodlné a pro některé uživatele to dokonce představovalo nepřekonatelnou překážku (už proto, že některé verze JRE a JDK obsahovaly chyby v nastavení přístupových práv).

Tato velká bariéra nyní padla. Díky novému licencování může být Java obsažena ve všech distribucích, kde má své místo (tedy ve všech "velkých"). Dokonce i v Debianu a dalších, jejichž autoři velmi dbají na čistotu licencí a jejich "svobodnost". Nevidím sebemenší důvod, proč bychom nemohli v příštím roce v distribucích nacházet nejen samotnou Javu od Sunu, ale i množství hodnotného aplikačního softwaru psaného v tomto jazyce.

Závěr

Rozhodnutí otevřít Javu a dát ji k dispozici pod GNU GPL lze hodnotit jako jednoznačně pozitivní krok (ústy R. Stallmana ho přivítala i FSF). Může přinést mnoho dobrého uživatelům i vývojářům (a koneckonců také firmě Sun Microsystems), výrazně pomoci též GNU/Linuxu, a v neposlední řadě podpořit Javu jako jazyk, který, přestože se nemusí líbit každému, má své nesporné kvality.

       

Komentáře

[Filip Jirsák]

Netřeba se snad zmiňovat o tom, že naprosto bezproblémové bude zkoumání kódu. U knihoven (resp. jejich části) tu určitá možnost byla již dřív, nyní to půjde i u JVM a kompilátoru (a také u nativních částí knihoven).

I tahle možnost už tady byla dřív, existuje tzv. Community Source Release, kde jsou zdrojáky i pro nativní části knihoven a měly by tam být i pro JVM a nástroje z JDK (píšu měly by být, protože jsem to nikdy sbuildovat nezkoušel).

[Boris Dušek]

Problém, který se ohledně těchto "source release" Javy od Sunu třeba v projektu GNU Classpath řešil, bylo to, že kdokoliv jednou v životě viděl jakkoliv malý úsek kódu z této "source release", tak už pak z licenčního hlediska nesměl nikdy v životě pracovat na jiné implementaci Javy. Takže na mailing-listech Classpathu se radilo vývojářům něco ve stylu "radši si ten zipák se zdrojákama smažte z disku, než abyste odolali pokušení se tam kouknout" Takže skutečně svobodné zkoumání může přijít až teď, co to Sun uvolnil pod GPL.

[Filip Jirsák]

Jenže Java vývojářů, kteří zároveň pracují na jiné implementaci Javy, je jen mizivé promile, takže pro běžné vývojáře to žádné omezení nebylo.

Mimochodem, nějak v té licenci tuhle klauzuli nemůžu najít. Navíc si nedovedu představit, že by takové ustanovení v licenci mělo v ČR nějakou platnost. Abych mohl program užívat, musím na to mít licenci. Ale když už program nepoužívám, žádnou licenci nepotřebuju. Takže kdybych chtěl v budoucnosti přispívat do jiné implementace Javy, možná tím budu porušovat ujednání licence, jenže tu licenci už nebudu užívat, takže jí nebudu potřebovat.

[Marcho]

Neporušujete tak žádnou licenci, ale možná nevědomky copyright. Když se podíváte na nějakou implementaci, pak ji z paměti znovu vytvoříte, tak potenciálně vytvoříte kód který bude ne zcela nepodobný tomu původnímu... Když se pak ukáže, že jste ten původní kód opravdu četl, tak těžko přesvědčíte někoho, že jste ten kód jednoduše neopsal.

Proto je bezpečnější takový kód vůbec nečíst.

[petr_p]

Navíc si nedovedu představit, že by takové ustanovení v licenci mělo v ČR nějakou platnost. Abych mohl program užívat, musím na to mít licenci. Ale když už program nepoužívám, žádnou licenci nepotřebuju.

V ceskem autorskem zakone je takova bota jeste z dob, kdy program nebyl chapan jako autorske dilo. Je tam totiz psano, ze jednou udelene licence se nelze zbavit a nabyvel je povinnen ji vyuzit. U knihy je to pochopitelne, ale u softwaru, ktery zakon stavi na rovinu s literarnim dilem, to kulha na vsechny nohy.

[Hynek (Pichi) Vychodil]

... Pouze některé malé části nebudou (kvůli patentům) takto dostupné. ...

Tomu nějak nerozumím. Znamená to snad, že tyto části nemohou být přítomny ve zdrojovém kódu, nebo že nemohou být dostupné pod GPL. To první je nesmysl, protože patent je (musí být) zveřejněn. Takže platí to druhé?

[Ripper]

Taky mi to neni jasne, znamena to ze budu mit standardne v linuxu implementaci Javy, ktere budou "male kousky" chybet?

[petr_p]

Na http://download.java.net/openjdk/jdk7/ se pise, ze je omezene stahovani z nekterych zemi kvuli nedostatecnemu pravnimu systemu.

Jenze kdo vi, k cemu se to stahuje, protoze jsem nikde nenasel zdrojaky, ktere by byly pod GPL. Poravde recno, i oznameni o uvolneni pod GPL jsem musesel hledat Googlem.

[pzad]

Hned ako to uvolnili tak tam bola linka na to ich cvs a tam to bolo aj s licenciou GPL.

[petr_p]

Uz jsem to nasel.

[Petr Adamek]

Ve skutečnosti nejde o patenty, ale o to, že některé čáti zdrojových kódů má SUN licencovány od jiných firem a není tak oprávněn daný kód uvolnit jako GPL. Tyto části proto budou ze začátku uvolněny jako binárrní balíčky a později se je SUN bude ve spolupráci s komunitou snažit nahradit nezávislou implementací, nebo přímět příslušné firmy, aby přistoupily na uvolnění pod GPL.

Takhle to vysvětloval Patrick Finch z Open Source Group firmy SUN na SUN Tech Days v Praze.

[Luk]

Ve skutečnosti nejde o patenty, ale o to, že některé čáti zdrojových kódů má SUN licencovány od jiných firem a není tak oprávněn daný kód uvolnit jako GPL.

Domnívám se, že i zmíněné patenty budou hrát určitou roli. Ve standardních balících určitě jsou nějaké části, které jsou nějakými patenty zatížené (nejspíš zrovna ty, které jsou licencované odjinud) a Sun si nemůže dovolit to ignorovat. Ale hlavním důvodem bude zřejmě opravdu to převzetí součástí od jiných firem.

[Hynek (Pichi) Vychodil]

patentované = zveřejněné, proto nechápu jak patenty brání samotnému zveřejnění. Je jasné, že co je patentované, nemůže být zveřejněno pod GPL, ale nechápu proč to nemůže být zveřejněno vůbec. Pokud je něco patentované, tak to stejně nemůže nikdo jiný implementovat pod jakoukoli licencí a stejně tak pokud je v javě něco patentované, tak nechápu jak dotyčný vybírá poplatky od Sunu, případně od jiných implementátorů javy. Pokud je možné napsat javu bez patentované části, tak nechápu proč to tam je. Jinými slovy furt to s těma patentama nechápu. Takže je tam něco patentované, potom každý kdo používá/implementuje/vyvýjí javu, používá patentovanou technologii a vlastník patentu by měl od všech vybírat patentové poplatky, nebo to pro samotnou javu není potřeba a pak nechápu proč to tam je. Jen podotýkám, že patent se nesmí vztahovat ke konkrétní implementaci, ale vztahuje se k obecnému řešení technického problému. Jinými slovy patenty na SW jsou stejně pičovanina na entou a právě proto se ptám, jak to v tomto případě je, protože formulace v článku mi přijde naprosto nesmyslná. Prostě patent nemůže bránit ve zveřejnění, to je prostě ptákovina, protože patent znamená, že popíšu jak na to a tento popis je zveřejněn! Patent brání v používání. Naproti tomu licence zveřejnění bránit může.

[pzad]

A co ked poviem, ze moje patenty sa mozu pouzivat iba v kode licencovanym pod GPL. Ak to chcu pouzit pod inou licenciou - nech cvakaju.

[Hynek (Pichi) Vychodil]

Dobrá, tu jednu větu "Je jasné, že co je patentované, nemůže být zveřejněno pod GPL, ..." je potřeba přeformulovat na "Je jasné, že co je patentované, nemusí být vždy možné zveřejnit pod GPL, ..." Zbytek je doufám OK.

[ldx]

...vyvýjí... -> vyvíjí

[Hynek (Pichi) Vychodil]

Ael v článku se hovoří o patentech, jinak bych se neptal.

[Michal Vyskočil]

Určitou drobnou změnou je i to, že zatímco původní licence v podstatě zakazovala (i když ne zcela striktně) použití JDK v souvislosti s jakýmkoli jaderným zařízením

Po přečtení tohoto mě zamrazila představa Javy v Linuxu, pak jsem s úlevou zjistil, že jde jen o jaderné elektrárny

[thingie]

Neexistuje důležitější aplikace výpočetní techniky než jaderné elektrárny. Aspoň to teda z tvrzení některých plyne.

[Michal Vyskočil]

Jo tak v zabezpečení jaderek se moc nevyznám. Ale potom, co jsem zjitil, že Honeywell používá pro avioniku C (čekal jsem spíše Adu), tak bych se nedivil snad už ničemu ...

[Kyosuke]

A kde všude? ([ link ])

[Michal Vyskočil]

Aspoň dle informací kamoše, který tam nastoupil. Link nemám a pokud to není pravda, můžu to svést na informační šum

[ldx]

C je nejpouzivanejsi a nejproverenejsi jazyk vubec (C++ nasleduje az na druhem miste), takze je to IMHO jedine dobre.

[Michal Vyskočil]

Zajímalo by mě, která z vlastností jazyka C ho činí tak skvělý pro letecký software ... nějak mě žádná nenapadá

[keson]

ale to je prece jasne, Cckove programy padaji, letadla padaji - takze je to kompatibilni :)

[Lukáš Zapletal]

C je nejpouzivanejsi a nejproverenejsi jazyk vubec (C++ nasleduje az na druhem miste)...

No Wikipedia tvrdí něco jiného (o C++), tedy že Java je před C++

[ldx]

V podminkach pro pouzivani Javy, ktere se musi odsouhlasit pred stazenim jakehokoli software ze Sunu stoji, ze se nesmi pouzivat v mission critical aplikacich, napr. jadernych elektrarnach.

[Ondra]

Je avionika a avionika. Je treba vzit v uvahu, jak kriticka je konkretni aplikace. Pro systemy s vysokou urovni kriticnosti se tam pouziva ADA (konkretne tusim vyvojove prostredi GreenHills), zatimco C se pouziva pro soucasti, ktere vysokou spolehlivost nevyzaduji. Krome toho programovani v C muze byt stejne spolehlive jako v ADA, jen je treba programovat poradne, vzajemne si kod kontrolovat a vlastne celkove dodrzovat predepsane postupy. V takovem pripade je sice vyvoj v C mozna delsi a vyzaduje vice lidi, aby udelali spolehlivy kod, ale spolehlivost se od ADA prilis nelisi.

:)

[Jary]

Je to špatně. Jak jednou řekl Homer J. Simpson: "Atomovou. Říká se a-to-mo-vou". (:

[Luk]

Špatně. Vzhledem k tomu, že je založena na jaderné reakci (štěpení jader), je vhodnější termín jaderná. A nějaký Homer nám tu nebude věšet bulíky na nos

[Ladicek]

Ale i elektrárna založená na termojaderné fúzi (syntéze; pomiňme na moment, že zatím žádnou nemáme) by si zasloužila označení jaderná. Takže jedné budeme říkat syntetická a té druhé analytická

[Kyosuke]

To už je lepší snad i můj návrh dělit jaderné elektrárny na termojaderné a kryojaderné…

[Hynek (Pichi) Vychodil]

Hmm, hezky jsem se pobavil, ale už před dvaceti lety na základce jsem jaderné elektrárny bez problému dělil na fůzní a štěpné a nikdy jsem neměl problémy s tím, že mi někdo nerozumí.

[Kyosuke]

Chápu, taky jsem si v osmé třídě počítal energetické bilance jaderných reakcí. Byl to jenom vtip.

[petr_p]

fúzní

[ldx]

Jen jestli si to nepletes s jadernymi bombami... )) )

[Vykook]

Ale mame a dokonce i v cechah...

[David Jaša]

A kdepak? A jak je zařízeno, aby se během spuštění neproměnila ve vodíkovou bombu?

[Heron]

Pokusný termojaderný reaktor v ČR opravdu je. A ve vodíkovou bombu se proměnit nemůže. Ono udržet stabilní fůzy vyžaduje (mimo jiné) externí mg. pole udržující plazmu v malém objemu (a velkém tlaku). Jakmile tohle pole bude odpojeno, plazma okamžitě schládne a fůze nebude dále pokračovat (v tomto směru by byl fůzní reaktor daleko bezpečnější než klasický, kde jeho zastavení vyžaduje určité akce). Bomba je na jiném principu. Tam je jako iniciátor použita klasická štěpná atomová bomba (která vytvoří vysokou teplotu a tlak a běhěm zlomku sekundy dojde k termojaderné fůzy.

[Vykook]

snad jenom dodam http://cs.wikipedia.org/wiki/Tokamak

[ldx]

...stabilní fůzy... no to se povedlo )) Zkuste to opravit na Stabilní fúzi. Jinak mate s tim vysvetlenim uplnou pravdu, jen doplnim, ze je tam problem urcite zbytkove radiace plaste reaktoru, ale to je bezne i u klasickych jadernych elektraren.

[Kyosuke]

Fakt? A kolik MWh dodá ročně do naší rozvodné sítě?

[disorder]

"debil". sorry, tie uvodzovky su tam omylom.

[J.]

Microsoft oznámil brzké vydání .NET Framework 3.0

To je dobrej ftip :) Sotva pár programů využije NET 2.0 a M$ vydá novou a ještě uzavřenější verzi, určitě to bude tak 1GB k downloadu, pěknej komplet s Vistou. Ještě před rokem jsme ve škole dělali ve vižual bejziku, nějaké staré verzi :) No a teď se učíme Javu, využíváme nejnovější 1.5, ale to už je jiná škola :)

[ldx]

Jsi uplne mimo. Porovnej si velikost frameworku .NET a J2EE. A kdyz uz se ti .NET nelibi, tak je tady jeste MONO.

[Lukáš Zapletal]

Mimo? J2EE má několik MB (ve své podstatě je to JAR archiv o velikosti pod 1 MB). A to že Sun nyní dává ke stažení celý balík nástrojů včetně aplikačního serveru, dokumentace a tutoriálů ještě neznamená, že J2EE je moloch. Navíc srovnáváte nesrovnatelné -- .NET a J2EE jsou dvě diametrálně odlišné věci a J2EE stále nemá v podstatě u .NETu žádnou paralelu.

J2EE aplikace distribujete vždy "bez J2EE" -- prostředí musí poskytnout aplikční server, který už vše potřebné obsahuje. Pokud byste chtěl něčeho podobného dosáhnout v .NETu, musíte toho stáhnout možná ještě mnohem víc...

[ldx]

No tohle je smesne. Potrebujete minimalne Java2 Runtime, a to je nejakych 50MB, a pro web aplikaci i server (napriklad Tomcat nebo nejaky jiny) a to je dalsich X megabytu. Navic C# v ASP.NET je o dost pokrocilejsi zalezitost, i kdyz pravda Java ma zatim navrch v aplikacnim modelu (dokonale oddeleni prezentační, procesni a databazove vrstvy)... Apropo, zkuste nekomu tady poradit, jak si ma stahnout jen ty vybrane class soubory z toho JAR-u, kdyz Sun nabizi jen a jen cely balik (navic az po zadani vasich osobnich udaju a odsouhlaseni licence, ktera si v nicem nezada s tou od M$ - jinak si ani neskrtnete).

[Tomas]

No .. vubec nevis o cem mluvis. .net framework 3 je totiz uplne obycejny .net framework 2 doplneni o nekolik knihoven. nejedna se o nic extra noveho a dokonce ani nijak velkeho. celkovy balik ke stazeni ma neco pres padesat mega...

prosim, v cem je .net framework 3 uzavrenejsi nez .net framework 2?

[J.]

Aha, takže rozdíl je asi jako mezi Win XP a Vista, že jo? To ale pak nechápu, proč vydávat novou major verzi (a že se NET nevydává často) s tak málo novými věcmi.

No a to ostatní: vycházím z toho, že to je od MS :)

[Tomas]

aha... kdy jsi naposled videl windows? v dobe win95? jinak bys takove blafy o minimu zmen mezi xp a vistou nemohl rikat..

mmch ... ono sice je to .net framework 2.0 s par knihovnami navic, ale tech par knihoven navic nepridava neco malo novych veci... ale dost brutalne rozsiruje moznosti .net frameworku a prinasi asi tak 4 uplne nova rozsahla api (rozsahem srovnatelna s stavajim frameworkem 2) .. takze ta major zmena verze je i na miste...

[Hynek (Pichi) Vychodil]

... .net framework 3 je totiz uplne obycejny .net framework 2 doplneni o nekolik knihoven. nejedna se o nic extra noveho a dokonce ani nijak velkeho. ...

vs

..., ale tech par knihoven navic nepridava neco malo novych veci... ale dost brutalne rozsiruje moznosti .net frameworku a prinasi asi tak 4 uplne nova rozsahla api (rozsahem srovnatelna s stavajim frameworkem 2) .. takze ta major zmena verze je i na miste ...

Heh, co kdyby jsi neprotiřečil aspoň sám sobě? To je pro tyhle fanatické M$ zastánce tak typické

[Tomas]

Ups.... :) spatne vyjadreni .. (ten puvodni) ..

jinak fanaticky zastance M$? nenechte se vysmat :)) vyvoj linuxovych aplikaci me poslednich pet let zivil ... takze fanaticky M$ zastance zdaleka nejsem.. ale nemam naopak rad fanaticke Linux zastance, kteri win videli z okna (mozna ani to ne) ale zasvecene o nem hovori .. a svym "radoby" zastancovstvim linuxu spis naopak skodi ... ale stejne tak nemam rad fanaticke m$ zastance, kteri nikdy nevideli linux ..

[J.]

Budeš se divit, ale já používám Win XP (doma samozřejmě ne) a taky jsem si zkoušel Visual Studio .NET 2005 a něco jsem i naprogramoval, takže jsem to viděl. A právě tohle studio totálně rozhodilo celý win a i po odinstalaci se zobrazují VS just-in-time debuger hlášky a aplikace náhle končí (předtím fungovaly) :)