The future of java

11.4.2006 19:59 | Přečteno: 3931× | Java

Tento krátký esej vznikl jako úkol do předmětu Advanced Java Programming, který letos opět učil pan Roman Szturc z Vysoké Školy Báňské, na Univerzitě aplikovaných věd v Jyväskylä, kde momentálně studuji. Rozhodl jsem se jej zde zveřejnit, snad v něm někdo zajde něco zajímavého. Je mi jasné, že se nejedná o žádné veledílo, a jistě také obsahuje množství nepřesností nebo chyb, pokud budete chtít, neváhejte napsat svůj názor. Doufám, že než další flame na nějaké profláklé téma, tady spíše případně vznikne zajímavá diskuze

Takže zde je esej, v původním znění, bez titulků, pouze se zjednodušeným formátováním aby šel vložit na abíčko:

This short essay was written as optional work to "Advanced Java" course taught in winter semester on Jyväskylä university by Mr. Roman Szturc (Technical University of Ostrava). Given topic was "Future of Java" and I will mostly concentrate on topic which I find quite interesting, and that is usage of native operating system facilities in Java in general, as well as support for usage of native GUI components in desktop applications.

Java was from its origin intended as platform independent language. SUN has always put great emphasize on portability ("Write once, run anywhere"), which is of course very usable and important feature, but it also brings some disadvantages - one of most painful is sometimes quite bad performance [1) I don't intend to spread the "java is slow" FUD, theese days java performance is generally very good, but there's always something to improve, most notably regarding speed of GUI applications] It is of course not only caused by Java's portable nature, but also by other factors like increased type-checking etc. Still it's obvious that some things simply can't be made that efficient as in lower level languages. Another thing, which many users find annoying is different look of GUI applications written in Java. While this is not very obvious on Windows operating systems, for example on Linux difference is much more evident (this is also given by fact, that generally usage of various widget themes is very spread in world of Linux, and every major Linux vendor usually has it's own theme). And it's not only look, but also feel - one of most annoying things is usage of nonstandard file dialogs. Mentioned problems can be (at least partially) solved by usage of various operating system facilities and components. Why could not Java application executed under GNOME desktop environment use GTK widgets and file dialogs? Or QT under KDE? Why use poll() call, if under Linux 2.6 kernels is epoll(), which is much more efficient and scalable? Of course, these things seem to be against philosophy of Java, but when made properly, portability can be retained, while gaining new advantages.

Why so suddenly?

While things have been slowly improving during all development of Java, it seems that development's gaining faster pace and things are improving much more these days (well, not exactly days of course, this is visible for longer time, but compared to all Java's lifetime, it's obvious that SUN's striving much more now). What happened? In my opinion there are two reasons: One of them is of course aggressive onset of Microsoft .NET platform. Microsoft took good care not to repeat many of java's childhood errors, and it's indisputable that .NET is very good platform, even though it has some vices. So SUN has to try hard to retain position it acquired and to grow even more. Second reason is increasing popularity of IBM supported open-source IDE platform Eclipse and other applications using SWT toolkit (ie Azureus). While SUN kept complaining that whole SWT philosophy is against Java principles, they must have realized that SWT applications have one big advantage over AWT or SWING ones: much better integration. Support for themes, native file dialogs, "native behavior", systray support - those are properties standard Java GUI applications supported only poorly, if at all.

What's new and what's to be expected

As it was already fore-mentioned, two main topics will be briefly covered in this essay. One of them is usage of native low-level operating system facilities resulting various performance improvements etc, and other is better integration of desktop applications, regarding GUI look & feel. Finally some notes about usage of libraries and frameworks written in other languages then Java will be mentioned.

Usage of advanced operating system facilities

Java have of course always used various services provided by operating system (not everything can be done by JVM - things like low-level networking, disk access, etc). And NIO package introduced in Java 1.4 proved, that extensive usage of those services can bring considerable improvement of performance. While some of the changes were made so to say "under the hood", bringing improved performance by optimizing of functionality of various existing classes (ie in package java.io.*), other brought brand new possibilities (techniques widely used for example in UNIX systems - memory mapped files, scatter-gather, etc). Java 1.5.0 has not brought any special news in this area, but there are some new interesting features in coming java 1.6.0. One of them is support of epoll() system call in implementation of NIO Selector, on systems running Linux 2.6 kernels. On Linux epoll() can be used to substitute traditional poll() event polling mechanism. This can greatly improve performance in some cases (users have reported even 95% CPU usage reduction in some cases with tens of thousands simultaneous connections). Interesting thing is, that this feature has for quite long time been already implemented in Blackdown java implementation and it's also not first such improvement in SUN's java - implementation of JVM on Solaris has been using improved it's specific /dev/poll mechanism for long time. I think that this kind of improvements is very useful, because it can bring considerable performance improvements, while retaining portability - on platforms which support more advanced resources, those are used, on platforms which don't, those are emulated or done in standard way and developers don't have to care about it - all is transparent.

