Vlákno názorů k článku Novinky v Javě aneb Tygří spáry od Honza - Podle tohohle vypisu je zjevne, ze Java dohani...

To je klasicke. Urazet a jeste tak primitivne. Kdyz nejsou argumenty, pouziji se takovehle nic nerikajici fraze. Prestante uz s timhle "marketingem" anti-neco a radeji jednejte racionalne a jako dospely lidi, co dokazi soudne uvazovat.A neboj jste porad jeste pubertaci, co musi neco shazovat, aby se ukazali, jak oni jsou ti borci sveta?

Vase intelektem a dospelosti nabita reakce me primela k jedne otazce - jake _konkretni_ informace o ekonomickych vysledcich spolecnosti Novell a Sun mate k dispozici? Ono je sice uplne jedno, jake maji vysledky, protoze tady mluvime o konkretni vyvojove platforme a zmenach navrhovanych primo v jazyce, ale kdyz uz mate plna usta racionality a atgumentu, pak by me zajimalo, jestli to neni jenom marketingovy letak;-)

Ach jo, to jsou porad jen obecny kecy nejakyho zaslepence. Tohle nema cenu komentovat, nebudu se snizovat k nejake flameware bez argumentu a nebo lacinym argumentum, ze neco je okopirovane a nebo to je tak dokonale, ze jiz nemuze byt nic lepsiho. Tohle fakt nema zadny vyznam krome emotivniho vybliti.

a ten zaslepenec jsem ja a nebo vy - me to pripada jako se bavit o tom co bylo drive - vejce ,nebo slepice. ?? holt je to vyvoj - MS nemel nic takoveho jako java a prebral si co bylo dobre. - blaboly typu - predni odbornik ,ktery vymyslel vsechno - si nechte pro deti ,ty vam to mozna sezerou

>>>NEt dosel s tou svoji nezavislosti nadruhou

