Strucna historie Swingu (diskuse)

[changeit]

swing nie je zly, na vsetko si mozem urobil vlastny model,renderer, atd... Ale niekedy ma nebavi ze pre zobrazeie udajov v tabulke si musim spravit vlastny model,rovnako sortovanie.

[Luk]

Byl jsem zvyklý dělat ve Swingu. Pak jsem byl nucen začít tvořit v MFC. Bylo to jako kopanec do zubů. Čistota psaní kódu byla pryč, pořád jsem narážel na to, že to či ono nešlo. Musel jsem si vytvořit spoustu vlastních tříd, abych byl vůbec schopen rozumně vyvíjet GUI. Swing není vůbec špatný - má některé neduhy, ale nedám na něj dopustit.

[finc]

Az na nektere komponenty (typu JTree a JTreeModel, implementace listu a vubec vsude, kde je "Vector") je to velice pouzitelne.

Myslim, ze dnes jiz neni pravda, ze by java desktop nemela sanci. I kdyz se Sun spise zameruje na server-side, je videt velky pokrok v rychlosti. Driv jsem swing aplikace pouzival z nutnosti, dnes mi je jiz jedno, zda je to GTK aplikace ci java aplikace. Jsem dost zvedavej, zda JavaFX nejak zamicha timto segmentem.

Jinak pri spojeni s NetBeans platformou je mozne tvorit skutecne kvalitni a profesionalni aplikace. Takze, kdo ma moznost, at nevaha :))

[alblaho]

Momentálně Javu na desktopu zabíjí delší start aplikací a nutnost "rozehřátí" (jit), než to začne opravdu šlapat.

Takový Python je mnohem pomalejší, než Java. Ale Python+(GTK|Qt) je super, protože a) nativní toolkit je nativní toolkit, b) rychle to startuje.

[bořek]

Este bych dodal, ze nejvetsi vyhodou Swingu proti AWT je, ze Swing je navrhnuty podle patternu Model-View-Controler.

[alblaho]

Tak SWING je v něčem rychlejší než GTK?

Tak zaprvé, opravdu věřím, že SWING a nové verze JVM doznaly opravdového zrychlení.

Zadruhé, GTK bývá kritizován za pomalost a v benchmarcích se třeba s Qt asi nemůže moc srovnávat.

Ale stejně je pro mě GUI ve SWINGu subjektivně pomalejší. Podle mě za to může GC, který způsobí občasné zaseknutí (i když samotné překreslení je třeba rychlé dost). GUI to je v podstatě soft-realtime záležitost, sice opravdu nehrozí, že při nedodržení deadlinu spadne letadlo, ale hrozí, že lidské oko zachytí záškub.

Tuhle smělou teorii podporuje i fakt, že SWT eclispu taky nějakou zázračnou rychlost nepřinesl.

[Trained.Monkey]

Swing mel rychlejsi vykreslovani komponent. Uznavam ze ten test nebyl zcela ferovy, GTK v te dobe nemelo 2D akceleraci...

Ad GC, myslim ze soucasny je ve vlastnim threadu a nezpusobuje zamrzani. Spis bych vydel ze neco delsiho se deje v AWT threadu a GUI nemuze prekreslovat.

[Ladicek]

Ad GC, myslim ze soucasny je ve vlastnim threadu a nezpusobuje zamrzani.

Defaultní GC je pořád jednovláknový Stop The World. Ale můžu si vybrat i paralelizovanou variantu, a dokonce i variantu, která ostatní vlákna neblokuje. Tedy na víceprocesorovém stroji, mám pocit, že jeden procesor si v takovém případě vlákno GC uzurpuje pro sebe

[alblaho]

To jako JVM umí tech algoritmů několik a při startu se to dá opšnou nastavit? Já žiju v tom, že je tam jenom stop-the-world mark'n'sweep. Ono udělat paralelní GC (natož pak realitmový) asi nebude žádná prdel.

Python má obyčejné počítání referencí a žije. A je to docela deterministické. Tedy do té doby, než se pustí detekce cyklů.

[Kyosuke]

Ono to těch parameetrů má docela dost. Jinak třeba RScheme by mělo mít deteministický GC úplně - nějak mi není jasné, jak to dělají, ale prý to nějak funguje.

[Ladicek]

Já mám radši tenhle seznam

[Ladicek]

To jako JVM umí tech algoritmů několik a při startu se to dá opšnou nastavit? Já žiju v tom, že je tam jenom stop-the-world mark'n'sweep.

Přesně tak. Teda ne úplně přesně, ony ty algoritmy jsou v podstatě pořád stejné, akorát si můžeš vybrat, jestli chceš jedno- nebo vícevláknový a blokující nebo neblokující ostatní vlákna. Jinak GC je generační, pro první generaci se používá něco na způsob kopírovacího algoritmu, pro druhou mark and sweep.