Improvements in area of desktop applications

As was already stated, SWT toolkit is becoming very popular, and widespread. As some of it's features are arguable, it's obvious that it brings a lot of advantages, and has been taken very well by users. And of course many common users don't really care about philosophy - they simply want solutions that work well for them. So instead of whining, SUN finally decided to counter in best possible way - by improving Java's weak areas. So lots of new features and improvements have been announced in upcoming Java 1.6 (Mustang), most of them can already be tried using publicly available beta versions.

Look and feel

So finally it seems that even swing applications will look and behave more "native" even under operating systems other then MS Windows. Linux users will probably be happy to find, that native support for GTK toolkit has already been integrated to Mustang. So Swing applications will be able to properly use user's selected theme, and also things like file selection dialogs should not be different now. Of course people using KDE desktop environment or people who simply prefer QT applications still won't be very happy, because there is no support for native usage of their preferred toolkit, and it even can't be expected (at least not soon), because QT is freely available only under more "aggressive" GPL license, while GTK is available under LGPL license. Only two possibilities would be, that either Java would be released under GPL compatible license, or SUN would pay for commercial license of QT toolkit. Well, neither of choices seems to be very likely, but who knows, maybe time will bring some surprises.

Notification area (systray) support

While it became quite bad habit, that virtually every MS Windows application has to use some kind of systray integration without real need, sometimes it can be useful. Especially for applications that are usually running for long time with only occasional user's interaction, like download programs, music players etc. SWT toolkit already supported systray integration, and it works well at least under both Windows and Linux (for example popular bittorrent client Azureus supports that), and now Mustang supports it too.

Something for gamers

Games (and generally multimedia) are kind of applications, which are usually especially performance demanding. For this reason, usage of various hardware acceleration features is very important. While this can be of course all implemented purely in Java, using only low level operating system drivers, it probably is not the best possible way. Smart combining of Java with libraries written in lower level languages can bring surprising results.

JOGL

JOGL is Java binding to popular OpenGL library. OpenGL is widely used open standard for three dimensional graphics and years of usage in various applications like games, but also more professional software like CAD systems has proved it to be very mature. It brings support for various features provided by modern graphics cards and hardware vendors take good care so all of them are well supported in drivers and also OpenGL libraries, because of big popularity of games. [2) this is unfortunately really true only for MS Windows platform, support for other systems is sometimes bit worse. While Nvidia is quite OK, ATI support really sucks.] Examples on the project webpage are quite nice, but what is really impressive is Jake 2 project. Jake 2 is reimplementation of ID software's open-sourced game Quake 2, done purely in Java, using JOGL (and also JOAL, more on it later). Very interesting is comparison of frames per second achieved in Jake 2 and in original C version of game. It shows, that not only Java version has almost as good performance as C one, but in some cases it even outperforms it. Of course this is not 100% fair, as Java version probably already contains optimizations not contained in original game, but important is that it IS possible to make games in java.

JOAL

JOAL is java binding for OpenAL library. Similarly to OpenGL, OpenAL is library for advanced sound support, including various effects, three dimensional sound support etc. It supports usage of hardware accelerated effects provided by modern sound cards. While JOAL can't of course provide such impressive examples as JOGL, it can still be considered very useful. Between others, JOAL is also used by Jake2 project.

Conclusion

As it was fore-mentioned, increasing pressure of Microsoft's .NET platform, IBM products, and also various free solutions (like aggressive pushing of free and open-source implementations of various Java software, starting with JVM self [3) though here it's something little different, because tools like GCJ are used, compiling java not only to byte-code, but also into native binaries], Eclipse and application servers by Red Hat and other vendors) is forcing SUN to try harder and speeding up development. And it is for sure good for both end-users and developers.

Related links: http://blogs.sun.com/roller/page/alanb?entry=epoll http://download.java.net/jdk6/docs/api/java/nio/channels/Selector.html http://ensode.net/java_swing_mustang_screenshots_gtk.html https://jogl.dev.java.net/ https://jogl-demos.dev.java.net/ https://joal.dev.java.net/ http://www.bytonic.de/html/jake2.html        