slova jako nezavislost ,najdete v kazdem druhem popisu .NET<br>
vymysly Ms jako COM , nebo binarni registry se nikam jinam nerozsirily ,nebot existuji kvalitnejsi - corba ,rmi web servisy atd<br>
"Co se faktického významu přenostelnosti týče, velké SW projekty v Javě beztak nejsou přenosné bez rozsáhlých úprav na jinou platformu" : jsou - to co nazyva Microsoft managed kod ( v jave jni ) se v jave dnes nepouziva ( nebo zridka v nutnych pripadech - nicmene bezne se s tim nesetkate<br>
"Co se rozšíření .NETu týče, je za dva roky rozšířen na 30% desktopů a zhruba na polovině aplikačních serverů." 30% procent z windows desktopu za celou dobu posobeni .NEt spise beru jako extremni neuspech ,nebot se to mohlo sirit updaty. - co se tyka aplikacnich servru ,tak samozrejme se to tyka pouze MS servru - jinak co se tyka webovych servru(www.netcraft.com) je velmi vystizne sledovat jak ohodnotili velci zakaznici kvalitu win2003 - za posledni kratke obdobi probehl brutalni propad na uroven ,kterou mel Microsofti produkt vroce 1997 - velmi vystizna je krivka dosvedcujici snahu o migraci na win platformu a rychly nasledny navrat na apache ( coz se tyka javy tez ,nebot apache je pouzivan modulem pro java aplikace ( neplest s tomcatem))<br>
". Už dnes lze říci, že .NET spolu s PHP vytlačil Javu z klinta i web serveru do oblasti middleware." vytlaceni viz vyse - jedna se o pravy opak. -jinak java a swing je dneska jediny zpusob jak propagovat gui aplikaci primo ke klientu nezavisle na operacnim systemu - viz web start <br>
" Další problém je absence kvalitních widgetů podporující visuální design jak pro pro desktopové i webové rozhraní (server web controls). Proč dodnes Javě chybí např. print preview dialog či datagrid podporující databinding (něco, co čím disponoval Visual Basic 3.0 blahé paměti) - to opravdu nechápu."
<br> mno evidedntne moc vyvoj nesledujete a neprogramujete jave - tudiz jen kratce - gui nastroje jsou imho kvalitni ,print preview dialog samozrejme v jave pouzivat muzete a datagrid alespon jsem kdysi resil prez beanu - na druhou stranu jsem vzdycky musel resit specificke dotazy ,ktere nejdou obecne popsat a tak pristup prez klasicke dotazy je jednodussi
- graficky navrh tagu mi krapet schazi ,ale myslim ,ze neco takoveho uz taky existuje - ale web nedelam ,takze mocnesleduji

>>>slova jako nezavislost ,najdete v kazdem druhem popisu .NET<

jinak k te platformove zavislosti ,nebo nezavislosti - prijde mi VELMI nerozumne vytvaret v dnesni dobe jakykoliv projekt s tim ,ze omezim cilovou skupinu pouze na majitele MS windows - uz pro migrace ,ktere dnes probihaji ( k nelibostem lidi ,kterym to holt nesedne) - pokud zvolite .NEt ,tak mate temto svym zakaznikum moznost nabidnout web interface ,coz jejen slaba nahrazka a vyvoj tvrva zbytecne moc dlouho

Co se podpory smart klientů na úkor web aplikací týče - to je určitě trend, který bude do budoucnosti podporovat i Microsoft. Ale obávám se, že je zbytečné o tom nyní diskutovat v souvislosti s Javou vzhledem k tomu, že Sun první kolo boje o desktopy vlastní neprozíravostí a sebestředností prohrál tím, že přiměl MS k vyvinutí vlastní platformy.

Když se Java na desktopech nedokázala prosadit za sedm let existence - jak by se jí to mělo povést nyní v situaci - když má v podobě platformy .NET takovou konkurenci ?

Dokonce i IBM pochopilo dřív než Sun, že k tomu aby se Java dala na desktopech rozumně používat nemůže být napsaná v Javě, ale v nativním kódu dané platformy (SWT widgety, obdoba MS Java wfc). Vylepšená HW podpora dnes Java GUI nezachrání - tim spíš, že Windows budou HW akceleraci brzy podporovat systémově (Avalon).

Jenže .NET bude mít i potom oproti Javě stále náskok ve výkonu, protože správu GUI událostí (listenery), resources a dalších záležitostí obstarávají v .NETu už dnes nativní Win32 API. Ale - jak už jsem uvedl výše - hlavní problém Javy pro použití na desktopech je, že Sun zaostal ve vývoji reusable GUI komponent a DB rozhraní.

To není problém z hlediska použití, ale návrhu - jenže s ohledem na konečný úspěch platformy je ergonomie designu z hlediska vývojáře snad ještě důležitější, než pohodlí uživatele. Bez dobrého vývojového prostředí a komponent rychle dobrou aplikaci neuděláte: vývoj IT diktuje ten kdo má desktopy a směr vývoj na desktopech určuje ten, kdo má kvalitní vývojové prostředí.

mno tak postupne:
Microsoft si vyvinul vlastni net z duvodu ,ze se mu nopovedlo ovladnout vyvoij javy - vyz problem s MS javou a umyslnym zanasenim nekompatibilit - tohle vyresil ku prospechu javy soud
.NEt je castecnou konkurenci pro javu pouze na MS platforme - a vzhledem k tou ,ze je zacinajici trend migrace z MS pryc ,tak ...
SWT je krapet nepovedene a dnes se uz nepouziva - prave proto je skoda ,ze autor zde neuvedl detaily ohledne hardwarove akcelerace j2d -swingu. SWT je etapou v historii
DB rozhrani v jave je podle me docela dobre udelano -
"Bez dobrého vývojového prostředí a komponent rychle dobrou aplikaci neuděláte: vývoj IT diktuje ten kdo má desktopy a směr vývoj na desktopech určuje ten, kdo má kvalitní vývojové prostředí." to naprosto souhlasim - tahle podminka splnena je

MS Java Foundation classes je v zásadě to samé rozšíření, co SWT toolkity, které mj. používá Eclipse - nejlepší vývojové prostředí pod Javou a pro Javu, co existuje - proto bych byl opatrný s prohlášením, že už se "moc nepoužívá".

DB rozhraní v Javě je o generaci pozadu za ADO.NET - jde víceméně o kurzorový engine nad ODBC (opět se mi mimoděk vybavuje VisualBasic 3.0 z roku 1994). Jenže VB 3.0 už podporoval od začátku ten databinding a model datových událostí....

Co se flamování týče, respektuji, že tenhle článek o Javě je pro příznivce Javy a původně jsem do diskuse nehodlal vůbec zasahovat - pokud si na závěr přečtou nevlídné srovnání s .NETem, můžou být za to první řadě vděčni Vám a Vaší zmínce o .NETu.

Jak se do lesa volá....

mno ,nevim ,jak jste prisel na to ,ze eclipse je nejlepsi editor na javu ????? eclipse byl dobry ,dokud byl jednodychy . Jenze jakmile chctete aby podporoval nejruznejsi veci ,tak musite doinstalovavat nejruznejsi moduly - v tom je zadrhel ,protoze okamzite se z toho stava nepohyblivy moloch. S eclipse jsem delal intenzivne skoro rok ,nez jsem si uvedomil ,ze z puvodne mileho maleho editoru mam pred sebou nepohybliveho golema - dneska delam v podstate jen v netbeansech. - je to jen subjektvni hodnoceni ,ale po vyzkouseni mnoheho se mi libi nejvic kombinace netbeans(swing) + xdoclet.
jinak ohledne toho netu jsem to nezacal ja
"DB rozhraní v Javě je o generaci pozadu za ADO.NET - jde víceméně o kurzorový engine nad ODBC " jdbc nema s odbc nic spolecneho ( nastesti)

Podív se, jak efektivně de dělat v .NET frontend pro relační databáze. A využívá to přitom jen standardní a standardně zdokumentovanou funkcionalitu .NET (tj. žádný klasy mebo bíny třetí strany, tim míň placený)

http://193.85.233.106/home/UNISEX/index1bak.htm

mno nevim jak jinym ,ale me to vyhazuje chybu FERMI :))

