Sun、JavaFX 1.0をリリース 44
ストーリー by hylom
Javaとは違うんです、 部門より
Javaとは違うんです、 部門より
あるAnonymous Coward 曰く、
SourceForge.JP MagazineによればSun Microsystemsは米国時間12月4日にJavaベースのRIAソフトウェアのプラットフォーム「JavaFX 1.0」をリリースしたそうだ。デスクトップおよびWebブラウザ向けのアプリケーションを開発できるようだ。同ソフトはSunのウェブサイトからダウンロードできる。
JavaFXは、GUIを構築するためのスクリプト言語であり、簡単なコードを記述するだけでGUIアプリケーションを構築できるのが特徴だ。たとえば、簡単なウィンドウを出すだけなら数行～十数行のコードだけで実現できてしまう。
GUIを構築するという点ではHTML+CSS＋JavaScriptと競合する技術とも言えるが、拡張性の高さや統合開発環境を備えている点などが優れている点といえる。
コンシューマJava (スコア:2, 興味深い)
これに先だって、クライアントサイドでJavaの利用を促すために、高速化をはかったコンシューマJavaこと、 Java SE 6 Update 10 [sun.com]が10月23日に公開されてますね。
ケータイではよく使われるJavaですが、PCやウェブブラウザ上での復活はあるんでしょうか?ハードウェアの性能も上がってますし、ソフト的に高速化が計られるのなら、Javaのクライアントサイドでの利用も悪くないかなと思うのですが。
いつも主観で書き込んでいます
Re:コンシューマJava (スコア:2, 参考になる)
たぶんわざわざチェックしに行ってないんだと思いますが
実は、Update11 [sun.com]が既に出ているのです。
JavaFXを探しに行った人は結構気づいていると思いますが・・・
Re:コンシューマJava (スコア:1)
自分の場合、今朝会社でニュースみて知ったけども。
Re:コンシューマJava (スコア:1, 興味深い)
むしろ処理は速かったです。
うまくいかなかった原因はAWTだと思います。
最初のAWTで酷い目にあった開発者たちは、一番メジャーなWindowsだけをサポートすべき、という考えをさらに固めてしまいました。
マイクロソフトのJavaVMが邪悪だったとか、そういう話をする人もいますが、
たしかに、マイクロソフトのCOMとのインターオペラビリティ部分は勝手な拡張でしょうが、
AWTについては、どの環境でも同じ見た目と動作をするような仕様にしなかったSunが悪いのです。
Re:コンシューマJava (スコア:2, 興味深い)
いろいろ違うと思います。JavaアプリでのGUIはWin32アプリと比べて
明らかにもっさりしていました。SwingもJDK1.4くらいまでは
かなーり遅かったです。
アプレットの場合JVMの起動が遅くてブラウザでアプレットを含むページに
アクセスするとイライラしました。MS製のJVMが悪いのはアプレット用VMの
話で、独自拡張のせいでSUNのJVMでは動かないアプレットが作られました。
しかもJDK1.1ベースでバージョンアップしなかったのでJDK1.2以降をターゲットにした
アプレットはSUNのJVMでないと動かない、でも入れ替えると独自拡張を使った
アプレットは動かないという状況になりました。私の会社ではこういった混乱に
備えてMS独自拡張を禁止していたのですが、顧客からは「お前のとこの推奨のJVM
入れたら今まで使ってたアプレットが動かなくなったぞふざけんな」という
クレームが来るのです。
ActiveXべったりの韓国ならともかく、日本にもMS独自拡張を使うベンダが結構
いたことに驚きました。アプレットが流行らなかった一番の理由はこれだと思います。
今ならFlash同様に「とりあえず最新にしとけばOK」なんで大丈夫なんじゃないでしょうか。
Re:コンシューマJava (スコア:1)
Re: (スコア:0)
Re: (スコア:0)
おかげでMSDNでWindows2000がダウンロードできねぇ。
Re:コンシューマJava (スコア:1)
因果関係からするとMSの自業自得でしかない。
また、MSのJavaVMが更新されないのは裁判でそういう条件で和解したからなので
これまたSUN(だけ)を責めるのは間違い。
当時のSUNのJavaのパフォーマンスが悪かったのは事実だけどもそれは別問題。
Re:コンシューマJava (スコア:1, 興味深い)
それからSwingも原因だな。
表示されるまで何十秒も待たせるファイルダイアログとか、
妙に太いフォントとか、プラットフォームを無視してダッサいUIを表示して、
いかにも使えないというイメージを決定付けたと思う。
むしろ、プラットフォームごとに本来のルックアンドフィールを実現できるAWTの方が評価できると思う。
まずかったのは実装じゃないのかな。
Swing？ (スコア:1, 興味深い)
そして (スコア:0)
仮想マシン上のOSでJava VMで動くスクリプト言語で書かれたフレームワークで動くLISPマシン
とかになるの?
Re: (スコア:0)
# いまでも頑張ればなんとかできるって？
Re:そして (スコア:1, 興味深い)
Re: (スコア:0)
そのVMちゃう [google.co.jp]
#今時の薄い箱で７階建てだと下の方のプラスチックが割れそうやね
簡単なウィンドウを出すだけでJAVAなんか使わないでくれ (スコア:0, 興味深い)
# というのがエンドユーザーとしての感想なんだけど、ムリなんだろうなあ
Re:簡単なウィンドウを出すだけでJAVAなんか使わないでくれ (スコア:1, 興味深い)
ちと面白い感覚だな。
というか、これはあれだな。もうウェブアプリとかデスクトップアプリとかそういう括りが無いな。
しかしバージョン云々なんて、そんなの、Javaの問題じゃねえだろう…
Re: (スコア:0)
って話はいたるところであるんじゃないですか？
FlashがダメでJavaFXがダメな理由はなんでしょうか。
SilverlightがダメでJavaFXがダメな理由はなんでしょうか。
FireFoxならダメでJavaFXがダメな理由はなんでしょうか。
JavaFXに限らず、バージョンの問題はソフトウェアが進化する限り仕方ないことだと思いますよ。
Re: (スコア:0)
ツッコミどころが違う (スコア:2, すばらしい洞察)
>>SilverlightがダメでJavaFXがダメな理由はなんでしょうか
>>FireFoxならダメでJavaFXがダメな理由はなんでしょうか。
全部ダメなのかよ！
-- う～ん、バッドノウハウ？
Re:簡単なウィンドウを出すだけでJAVAなんか使わないでくれ (スコア:1)
# でも、織田さんがキターって言うCMをやったらやめたい＜それはFXが違う
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re: (スコア:0)
初期のAppletの互換性問題はMSもJavaVMを提供していて、それとSunJavaの整合性が微妙だったせいだし。
今はWindowsはSunが提供してるのを使うのが普通だし、LinuxやBSDユーザは自分で何とかするだろう。MacもSunのが標準だよね？
Re:簡単なウィンドウを出すだけでJAVAなんか使わないでくれ (スコア:1, 参考になる)
そしてAppバンドルにパッケージされていないJavaアプリケーションからDockのアイコンを変更することは、いまだにどのバージョンでも不可能です。おそらく、Appleに任せておけば終焉までサポートされないままでしょう。
#Cocoa-Javaブリッジを捨てたのは下策だと思うAC
Re: (スコア:0)
Re: (スコア:0)
例えば教育機関では生徒自身がお金を出さないといけないので更新できない…ということもよくある。
おかげで相当苦労してるよ。iBookなんかを大量に導入したつけということかね？
#オープンソースになったのでMacでもApple以外のベンダーからJREが出ないかとちょっと期待してる
Re:簡単なウィンドウを出すだけでJAVAなんか使わないでくれ (スコア:1)
これは、Leopardにすればいいだけの話ではない、という反論にはなってないよ。
別に、お金がないからって、LeopardにしてもJava 6が使えない、という事にはならないのだし。
http://landonf.bikemonkey.org/static/soylatte/ [bikemonkey.org]
OpenJDKになって、恐らくそちら経由でJava 7がMac OS Xも含むプラットフォーム向けに出るようになると思いますが、とりあえずはSoyLatteという方法もありますよ。
Re: (スコア:0)
MacがいまやUNIXであるのに、
(野良)移植が大変だってのは
少々意外な気がしています。
コアじゃなく画面まわりとかでしょうか？
>#Cocoa-Javaブリッジを捨てたのは下策だと思うAC
その上で動かないとならんJavaにとっては損害でしょうけど、
CocoaというかObjective-Cから見れば、
動的で自由度の高い世界から引き摺り下ろされるのは
さぞかし嫌だったのでしょうね。
どこもかしこもスクリプト言語開発ですが (スコア:0)
Re: (スコア:0)
これ自体古い(昔からある)けどな～
Re: (スコア:0)
ボトルネックになりそうなデータをメモリにキャッシュしておけないスクリプト言語は
パフォーマンス以前の問題だと思うんですが。
そりゃHello World 1000回繰り返すような実システムとかけはなれた実行速度とかは知らんけど
スクリプト言語開発ってそんなにメジャーですか？ (スコア:0)
私の周りではC/C++/Javaがメインであり、PHPが若干、そしてRoRなどは実験的プロジェクト扱いです。
>Javaベースはネイティブスレッドが扱えるだけでパフォーマンスは低いし。
同じ処理を行うのならば、C/C++と比較すると遅いですが、貴方が利用しているスクリプト言語より１０倍以上は速いと思いますよ。
>新言語を乱立させるなら大きな技術革新を期待したい
JavaVMの実行時コンパイル技術は、ここ５・６年で大きく進化しています。
そして、同じバイトコードが飛躍的に速く実行されるようになったことをご存知でしょうか？
貴方の知らないところで、技術革新は進んでいます。
Re: (スコア:0)
新言語の乱立もまた技術革新の一種なのですが。
具体的にいえば「より楽にコーディングできる、という新技術」の進歩です。
そりゃあ「すべる」言語は有りますが、「すべる」新技術が有るのは分野を問いませんしね。
簡単なウィンドウを出すだけ。 (スコア:0)
は？スクリプト言語なら１行で出すべき。
Re:簡単なウィンドウを出すだけ。 (スコア:3, おもしろおかしい)
#こういうコトだよね？
Re: (スコア:0)
既存のスクリプト言語でも大抵はGUIライブラリを読み込む必要があるので数行は仕方ないのでは？
Re: (スコア:0)
new MyWindow().搭載する部品の定義1().定義2().定義3(). …
というように一行に書けます。
部品の追加(そして追加される部品の定義)をメソッドチェインで書くわけです。
色々な分野で少し使ってみましたが、これ、かなり快適ですよ。
流れないJavaBeans(Setterのreturnがvoidだ)はもう古い。
これからは、流れるように、豆をきちんとコーヒー(液体)にしてあげよう。
具体的にはsetterはthisをreturnすべきだ。
乱暴にいえばそれで流れるコードの第一歩は実現できる。
Re: (スコア:0)
私も色々な分野で使ってみましたが、最終的に
new MyWindow().
搭載する部品の定義1().
定義2().
定義3().
…
となるのがオチだったので、元に戻しました。
しかもデータフローの観点からは混乱の元でしかないですね、上のスタイルは。
Re: (スコア:0)
> 具体的にはsetterはthisをreturnすべきだ。
つまり a.x = 1 がaを返すべきだと
こんなことをすれば余計な混乱を招くだけです
目先に囚われた愚行としか思えませんね
Re: (スコア:0)
x=がaのメソッドであると考える状況が思いつきません。
プロパティとかを使ってる場合でも、
xにオブジェクトとして振る舞って欲しいから
プロパティを使うわけですよね。
Re: (スコア:0)
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FluentInterface [capsctrl.que.jp]
個人的には
> customer.newOrder().with(6, "TAL").with(5, "HPK").skippable().略
が、例のように破壊的なものか、関数的に
> オブジェクト（特にバリューオブジェクト）を組み立てる
ものなのか判別しがたいところに気持ち悪さを感じる。
> Ericが述べていたことだが、彼が流れるようなインターフェースをこれまでに使ったり目にしたりしてきたのは、バリューオブジェクトの組み立てだったそうだ。バリューオブジェクトはドメイ
Javaもそうだけど (スコア:0)
簡単なウィンドウを出すにも数百行が必要になるんだよ。
いつかきた道が繰り返される～
なんか (スコア:0)
WinXP64bit (スコア:0)
Fx3.04(32bit)
jre1.6.0_10(32bit)
数秒動いたあと必ずフリーズします
#winxp64が異端なんだろうけどさ