Komentáře

[Luboš Doležel (Doli)]

Pěkné. Češtinářský dotaz: esej je rodu mužského?

[Martin]

Jako maturant (zítra píšu maturitní písemku :o)) musím říct, že esej může být jak rodu mužského, tak ženského. Obě možnosti jsou správně.

[Nikola Ciprich]

uff, diky, uz jsem si malem chtel zacit sypat popel na hlavu, pac 100% jisty si tim nejsem jak tak nad tim uvazuju ;).

no hodne stesti u maturity :o)

[Martin]

Není zač. Je fakt, že já bych spíš mluvil o eseji v ženském rodě, ten esej mi zní podivně. Ale správně je obojí...

Díky moc, budu to fakt potřebovat. Ještě před nedávnem bych neřekl, že z toho budu mít docela bobky. Ale čím víc jsem přemýšlel nad tím, jaká šílená témata nám může říďa vybrat, tím víc nejistej jsem si začal bejt. Kór když jsem si pak přečetl na netu příklady naprostých šíleností, který psali jinde, to už mi začalo bejt fakt ouzko...

[Nikola Ciprich]

no jo, hruzou z maturity si prosel kazdy kdo to zkusil. a vsichni pak rikaji jak to bylo lehke. zvlaste kdyz nastoupi na vysku. to se pak pomalu kazda zkouska zda horsi nez maturita

jinak s tim ten/ta esej mate asi pravdu, ta zni lepe. no taky by mne zajimaly pripadne pripominky k anglictine, nektere konstrukce se mi zdaji celkem neohrabane, a dost casto nektere fraze opakuju, ale vzhledem k tomu s jakym spozdenim jsem to psal, tak to byla celkem rychlovka - klasika, spousta casu, ale stejne se to pak pise na posledni chvili po nocich.

no a k obsahu pripominky nikdo nema? zadna kritika, opravy a tak?

[happy barney]

k obsahu eseje?
moj osobny nazor je, buducnost javy nesie skratku rip. ono, povodne motto sa zmenilo na "write once, run on 4 platforms" (Linux x86, Solaris x86, Solaris SPARC, windos x86).

navyse, JNI ta priviaze na tu jednu konkretnu platformu. Nevraviac o tom, ze vyuzivanie action-handlerov v konecnom dosledku vedie k mnozstvu anonymnych tried.

pre mna osobne je java prilis obmedzujuca. je to jazyk pre drevorubacov.

uznavam, navrhnut vykonny jazyk s cielmi povodne propagovanymi javou je tazke, v konecnom dosledku by sa clovek dostal k MVC, kde M a V su len deklarativne, interpretovane jazyky. Skutocna prenositelnost (v mojom pohlade) znamena, ze rozne casti systemu dokazes prenasat medzi roznymi dodavatelmi, ze mas jednoznacne a otvorene definovany kazdy interface. tuna imho je velky priestore pre open-source teoretikov )

[Nikola Ciprich]

k obsahu eseje? moj osobny nazor je, buducnost javy nesie skratku rip. ono, povodne motto sa zmenilo na "write once, run on 4 platforms" (Linux x86, Solaris x86, Solaris SPARC, windos x86).