Jo, diky - spravne je to

http://193.85.233.106/home/UNISEX/index1bak.html

btw sem JOX...:o)

mily zephire ,aleias fermi - stejne efektivne to napises i v jave ,ale s tim rozdilem ,ze to bude prehlednejsi a nebudu psat deset prikazu na jedu radku - a to nebudu pouzivat zadne cizi veci ,ale i zadne databindery - proste nasypsat veci do tabulky je jednodussi ,nez to co jsi sem dal

Milý sss, alias WELFe: nenasypeš - musíš na to použít cyklus. A i když to nakrásně nasypeš nějakou smyčkou, pro propisování hodnot do DB při každé změně DataGridu budeš muset napsat další kód (WindowsForms DataGrid nabindovaná data v databázi aktualizuje sám, ASP.NET DataGrid poloautomaticky). A i když ty data budeš zapisovat z tabulky do databáze (v té chvíli ovšem tvůj kód v Javě bude mít více než sto řádek, pokud bude stále umět současně podporovat filtrování a řazení záznamů - můj DataGrid umí sám od sebe), tvoje tabulka stále nebude relační (všimni si těch linků na relačně svázaný tabulky v mý ukázce). Odhadem bys na emulování základní funkcionality DataGridu v mojí ukázce potřeboval několik tisíc řádků Java kódu.

Jinak pro představu - mých deset řádků je kompletní Panel aplikace, včetně nadefinování relací a naplnění tabulky - to ostatně v mojí ukázce obstarává jediná metoda.

Jen zapominas, ze k tomu potrebujes ovladac databaze pro ODBC od treti firmy (obdoba tech beanu nebo klasu tretich stran).

JEZIS!!!

No to je novinka to je uplna bomba. Nahodou neco o JRE i o .NETu vim a muzu tyto API srovnat. Pokud budeme srovnavat .NET OLEDB a JDBC3 pak jsou to naprosto totozne technologie se kterymi jde stejne efektivne pracovat.

Jinak absolutne jste nepochopil, co je hlavni myslenka .NET OLEDB. Je to naprosto stejny jako u Javy, tj. ze ovladac, ktery implementuje toto API *POTREBUJETE*. Jenomze vy asi pristupujete jenom do Accessu nebo MSSQL, ktery tam uz jsou predinstalovany... Takze vam to ani neprijde.

