- 1 名前：デフォルトの名無しさん mailto:sage [2006/11/20(月) 10:38:16 ]
- 前スレ
[mustang] 次世代Javaの動向 3 [dolphin]
pc8.2ch.net/test/read.cgi/tech/1157227790/
次世代Javaの動向 ２
pc8.2ch.net/test/read.cgi/tech/1147881822/
【Java】次世代Java・J2SE1.6の動向【Mustang】
pc8.2ch.net/test/read.cgi/tech/1081698555/
2006年12月にMustang Java SE 6がリリース予定
Mustangの掲げる主な目標は以下の点にある。
* 互換性と安定性および品質の向上
* Easy of Developmentの実現
* WebサービスおよびXMLサポート機能の拡張
* リソース管理や診断機能の強化
* デスクトップ環境の強化
Java SE 6 じゃじゃ馬ならし
www.javainthebox.net/laboratory/JavaSE6/
- 445 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 16:32:00 ]
- >>444
System.GCしか今のところコントロールする方法はない。
あとはVMの実行時パラメータでヒープやアルゴリズムの調整でカバー。
ただ、System.GCはほとんどの実装でFullGC動くので実質使っちゃダメ。
System.newGCとかがあればかなり変わるんだろうけど。
ゲームとかにしろ常にシビアなタイミングがあるわけじゃなくて、今は100μsも遅れるとまずいけど
このタイミングなら10msは大丈夫とかあるからね。
1フレームに1回殿堂入りさせない新世代GCが指定できればそれでおけ。
どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
- 446 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 17:33:20 ]
- > 所でJavaってGCが勝手にメモリガリガリやってるから
> メモリの断片化をプログラマで制御出来ないよな？
↑出来る処理系ってあるの？
- 447 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 17:47:52 ]
- >>446
C/C++だとメモリ管理は自分でするから確保も解放も
自分のタイミングで出来るって程度の意味だ。
勝手なタイミングでガンガンGCされるより断片化起こらないよねって話な。
- 448 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 18:01:42 ]
- >>447
それはおかしい
断片化と解放とは別の話だろ
それにC++だってアロケートしなおししないと同じだし
JavaのGCはそのタイミングをコントロールできないという点だけが問題
- 449 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 20:44:23 ]
- >>445
-XX:+ExplicitGCInvokesConcurrent
で、Java6なら完全停止は回避できる、のかな？
ttp://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/cms-6.html
- 450 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:45:23 ]
- >>448
mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に
placed newでオブジェクト作れば、制御できると思う。
制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。
- 451 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:50:06 ]
- >>444
GC でコンパクションが発生するのに断片化って???
- 452 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:53:01 ]
- なんか、全然次世代じゃない話で盛り上がってるな。
- 453 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:57:03 ]
- >>452
いつもの事だ。
- 454 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:01:05 ]
- >>445
> >>444
> System.GCしか今のところコントロールする方法はない。
java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。
- 455 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:02:05 ]
- >>445
> >>444
> どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
> 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
彼らがJavaを作った目的は家電制御なんだけどな。
彼らはサーバを発電所のように使うものを想定している。
- 456 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:04:13 ]
- >>446
Bufferインタフェースを使って
巨大な配列を確保すれば
擬似的に管理できないこともないぞｗ
C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。
Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw
- 457 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:05:52 ]
- java.lang.refでオブジェクトの「到達可能性」をコントロールできる
香具師はいないのね
- 458 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:14:10 ]
- >>457
そりゃ、居ないだろ。
あれは到達可能でなくなった事を知るためのもので、
到達可能でなくす事を可能にしてくれるわけじゃない。
- 459 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 01:27:33 ]
- >>454
それ定期的に出てくるけどぜんぜんコントロールできねーよ
- 460 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 13:56:01 ]
- いつの世代でもGCは永遠の謎なのだ。
- 461 名前：デフォルトの名無しさん [2007/02/22(木) 21:22:26 ]
- GCなしの方がよかったかもな〜
- 462 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:09:49 ]
- GCなしなんていまさらありえんだろ
- 463 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:26:43 ]
- C++に逆戻りか？
- 464 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:27:32 ]
- C++0xの使用をみたが、期待はずれだった。
あんな仕様では当分Javaには勝てないことがわかった。
D言語やC#のほうが全然魅力的だった。
- 465 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:31:08 ]
- もう使用されているとは
- 466 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 01:51:35 ]
- なんで、C++はそんなに使用を拡張していくんだろうねぇ…。今でも十分じゃん。
- 467 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 01:57:48 ]
- そうだよな。
チンコの仕様に優れていても、使用に優れてない奴とかいるし。
- 468 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 02:01:08 ]
- チョンの仕様かと思ったw
チョンのチンコの仕様は9cmで世界一ミクロ
- 469 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 02:06:38 ]
- 仕様も使用もダメな例だな
- 470 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 04:24:39 ]
- JDK7 build08
download.java.net/jdk7/changes/jdk7-b08.html
download.java.net/jdk7/binaries/
サマリが何も出来ていない
変わってないのかっ
と疑問も持ちつつUpdateする俺でした
- 471 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 05:02:19 ]
- マネージド○○って完全にわすｒｙ
- 472 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 06:35:41 ]
- CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
最近標準化連中は仕様作り過ぎｗ
C++のexportみたいにry
コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
みたいにさ。
マジレスするとunsignedが欲しい。
static final unsigned byte の範囲の定数が欲しいのにって度々思う
#Java書いてるとshortの存在を忘れてint使っちゃう俺
- 473 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 07:56:31 ]
- >>472
>static final unsigned byte の範囲の定数が欲しいのにって度々思う
short や int じゃだめってこと？
ケータイJavaかなんかかな。
- 474 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 08:57:09 ]
- マイナス、負の値を使えばいい。
- 475 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 10:10:27 ]
- >>473
そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
ビット操作中心なんで負数は使えんし、
そもそもMEで使わんディスクスペースとヒープを確保する余裕はない！
そもそもstatic finalなフィールドすら宣言する余裕なんて無いんだよ。
文字列定数の長さを気にする様な世界だ。
ややこしい・・・
- 476 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 11:16:49 ]
- >丁度0-128を使う
嫌がらせだなｗ
- 477 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 11:19:44 ]
- >>475
ビット操作でも負数は使えるはずだが
- 478 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 12:33:58 ]
- まあ、負数使いたくないのは個人的理由でもあるｗ
どうせ作ってたらサイズでかくなって定数をプリプロセッサやエディタの置換なんかで
マジックナンバーに展開して定数フィールド排除、
クラス名・メソッド名・フィールド名・インターフェイス名何かをAとかBとかにして長さ短くしてそもそもOOP何か無視して設計して
昔はそれでもダメなんでバイナリエディタで無駄なバイトコード手作業で最適化してサイズ落としたよ。
（まあ、今は難読化だけで間に合うが）
そんなんでshortとかintとかlongなんて無駄に使ってられませんｗ
少数も勿論固定少数点数ですｗ
XML1.0とXML in Namespace 仕様フルサポートしたライブラリ書いてjarサイズが50K台じゃでか過ぎるって世界だぜ・・・orz
一般的にはCLDC用のXMLパーサって10K台だよ。
＃つくづく趣味グラマで良かったと思うこの頃。
よくopera mini何て出来たもんだ
- 479 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:38:05 ]
- >>472
> CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
> 最近標準化連中は仕様作り過ぎｗ
> C++のexportみたいにry
> コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
> みたいにさ。
> マジレスするとunsignedが欲しい。
> static final unsigned byte の範囲の定数が欲しいのにって度々思う
> #Java書いてるとshortの存在を忘れてint使っちゃう俺
ラッパークラス作れ
- 480 名前：デフォルトの名無しさん [2007/02/23(金) 13:54:21 ]
- >>475
> >>473
> そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
今はJ2MEではなくJava ME。
つうか、もうそろそろ、スペック問題解決してもいいのでは。
昔と比べ、容量は10倍以上になったんじゃないのか？
S!アプリももう何年か前から1MBアプリを作れるようになったし
iアプリも903iからDoja5.0になって1MBにもなったし、今やダウンロード、スクラッチパッドの境界が
無くなって外部メモリも使えるようになって1MB以上のアプリも作れるようになったろ。
昔の10kB時代と比べたら全然気にしなくても良いようになってきたんではないのか？
- 481 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:55:32 ]
- >>476
0-127に加えて-1か128を128替わり使えばいいのではと
- 482 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:56:13 ]
- >>478
とりあえず新たにデータ型作るってのはどうよ
- 483 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:57:12 ]
- >>478
jarsで圧縮率を上げればjarサイズが半分になるぜ
- 484 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 21:57:02 ]
- static final は普通に、コンパイラでインライン展開することが
言語仕様で決まってなかったっけ。
- 485 名前：デフォルトの名無しさん [2007/02/23(金) 22:04:07 ]
- 今のJava MEではGenericsやアノテーションは
使えるのか？
- 486 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 22:05:35 ]
- >>484
決まってない。final で修飾されて、確実に定数式で初期化される変数だけ。
それに、ME とかの場合は static final な変数自体も節約したいんでしょ。
- 487 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 03:48:32 ]
- >>845
使えない。VM仕様がJITがオプション扱いでブートストラップクラスローダしかない1.4か1.3時代程度だったとオモ。
けどジェネリックスなんて使うケースないと思う。
MEじゃあるべき処理を平気でとっぱらうからアルゴリズムの使い回しとか不要。
他にも汎用データクラス作るんじゃなくて一つのクラスに全てのデータと処理をぶち込むからジェネリックスの立場がない・・・。
インターフェイスすら排除する世界だぜｗ
ところでこんなリスト見つけた。VM仕様関連の情報らしい。
ttp://www.ingrid.org/java/vm/
- 488 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 12:23:48 ]
- >>487
ジェネリクスはコレクションを手軽に扱うためだけとおもっても十分な効果が出るよ
- 489 名前：デフォルトの名無しさん [2007/02/24(土) 12:59:51 ]
- Java SE 5になってから大分高速化したのに携帯電話には
まだ搭載できないでいるのか・・・
しかもまたまた1.3レベルとは。assertも使えぬのか。
アノテーションくらいはつかえたほうがいいとは思うのだが。
コンパイル時には無視できるタイプのアノテーションはとくにあったほうが便利だろう？
それに、いくつかクラスやメソッドが増えているし。
制約上全部は使えないとは思うけど、利便性を考えると、1.3レベルってつらそう。
- 490 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 13:32:37 ]
- >>487
> ttp://www.ingrid.org/java/vm/
古いね。デッドリンク多いし。
- 491 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 15:42:08 ]
- >>489
高速化したのはSunのJava SE 5の実装で、Javaっていう規格じゃないだろ。
ケータイって、SunのJVMが主流なの？
- 492 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:23:16 ]
- >>488
コレクションFWないよ？レガシーしか。
java.util.*はDataとCalenderが端末依存でGMTすら禄に扱えない。
端末毎に返ってくる値が違う事があるし端末の時計とは
別にＶＭが時計持ってて端末と時間違うし時計アプリなんて信頼できんよ？
UTCなんてない。
これでもちゃんとした仕様の範囲だから困りもんだ。
>>491
主流はアプレックスのJBlend。
一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。
KDDIとかSBM専用のオプションパッケージの実体はcom.jblend.*パッケージが主でリンク用のスタブクラスとJavaDocをCPに公開してるだけ。
最近のSEの仕様の恩恵が受けられないのが保守性が悪い悪い・・・
ドコモキャリア仕様の端末以外例外投げると問答無用でVM落とすしエラー出力ないから酷い酷い・・・
クラスローダーがブートストラップのしかないんで動的リンクできんしJarサイズがデカクなるって言うんで汎用のFWは作れんから
再開発部分が多いだろうねぇ。
プリベリファイがSEに取り込まれたんだからMEに何かくれよｗ
- 493 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:52:22 ]
- >>492
CLDC 1.1 なら java.util.TimeZone が GMT をサポートするのは義務じゃなかったっけ？
TimeZone は GMT をサポートするけど、それを使っても
GMT な時間が返ってくるとは限らないってオチはあるかもなー、とか思った。
そーいや、JSR-310 で Date and Time API ってのがあったような。
あれって、JDK7 の contents だっけか？
- 494 名前：デフォルトの名無しさん [2007/02/24(土) 18:28:20 ]
- >>492
System.currentTimeMills()の値を引数にして
DateやCalenderを作っても正確にならない？
- 495 名前：デフォルトの名無しさん [2007/02/24(土) 18:31:30 ]
- >>492
> >>491
> 主流はアプレックスのJBlend。
> 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。
遅いとかではなく、かれらがハードウェアリソースをケチっているだけだと
いってみたかったりする。
携帯電話をもう少し大型化して、JVMの部分を物理的に大きく専有するようにして、電池も
巨大化させれば携帯電話でも十分早くなるはずだ、と言ってみる。
ハードディスク搭載、とバッテリ寿命さえ延びれば、さらにその理屈もとおるはずだ、と言ってみる。
そして、連中は、独自実装で市場を独占したいだけに過ぎないのだ、
かつてのSonyがやってたような、独自製品で覆い尽くし、ライバル製品との
互換性をわざと奪うために標準Java実装から逃げているだけなのだ、と言ってみせる。
- 496 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:48:51 ]
- >>492
いやVectorとかでいいんだよ
それでも十分使い勝手がいい
中に何を格納するべきなのかをドキュメントに書かないとわからないってのは面倒だったりする
そういやJavaME用HotspotVMを開発したとかどっかのニュースみたな
携帯の用途だとhotspotよりはアーカイブ単位での丸ごとコンパイルのほうがよさそうだが
- 497 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 20:10:36 ]
- >>489
IBMのJavaME向けコンパイラ/オプティマイザみたいな商用系使ってると
かなりのレベルまでstaticメソッドのインライン展開するし、
アサーションってMEの言語仕様で定めなくてもいいかなって気がするんだよね。
それよりも言語仕様のほうはシンプルにしてアプリケーションプログラマ
のほうで適切にアサーションのutilクラスを書いた方が全体としてシンプルで融通効くと思う。
というかコンパイル時にstaticメソッドのインライン展開なくても
>static final boolean DEBUG = false;
>public void assert(...){
> if(DEBUG){
> System.err.println(...);
> ...
> }
>}
みたいなコードが書けるように1.3でも言語仕様上ifブロックでの到達不能性チェックに
例外が設けられていて、かつ実装系の方でもSunとかIBMとか大体のコンパイラは
DEBUG=falseのときこの部分ごっそり削除してくれるし。
- 498 名前：497 mailto:sage [2007/02/24(土) 20:36:05 ]
- アサーションだから
>static final boolean DEBUG = false;
>public void assert(boolean flag, ...){
> if(DEBUG){
> if(!flag){
> ...
> }
> }
>}
みたいな感じか。細かいことだけど。
- 499 名前：デフォルトの名無しさん [2007/02/24(土) 20:52:52 ]
- なるほどー。
今ならAspectJでもっと効率よくできるかな？
- 500 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:31:51 ]
- >>493
確か仕様上はGMTサポートしろゴルァだけどオチは
>GMT な時間が返ってくるとは限らないってオチはあるかもなー
だったかと・・・
>>495
仕様上は130K程度の不揮発性メモリ（KVM用）と30K程度の揮発性メモリ（コンフィグレーションライブラリロード用）
と16/32bit CPU及び何らかの方法でのネットワーク接続方法。
結局はプロファイルとオプションのライブラリロードが居るんでSUNは160~500K程度のメモリ（揮発・不揮発問わず）を想定してるんだけど。
が仕様上の要求だけどねぇ。携帯電話はそれでもリソースケチるからな・・・。
>>496
いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。
ホットスポットVMなら仕様上はCDC HIとCLDC Hotspotて感じのが一応ある。
CDC用はネフロのVMが実装してたな。
>>497
良いねそれ。eclipseのjavacで試してみよう。
まあ、MEも仕様上はEcmaScript並みに互換性あるけどベンダーの実装が変な事やってんだよね。
MS VMとネスケVMとSUN VMで互換性が無かった時代のように
（厳密にはMS VMがネスケVMとSUN VMに互換性なかったんだけど。ライブラリのサポートも屑だったし）
学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。
- 501 名前：497 mailto:sage [2007/02/24(土) 22:46:46 ]
- >>500
IBMがつくったコンパイラは例えば
1. VisualAge for Java
2. j9c(後期型は4と同等) + jxelink
3. IBM JDKのjavac
4. Eclipse/JDT(ecj.jar)
5. jikes
が挙げられる。497でstaticメソッドの展開が...って言ったのは
1のjxelink。厳密にはポストプロセッサ。
>良いねそれ。eclipseのjavacで試してみよう。
これが4のことを言っているのなら、1のjxelinkとは別物だよ。
- 502 名前：デフォルトの名無しさん [2007/02/24(土) 23:54:51 ]
- >>500
もうさ、メガアプリ限定にしてしまえばいいよ。
俺たちが作りたいソフトはこういうものだから、
ハードウェアをもっと強化しろ！
とハード屋に圧力をかけてさ。
マイクロソフトみたいに力がないと
Vistaみたいな激重Windowsを開発してハードウェア屋が
それに追従するってこと難しいかな。
今はハード基準で携帯電話開発を強いられているみたいだけど、
ソフト屋からハード屋になんとかして圧力かけられないかねえ。
「お前らハード屋がだらしないから携帯電話開発がしづらいんだ！
ハードのスペックを高めることを要求する！」
みたいにさ
- 503 名前：デフォルトの名無しさん [2007/02/24(土) 23:58:12 ]
- >>500
> >>496
> いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。
java.nio.Bufferを実装したクラスを配列代わりに扱えば高速化するのでは？
と思ったら、あれJ2SE1.4からのものだった。
> >>497
> 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。
SoftBankもまともじゃないし、KDDIもまともじゃないし、Docomoもどいつもこいつも
独占欲だけは高いからねえ。
ハードウェア重視でソフトウェアをなめてかかっているところが、だらしないよ。
日本の有名な大手家電メーカーがインターネット産業ろくに力を注がず、Web2.0に
乗り遅れたことをも証明しているし。
- 504 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 00:04:27 ]
- >>502
とは言え、行き過ぎると Vista や PS3 の二の舞になると思うよ。
- 505 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 00:42:46 ]
- 国内だとキャリア（←こいつが一番無関係ｗ）、世界的にはハード屋が頂点か。
どちらにしてもオープン標準のJava仕様がないがしろにされてるな。
まあ、ソフト屋ですら飼いならされてる現状じゃ仕方ないか。
仕様の地位をもっとこうW3C勧告の仕様並みに出来んかねぇ？（IEの糞実装さえなくなれば平和だからなアッチは）
ハードの方は十分にパワフルだと思うけどな・・・
翌々考えたら昔はメモリ以外今の携帯以下のハードと糞ＯＳでJavaが動いてたんだから。
win95よりce5のが安定してるしｗ
国内携帯は無駄な機能に溢れ返ってるからそれにシステムリソースとコストと
開発期間が圧迫されて一ソフトウェアどころじゃないだろうな。
またしても仕様の地位不足か・・・
SUNの苦労体質全部をJavaが担ってる気がするｗ
- 506 名前：デフォルトの名無しさん [2007/02/25(日) 01:02:42 ]
- >>505
パワフルな割には容量が足りないってどういう事なんだろうなあと思うよ。
メモリもっと増やすべき。でないととてもパワフルじゃないな。
現実問題として電力消費が激しいと言う問題があるそうだ。
しかし省エネ型DRAMのようなメモリがもっと普及すれば解決できるんだとか。
つうか、携帯電話会社は、余計な機能にエネルギーを無駄に費やさず
Javaの部分にエネルギーを費やして欲しいな。
あらゆる機能をJavaを中心に動かせるようにすれば水平ポータビリティを
維持できるし、どの携帯電話でも同じように動くアプリを簡単に作れるようになる。
- 507 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 01:23:02 ]
- KDDIがBREWで水平ポータビリィティやろうとしてソフト屋・消費者から大ブーイング受けた結果
建前上JBlend on BREW（サービス名オープンアプリ/どこがオープン何だと小一時間・・・）のっけましたが？
Javaで水平ポータビリティ実現すればsunの当初の目的が実現するな。
その為にはベンダーに協力してもらわんとダメだが。
その前に日本の携帯ビジネスモデルを破壊しないと受け入れられないだろう。
4G携帯なんて出したらドコモが死守してソフトバンクが
嘘ばら蒔いてイーモバとウィルが歓迎するんだろうな。
KDDIはBREW動いて音楽と動画DL出来れば何でも良さそうだが。
ネイティブ開発は個人には不可能か敷居高いだろうしJava（MIDP）流行らんもんかね
- 508 名前：デフォルトの名無しさん [2007/02/25(日) 01:38:36 ]
- つかネイティブ開発はCPの審査がウザイよ。
審査に金かかるわ時間もかかるわ。
- 509 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 06:56:24 ]
- 今のケータイでJavaをやろうとすること自体が間違いなことに気づけ。
- 510 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 07:12:43 ]
- て事は昔の、今の携帯以下のスペックで動かしてたJava自体間違いだったって事か
- 511 名前：デフォルトの名無しさん [2007/02/25(日) 10:59:44 ]
- Javaで何をするかが問題。
今の技術では、携帯に望みすぎ。
- 512 名前：デフォルトの名無しさん [2007/02/25(日) 12:55:29 ]
- >>509
燃料電池またはＨＤＤが搭載されるもしくは
PDAなどもっと大型の携帯端末なら、
Javaをやる価値は少しはあるのではないかと言ってみる。
携帯キャリアメーカーもJavaに自分たちの収入源を
奪われるのを恐れて、わざとJavaの機能を制限して
Write Once, Run Anywhereの妨害をしているとおもうけどな。
彼らの、Javaの普及を妨害するやり方はつくづく陰湿だと思う。
- 513 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 13:37:18 ]
- >>510
CPUのクロックだけで比べても意味がないぞ
- 514 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 21:46:09 ]
- まあ、VMはハードウェアとＯＳを仮想化してるから下にパワーが無いとVMも非力になるな。
- 515 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 22:17:51 ]
- >>510
すごく間違いだと思うなあ。Java熱に浮かされてただけじゃないかな。
- 516 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 03:24:52 ]
- >>510
今に間違いじゃない日が来るって
おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
５年前に予想してたか？
>>512
わざとっていうか、自由はセキュリティリスクを持っているからな。
徐々に拡大してけばいいだろう
何でも出来る穴だらけの何かがデファクトになるのが怖いよ
- 517 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 04:23:39 ]
- >>516
>今に間違いじゃない日が来るって
それって、今は間違いってことじゃん。
間違いじゃない日がきてから実用化すればいいのに。
なんでJava以外の選択肢を考えないのかね。
Collectionも使えないなんて、そんなんJavaじゃねーよ。
道具は適材適所。そこまでしてJavaにこだわるのが分からん。
- 518 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 06:53:19 ]
- *7の頃から追っかけてるがあの頃の方が見向きもされなかったぞ。
それどころかボロクソに言われてた
昔はAWTすら使いもんにならなかった気がする。もっとスリムだったし。
- 519 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 08:18:20 ]
- Avalon・Quartz・Cairoて出そろったのになんでJavaだけJava2Dなんだよ。
新型レンダラまだー？
- 520 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 09:07:33 ]
- JOGLがあるよ。
- 521 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 10:50:29 ]
- 3DはJOGLが1.0になったので使い物になった
ただ、フルスクリーン時にGLCanvasが描画されないプラットフォームがあるとかが気になる
GLJPanelは遅くてゲームなどでは実用にならないし
あと日本語ドキュメントが皆無なのがきついな
OpenGL部分はどうでもなるがそこ以外が追うのがきつい
JOGLがコアAPIになればJOGL自体の機能も充実してくると思われ
- 522 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 16:20:42 ]
- JOGLのコア化ってありえるか？
あるとしたら現行Java2Dのハードウェア支援コードとの統合くらいじゃない？
どちらにせよいつの時代もOpenGLはデスクトップ向けVGAのドライバ対応が中途半端だからな。
ワークステーション向けは知らんが。
- 523 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 16:59:41 ]
- >>516
> >>510
> 今に間違いじゃない日が来るって
> おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
> ５年前に予想してたか？
> >>512
> わざとっていうか、自由はセキュリティリスクを持っているからな。
> 徐々に拡大してけばいいだろう
> 何でも出来る穴だらけの何かがデファクトになるのが怖いよ
多重継承も演算子オーバーロードも何でもできますよとPRする
C++言語仕様じゃあるまいし。それはちょっと違うだろう。
Javaでできることはいっぱいあるのに、あえて彼らがそれをやらないのは
彼らが己の既得権益が破壊されるのを恐れているから。
日本企業はハードウェアに強い企業は多いけどソフトウェアには弱い
企業ばかりだからね。ソフト屋にハード屋をつぶされるのを恐れている。
その構図は、テレビ局などのメディアがインターネットを嫌っている理由に非常に良く似ている。
彼らがインターネットやGoogle、Web2.0を嫌っているのは、
彼らが苦労して長い時間をかけて培ってきたノウハウを破壊されるのを恐れているから。
彼らは小泉純一郎のような「痛みを伴う改革」や「格差社会」に自分たちが巻き込まれる
ことをひどく嫌い、ひどく恐れている。
- 524 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:06:04 ]
- >>517
Javaでもこういうことができるよってことで、
とりあえず宣伝だけしておいただけだと思うがな。
いや「だけ」ってことはないな。
Sunが目指していることを実現するための
前準備としての実験でもあったわけだし
一般人にも、Javaというものがどういうものか、
これで理解してもらえたかもしれないね。
最近じゃauの勢力が拡大してどうなるかわからないけど、
一応、BREWの上でJavaも動かせると言われているし。
それに携帯Javaアプリは使えるものはいくつもある。
SuicaのアプリだってＦｅｌｉＣａチップと入出力するところを除き、
アプリケーションはJavaでできている。
なんだかんだいって、燃料電池のような大容量電池を携帯電話に搭載し、
チップが小型化すれば携帯電話Javaもますます良い方向に進んでゆくと
思うけどね。
そこで、Java以外の選択肢を出すと、結局ベンダ依存になってしまう。
今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
基本的なAPIはベンダ依存していない。Java以外の選択肢で、
複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。
BREW開発なんてCPに検査してもらうコストも時間もかかるし、メモリリークの
心配ばかりしないといけないし、容量は相変わらずS!アプリやiアプリの半分くらいでとっても地獄じゃないか。
そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
- 525 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:21:02 ]
- >>523-524
マ板行け。
- 526 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:30:02 ]
- マ板ネタも含まれているかもしれないけどJava MEの将来に対する
要望も含まれているから、ここでもいいのではないかと
- 527 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:35:53 ]
- >>526
要望なら要望聞いてくれるところで言わんと意味無かろうが。
動機からして現状を変えたいというものではなく、
単なる現状の愚痴なわけだし、完全にマ板ネタだろ。
>>523-524 は技術的な話ですらないし。
- 528 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 22:03:34 ]
- 表題みるかぎりSE専門かと
- 529 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:23:01 ]
- 技術的な話も含まれているがのう。
要望ねえ。JCPか？
- 530 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:26:20 ]
- >>529
含まれてないよ。マ板池。
- 531 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:29:54 ]
- >>530
営業やってる連中とか、プログラマ卒業した連中とかだと
>>523-524 が技術的に見えるのかもしらん。
- 532 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 03:14:34 ]
- むしろBREW上のJAVAで話を広げて欲しかった。
というか、そろそろ携帯でJavaSE動かすことできそうなんだけど・・・
Mysaifuの取り組みには期待している
- 533 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 06:00:49 ]
- >>524
>今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
>基本的なAPIはベンダ依存していない。Java以外の選択肢で、
>複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。
ダウト。Write once Run anywhere はケータイでは全然できていない。
APIも仕様も違うのに、簡単とかいうな。お前、じつは作ったことないだろ。
＃何だよ、scratch padって。
#if #else #endif が使えるC++のほうがまだケータイ向き。
でもauの審査がクソ遅いのはなんとかしてほしい。マジで。
> そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
つうかPalmOSが載ってくれれば一番よかったんだよ。なんでJavaなんだ？
- 534 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 07:00:15 ]
- >>532
phoneME Advancedのどこが不満なんだ！ｗ
Mysaifu JVMは俺も入れてるけど・・・。
だって〜かんきょうなくてびるど出来なかったんだも〜んｗｗ
まあ、冗談は置いといてphoneME AdvancedならRIだし全部入りだしHotoSpotあるし、phoneMEベースのプロジェクトを見かけた事ないのが不思議だ。
てかBREW自体流行ってないし国内じゃあうのせいでBREWの印象悪いし、正直実装さえしてくれたらKJNIの方が良いな。
もうちょっとJBlendがRI通りに実装してくれたら・・・
MIDPにMMAPIのprotocolパッケージ入れてくれたら・・・
WavPlyer実装してくれたら・・・
後はデコードくらい自分でするのに・・・
ところでMEにnioパッケージ実装しても端末の物理メモリが足りませんって落ちになるんだろうか？
- 535 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 07:09:12 ]
- >>533
M1000ってPalmじゃなかったけ？
MIDPが使えるからkjavaじゃなくてMIDP for Palm OSなんだろうか。
- 536 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:07:15 ]
- >>532-535
キミら、次世代と関係ない話題は他所でやってくれんかね？
次世代っても、勝手な妄想とか勝手な要望とかは愚痴と変わらんのよ。
便所に「税金安くしてくれ」って書いて要望とか言わんでしょ。
- 537 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 19:04:27 ]
- て言ってもSE7って情報少ないな
- 538 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 20:21:12 ]
- これがSDKに内包されてjavaguiが広まないかなぁ
journal.mycom.co.jp/articles/2007/02/26/jsr296/
- 539 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 21:17:25 ]
- それSwing普通に使える人にとってメリットがほとんどないぞ
フレームワークがはやったから作っただけというのが近い
struts以上に薄いラッパだし、SwingWorerとダブるところも多いし
これほどメリットがないフレームワークってのも珍しい
- 540 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 21:33:51 ]
- ポトペタツールが対応するか次第のよーな。
- 541 名前：デフォルトの名無しさん [2007/02/28(水) 09:38:38 ]
- >>533
> >>524
> #if #else #endif が使えるC++のほうがまだケータイ向き。
> でもauの審査がクソ遅いのはなんとかしてほしい。マジで。
プリ糞セッサに依存している時点で設計が全然駄目じゃん。
> > そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
> それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
Python載せられることのどこがいいの理解できない。
- 542 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 22:01:15 ]
- どこかで見たような・・
- 543 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 22:22:37 ]
- >>533
んー、まえもimodeスレかMIDPスレで書いたけど、#ifdefのような条件
コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だよね。C/C++の後追いだからちゃんと考えられてる。仕様書よんでごらん。
そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。まあ
マクロはないから文法ひっくりかえすような表記でコードは書けないけど、
それはC/C++でも行儀良くないからな。
- 544 名前：543 mailto:sage [2007/02/28(水) 22:31:04 ]
- スレ違いの話だけだとあれなんでSEの話もふっとく。
techon.nikkeibp.co.jp/article/HONSHI/20070220/127928/
↑
OSGi(JSR232)はJavaMEの分野では静かに着々と浸透しているのに
SEへの導入(JSR291)は及び腰なんだよな、Sun。自分で旗振って
OSGi始めたのにいまさら梯子外すのはないよなあ。
- 545 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 09:21:12 ]
- >>543
>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だからそれはJ2SEのような環境が統一されている場合の話であって、
機種依存が激しい携帯ではなりたたないって。
VMですら機能やバージョンが違うのに。
>そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
>併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。
インライン展開があればプリプロセッサは必要ないという根拠が分からん。説明よろしく。
|
 |