Myslim ze tak hrozne to neni, pokud zrovna nejde o veci jako zminovany JOGL/JOAL, tak minimalne Free BSD a MacOSX jsou v pohode (a na MacOSX bezi ostatne i ty knihovny a zminovany Jake. Pokud jde o cistou javu, tak myslim ze prenositelnost je velice slusna.

navyse, JNI ta priviaze na tu jednu konkretnu platformu. Nevraviac o tom, ze vyuzivanie action-handlerov v konecnom dosledku vedie k mnozstvu anonymnych tried.

ale to nepopiram, take to ostatne zminuju, ale jak rikam, pokud napisete ciste javovou aplikaci, tak na tento problem nenarazite. a aplikaci vyuzivajicich JNI opravdu zas tak moc neni...

pre mna osobne je java prilis obmedzujuca. je to jazyk pre drevorubacov.

tak k tomu nevim co bych napsal, nevim jaka omezeni mate na mysli (i kdyz spousty jsem si samozrejme vedom ;)

Skutocna prenositelnost (v mojom pohlade) znamena, ze rozne casti systemu dokazes prenasat medzi roznymi dodavatelmi, ze mas jednoznacne a otvorene definovany kazdy interface.

Ale toto je prave podle mne neco co v jave funguje docela solidne. Neni to ani tak o jazyku, jako spise o podpore tech rozhrani dodavateli, coz samozrejme vzdycky trosku skripe, protoze to nikdo z nich doopravdy nechce. Ale s javou zde myslim fakt neni problem, a ostatne pri rozumnem pouziti reflexe toto muze fungovat i kdyz treba rozhrani nejsou uplne stejna, nebo nektere komponenty implementuji i neco navic. Krasna ukazka myslim je, ze je ve vyvoji API, ktere umozni pouzivat mnozstvi pluginu jak pod eclipse, tak pod netbeans. Az tohle bude fungovat, tak to bude opravdu fajn...

[happy barney]

Myslim ze tak hrozne to neni, pokud zrovna nejde o veci jako zminovany JOGL/JOAL, tak minimalne Free BSD a MacOSX jsou v pohode (a na MacOSX bezi ostatne i ty knihovny a zminovany Jake. Pokud jde o cistou javu, tak myslim ze prenositelnost je velice slusna.

ono aj ciste C alebo C++ je prenositelne velmi slusne . nemal som na mysli teoreticku schopnost jazyka, ale realnu migraciu programov.

tak k tomu nevim co bych napsal, nevim jaka omezeni mate na mysli (i kdyz spousty jsem si samozrejme vedom ;)

ok, veci ktore mi vadili (javu od verzie 1.5 uz nesledujem, mozno sa nieco pomenilo alebo chysta zmenit)

• chybajuci overloading operatorov
• zakladne typy nie su objekty, objektove reprezentacie sa nedaju zmysluplne pouzit v algoritmoch
• chybajuca viacnasobna dedicnost. kazdy projekt, na ktorom som pracoval, trpel problemom cut&paste prave kvoli tomuto. samozrejme, da sa to vyriesit odsunutim implementacie metody do inej triedy, ale ta rezia ...)
• absencia premenliveho poctu argumentov - napriklad inicializializacia hashtable
• striktna previazanost jeden subor, jedna public trieda a opacne - v konecnom dosledku to viedlo k zdrojakom velkosti radovo desiatky kB. tu by som navrhoval moznost implementovat jednotlive metody v separatnom subore

aby som nebol len kriticky, myslim, ze samotne design patterny vznikli prave na obchadzanie a riesenie roznych obmedzeni javy

Ale toto je prave podle mne neco co v jave funguje docela solidne. Neni to ani tak o jazyku, jako spise o podpore tech rozhrani dodavateli, coz samozrejme vzdycky trosku skripe, protoze to nikdo z nich doopravdy nechce. Ale s javou zde myslim fakt neni problem, a ostatne pri rozumnem pouziti reflexe toto muze fungovat i kdyz treba rozhrani nejsou uplne stejna, nebo nektere komponenty implementuji i neco navic. Krasna ukazka myslim je, ze je ve vyvoji API, ktere umozni pouzivat mnozstvi pluginu jak pod eclipse, tak pod netbeans. Az tohle bude fungovat, tak to bude opravdu fajn...

hej? vyskusajte si pouzivat rozne J* interface z inych programovacich jazykov
to je vsak debata viac na mailing-list ako na diskusiu pod blogom (a uz by som navyse aj mohol dnes zacat pracovat)

[Nikola Ciprich]

ono aj ciste C alebo C++ je prenositelne velmi slusne . nemal som na mysli teoreticku schopnost jazyka, ale realnu migraciu programov.

jakou migraci mate na mysli? popularni javove programy se vetsinou pouzivaji na vsem moznem (windows, linux, macky), takze ani v realu to nebude tak spatne ;). i kdyz uznavam, ze existence separatnich balicku pro ruzne platformy trochu vypovida i o tom, ze to neni uplne bez problemu. i kdyz casto jde jen o ruzne instalatory atd.

ok, veci ktore mi vadili (javu od verzie 1.5 uz nesledujem, mozno sa nieco pomenilo alebo chysta zmenit)

no nektere z tech veci uz jsou opravdu resene prave v 1.5, ale to Vas uz asi nenalaka co?

chybajuci overloading operatorov

to je jedna z veci ktera podporovana neni, a myslim ze nejspis ani nebude. osobne prinos pretezovani operatoru povazuju za minimalne diskutabilni, i kdyz nekomu to asi muze chybet...

zakladne typy nie su objekty, objektove reprezentacie sa nedaju zmysluplne pouzit v algoritmoch

to je prave jedna z veci ktere v 1.5 doznaly vcelku podstatnych zmen...