Pro Javu existuje hafo ovladacu (vic nez pro .NET) a jak komercni tak i zadarmo (stejne je to u .NETu to mi verte). Pokud si ale zakoupite nejaky profesionalni nastroj (za stejnou cenu jakou date dejme tomu za MS VS), pak obvykle dostanete s timto nastrojem balik kvalitnich ovladacu. Coz u MS VS nemate. Takze bych to shrnul...

.NET OLEDB ma zatim do Java JDBC daleko :)

Nene nezakladejme novy flame, na ten tu neni sirka :)) Technologie jsou to minimalne srovnatelne...

Já nový flame zakládat nehodlám - na druhý straně vaše obavy z mý odpovědi tak trochu chápu...;-) Především věta že .NET OLEDB ma zatim do Java JDBC daleko je tak trochu nesmysl, protože něco jako ".NET OLEDB" v .NETu neexistuje. Existuje tu jen OLEDB provider pro ODBC datový zdroje, ale pro MS SQL nebo Oracle existuje samostatná datová vrstva. Ale ta hlavně nepředstavuje základ databázových technologií .NETu, to je jenom datová pajpa - "trubka na data".

Základem DB technologií je vrstva ADO.NET což je v kostce engine pro in-memory replikační XML databáze. Myslím, že schopnost JDBC3 končí někde kdesi u odpojených datasetů (CachedRowSet) a sortování a filtraci rowsetu - ale už nepodporuje fíčury klasického ADO (datashaping, hiearchický, vícenásobný a relační rowsety a recordy, distribuovaný datový zdroje a persistenci a indexaci datasetu - a to jsme stále u klasické, sedum let staré COM technologie - nikoliv .NETu. Ten k tomu navíc přidává referenční integritu a replikační engine. Pomocí ADO.NET lze relativně jednoduše aplikaci vybavit off-line databázovým engine, který cachuje změny v relačních tabulkách (dataset zde není jednoduchý nebo několikanásobný rowset - ale kompletní relační databáze s udržování konzistence, co se týče DRI a datových typů) a při replikaci/synchronizaci je propíše do podkladové databáze.

Pokud ani teď netušíte, co ADO.NET umí anžto ho usilovně srovnáváte s JDBC (a co víc, snažíte se přisoudit tento omyl mě...) - pokusím se objasnit základní myšlenku ADO.NET na příkladu: Mám smart klienta napsaného v .NETu, který si po spuštění v režimu on-line natáhne kompletní data ze všech tabulek týkající se daného konkrétního uživatele včetně constraintů a relací do datové struktury, kterou lze snadno (jediným příkazem) serializovat na disk a vytvořit tak pro klienta jeho vlastní kopii databáze. Off-line uživatel si v ní data šudlá, mění maže a upravuje tak dlouho, než má možnost/potřebu práce v režimu on-line - ADO.NET s datovým vzorkem přitom stále nakládá tak, jako by byl pořád připojený on-line. A nakonec se klient připojí se na server buď přímo, nebo přes middle-tier vrstvu webových služeb a propíše jediným příkazem všechny změny do databáze zpět. V zásadě jde o replikaci dat a v trochu odlehčené a redukované podobě to funguje i po dobu web session na web serveru, kdy třeba uživatel kliká po e-biz serveru semo tamo a modifikuje nákupní košík (zde se ovšem in-memory databáze udržuje pouze v paměti). ADO.NET engine se přitom stará o všechny otázky s tím spojené - třeba replikační identifikátory, správné pořadí update relačně svázaných tabulek při jejich replikaci, optimalizaci - indexaci a datové manipulace, dotazování z DataSetu atd.) - čili zdaleka zde nejde vůbec o nějakou OLEDB nebo SQLDB vrstvu, což je pouze kurzorový engine na nejnižší vrstvě téhle technologie.

A to celé je pěkně prosím součást základní funkcionality .NETu, kterou si stáhnete free z MSDN, je prefektně zdokumentovaná (pokud nevěříte, porovnejte si v Google počet výsledků na "+sort +filter +Rowset" (430 výsledků) a "+sort +filter +DataSet" - 42.000 výsledků) a je pěkně integrovaná do Visual Studia.NET (databinding, design-time containery, atd.) a funguje to pěkně i ve standard verzi VS.NET za 4.000,- Kč (v profi verzi VS.NET platíte za generátory sestav a enterprise rozšíření, ale nikoliv za popsané features).

