[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/11/20(月) 10:38:16[mustang] 次世代Javaの動向 3 [dolphin]
http://pc8.2ch.net/test/read.cgi/tech/1157227790/
次世代Javaの動向 ２
http://pc8.2ch.net/test/read.cgi/tech/1147881822/
【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc8.2ch.net/test/read.cgi/tech/1081698555/
2006年12月にMustang Java SE 6がリリース予定
Mustangの掲げる主な目標は以下の点にある。
* 互換性と安定性および品質の向上
* Easy of Developmentの実現
* WebサービスおよびXMLサポート機能の拡張
* リソース管理や診断機能の強化
* デスクトップ環境の強化
Java SE 6 じゃじゃ馬ならし
http://www.javainthebox.net/laboratory/JavaSE6/
0446デフォルトの名無しさん
2007/02/21(水) 17:33:20> メモリの断片化をプログラマで制御出来ないよな？
↑出来る処理系ってあるの？
0447デフォルトの名無しさん
2007/02/21(水) 17:47:52C/C++だとメモリ管理は自分でするから確保も解放も
自分のタイミングで出来るって程度の意味だ。
勝手なタイミングでガンガンGCされるより断片化起こらないよねって話な。
0448デフォルトの名無しさん
2007/02/21(水) 18:01:42それはおかしい
断片化と解放とは別の話だろ
それにC++だってアロケートしなおししないと同じだし
JavaのGCはそのタイミングをコントロールできないという点だけが問題
0449デフォルトの名無しさん
2007/02/21(水) 20:44:23-XX:+ExplicitGCInvokesConcurrent
で、Java6なら完全停止は回避できる、のかな？
ttp://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/cms-6.html
0450デフォルトの名無しさん
2007/02/21(水) 23:45:23mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に
placed newでオブジェクト作れば、制御できると思う。
制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。
0451デフォルトの名無しさん
2007/02/21(水) 23:50:06GC でコンパクションが発生するのに断片化って???
0452デフォルトの名無しさん
2007/02/21(水) 23:53:010453デフォルトの名無しさん
2007/02/21(水) 23:57:03いつもの事だ。
0454デフォルトの名無しさん
2007/02/22(木) 00:01:05> >>444
> System.GCしか今のところコントロールする方法はない。
java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。
0455デフォルトの名無しさん
2007/02/22(木) 00:02:05> >>444
> どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
> 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
彼らがJavaを作った目的は家電制御なんだけどな。
彼らはサーバを発電所のように使うものを想定している。
0456デフォルトの名無しさん
2007/02/22(木) 00:04:13Bufferインタフェースを使って
巨大な配列を確保すれば
擬似的に管理できないこともないぞｗ
C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。
Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw
0457デフォルトの名無しさん
2007/02/22(木) 00:05:52香具師はいないのね
0458デフォルトの名無しさん
2007/02/22(木) 00:14:10そりゃ、居ないだろ。
あれは到達可能でなくなった事を知るためのもので、
到達可能でなくす事を可能にしてくれるわけじゃない。
0459デフォルトの名無しさん
2007/02/22(木) 01:27:33それ定期的に出てくるけどぜんぜんコントロールできねーよ
0460デフォルトの名無しさん
2007/02/22(木) 13:56:010461デフォルトの名無しさん
2007/02/22(木) 21:22:260462デフォルトの名無しさん
2007/02/23(金) 00:09:490463デフォルトの名無しさん
2007/02/23(金) 00:26:430464デフォルトの名無しさん
2007/02/23(金) 00:27:32あんな仕様では当分Javaには勝てないことがわかった。
D言語やC#のほうが全然魅力的だった。
0465デフォルトの名無しさん
2007/02/23(金) 00:31:080466デフォルトの名無しさん
2007/02/23(金) 01:51:350467デフォルトの名無しさん
2007/02/23(金) 01:57:48チンコの仕様に優れていても、使用に優れてない奴とかいるし。
0468デフォルトの名無しさん
2007/02/23(金) 02:01:08チョンのチンコの仕様は9cmで世界一ミクロ
0469デフォルトの名無しさん
2007/02/23(金) 02:06:380470デフォルトの名無しさん
2007/02/23(金) 04:24:39http://download.java.net/jdk7/changes/jdk7-b08.html
http://download.java.net/jdk7/binaries/
サマリが何も出来ていない
変わってないのかっ
と疑問も持ちつつUpdateする俺でした
0471デフォルトの名無しさん
2007/02/23(金) 05:02:190472デフォルトの名無しさん
2007/02/23(金) 06:35:41最近標準化連中は仕様作り過ぎｗ
C++のexportみたいにry
コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
みたいにさ。
マジレスするとunsignedが欲しい。
static final unsigned byte の範囲の定数が欲しいのにって度々思う
#Java書いてるとshortの存在を忘れてint使っちゃう俺
0473デフォルトの名無しさん
2007/02/23(金) 07:56:31>static final unsigned byte の範囲の定数が欲しいのにって度々思う
short や int じゃだめってこと？
ケータイJavaかなんかかな。
0474デフォルトの名無しさん
2007/02/23(金) 08:57:090475デフォルトの名無しさん
2007/02/23(金) 10:10:27そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
ビット操作中心なんで負数は使えんし、
そもそもMEで使わんディスクスペースとヒープを確保する余裕はない！
そもそもstatic finalなフィールドすら宣言する余裕なんて無いんだよ。
文字列定数の長さを気にする様な世界だ。
ややこしい・・・
0476デフォルトの名無しさん
2007/02/23(金) 11:16:49嫌がらせだなｗ
0477デフォルトの名無しさん
2007/02/23(金) 11:19:44ビット操作でも負数は使えるはずだが
0478デフォルトの名無しさん
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何て出来たもんだ
0479デフォルトの名無しさん
2007/02/23(金) 13:38:05> CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
> 最近標準化連中は仕様作り過ぎｗ
> C++のexportみたいにry
> コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
> みたいにさ。
> マジレスするとunsignedが欲しい。
> static final unsigned byte の範囲の定数が欲しいのにって度々思う
> #Java書いてるとshortの存在を忘れてint使っちゃう俺
ラッパークラス作れ
0480デフォルトの名無しさん
2007/02/23(金) 13:54:21> >>473
> そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
今はJ2MEではなくJava ME。
つうか、もうそろそろ、スペック問題解決してもいいのでは。
昔と比べ、容量は10倍以上になったんじゃないのか？
S!アプリももう何年か前から1MBアプリを作れるようになったし
iアプリも903iからDoja5.0になって1MBにもなったし、今やダウンロード、スクラッチパッドの境界が
無くなって外部メモリも使えるようになって1MB以上のアプリも作れるようになったろ。
昔の10kB時代と比べたら全然気にしなくても良いようになってきたんではないのか？
0481デフォルトの名無しさん
2007/02/23(金) 13:55:320-127に加えて-1か128を128替わり使えばいいのではと
0482デフォルトの名無しさん
2007/02/23(金) 13:56:13とりあえず新たにデータ型作るってのはどうよ
0483デフォルトの名無しさん
2007/02/23(金) 13:57:12jarsで圧縮率を上げればjarサイズが半分になるぜ
0484デフォルトの名無しさん
2007/02/23(金) 21:57:02言語仕様で決まってなかったっけ。
0485デフォルトの名無しさん
2007/02/23(金) 22:04:07使えるのか？
0486デフォルトの名無しさん
2007/02/23(金) 22:05:35決まってない。final で修飾されて、確実に定数式で初期化される変数だけ。
それに、ME とかの場合は static final な変数自体も節約したいんでしょ。
0487デフォルトの名無しさん
2007/02/24(土) 03:48:32使えない。VM仕様がJITがオプション扱いでブートストラップクラスローダしかない1.4か1.3時代程度だったとオモ。
けどジェネリックスなんて使うケースないと思う。
MEじゃあるべき処理を平気でとっぱらうからアルゴリズムの使い回しとか不要。
他にも汎用データクラス作るんじゃなくて一つのクラスに全てのデータと処理をぶち込むからジェネリックスの立場がない・・・。
インターフェイスすら排除する世界だぜｗ
ところでこんなリスト見つけた。VM仕様関連の情報らしい。
ttp://www.ingrid.org/java/vm/
0488デフォルトの名無しさん
2007/02/24(土) 12:23:48ジェネリクスはコレクションを手軽に扱うためだけとおもっても十分な効果が出るよ
0489デフォルトの名無しさん
2007/02/24(土) 12:59:51まだ搭載できないでいるのか・・・
しかもまたまた1.3レベルとは。assertも使えぬのか。
アノテーションくらいはつかえたほうがいいとは思うのだが。
コンパイル時には無視できるタイプのアノテーションはとくにあったほうが便利だろう？
それに、いくつかクラスやメソッドが増えているし。
制約上全部は使えないとは思うけど、利便性を考えると、1.3レベルってつらそう。
0490デフォルトの名無しさん
2007/02/24(土) 13:32:37> ttp://www.ingrid.org/java/vm/
古いね。デッドリンク多いし。
0491デフォルトの名無しさん
2007/02/24(土) 15:42:08高速化したのはSunのJava SE 5の実装で、Javaっていう規格じゃないだろ。
ケータイって、SunのJVMが主流なの？
0492デフォルトの名無しさん
2007/02/24(土) 17:23:16コレクション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に何かくれよｗ
0493デフォルトの名無しさん
2007/02/24(土) 17:52:22CLDC 1.1 なら java.util.TimeZone が GMT をサポートするのは義務じゃなかったっけ？
TimeZone は GMT をサポートするけど、それを使っても
GMT な時間が返ってくるとは限らないってオチはあるかもなー、とか思った。
そーいや、JSR-310 で Date and Time API ってのがあったような。
あれって、JDK7 の contents だっけか？
0494デフォルトの名無しさん
2007/02/24(土) 18:28:20System.currentTimeMills()の値を引数にして
DateやCalenderを作っても正確にならない？
0495デフォルトの名無しさん
2007/02/24(土) 18:31:30> >>491
> 主流はアプレックスのJBlend。
> 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。
遅いとかではなく、かれらがハードウェアリソースをケチっているだけだと
いってみたかったりする。
携帯電話をもう少し大型化して、JVMの部分を物理的に大きく専有するようにして、電池も
巨大化させれば携帯電話でも十分早くなるはずだ、と言ってみる。
ハードディスク搭載、とバッテリ寿命さえ延びれば、さらにその理屈もとおるはずだ、と言ってみる。
そして、連中は、独自実装で市場を独占したいだけに過ぎないのだ、
かつてのSonyがやってたような、独自製品で覆い尽くし、ライバル製品との
互換性をわざと奪うために標準Java実装から逃げているだけなのだ、と言ってみせる。
0496デフォルトの名無しさん
2007/02/24(土) 19:48:51いやVectorとかでいいんだよ
それでも十分使い勝手がいい
中に何を格納するべきなのかをドキュメントに書かないとわからないってのは面倒だったりする
そういやJavaME用HotspotVMを開発したとかどっかのニュースみたな
携帯の用途だとhotspotよりはアーカイブ単位での丸ごとコンパイルのほうがよさそうだが
0497デフォルトの名無しさん
2007/02/24(土) 20:10:36IBMの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のときこの部分ごっそり削除してくれるし。
0498497
2007/02/24(土) 20:36:05>static final boolean DEBUG = false;
>public void assert(boolean flag, ...){
> if(DEBUG){
> if(!flag){
> ...
> }
> }
>}
みたいな感じか。細かいことだけど。
0499デフォルトの名無しさん
2007/02/24(土) 20:52:52今ならAspectJでもっと効率よくできるかな？
0500デフォルトの名無しさん
2007/02/24(土) 22:31:51確か仕様上は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騒動であれだけカオスったのに。
0501497
2007/02/24(土) 22:46:46IBMがつくったコンパイラは例えば
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とは別物だよ。
0502デフォルトの名無しさん
2007/02/24(土) 23:54:51もうさ、メガアプリ限定にしてしまえばいいよ。
俺たちが作りたいソフトはこういうものだから、
ハードウェアをもっと強化しろ！
とハード屋に圧力をかけてさ。
マイクロソフトみたいに力がないと
Vistaみたいな激重Windowsを開発してハードウェア屋が
それに追従するってこと難しいかな。
今はハード基準で携帯電話開発を強いられているみたいだけど、
ソフト屋からハード屋になんとかして圧力かけられないかねえ。
「お前らハード屋がだらしないから携帯電話開発がしづらいんだ！
ハードのスペックを高めることを要求する！」
みたいにさ
0503デフォルトの名無しさん
2007/02/24(土) 23:58:12> >>496
> いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。
java.nio.Bufferを実装したクラスを配列代わりに扱えば高速化するのでは？
と思ったら、あれJ2SE1.4からのものだった。
> >>497
> 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。
SoftBankもまともじゃないし、KDDIもまともじゃないし、Docomoもどいつもこいつも
独占欲だけは高いからねえ。
ハードウェア重視でソフトウェアをなめてかかっているところが、だらしないよ。
日本の有名な大手家電メーカーがインターネット産業ろくに力を注がず、Web2.0に
乗り遅れたことをも証明しているし。
0504デフォルトの名無しさん
2007/02/25(日) 00:04:27とは言え、行き過ぎると Vista や PS3 の二の舞になると思うよ。
0505デフォルトの名無しさん
2007/02/25(日) 00:42:46どちらにしてもオープン標準のJava仕様がないがしろにされてるな。
まあ、ソフト屋ですら飼いならされてる現状じゃ仕方ないか。
仕様の地位をもっとこうW3C勧告の仕様並みに出来んかねぇ？（IEの糞実装さえなくなれば平和だからなアッチは）
ハードの方は十分にパワフルだと思うけどな・・・
翌々考えたら昔はメモリ以外今の携帯以下のハードと糞ＯＳでJavaが動いてたんだから。
win95よりce5のが安定してるしｗ
国内携帯は無駄な機能に溢れ返ってるからそれにシステムリソースとコストと
開発期間が圧迫されて一ソフトウェアどころじゃないだろうな。
またしても仕様の地位不足か・・・
SUNの苦労体質全部をJavaが担ってる気がするｗ
0506デフォルトの名無しさん
2007/02/25(日) 01:02:42パワフルな割には容量が足りないってどういう事なんだろうなあと思うよ。
メモリもっと増やすべき。でないととてもパワフルじゃないな。
現実問題として電力消費が激しいと言う問題があるそうだ。
しかし省エネ型DRAMのようなメモリがもっと普及すれば解決できるんだとか。
つうか、携帯電話会社は、余計な機能にエネルギーを無駄に費やさず
Javaの部分にエネルギーを費やして欲しいな。
あらゆる機能をJavaを中心に動かせるようにすれば水平ポータビリティを
維持できるし、どの携帯電話でも同じように動くアプリを簡単に作れるようになる。
0507デフォルトの名無しさん
2007/02/25(日) 01:23:02建前上JBlend on BREW（サービス名オープンアプリ/どこがオープン何だと小一時間・・・）のっけましたが？
Javaで水平ポータビリティ実現すればsunの当初の目的が実現するな。
その為にはベンダーに協力してもらわんとダメだが。
その前に日本の携帯ビジネスモデルを破壊しないと受け入れられないだろう。
4G携帯なんて出したらドコモが死守してソフトバンクが
嘘ばら蒔いてイーモバとウィルが歓迎するんだろうな。
KDDIはBREW動いて音楽と動画DL出来れば何でも良さそうだが。
ネイティブ開発は個人には不可能か敷居高いだろうしJava（MIDP）流行らんもんかね
0508デフォルトの名無しさん
2007/02/25(日) 01:38:36審査に金かかるわ時間もかかるわ。
0509デフォルトの名無しさん
2007/02/25(日) 06:56:240510デフォルトの名無しさん
2007/02/25(日) 07:12:430511デフォルトの名無しさん
2007/02/25(日) 10:59:44今の技術では、携帯に望みすぎ。
0512デフォルトの名無しさん
2007/02/25(日) 12:55:29燃料電池またはＨＤＤが搭載されるもしくは
PDAなどもっと大型の携帯端末なら、
Javaをやる価値は少しはあるのではないかと言ってみる。
携帯キャリアメーカーもJavaに自分たちの収入源を
奪われるのを恐れて、わざとJavaの機能を制限して
Write Once, Run Anywhereの妨害をしているとおもうけどな。
彼らの、Javaの普及を妨害するやり方はつくづく陰湿だと思う。
0513デフォルトの名無しさん
2007/02/25(日) 13:37:18CPUのクロックだけで比べても意味がないぞ
0514デフォルトの名無しさん
2007/02/25(日) 21:46:090515デフォルトの名無しさん
2007/02/25(日) 22:17:51すごく間違いだと思うなあ。Java熱に浮かされてただけじゃないかな。
0516デフォルトの名無しさん
2007/02/26(月) 03:24:52今に間違いじゃない日が来るって
おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
５年前に予想してたか？
>>512
わざとっていうか、自由はセキュリティリスクを持っているからな。
徐々に拡大してけばいいだろう
何でも出来る穴だらけの何かがデファクトになるのが怖いよ
0517デフォルトの名無しさん
2007/02/26(月) 04:23:39>今に間違いじゃない日が来るって
それって、今は間違いってことじゃん。
間違いじゃない日がきてから実用化すればいいのに。
なんでJava以外の選択肢を考えないのかね。
Collectionも使えないなんて、そんなんJavaじゃねーよ。
道具は適材適所。そこまでしてJavaにこだわるのが分からん。
0518デフォルトの名無しさん
2007/02/26(月) 06:53:19それどころかボロクソに言われてた
昔はAWTすら使いもんにならなかった気がする。もっとスリムだったし。
0519デフォルトの名無しさん
2007/02/26(月) 08:18:20新型レンダラまだー？
0520デフォルトの名無しさん
2007/02/26(月) 09:07:330521デフォルトの名無しさん
2007/02/26(月) 10:50:29ただ、フルスクリーン時にGLCanvasが描画されないプラットフォームがあるとかが気になる
GLJPanelは遅くてゲームなどでは実用にならないし
あと日本語ドキュメントが皆無なのがきついな
OpenGL部分はどうでもなるがそこ以外が追うのがきつい
JOGLがコアAPIになればJOGL自体の機能も充実してくると思われ
0522デフォルトの名無しさん
2007/02/26(月) 16:20:42あるとしたら現行Java2Dのハードウェア支援コードとの統合くらいじゃない？
どちらにせよいつの時代もOpenGLはデスクトップ向けVGAのドライバ対応が中途半端だからな。
ワークステーション向けは知らんが。
0523デフォルトの名無しさん
2007/02/26(月) 16:59:41> >>510
> 今に間違いじゃない日が来るって
> おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
> ５年前に予想してたか？
> >>512
> わざとっていうか、自由はセキュリティリスクを持っているからな。
> 徐々に拡大してけばいいだろう
> 何でも出来る穴だらけの何かがデファクトになるのが怖いよ
多重継承も演算子オーバーロードも何でもできますよとPRする
C++言語仕様じゃあるまいし。それはちょっと違うだろう。
Javaでできることはいっぱいあるのに、あえて彼らがそれをやらないのは
彼らが己の既得権益が破壊されるのを恐れているから。
日本企業はハードウェアに強い企業は多いけどソフトウェアには弱い
企業ばかりだからね。ソフト屋にハード屋をつぶされるのを恐れている。
その構図は、テレビ局などのメディアがインターネットを嫌っている理由に非常に良く似ている。
彼らがインターネットやGoogle、Web2.0を嫌っているのは、
彼らが苦労して長い時間をかけて培ってきたノウハウを破壊されるのを恐れているから。
彼らは小泉純一郎のような「痛みを伴う改革」や「格差社会」に自分たちが巻き込まれる
ことをひどく嫌い、ひどく恐れている。
0524デフォルトの名無しさん
2007/02/26(月) 17:06:04Javaでもこういうことができるよってことで、
とりあえず宣伝だけしておいただけだと思うがな。
いや「だけ」ってことはないな。
Sunが目指していることを実現するための
前準備としての実験でもあったわけだし
一般人にも、Javaというものがどういうものか、
これで理解してもらえたかもしれないね。
最近じゃauの勢力が拡大してどうなるかわからないけど、
一応、BREWの上でJavaも動かせると言われているし。
それに携帯Javaアプリは使えるものはいくつもある。
SuicaのアプリだってＦｅｌｉＣａチップと入出力するところを除き、
アプリケーションはJavaでできている。
なんだかんだいって、燃料電池のような大容量電池を携帯電話に搭載し、
チップが小型化すれば携帯電話Javaもますます良い方向に進んでゆくと
思うけどね。
そこで、Java以外の選択肢を出すと、結局ベンダ依存になってしまう。
今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
基本的なAPIはベンダ依存していない。Java以外の選択肢で、
複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。
BREW開発なんてCPに検査してもらうコストも時間もかかるし、メモリリークの
心配ばかりしないといけないし、容量は相変わらずS!アプリやiアプリの半分くらいでとっても地獄じゃないか。
そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
0525デフォルトの名無しさん
2007/02/26(月) 17:21:02マ板行け。
0526デフォルトの名無しさん
2007/02/26(月) 17:30:02要望も含まれているから、ここでもいいのではないかと
0527デフォルトの名無しさん
2007/02/26(月) 17:35:53要望なら要望聞いてくれるところで言わんと意味無かろうが。
動機からして現状を変えたいというものではなく、
単なる現状の愚痴なわけだし、完全にマ板ネタだろ。
>>523-524 は技術的な話ですらないし。
0528デフォルトの名無しさん
2007/02/26(月) 22:03:340529デフォルトの名無しさん
2007/02/26(月) 23:23:01要望ねえ。JCPか？
0530デフォルトの名無しさん
2007/02/26(月) 23:26:20含まれてないよ。マ板池。
0531デフォルトの名無しさん
2007/02/26(月) 23:29:54営業やってる連中とか、プログラマ卒業した連中とかだと
>>523-524 が技術的に見えるのかもしらん。
0532デフォルトの名無しさん
2007/02/27(火) 03:14:34というか、そろそろ携帯でJavaSE動かすことできそうなんだけど・・・
Mysaifuの取り組みには期待している
0533デフォルトの名無しさん
2007/02/27(火) 06:00:49>今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
>基本的なAPIはベンダ依存していない。Java以外の選択肢で、
>複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。
ダウト。Write once Run anywhere はケータイでは全然できていない。
APIも仕様も違うのに、簡単とかいうな。お前、じつは作ったことないだろ。
＃何だよ、scratch padって。
#if #else #endif が使えるC++のほうがまだケータイ向き。
でもauの審査がクソ遅いのはなんとかしてほしい。マジで。
> そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
つうかPalmOSが載ってくれれば一番よかったんだよ。なんでJavaなんだ？
0534デフォルトの名無しさん
2007/02/27(火) 07:00:15phoneME Advancedのどこが不満なんだ！ｗ
Mysaifu JVMは俺も入れてるけど・・・。
だって〜かんきょうなくてびるど出来なかったんだも〜んｗｗ
まあ、冗談は置いといてphoneME AdvancedならRIだし全部入りだしHotoSpotあるし、phoneMEベースのプロジェクトを見かけた事ないのが不思議だ。
てかBREW自体流行ってないし国内じゃあうのせいでBREWの印象悪いし、正直実装さえしてくれたらKJNIの方が良いな。
もうちょっとJBlendがRI通りに実装してくれたら・・・
MIDPにMMAPIのprotocolパッケージ入れてくれたら・・・
WavPlyer実装してくれたら・・・
後はデコードくらい自分でするのに・・・
ところでMEにnioパッケージ実装しても端末の物理メモリが足りませんって落ちになるんだろうか？
0535デフォルトの名無しさん
2007/02/27(火) 07:09:12M1000ってPalmじゃなかったけ？
MIDPが使えるからkjavaじゃなくてMIDP for Palm OSなんだろうか。
0536デフォルトの名無しさん
2007/02/27(火) 12:07:15キミら、次世代と関係ない話題は他所でやってくれんかね？
次世代っても、勝手な妄想とか勝手な要望とかは愚痴と変わらんのよ。
便所に「税金安くしてくれ」って書いて要望とか言わんでしょ。
0537デフォルトの名無しさん
2007/02/27(火) 19:04:270538デフォルトの名無しさん
2007/02/27(火) 20:21:12http://journal.mycom.co.jp/articles/2007/02/26/jsr296/
0539デフォルトの名無しさん
2007/02/27(火) 21:17:25フレームワークがはやったから作っただけというのが近い
struts以上に薄いラッパだし、SwingWorerとダブるところも多いし
これほどメリットがないフレームワークってのも珍しい
0540デフォルトの名無しさん
2007/02/27(火) 21:33:510541デフォルトの名無しさん
2007/02/28(水) 09:38:38> >>524
> #if #else #endif が使えるC++のほうがまだケータイ向き。
> でもauの審査がクソ遅いのはなんとかしてほしい。マジで。
プリ糞セッサに依存している時点で設計が全然駄目じゃん。
> > そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
> それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
Python載せられることのどこがいいの理解できない。
0542デフォルトの名無しさん
2007/02/28(水) 22:01:150543デフォルトの名無しさん
2007/02/28(水) 22:22:37んー、まえもimodeスレかMIDPスレで書いたけど、#ifdefのような条件
コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だよね。C/C++の後追いだからちゃんと考えられてる。仕様書よんでごらん。
そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。まあ
マクロはないから文法ひっくりかえすような表記でコードは書けないけど、
それはC/C++でも行儀良くないからな。
0544543
2007/02/28(水) 22:31:04http://techon.nikkeibp.co.jp/article/HONSHI/20070220/127928/
↑
OSGi(JSR232)はJavaMEの分野では静かに着々と浸透しているのに
SEへの導入(JSR291)は及び腰なんだよな、Sun。自分で旗振って
OSGi始めたのにいまさら梯子外すのはないよなあ。
0545デフォルトの名無しさん
2007/03/01(木) 09:21:12>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だからそれはJ2SEのような環境が統一されている場合の話であって、
機種依存が激しい携帯ではなりたたないって。
VMですら機能やバージョンが違うのに。
>そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
>併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。
インライン展開があればプリプロセッサは必要ないという根拠が分からん。説明よろしく。
■ このスレッドは過去ログ倉庫に格納されています