chybajuca viacnasobna dedicnost. kazdy projekt, na ktorom som pracoval, trpel problemom cut&paste prave kvoli tomuto. samozrejme, da sa to vyriesit odsunutim implementacie metody do inej triedy, ale ta rezia ...)

k vicenasobne dedicnosti asi tolik co k pretezovani operatoru. v jave k tomu proste slouzi implementace rozhrani a oddelene tridy, jak jste napsal. ze by si nekdo stezoval na prilis velkou rezii vidim poprve, i kdyz nejaka jiste bude...

absencia premenliveho poctu argumentov - napriklad inicializializacia hashtable

promenne pocty argumentu uz jsou take podporovane, i kdyz jestli primo podpora v hashtables ani nevim...

striktna previazanost jeden subor, jedna public trieda a opacne - v konecnom dosledku to viedlo k zdrojakom velkosti radovo desiatky kB. tu by som navrhoval moznost implementovat jednotlive metody v separatnom subore

nevim, ja se vzdycky snazim skladat kod spise z mensich fragmentu, i kdyz vzdycky to asi taky neni mozne. ale ani obrovske tridy mi zase problemy nedelaji, ale dokazu si predstavit ze pro lidi co jsou zvykli na editory jako vim to nemusi byt pohodlne (no flame prosim, poukazuju jen na to, ze existence ruznych outline pohledu a podobne v nastrojich jako eclipse nebo netbeans tohle proste hrozne usnadnuje)

hej? vyskusajte si pouzivat rozne J* interface z inych programovacich jazykov

tak to moc nechapu, o prenositelnosti na jine jazyky jsem vubec nemluvil. i kdyz uznavam ze tohle je jedna z velkych vyhod .NET oproti jave. v jave sice existuje spousta projektu na podporu vseho mozneho, ale AFAIK pouze python se nejak vice pouziva. ale v 1.6 uz by to melo byt lepsi, zahledl jsem zminky o oficialni podpore pythonu, perlu a javascriptu (proc javascript osobne moc nechapu). nicmene v tomhle je .NET asi mnohem dal, protoze uz to bylo soucasti navrhu. jestli je to dobre nebo spatne si ale uplne 100% jisty taky nejsem.

no nic, jdu taky neco delat

[MarrLiss]

adJavaScript: 1.6 by mela obsahovat cely engine pro scriptovani v aplikacich pomoci JavaScriptu (mel by byt vyuzity engine z gecka). Tak proc toho rovnou nevyuzit.

[Michal Vyskočil]

ale dokazu si predstavit ze pro lidi co jsou zvykli na editory jako vim to nemusi byt pohodlne (no flame prosim, poukazuju jen na to, ze existence ruznych outline pohledu a podobne v nastrojich jako eclipse nebo netbeans tohle proste hrozne usnadnuje)

Příště prosím nezmiňovat vim, ale vybrat si omezenější editor . Aneb Vim outliner. Mě tedy stačí vestavěný folding (Příklad nastavení pro Javu/C/C++ ).

[happy barney]

vim/ne-vim, nejedna sa o obmedzenost editora. nikto nevravel o foldingu, a pod, to je predsa zakladna vlastnost development nastroja. osobne som mal na mysli manageovatelnost, naivne si myslim, ze sa pracuje tymovo (riesenie cut&paste sa da pouzit tiez ...)
imho, vim je prakticka ukazka, ako z vi vytvorit emacs

[Martin]

Tak, pisemka (snad uspesne) dopsana :o)

Kritizovat, opravovat bohužel nemůžu, protože Javu (zatím) neumím. Před dvěma měsíci jsem se naučil Python a asi by myslím bylo lepší ovládnout jeden jazyk dobře, a pak se pustit do dalších. Minulý týden jsem se už rozhlížel na internetu po nějaké dobré online učebnici Javy (třeba ve stylu knihy www.byteofpython.info, ze které jsem se toho o Pythonu naučil nejvíc - neznáte něco v podobném stylu?), ale pak jsem si to z výše uvedeného důvodu rozmyslel. Nevím, jestli jsem udělal dobře nebo špatně a co je lepší. Před Pythonem jsem se učil C, ale Java mi přijde taky celkem sympatická.

[bodo]

Thinking in Java, 3rd Edition, začina sa od objektov a ich principov + je k tomu aj zdrojový kód s buildami pre anta, čo viac si môže človek želať :)).

[Martin]