Jinými slovy, technologie jsou to nesrovnatelné - protože co se DB technologií týče, zde MS staví na více než desetiletých zkušenostech s vývojem ODBC, RDO a OLEDB/ADO.

Pominu-li, že jsem omylem zazěnil dva pojmy (OLEDB s ADO.NET - kdo se v tom má
vyznat, těch zkratek je prostě moc a MS nám to teda moc neleučuje), tak vy
se jenom snažíte přenést diskuzi na vyjmenovávání, co že to vlastně s ADO.NET
lze dělat a poukazujete na to, že to má všechno vestavěno přímo v RT
knihovnách.

Stejně tak tady mohu já začít psát, čeho všeho dosáhnete spojením JDBC a
jiných technologií (mapování objektů, XML, EJB), které většinou seženete jako
open source (což se jeví vždy jako lepší řešení než MS) a jedinou nevýhodou je
to, že musíte stáhnout několik souborů s příponou JAR a přidat je k projektu.
Mohl bych pokrýt všechno, o čem tady dlouhosáhle píšete. Zkušenosti na to mám
a můžete si být jist, že se Vašich odpovědí nebojím. Čeho se bojím jsou ty
úzké nudle, které na rootu vznikají a redakce to ne a ne odstranit. Je to asi
nejslabší stránka roota.

Diskuze se týkala něčeho jiného. Poukázal jste na to, jak efektivně se dá
dělat frontend pro rel. databázi. Uporotnil jsem vás, že toto jde stejně dobře
v Javě, přičemž ovladače třetích stran jsou samozřejmě pro ADO.NET také
zapotřebí. Nevidím důvod, proč se při vývoji omezovat na jedno API, které
poskytuje sadu rozšíření, jež asi stejnak ani nevyužijete. Třeba replikace by
měl podporovat přímo dat. server a pokud je k tomu nutná nějaká emulace v .NET
vrstě, asi byste měl uvažovat o změně serveru. Nehledě na to, že toto
rozšíření nadiktoval a navrhnul Microsoft.

U Javy si můžete technologii vybrat. Kvalitních technologií, které se dají
použít, jsou stovky, možná tisíce. Ať to jsou inmemory databáze, XML,
distribuované datové zdroje, perzistence, objektové mapování včetně
dědičnosti. Co je datashaping nevím, tak podrobně jsem ADO.NET nestudoval,
nicméně je asi jasné, že všechny tyto věci "navíc" musí ovladač nějak
implementovat. Jestli to dělají všechny ovladače to je otázka, kterou Vám
touto formou pokládám a o čemž pochybuji.

Technologie jsou to srovnatelné. Nic nového či převratného podle mě ADO.NET
nepřináší a na té nejnižší úrovni zhruba kopíruje JDBC (teď netvrdím, že MS
okopíroval JDBC, pouze kopíruje) přičemž přidává ty fajnůstky navíc.

trosku (no, hodne) si pletete AWT a SWT... to jsou hrusky a jabka, takze:

AWT - je nepovedene API, ktere bylo nahrazeno Swingem, nejlepsim OO rozhranim pro tvorbu GUI na teto planete

SWT - je API od firmy IBM, ktery dela presne to, co .NET WinForms, tedy rychly okna, problem je, ze je to hure dokumentovane

tak, pro priste uz to vite...

Myslím, že rozdíly mezi AWT, Swingem, IFC/WFC, JFC a SWT chápu.

Co k tomu dodat ? SWT má řadu nevýhod a jeho vývoj ustrnul, takže ho nikomu pro seriózní vývoj doporučit nelze, ale kdyby byl Swing ve své době nejlepší OO rozhraní pro GUI, nevyvinulo by IBM vlastní. A kdyby bylo AWT tak špatné, nepoužívalo by se dodnes javax.swing spolu s java.awt. Většina appletů na webu pracuje s AWT, protože je jednak jednodušší a snáze se programuje, je komaptibilní s MS Java - a v neposlední řadě je rychlejší, než Swing.