No a aby toho nebylo málo, tak teď vyvíjejí ještě úplně jiný (G1).

Ono udělat paralelní GC (natož pak realitmový) asi nebude žádná prdel.

No to není. On i ten "neblokující" algoritmus na dvě krátké chvilky všechna ostatní vlákna zablokuje A už se mi jednou stalo, že kvůli nějaké chybě v jeho implementaci JVMko spadlo.

Jak to řeší v realtime Javě, tak to už vůbec netuším.

[Karel]

Me se porad zda je java je v gui pro desktop tak 5 let za .NETem... viz GUI komponenty od devexpress.com a infragistics.com, to ekvivalent v jave proste nema

[changeit]

suhlasim, este aj stare delphi 7 bolo na desktop RAD lepsie ako java.

[Karel]

Ale proc s tim nekdo (SUN) neco nedela???

[Filip Jirsák]

S tím, že nějaká firma svoje komponenty neportovala i do Javy? Třeba proto, že na tu firmu nemá Sun žádné páky, a asi ty komponenty nikomu tak moc nechybí (jinak by je naprogramoval).

[Karel]

Ne, ze kdyz uz ty komponenty pro javu nejsou, ze je SUN nenapise

[Filip Jirsák]

Asi ty komponenty nikomu tak moc nechybí (jinak by je naprogramoval).

[Karel]

Hm, a pro .NET je tech firem asi 20, co vyviji takoveto komponenty (co znam ja....),takze je to mozna opravdu spis o nevhodnosti javy pro desktop app.... nemluve o treba GIS pro .NET: http://www.geoframeworks.com/Products/GIS/

[Filip Jirsák]

Co je na těch komponentách tak extra? Existují desítky nebo stovky projektů s komponentami pro Swing. GIS komponenty pro Javu také existují. Takže asi bude potřeba napsat, v čem je rozdíl – z jednoho screenshotu se opravdu nepozná, co je na té které komponentě tak úžasného.

[Karel]

no, ono se to blbe popisuje, ale obecne mi java komponenty pro deskop prijdou na 1/2 cesty, nic moc vzhled, 1/2 moznosti, proste celkova "profesionalita" tech komponent je nizsi. Pro .NET vetsiou najdu firmu, jejiz komponenty v dane oblasti jsou opravdu spicka (viz tento GIS, nebo devexpress, infragistics, telerik, xceed pro GUI), kdyz chci neco obdobneho pro javu, tak to 1/2 veci neumi a stejne funkcni app v tom budu vyvijet 3x delsi dobu... ted se nebavim o jave na serveru,kde ma opravdu sve misto, sam v ni delam v SAP Netweaver developer studiu

[Filip Jirsák]

Já právě nevím, co by mělo být to navíc. Existuje pár základních komponent, které představují jakési GUI vzory, které uživatelé znají a umí je ovládat. Všechny takové komponenty Swing má, a můžete je dál hodně rozšiřovat. Vymýšlet novou komponentu je dost riskantní podnik a nedaří se to ani takovým třídám jako je MS. Já netvrdím, že nemohou existovat komponenty, které pro Swing nejsou a chybí – ale vždycky, když se začne mluvit o desítkách výborných komponent, vybaví se mi desítky líbivých zbytečných komponent.

Pak jsou samozřejmě další komponenty vzniklé poskládáním dílčích komponent, typicky kalendář. Ale i na to má Swing myslím dost komponent. Třeba MiG calendar nebo komponenty od JIDE software. Možná jsou ty .NET komponenty lepší, nedokážu to posoudit, protože jsem tenhle typ komponent kromě těch nejjednodušších (jako kalendář) nikdy nepotřeboval.

[Karel]

No prave M$ na to ma ty dalsi firmy, MS udela zakl. balik. Ja netvrdim, ze se ty komponenty v jave nedaji napsat, samo daji,ale mozna o neco hur nez pro .NET, mozna, pokud by meli mit stejny vzhled, tak zaplati dan za multiplatformnost javy v podobe rychlosti, takze vysledek je ten, ze tyto "pekne" GUI komponenty pro RAD pro javu nikdo moc nepise, pac vi, ze .NET v tomto mozna bude lepsi....

[podlesh]

Hm, a pro .NET je tech firem asi 20, co vyviji takoveto komponenty (co znam ja....),takze je to mozna opravdu spis o nevhodnosti javy pro desktop app....

Je to především tím, že .NET je v současné době primárním prostředím pro psaní Windows aplikací. Což má vliv jak nepřímý (tj. firmy dělají komponenty), tak přímý (tj. Microsoft si s tím dáva opravdu velkou práci - je to důležitější než celý kernel Windows a Office dohromady).

[Trained.Monkey]

Delam s Jide components, www.jidesoft.com. V cem konkretne zaostava?