Díky za odkaz. Na tuhle učebnici jsem tehdy narazil, ale trošku jsem znejistěl kvůli datu vydání. Tři a půl roku mi přišlo jako docela dost stará kniha. Ale je možný, že to nehraje žádnou roli, nevím jak to kolem Javy chodí.

Taky mě napadlo, že bych si později mohl pořídit Učebnici jazyka Java od Pavla Herouta. Mám doma jeho učebnici Céčka a myslím, že jsem ho s ní zvládnul poměrně dobře (je fakt, že od tý doby, co znám Python už jsem v Céčku prakticky nic nedělal, takže jsem toho asi už hodně zapomněl). Je jeho kniha o Javě napsána stejně kvalitně? Před týdnem jsem byl v Praze a říkal jsem si, že si ji asi pořídím, ale nakonec jsem koupil dárek své milé a na tu učebnici mi nezbyly peníze. Ne, že by mi to vadilo, samozřejmě ;o)

[Nikola Ciprich]

no ja jsem od pana Herouta jeste spatnou knihu necetl, ucebnice C, ucebnice Javy, IPV6, vsechno IMHO kvalitni a ctive knihy...

[Martin]

Díky, určite si ji dříve nebo později pořídím. Ta kniha o Céčku byla opravdu perfektní, učení s ní šlo opravdu samo.

Jsem hodně zvědav, jaká ta Java opravdu je. Céčko se mi opravdu líbí, Python jakbysmet, navíc v něm můžu dělat věci, který bych buď v Céčku nezvládnul nebo by to asi nebyla taková hračka (to je důvod, proč dělam v poslední době jenom v něm). Jsem zvědavej, jestli mi Java sedne nebo ne :o)

[bodo]

Učebnica jazyka Java od Herouta je vcelku príjemna záležitosť ale má jednu nevýhodu, viac sa tam rozoberá syntax ako objekty, takže ako prvú knihu by som zvolil TIJ3. A na dátume až tak nezáleží pokial sa jedná o naučenie základov jazyka. A z vlastnej skúsenosti si myslím že je doslova nevyhnutné získat nejaký obecný základ objektového programovania, napríklad tu :)) java.vse.cz

[Martin]

O objektech už mám něco málo načteno, akorát že pro Python. Ale myslím, že princip by měl být pořád stejnej. 100% objektově jsem si zatím nedávno naprogramoval jenom hada v Pythonu (ale zato myslím, že celkem dobrýho ;o)) a myslím si, že to už trochu chápu. Alespoň minimálne ten princip teda. Nic moc složitýho bych nejspíš nezvládnul.

Tak ještě jednou dík za rady a taky za ten super poslední odkaz, pořádně si to pročtu.

[zde]

Thinking in Java je vynikající. Četl jsem 1st edition a mohu jen doporučit. Akorát Bruce Eckell napsal Thinking in Python (které jsem nečetl), a docela v něm i jinde Javu kritizoval.. Jo a taky jsem četl že Bruce kdesi napsal, že Python u něj nahradil Javu jako primární nástroj pro nové projekty

[Martin Baleja]

Interesting, but a little long for me to read it in the morning But I'm sure I'll get back later and read it all. Thanx.

[Nikola Ciprich]

Terve, kiitos!

[zde]

Je až neuvěřitelné, jak tuhý má Java život. Byla určena pro průmyslovou automatizaci, ovšem procesory co interpretovaly Java bytecode v mikrokódu byly ve srovnání s čímkoliv rozumným (RISCy) příliš pomalé a žravé, tak to po zásluze chcíplo.

SUN začal tedy Javu razit jako formát pro distribuci untrusted kódu pro applety webových browserů. Udělali ale spoustu omylů v návrhu jazyka, a programátory frustrovali chybnými knihovnamy s nestabilním API, proto je nakonec (opět po zásluze) na hlavu porazila Macromedia s Flashem. Když naleznu na webu javovský applet, je to naprostá výjimka.

SUN se ale nevzdává, a chce z Javy udělat aplikační jazyk. Po mnoha letech vývoje je konečně trochu funkční JIT, takže to opravdu běhá docela rychle. Paměťová režie a startup time jsou ale stále katastrofické, takže na desktop Java nepatří. Co zbývá? Aplikační servery mají hafo paměti, takže nabubřelost Java runtime se v tom schová, a pro dlouhodobě běžící tasky zdlouhavý startup není kritický. Java tedy nakonec domigrovala nikoliv "tam kam patří" ale "tam kde nejméně vadí" :)

Jo mám pocit že SUN se jednu chvíli snažili z Javy udělat i něco jako skriptovací a prototypovací nástroj, ale taky to selhalo- statické typování je pro skriptovací nástroje opravdu nevhodné.

