Názory k článku
Sun portuje velkou Javu na mobilní zařízení
-
erg (neregistrovaný)no jestli nebude spis problem v VM nebo spise integraci s zbytkem telefonu.. Ta samotna rychlost zpracovani Java bytecodu je velice slusna, zvlast u procesoru podporujici jazele (nativni spousteni java bytecodu v procesoru). Dal uz je to o rychlosti samotne platformy pristroje, toolkit je koneckoncu implementovany z vetsi casti nativni (resp. u swingu jeho L&F - swing podporuje oboji).
Ja bych se toho nebal, jsou to plany do budoucnosti, J2ME timhle nekonci, pro mene vykonna zarizeni tu porad bude dlouhou dobu k dispozici. Pro vykonnejsi zarizeni je to vyznamny krok kupredu, protoze to umozni vytvaret aplikace plne vyuzivajici moznosti platformy, kde Java v soucasnosti zaostava (napr. na PDA jsou aplikace v J2ME dost omezenejsi nez nativni aplikace). Podivejte se treba na .net compact framework, tohle je to same, takze je to urcite krok tim spravnym smerem. -
No ono je nutné říci, že mobilní JVM je ve většině mobilů jen pár desítek tisíc řádků v C/C++ kódu - je to velmi oholená věc bez JIT kompilace a triků umožňující větší rychlost. Jen naprosto holá kostra JVM, to nejnutnější, aby to chodilo.
Proto mobilní Java je velmi pomalá - i když to ve většině případů vůbec nevadí. Ale nacpání velké Javy do mobilů - a dovolím si zavěštit - se obecně nikdy nepodaří. Už jen díky tomu, že by se musela vyvinout JVM - a zase dobrá JVM by zbytečně prodražila celý mobil. K tomu by se muselo nést obrovské množství javových knihoven, což znamená zabrání obrovského množství paměti, nesmírně pomalý běh, a další věci.
Nevím, jak Sun dokáže vysvětlit výrobcům mobilů i jeho zákazníkům, že díky velké Javě v mobilu bude výrobní cena mobilu třeba několikanásobná oproti současnému stavu, že javovské aplikace na mobilech poběží pomaleji, než dosud, a jak bude řešit diference a odchylky vyplývající z toho, že velká Java není pro mobily připravena - a vyřešit toho není zdaleka tak jednoduché, jak by se manažerům Sunu u piva v hospodě čtvrté cenové kategorie mohlo zdát.
Nebral bych tuto zprávu vůbec vážně, fantastických zpráv úplně mimo reál Sun vypouští docela dost - tohle je naprosto mimo mísu. -
Bilbo (neregistrovaný)Mit v mobilu 100MB (tolik cca zabira jre 1.6.0) rom navic na java runtime asi nebude moc velky problem ... soupne se tam nejaky integrovany flash cip, nebo pokud tam je (vetsina mobilu uz ma vcelku velkou vnitrni pamet) tak se proste jen o kus zvetsi, otazkou je spis jestli to utahne CPU a RAM ... vlastni knihovny (vlastni java) bude vyvinuta od sunu, takze v tom taky asi pro vyrobce nebude problem ...
-
hisaak (neregistrovaný)Tech 100MB mozna plati ted. Slysel jsem o iniciative, ktera ma vest k JRE v podobe on demand stahovanych komponent. Minimalni verze (napr. bez crypto knihoven, ruznych provideru atd.) se odhadovala na cca 6 MB. Zbytek by slo dotahovat, pokud by to aplikace potrebovala.
Dovedu si to predstavit, i kdyz je v tom nekolik "ale". Pres GRPS to asi nepujde :-), bez 3G siti by tento pristup asi nemel sanci, bude nezbytne zaplatit za takovy datovy prenos, ...?
Na druhou stranu dnesni prohlizece to pro pluginy delaji bezne. -
_FP (neregistrovaný)
"No ono je nutné říci, že mobilní JVM je ve většině mobilů jen pár desítek tisíc řádků v C/C++ kódu - je to velmi oholená věc bez JIT kompilace a triků umožňující větší rychlost. Jen naprosto holá kostra JVM, to nejnutnější, aby to chodilo."
A k čemu JIT, když na to už samotný procesor má extra elektroniku? Tj. něco jako http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-514.pdf, akorát pro javí bajtkód. ;-) -
...Už jen díky tomu, že by se musela vyvinout JVM...
Já považuji např Squawk za určitou cestu - většina JVM je v Javě, takže náklady na vývoj HW závislého kódu je nižší než při konstrukci celé JVM. -
erg (neregistrovaný)no 1.5 ghz asi ne, ale nemusim snad nikomu rikat ze vykon a frekvence procesoru jsou uplne neco jineho.. Jazelle (aka nativni spousteni java bytecodu v procesoru) k tomu taky doda sve (a ARMy jsou pomerne bezne v tehle zarizenich, takze cesta k Jazelle je tu otevrena).
BTW, nekolik GB flashky je standard uz dneska. Moc si nedovedu predstavit mit napr. v mp3 prehravaci nebo PDA mensi, zvlast pri dnesni cene pametovych karet (a flash pameti obecne) :-) A s tou spotrebou bych to urcite u flash pameti nevidel nijak dramaticky...
I kdyz samozrejme 100MB VM je dost nadnesene (ale jednou to k tomu asi dospeje - ono konec koncu velikosti "chytrych" OS ala Windows Mobile taky nejsou nejmensi).
Myslim, ze v tehle diskusi dost zanika jeden detail, vetsina lidi si zde predstavuje obycejny telefon (kde ty prinosy jsou spise pro programatora) - ale tohle ma prave neuveritelny potencial pro "chytre" telefony, organizery, etc. (kde to velmi vyznamny prinos pro programatora i pro uzivatele). -
Bilbo (neregistrovaný)100 MB zabira VM na desktopu (gentoo linux). Da se cekat, ze pro mobily to jeste mozna o neco malo orezou nebo zoptimalizujou, takze to bude asi min ... a za par let bude 100 mb na mobilech vcelku bezvyznamna polozka - uz dnes stoji treba 1 GB SD karta cca 200 Kc, takze pokud mobil neni nejaky opravdu ultra-lowend, tak se tam 100Mb pameti navic ztrati :)
-
Marian Kechlibar (neregistrovaný)Na to jsem, upřímně řečeno, dost zvědav.
Za posledních 2,5 roku jsem strávil s J2ME řadu chvil, většinou méně šťastných. Fragmentace mezi jednotlivými mobilními zařízeními je děsivá a spousta věcí nefunguje tak, jak by měla.
V J2ME se relativně rychle píše (oproti třeba Symbian C++), je dobře dokumentovaná a hodně rozšířená. Ale na nějaké "Write Once, Run Anywhere" zapomeňte; neexistuje. Každý firmware každého telefonu má nějaké mouchy.
Kdyby se na mobilech ujala skutečně unitární J2SE, byl bych první, kdo tomu zatleská. Ale musela by být opravdu unitární. Ta současná fragmentace je neúnosná.
Jenže jak toho dosáhnout? Patrně by SUN musel certifikovat JVM v každém novém přístroji každého výrobce... -
"Patrně by SUN musel certifikovat JVM v každém novém přístroji každého výrobce..."
Čímž by se dosáhlo současného stavu, neboť certifikace by něco stálo, prodražovala by vývoj - a tím pádem by to skoro nikdo nedělal.
Ale jinak, já v J2ME vyvíjel také - a i to C++ bylo daleko multiplatformnější, než mobilní Java - byť se v něm samozřejmě vyvíjelo daleko pomaleji.
Jde ale také o to, že J2SE nemá funkce pro mobily, ani není na mobily přizpůsobena - tudíž velmi pochybuji vůbec o reálnosti a užitečnosti tohoto počinu - je tedy nutné J2SE mobilům přizpůsobit a blížíme se znovu k roztříštěnosti J2ME, jen z jiné strany - dokonalé to rozhodně nebude. -
anonymníJa myslim, ze to bude dobry pocin. Alespon pro programatory. Prece jen, kdyz programujete, casto chcete vyuzit nejakou knihovnu (napr. pro MD5SUM). Ta knihovna muze byt docela jednoducha, ale casto se stava, ze zrovna potrebuje ke svemu behu nejakou tridu (napr BigInteger), ktera se nachazi jen ve "velke" jave. Potom musite dotycnou tridu do projektu nakopirovat z velke javy. Pak vam kompilator zacne rvat, ze trida se nachazi na systemove classpath. Tak musite cely projekt prohnat obfuskatorem aby se to nejak prejmenovalo. A to musite mit jeste stesti, ze dotycna knihovna je opensource, aby to tak slo.
Takze, ja tento pocin vitam. -
jinxx (neregistrovaný)Ona to zas az tak horka novinka nebude, ze? Sun pred casem udelal akvizici s firmou SavaJe na jejiz implementaci to cele bude zalozeno
viz napriklad http://www.deviceforge.com/news/NS9280947932.html -
Ondra "Satai" NekolaZlatý podporovatelA kdyz to rika James Gosling, tak to bude pravda: http://blogs.sun.com/jag/entry/javame_is_not_dead