Jen bych to doplnil. SWT vzniklo v době, kdy Swing prakticky neexistoval.
Jeho použití je však zavádějící. Nesnaží se nahradit Swing a ani není možné je
srovnávat. Dneska velké programy ve Swingu (IDEA, Netbeans) jsou možná
rychlejší než Eclipse. To je ale můj subjektivní názor.

Jinak dělat aplety tak, aby fungovaly na MS implementaci je holý nesmysl. Já
to vím, protože jsem zruba rok pracoval na projektu, který byl původně
zamýšlen tak, aby pracoval i pod tou jejich chudou implementací Javy, která je
nekompatibilní a pomalá. Ukázalo se, že se to prostě nedá. Nakonec stejnak
aplety smetla technologie WebStart. Aplety už prostě nejsou potřeba, tady už
známe vítěze už dávno - je jím Flash.

AWT je slabé řešení pro správu GUI a bylo to zapříčeněno také tím, že bylo
navrženo narychlo a v době, kdy v jazyku nebyla zakomponovaná jedna klíčová
vlastnost, která dělá programování ve Swingu tak příjemnou. Bohužel se
používají třídy z AWT i ve Swingu, do dneska nechápu proč (uspora místa na
disku?). Toto je jedna z věcí, která me u Javy tíží. Java a její RT API se
dost vyvíjelo a programátor se musí seznámit ve většině klíčových tříd hned s
několika verzemi a vědět, jak se to dělalo dříve a jak se to doporučuje dělat
nyní. Stejné to nebude ani s Javou 1.5 ačkoliv by měly být změny zpětně
kompatibilní. Tady spatřuji výhodu hlavního konkurenta: .NETu.

Jak můžete říci že vývoj SWT ustrnul? Stačí se podívat na stránku projektu
Eclipse a hned zjistíte, že se připravuje verze 3.0 s mnoha vylepšeními právě
pro SWT. Nic tady netrne a SWT je prostě alternativa pro ty, kteří třeba
Swing použít nemohou (GCJ, diskety a podobně).

Když už se mluví o soudu, tak ve skutečnosti došlo mezi MS a Javou k mimosoudnímu vyrovnání. Z nějakých důvodů ovšem Sun začal porušovat podmínky tohoto vyrovnání, a to i přesto, že MS všechny podmínky plnil a plní.

Pravděpodobně se projevila skutečná, tedy i ta nepěkná tvář firmy Sun.

To jen pro upřesnění soudu o úmyslné zanášení nekompatibilit. Po mimosoudním vyrovnání mimo jiné se Sun písemně zavázal, že jsou vyrovnáni, a že nejsou mezi nimi žádné závazky a nedořešené otázky. Sun za to dostal slušný paklík dolarů. Součástí dohody byla i možnost instalovat velmi starou verzi MS Javy po dlouhý čas do Windows.

Sun ovšem dohody dodržovat nemusí, nebo si to aleposň myslí...

jinak bych chtel rici ,ze s podobnou diskuzi koncim - malo faktu ,mnoho kecu - mejte se ,na flame si utikej zpatky na mageo :) F/U/Z/J :)))

windows sice budou akcelerovat :))))

jenze novy windows vyjdou az tak za dva roky :))))))

takze mas smulu, bwhahahaaahah

java rulez, java ownz!

Kdo se směje nejlíp...;-)

ASP.NET controls, ktere jsou standardne nabizeny jsou nechutny perverzni bastl, vedle ktereho vypada dort Pejska a Kocicky jako gurmanska pochoutka. A nemluvim o koncepci, mluvim o implementaci -- nakonec zjistite, ze je snazsi to vubec nepouzivat, nez se neustale piplat s tim, vsechny ty blbosti povypinat a ty co nejdou alespon neutralizovat. Takze s takovym vizualnim designem jdete do ........ (kdzy si doplni svoje oblibene misto).

Jak se dají ASP.NET controls povypínat nebo aspoň neutralizovat ?

MS soud kvůli poškozování Javy neprohrál, podívejte se, prosím, jak to bylo, než začnete psát bludy. MS a Sun se spolu mimosoudně vyrovnali.