Takže budoucnost vidím jednoznačně: Java opět chcípne (už popáté?). .NET nabízí krom lepšího návrhu a lepší podpory pro desktop širší výběr front-endů, takže psaní aplikací je pohodlnější. Až počet vývojářů přeroste kritickou mez, postupně vyštípou Javu i z aplikačních serverů.

PS: moc jsem nepochopil proč autor chce lepší poll() když jej Java skoro nepoužívá, protože umí docela dobrý threading. PPS: abych nenadával na něco co neznám tak jsem si nedávno zkoušel Eclipe + C Toolkit. Na 512MB RAM a 2G+ CPU to bylo skoro použitelné. Ovládání intuitivní, odezvy rozumné. Ale proč to proboha má 150MB ???

[happy barney]

hmm, ak si mam vybrat medzi zlym navrhom a este horsim navrhom, tak pri porovnani java vs .net mi o kusok lepsie vychadza prave ta java

thready? thready sux, 99,999% programatorov nevie programovat multithreadove aplikacie, takze je lepsie (a castokrat s lepsim vykonom) pouzivat oddelene aplikacie.
priklad: mam server s 1000 paralelnymi konexiami. co pouzijete? 1 thread a 1 poll s neblokujucimi socketmi alebo 1000 threadov a blokujucimi socketmi ?
neblokujuce je tazsie, tam si treba pamatat stav, treba viac osetrovaciek, narocnejsi parser protokolu ...

a tak

[zde]

1000 threadu neni na Linuxu s O(1) schedulerem zadny problem, proto kazda konexe pobezi v jednom threadu. A synchronizace je v Jave docela trivialni. Zadny stavovy automat, zadne slozite parsovani, sama pozitiva a same jistoty :)

[Nikola Ciprich]

Je až neuvěřitelné, jak tuhý má Java život. Byla určena pro průmyslovou automatizaci, ovšem procesory co interpretovaly Java bytecode v mikrokódu byly ve srovnání s čímkoliv rozumným (RISCy) příliš pomalé a žravé, tak to po zásluze chcíplo.

no jak je to s podporou prumyslovych zarizeni moc nevim, ale na mobilech se jave myslim dari v posledni dobe celkem dobre . Ja mam zkusenosti teda jenom s J2ME a se Symbianem, a musim rict ze programovani v J2ME je tezka pohoda a vykon nijak hrozny neni.

ohledne appletu asi neni moc co dodat, moc se to nerozsirilo, ohledne bugovitosti nevim, ale mozna nenazranosti java trochu taky predbehla dobu :)

ze se jave dari v serverove oblasti jen diky tomu ze tam nejmene vadije podle mne trochu nefer tvrzeni. myslim ze java je na psani takto velkych veci jednoduse docela vhodna, a to je taky duvod proc se na takove veci pouziva. co momentalne existuje v prostredi .NETu bohuzel ani nevim, i kdyz predpokladam ze minimalne MS urcite neco ma. co se tyce javy, tak je toho na vyber (i mezi free produkty!) urcite neskonale vice.

jestli chce SUN delat z javy prototypovaci jazyk netusim, ale musim rict ze ja ji takto obcas pouzivam (treba ted jsem si celkem rychle udelal prototyp mobilni aplikace, kterou jsem nasledne pouze prepsal do C++ na zminovany symbian) a nestezuju si. je to vzdycky spis o tom co komu vyhovuje a v cem je zvykly (rychle) psat...

ohledne pollu, ja jsem ho nijak nevyzdvihoval, ani neprosazoval, byla to jen ukazka k tematu, o kterem byla esej napsana. nic vice, nic mene. ale ze by nemel zadne vyuziti, to bych taky netvrdil...

jinak ze je .NET slusna platforma jsem tam ostatne psal take, ale ze by vsichni na nej s radosti presli, tomu teda moc neverim. i kdyz MS pro to dela co muze. na to uz ma java prilis velkou programatorskou zakladnu. jak v komercni sfere, tak i ve svete free sw.

k eclipse, jakych 150MB mate na mysli? jako ze to tolik zabira? no a? je to platforma, pomoci (relativne) malych pluginu se z toho da udelat celkem dost univerzalni balik (ja osobne v eclipse mam podporu pro C/C++, javu, webove sluzby a python). v dnesni dobe mi 150MB prijde opravdu nic. zvlaste kdyz se takove visual studio dodava na nekolika DVD... (tim ovsem vubec nechci porovnavat eclipse a visual studio, vim ze je k nemu pribaleno mnozstvi dokumentace, a mnoho lidi na nej neda dopustit. i kdyz ja k nim teda po svych zkusenostech s nim rozhodne nepatrim...)

