Už je to nějaký pátek, co jsem se zabýval vlastnostmi, které bych rád viděl v Javě 7. Něco málo se na mém názoru změnilo: jsem ještě radikálnějsí. Proč? Jsem přesvědčen, že není možné rozšířit Javu tak, aby byla zpětně kompatibilní a zároveň nabízela prvjky, které by moderní jazyk měl mít. Sun se snaží udržen nejen zpětně kompatibilní bytecode, ale i zdroják. A to je ten problém.
A jak z toho ven. Současnou Javu bych nechal takovou jakou je. Cestu ven by nám ukázala nová Java, říkejme jí např. JavaNW (New Way). JavaNW by byla překládána do stejného bytecode, ale byla by nekompatibilní na úrovni zdrojového kódu. Co to znamená? Nepřijdeme o nic z existující infrastruktury: JRE, HotSpot, Terracotta, Tomcat, ... všechno funguje. Ale to není ještě konec seznamu, protože všechny knihovny budou také použitelné: standardní knihovny Javy, Hibernate, Tapestry, FOP, ... vše budeme moci používat i nadále. Takže vlastně skoro o nic nepřijdeme, ale co vlastně získáme? To co získáme je absolutně závislé na tom, jaká bude JavaNW?
Bude JavouNW Scala? Poslední dobu jsem vyplnil studiem tohoto opěvovaného jazyka. Musím přiznat, že jeho prvky jsou opravdu úchvatné (snad se o nich někdy rozepíšu podrobněji), ale je to jiný jazyk. Syntaxe je jiná, pravda kompaktnější (není tolik upovídaná a všechny vlastnosti jsou zakomponovány tak, že do sebe krásně zapadají). Je možné použít stávající knihovny, ale Scala má také vlastní, a ty je potřeba poznat. Je mi to moc líto, protože se mi Scala opravdu moc líbí, ale nemyslím, že se Scala stane JavouNW (nikdy jsem nevěštil, tak spoléhám na to, že to neumím ...).
Tak co třeba některý ze skriptovacích jazyků: Groovy, JRuby, Jython, ... Ne nemyslím si, že budoucnost je v netypových jazycích, Scala nabízí spoustu (netroufám si napsat všechny) vlastnosti, pro které se mi tyto jazyky zamlouvají, ale je typová. Nemyslím, že jsme schopni a ochotni se připravit o výhody typového jazyka: odhalení řady chyb již při překladu, lépe fugující Code Assist, refaktoring, ... Takže JavaNW musí být něco jiného.
Takže kde vzít JavuNW? Za rozumné považuji více vyjít z Javy, aby se syntaxe nového jazyka Javě více podobala a přechod nebyl tak bolestný. Zakomponovat do něj všechny "potřebné" prvky pořádně: generiky, closures, paralelní zpracování a další. Pak by přechod mohl být pozvolný, poklidný a měli bychom nový "nabušený" jazyk.
1. února 2008
Nová Java: Jak z toho ven ...
Přihlásit se k odběru:
Komentáře k příspěvku (Atom)
Příspěvky
10 komentářů:
skriptovaci (mam radsi nazev "dynamicke") jazyky (ruby, groovy, smalltalk) jsou samozrejme "typove" (instance objektu maji vzdy sve tridy), ale s typy/tridami se pracuje az za behu - pro nekoho je to nevyhoda, ale tato vlastnost + nektere dalsi koncepty na druhou stranu umoznuji naprosto elegantni a čisté metaprogramovani (určování chovani samotnych trid, ne jen instanci objektu) a to je silny nastroj... dale - reflexe je v dynamickym jazyku naprosto prirozena a trivialni atd. apod., nechci moc flámovat, šlo mi o ty "typy"...
Jest pravdou, že dynamické je vhodnější přívlastek než scriptovací. To, zda je to výhody či nevýhoda je věcí vkusu, mě se to jeví trošku jako nevýhoda, ale bůh ví co budu říkat za pár let. Ostatní co připomínáte již záleží na navrhovaném jazyku a nikoliv na tom, zda je typovaný nebo nikoliv.
Groovy je nepovinně silně typované :-) Když určím typ, překladač provádí statické typové kontroly, když ne, provádí se jenom za běhu. Jinak dneska považuju za nejzásadnější výhodu silného typování v Javě právě snadné automatické zpracování kódu (doplňování, refaktoring, IDEA :-) ). Vliv na bezpečnost má statické typování možná tak v Adě (_tam_ jsou pořádné generiky).
Ano, ano, typovost je výhodou pro již zmiňovaný Code Assist a refactoring. Mimojiné ve Scale jsou také pořádné generiky ... tedy jsou rozhodně lepší než ty v Javě.
Musím se na tu Scalu trochu podívat. Když ono těch jazyků pro Javu je hrozně moc: Scala, Nice, MultiJava, X10, Groovy (o tom aspoň něco málo vím a přijde mi fajn) etc. etc.
No me uplne staci Java "Old Way". Zadne nove syntakticke pozlatka nepotrebuju. IMO hlavni duvod, proc k nim Sun v poslednich verzich pristoupil, byl tlak ze strany C# ("musime mit srovnatelne funkce").
Me by uplne stacilo, kdyby jedina nova vlastnost Javy 7 bylo sdileni VM, tedy kdyz mam spustenych 10 Java aplikaci, aby nebylo potreba spoustet i 10 instanci JVM, ale sdilely spolecne pamet. Na desktopu se to jeste nejak snese (stejne se tezko hleda 10 aplikaci, ktere by jeden uzivatel pouzival), ale na serveru je to dost zavazny problem, kdyz chcete provozovat nekolik web aplikaci na stejnem stroji. Ve srovnanim s tim jsou zmeny syntaxe s prominutim [zadne slusne slovo me nenapadlo].
Přesně se blížíme tam kam to chci dostat, tj. odtrhnout od sebe VM a Javu. Vývoj těchto dvou věcí již dnes na sobě né zcela závisí a je rozumné je rozdělit. Vývoj na poli VM bude prospěšný pro Javu, Scalu, Groovy, JRuby a další.
A jaký nad tím poběží jazyk? To je věcí vkusu a potřeb.
Tahle exploze jazyku uz tady jednou byla, vysledkem je C++ ktere ma sice vsechny "featury" ale je neskutecny opruz v nem delat.
Me by stacilo kdyby vylepsili virtualni masinu.
Jo jo, o tom C++ jsem už psal, co o tom řekl Bjarne Stroustrup osobně. Obávám se, že uhodil hřebíček na hlavičku a Java se pomalinku přibližuje do stejného bodu.
No sice je to hezke, ze se tady shodneme, ze by bylo fajn, kdyby se dalsi vyvoj zameril predevsim na rozvoj VM, ale obavam se ze to nebude mit zadny realny dopad na rozhodovaci proces v Sunu :(
Okomentovat