21. prosince 2007

Nová Java: Chceme ji?

Zamýšlel jsem se nad myšlenkou, změny jazyka Java tak, aby lépe odrážel dnešní potřeby a obsahoval moderní prvky představené především ve skriptovacích jazycích. V poslední době se objevilo pár příspěvků na toto téma, na jedné straně příznivci změn reprezentovaní například JavaPosse #151 a na straně druhé spíše odpůrci, např. Dagi.

Já se spíš stavím za to, aby se jazyk vyvíjel a měnil. Jsem přesvědčen o tom, že požadavky kladené na dnešní "moderní" programovací jazyky jsou diametrálně odlišné od požadavků kladených před oněmi 12 lety, kdy byla Java představena.

Co považuji za nejdůležitejší změnu? Jednoduše použitelná podpora programování multithreadových aplikací. Jistě od roku 1995 máme synchronized, nyní již máme i java.util.concurrent. Do Javy 7 se blíží implementace fork-join algoritmu (pod vedením JSR 166), ale stále si myslím, že je to málo.

Proč chci víc? Programování multithreadových aplikací je stále složitá věc, rozhodně to není pro široké masy programátorů. A dneska je každý nový počítač více-procesorový a abychom využili jejich schopností, pak potřebujeme multithreadovou aplikaci.

Kde bych hledal inspiraci? Co třeba programovací jazyk X10. Ten je dokonce překládán do Javy. Obsahuje řadu konstruktů, které k programování fork-join konstruktů přímo vybízejí (async, atomic, finish, when, atd.).

Myslím, ře prostorů, ve kterých by se Java mohla zlepšovat je jistě nepřeberné množství, a Java bude muset tuto hozenou rukavici zvednout.

3 komentáře:

Anonymní řekl(a)...

Oni programátoři co se setkávají hlavně s Javou na serveru mají tendenci zapomínat, že stavět GUI aplikace bez podpory události nebo properties na úrovni jazyka je docela pakárna. Naopak client side programátoři nemají takový přehled, co chybí Javě na serveru. Javaposse poslouchám, a opravdu jsou to spíš programátoři zaměření na Javu na klientu. Dagi zase zmiňuje izolaci VM a hotswap tříd, a to jsou docela typické příklady toho, co by chtěli vidět server-side programátoři.

Ta cesta ke "komponentovosti" ale zřejmě daná a vyhnout se jí nedá. Ať už to jsou komponenty grafického rozhraní nebo aplikační komponenty ve stylu beanů ve Springu. Programátoři to z velké míry chcou a asi to i dostanou. Mě z toho nadšení do komponent trochu mrazí. Vždycky si představím Delphi, kde člověk psal třeba HTTP klienta tak, že přetáhl na formulář nějakou komponentu. Bohužel když chtěli psát konzolovou aplikaci, která formuláře nemá, tak měl smolíka :-)

Unknown řekl(a)...

Tebou otevrene tema ma nekolik aspektu.

- fork/join nijak nemeni syntaxi jazyku

- mela by se Java specializovat na reseni vsech vypocetnich problemu. Proc to nenechat takovym jazykum jako X10 a nebo Erlang

Je jasne, ze Java musi udelat krok k tomu, aby dokazala efektivne vyuzit stavajici hardwarove moznosti. To se da delat jednak na urovni API (java.util.concurrent) a jednak na urovni JVM (lock biasing, specialni instrukcni sady atp.).

K tomu musi jeste existovat obdobna podpora na vyssi urovni abstrakce. Tim myslim gridova reseni, pekne je to popsane v nasledujicim clanku http://www.jroller.com/nivanov/entry/thoughts_on_invigorating_jsr_107

Jira řekl(a)...

Já jsem se snažil zaměřit na rozšíření syntaxe jazyka a ne na knihovny, které jsou s jazykem dodávány.

Problém je samozřejmě složitějsí, protože má spoustu úhlů pohledu. Někomu současné možnosti vyhovují, někomu se zdají nedostatečné.

Řekl bych, že se mi zdály dostatečné pokud jsem programoval v Javě a jiným jazykům jsem svůj čas nevěnoval. Co jsem začal nějaké problémy řešit v Groovy, vše se změnilo. Byl bych velmi rád, pokud by v Javě byly dostupné takové konstrukty.

Poté co jsem si vyzkoušel Erlang, poznal jsem co to je jednoduše psát vysoce paralelní aplikace, pokud je jazyk navrhován s touto možností na paměti. X10 rozšiřuje standardní Javu o pár nových klíčových slov a napsání paralelní aplikace je rázev významně jednodušší.

Jistě řada věcí se dá pro x procent případů vyřešit pomocí vylepšením knihovny (to je krásně vidět na java.util.concurrent.atomic v Javě versus atomic v X10), ale systémové řešení to není.

Jak jsi Dagi několikrát naznačoval, ano syntaxe Javy je jednoduchá, ale je srovnatelná s jazyky podobného typu, tj. C, C#. Groovy má syntaxi také velmi jednoduchou a je to skriptovací jazyk se spoustou cukrátek. Prostě speciálně tyto věci týkající se paralelního programování jsou klíčová slova, která by se nemusela používat a je to ...

No já jsem zkrátka pro. Pokrok musí být a nebo přijde úpadek.