[zde]

> ale na mobilech se jave myslim dari v posledni dobe celkem dobre

Jo, souhlas. Na mobily jsem uplne zapomel, tam se Java chytla docela dost. Mobily jsou ale hardwarove dosti specificka zarizeni. Maji docela vykonna CPU, ale relativne malo pameti. Java ma docela kompaktni bytecode, takze se na ne hodi. A taky nevim jestli se Java Micro edition (nebo jak se to orezane API jmenuje) da jeste nazyvat Java :)

> ohledne bugovitosti nevim

No ja kdysi (pred 10+ lety) napsal pro jeden web nejake trivialni applety nad awt.*, a na kazdem browseru a kazde verzi Javy to behalo jinak nebo taky vubec ne.

> myslim ze java je na psani takto velkych veci jednoduse docela vhodna

stejne vhodny by byl libovolny jiny jazyk, ktery umi spravne oddelovat jmenne prostory svych komponent, a poskytuje pametovou bezpecnost. A dulezite pravidlo: Velke projekty = stare projekty. Dnes se Java pouziva na serverech hodne i ze setrvacnosti; kdyby se podobne veci delaly znova, dost mozna uz nebudou v Jave ale treba v Pythonu. :)

> co se tyce javy, tak je toho na vyber (i mezi free produkty!) urcite neskonale vice.

Jo, souhlasim, objemen nastroju Java jasne vede. Ale mystlim ze na desktopu je .NET lepsi, proto tam poroste vyvojarska a uzivatelska baze, a prehoupne se to i do serveru.

> je to vzdycky spis o tom co komu vyhovuje a v cem je zvykly (rychle) psat...

Presne. A taky (zejmena) externimi rozhranimi, a zda je na ne ve zvolenem nastroji vhodny binding. Ale postupem casu jsem prisel na to ze casto je lepsi tohle omezeni ignorovat, a binding si pak dopsat dodatecne; kdyz mas pevne API nebo protokol na obou stranach, jde napsat adapter velmi rychle a ciste.

> na to uz ma java prilis velkou programatorskou zakladnu. jak v komercni sfere, tak i ve svete free sw.

To neni vubec jiste. Bylo by zajimave videt jeji vyvoj. Drive se lidi Javu ucili, protoze (opravnene) chteli pryc z C++ a Java se jim libila. Dnes se Javu uci uplne z jinych duvodu- kvuli inzeratum firem, ktere shaneji cerstve maso do svych J2EE kafemlejnku.

> v dnesni dobe mi 150MB prijde opravdu nic.

Nejde o absolutni cislo, 150MB je opravdu nic. Jde o pomer funkcnosti k velikosti, ktery povazuji za jiste (uznavam ze velmi hrube) meritko kvality, a ktery je u Eclipe velmi nevyhodny. Ono to toziz neumi o mnoho vice nez treba 10x mensi Code::blocks. Jo a Visual Studio se mi taky docela libi :)

[Vinicius]

Nikdo tu nezminil vhodnost Javy pro vyuku programovani. Sam jsem ji ocenil, protoze mi pomohla soustredit se na jadro problemu/algoritmu. psal jsem treba svuj prvni prekladac a ocenil jsem hodne hotovych trid (mapy,kolekce,spojove seznamy). Zadne honeni segfaultu...

A velkym trumfem je podle me SWING. To je GUI toolkit, se kterym se da tvorit pekne GUI doslova na kolene (EDIT + JAVAC, z doby kdy jsem mel procesor K5), proste jen pridavate komponenty do kontejneru... (proti QT (QT designer je odporny),GTK,FLTK jsem si pripadal jako v pohadce) Proste toolkit meho srdce.

[Nikola Ciprich]

no ke swingu zas tak vrely vztah nemam, ale co se tyce vhodnosti javy k vyuce, tak to souhlas. na VSB se java pouziva ted uz od sameho zacatku studia IT a myslim ze to je dobra volba...

[zde]

Coze? Jste sadisti? Jak to chcete ucit prvaky, kdyz to nema ani interaktivni shell!

[Nikola Ciprich]

myslim ze to opravdu nikdo moc nepostrada. ja osobne treba v pythonu pouzivam shell tak leda kdyz potrebuju kalkulacku

[DjAARA]

bean shell, bean shell ...