Annyit hallani már a JavaFX programnyelvről, hogy az embernek a könyökén jön ki, s a csapból is ez folyik... ennek ellenére alig tudják páran, hogy mi is ez a JavaFX. No, nézzük meg közelebbről. Első lépésként írjuk be böngészőnkbe a https://openjfx.dev.java.net/ címet, itt találjuk meg az Open JavaFX minden információját és újdonságait. Telepítsük fel kedvenc fejlesztőkörnyezetünkhöz (Eclipse 3.2, NetBeans 5.5 illetve NetBeans 6.0 M9 támogatott) a JavaFX plugin-t (mi NetBeans 6.0 M9 környezetre tettük fel). A leírások alapján hozzunk létre egy új projektet, amely JavaFX Application típusú legyen, nevezzük például FirstJavaFX néven.
A JavaFX forrásállománynak nem java a kiterjesztése, hanem fx, minden egyebet tekintve bele lehet illeszteni a már kialakult struktúrába. A NetBeans 6.0 a Main.fx nevet adja a főprogramunknak, ezt megnyitva írjuk bele az alábbi kis programot:
import javafx.ui.*; Frame { title: "Az első JavaFX programom!" width: 200 height: 50 content: Label { text: "Helló Java Fórum olvasók!" } visible: true }
Ez meg fog nyitni egy ablakot ( Frame ), beméretezi a megadott méretekre, létrehoz benne egy címkét, az egészet láthatóvá teszi. Ja, és elbaszelrontja a karakterkészletet (legalábbis Windows XP alatt). Nade sebaj, nyilván még dolgoznia kell ezzel a fejlesztőknek, hogy hibamentes és gyors legyen... :)
A (helló világot követő) következő lépcső a grafikus felületű programok esetén általában valami gomb vagy beviteli mező felhasználása, hogy bizonyítani tudjuk az interaktivitást:
import javafx.ui.*; class MainModel{ attribute name: String; } var model = MainModel{ name: "Write your name!" }; var win = Frame { title: bind "Hello {model.name}, this is the JavaFX!" width: 400 height: 100 content: GridPanel { rows: 2 columns: 1 vgap: 10 cells: [ Label { text: "Your name:" }, TextField { value: bind model.name } ] } visible: true }
Ez a program értelemszerűen hosszabb, viszont látni belőle, hogy az eseménykezelés nagyon egyszerű: a bind parancsot kell használunk két valami összekötéséhez. A programban létrehoztunk egy modellt a szövegmező számára, amely a beleírt szöveget fogja hordozni, ezt hozzákötjük a szövegmezőhöz. Ezek után a program címsorát is hozzákötjük a modellhez, s itt egyfajta Expression Language alapján összefűzzük a megjelenítendő szöveget és a modell használandó tulajdonságait (model. name ). A program eseménykezelése egyszerűen a név beírása után ütött Enter billentyűre fog feléledni, ugyanis ez a TextField alapértelmezett eseménye.
A most használt angol szövegekkel már semmi baja nincs a JavaFX kód futtató részének. Ugyanis a JavaFX forrásból Java osztály keletkezik és már ezt futtatja a Java virtuális gép. Valahol elveszik a karakterek kódolási információja (gondolom a Win1250 kódlap érvényes a konzolomon, és ezzel fordítja le a Main.fx állományt, a NetBeans pedig UTF-8 kódlappal teszi bele a szöveget).
További információkért érdemes megnézni az Open JavaFX oldalon lévő gyorstalpalót, amely röviden és gyorsan bemutatja az összes JavaFX komponenst, eseménykezelést, lehetőségeket (amelyek már elkészültek :). Ezeket végignézve azt kell mondjam, hogy nem néz ki rosszul a JavaFX, sok programsort meg lehet spórolni, ugyanakkor nyilván nem fogja elbitorolni a Java kivívott pozícióját, de esélye lesz betörni a * on Rails által elfoglalt piaci szegmensekbe.
9 Comments
Auth Gábor AUTHOR
Nos, a karakterkészlet probléma fordítási időben áll elő, futási időben már probléma nélkül fut... fordításkor kerül bele egy felesleges konverzió, amely a feltételezett Win1250 kódlapról átkonvertálja UTF-8-ra az UTF-8 karaktereket.
Böszörményi Péter
Amennyiben konnyen ossze lehet hozni javas koddal, akkor a formok elkeszitesere idealis lehet. Egyebkent nem lepodnek meg, ha a Silverlight utan valo kapaszokdas lenne ez a tortenet.
Auth Gábor AUTHOR
Úgy gondoltam ez annyira triviális, hogy nem írtam le... :)
Unknown User (frimen)
Rosszul irtad. :)
... és esélye sem lesz betörni a * on Rails által elfoglalt piaci szegmensekbe.
Auth Gábor AUTHOR
No? Mit jósolsz? Mennyi időt adsz a JavaFX-nek? :)
Unknown User (frimen)
A kód maga 2 MB, azaz reménytelen használni simán egy oldalon, appletként szintén halott, ugyhogy a kérdés az beleteszik-e a JRE-be. Jobbik eset: beleteszik abba, ami kijön jövőre (ha kijön). Ugy 1 év mire elfogadott egy uj uj java kiadás, igy ez cirka 2-3 év innentől, mire használni lehet..
Csak van pár "baj".. az egyik, hogy null a multimédia támogatássa van.. (streaming, webcam, stb.), amit az a szar (mert rühellem) flash már évek ota tud.
Szóval amig a Sun és barátai ráfeküdtek a J2EE-re és a többi nagyválalati technologiára, és szartak a "nép" fejére, addig az adobe lenyomta a "piacot" a java ellenében, és most kaptak észre a seggfejek (akik megszabták merre fejlesszék a java-t).
Auth Gábor AUTHOR
Jogos... kivéve, ha sikerül a Java Web Starthoz hasonlóan a kliens oldalon gyorstárban tartani a már letöltött részeket. Gondolom a modularitással ezt megoldják a hetes Java-ban.
Márpedig egyfajta appletként gondolják... csak olyan módon, hogy ne okozzon megrázkódtatást az applet futtatása. Ha kevesebb erőforrást igényel, mint a Flash, akkor már jó a dolog... :)
A Flash-t pedig nem olyan nehéz appletekkel lealázni sebességben, csak azt kellene megoldani, hogy 100 futó applet ne indítson 100 VM-et.
Ezt bele lehet heggeszteni szerintem... :)
Ez viszont nagyon igaz... sőt. Az 1.4.x kiadás után jópár évet ültek a fejlesztéseken. :)
A real-time Java ötlete az első JSR volt, lassan 10 éve... :(
Unknown User (frimen)
A JWS-el is van azért pár gond:
- egyrész egy egyszerű kódnál müködhet, egy bonyolultnál már magadnak kell megvalósítani a cachelést..
- másrészt átverős.. ettől még senki nem tanul meg ugy programot irni, ahogy egy ilyen környezethez kell..
ezért van az sok fél-egy megás letöltés és lassu indulás.
Aha. :)
Erről olvastam pár éve, ugyanis terminal szerver környezetben halálosak a java-s programok, és az lett a vége, hogy ez "talán" soha nem fog megvalósulni, mert akkor egy program magával ránthatja az egész jvm-et és vele a többi futó programot. Valami "shared library" volt akkor a favorit.. de már nem tudom pontosan miről szolt.
Auth Gábor AUTHOR
A letöltött programokra gondolok. Nem látom problémának azt, hogy legyen a Java module cache, ahol ezek a letöltött modulok figyelnek.
Ez nem a környezet problémája általában... :)
Valamit kellene kezdeni a helyzettel. Hirtelen nem is tudom, hogy van-e erre JSR jelenleg.