[Karel]

No, devexpress poskytuje opravdu komplexni balik komponent pro GUI (jak pro winforms, tak pro asp.net)

konkretne treba xtragrid: kompletni zdrojovy kod

velice snadny design-time binding na data

design time designer gridu, primo ve visual studiu: http://www.devexpress.com/Help/?document=XtraGrid/CustomDocument805.htm&levelup=true

podpora master-detail podpora skinovani (pro vsechny komponenty od devexpress) velice snadno zmenite vzhled cele aplikace moderni vzhled - gradient prechody velice privetivy programovy model gridu

a tohle vsechno plati pro dalsi komponenty od devexpress napr. zajimavy je lookupedit: http://www.devexpress.com/Help/?document=XtraEditors http://www.devexpress.com/Help/Content.aspx?help=XtraEditors&document=clsDevExpressXtraEditorsLookUpEdittopic.htm

xtrareports, dalsi perfektni nastroj: http://www.devexpress.com/Products/NET/WinForms/XtraReports/features_allinone.xml http://www.devexpress.com/Products/NET/WinForms/XtraReports/features_layoutoptions.xml http://www.devexpress.com/Products/NET/WinForms/XtraReports/features_enduserdesigner.xml

a tuna dalsich veci....

Myslim, ze pokud si to poradne projdete, zjistite, jako ja, ze java v tomhle opravdu zaostava....

[Pavel Stárek]

podpora skinovani (pro vsechny komponenty od devexpress) velice snadno zmenite vzhled cele aplikace moderni vzhled - gradient prechody

Ano, toto je opravdu "strašně důležité". Jestli by nebylo lepší se zabývat funkční stránkou aplikace, než tím, že si potencionální uživatel bude moci změnit skin v aplikaci. Nedalo mi to, ale musel jsem si rýpnout. Povšechně v Javě mě chybí (i když teď už sem v ní nic desktopového nedělal, takže nevím kam se hnul vývoj) nějaké rozumné swing komponenty s databázovým bindingem - svého času byly relativně rozumné součástí borlandího JBuilderu.

[Karel]

Ano, krasne jste vypichl jednu z mene dulezitych veci meho postu, s ostatnimi tedy souhlasite? (i kdyz na vzhledu app taky zalezi, podivejte treba na iPhone manii), jenze u tech komponent jde o vice veci (treba ten binding, ktery zminujete je u devexpress docela promakany, dale treba nastaveni masky editoru, podpora regexu, je toho opravdu strasne moc, co ty komponenty umi), ktere vyvoj app pote strasne zjednodusuji a ulehcuji...validace napr.. Jasne, vsechno napisu i v jave, ale takovou typickou kancl app. s napojenim na DB napisu proste v .NET 2x,3x (hruby odhad, prosim nekamenovat!!!) rychleji (a tudiz levneji), mam ji driv nez konkurence treba (coz muze rozhodovat o uspechu)

[alkoholik]

No a tom uz by se dalo hadat. Ja jako byvaly programator po par letech sahnul na Javu a Hibernate.
Clovek napise par anotaci a o databazi se uz nemusi v jednoduche kancelarske aplikaci dal starat. Dokonce to mi vytvori podle trid tabulky.
V Netbeansech je GUI pres klik klik klik a hotovo.
A flamovat nebudu, naposledy jsem psal velke veci pred 5 lety. Adminovani je vetsi zivacka, stejne placena, tak jsem utekl.
:P

[Karel]

Tak ja v praci taky adminuju SAP, obcas teda napisu neco ve webdynpru Java, ale tak bokem pisu nejake kancl app a prave v .NET no :) zivit se je potreba hadat se nechci, spis jen se treba dovedet, ze java je v tomto dal, nez si myslim a nez jsem objevil

[Trained.Monkey]

Delam s Jide components, www.jidesoft.com. V cem konkretne zaostava?

[xkucf03]

Zakladnim problemem Swingu je jeho slozitost. I primitivni JButton ma stovky metod.

Na tom nesejde, SWING je taková knihovna, ze které si člověk vyzobává to, co zrovna potřebuje. To že má tlačítko x metod, nevadí. Nejjednodušší aplikaci prostě začneš s jedním tlačítkem, textovým polem, metodami getText(), setText() a jednou událostí.

S těmi správci rozvržení je to trochu pravda, ale pokud člověk používá NetBeans, tak se s tím velmi rychle vyrovná.

Pokud jde o nevýhody Swingu, tak vidím dvě: dost komponent člověk musí suplovat knihovnami třetích stran (třeba open source SwingX) a to, že pod Windows vypadá nativně, zato v Linuxu je to pořád dost mizerné, zvlášť v KDE. Ale vynahradit se to dá look&feely, takže ty aplikace pak vypadají dobře, jen trochu jinak.