[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]

[mustang/Java SE 6] ..

449:デフォルトの名無しさん
07/02/21 20:44:23
>>445
-XX:+ExplicitGCInvokesConcurrent
で、Java6なら完全停止は回避できる、のかな？
URLﾘﾝｸ(java.sun.com)

450:デフォルトの名無しさん
07/02/21 23:45:23
>>448
mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に
placed newでオブジェクト作れば、制御できると思う。
制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。

451:デフォルトの名無しさん
07/02/21 23:50:06
>>444
GC でコンパクションが発生するのに断片化って???

452:デフォルトの名無しさん
07/02/21 23:53:01
なんか、全然次世代じゃない話で盛り上がってるな。

453:デフォルトの名無しさん
07/02/21 23:57:03
>>452
いつもの事だ。

454:デフォルトの名無しさん
07/02/22 00:01:05
>>445
> >>444
> System.GCしか今のところコントロールする方法はない。

java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。

455:デフォルトの名無しさん
07/02/22 00:02:05
>>445
> >>444
> どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
> 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。

彼らがJavaを作った目的は家電制御なんだけどな。
彼らはサーバを発電所のように使うものを想定している。

456:デフォルトの名無しさん
07/02/22 00:04:13
>>446
Bufferインタフェースを使って
巨大な配列を確保すれば
擬似的に管理できないこともないぞｗ

C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。
Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw

457:デフォルトの名無しさん
07/02/22 00:05:52
java.lang.refでオブジェクトの「到達可能性」をコントロールできる
香具師はいないのね

458:デフォルトの名無しさん
07/02/22 00:14:10
>>457
そりゃ、居ないだろ。

あれは到達可能でなくなった事を知るためのもので、
到達可能でなくす事を可能にしてくれるわけじゃない。

459:デフォルトの名無しさん
07/02/22 01:27:33
>>454
それ定期的に出てくるけどぜんぜんコントロールできねーよ

460:デフォルトの名無しさん
07/02/22 13:56:01
いつの世代でもGCは永遠の謎なのだ。

461:デフォルトの名無しさん
07/02/22 21:22:26
GCなしの方がよかったかもな～

462:デフォルトの名無しさん
07/02/23 00:09:49
GCなしなんていまさらありえんだろ

463:デフォルトの名無しさん
07/02/23 00:26:43
C++に逆戻りか？

464:デフォルトの名無しさん
07/02/23 00:27:32
C++0xの使用をみたが、期待はずれだった。

あんな仕様では当分Javaには勝てないことがわかった。

D言語やC#のほうが全然魅力的だった。

465:デフォルトの名無しさん
07/02/23 00:31:08
もう使用されているとは

466:デフォルトの名無しさん
07/02/23 01:51:35
なんで、C++はそんなに使用を拡張していくんだろうねぇ…。今でも十分じゃん。

467:デフォルトの名無しさん
07/02/23 01:57:48
そうだよな。

チンコの仕様に優れていても、使用に優れてない奴とかいるし。

468:デフォルトの名無しさん
07/02/23 02:01:08
チョンの仕様かと思ったw

チョンのチンコの仕様は9cmで世界一ミクロ

469:デフォルトの名無しさん
07/02/23 02:06:38
仕様も使用もダメな例だな

470:デフォルトの名無しさん
07/02/23 04:24:39
JDK7 build08
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)

サマリが何も出来ていない
変わってないのかっ
と疑問も持ちつつUpdateする俺でした

471:デフォルトの名無しさん
07/02/23 05:02:19
マネージド○○って完全にわすｒｙ

472:デフォルトの名無しさん
07/02/23 06:35:41
CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
最近標準化連中は仕様作り過ぎｗ
C++のexportみたいにry

コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
みたいにさ。

マジレスするとunsignedが欲しい。

static final unsigned byte の範囲の定数が欲しいのにって度々思う

#Java書いてるとshortの存在を忘れてint使っちゃう俺

473:デフォルトの名無しさん
07/02/23 07:56:31
>>472
>static final unsigned byte の範囲の定数が欲しいのにって度々思う
short や int じゃだめってこと？
ケータイJavaかなんかかな。

474:デフォルトの名無しさん
07/02/23 08:57:09
マイナス、負の値を使えばいい。

475:デフォルトの名無しさん
07/02/23 10:10:27
>>473
そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
ビット操作中心なんで負数は使えんし、
そもそもMEで使わんディスクスペースとヒープを確保する余裕はない！

そもそもstatic finalなフィールドすら宣言する余裕なんて無いんだよ。

文字列定数の長さを気にする様な世界だ。
ややこしい・・・

476:デフォルトの名無しさん
07/02/23 11:16:49
>丁度0-128を使う

嫌がらせだなｗ

477:デフォルトの名無しさん
07/02/23 11:19:44
>>475
ビット操作でも負数は使えるはずだが

478:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/23 13:38:05
>>472
> CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
> 最近標準化連中は仕様作り過ぎｗ
> C++のexportみたいにry
> コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
> みたいにさ。
> マジレスするとunsignedが欲しい。
> static final unsigned byte の範囲の定数が欲しいのにって度々思う
> #Java書いてるとshortの存在を忘れてint使っちゃう俺

ラッパークラス作れ

480:デフォルトの名無しさん
07/02/23 13:54:21
>>475
> >>473
> そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。

今はJ2MEではなくJava ME。

つうか、もうそろそろ、スペック問題解決してもいいのでは。

昔と比べ、容量は10倍以上になったんじゃないのか？

S!アプリももう何年か前から1MBアプリを作れるようになったし
iアプリも903iからDoja5.0になって1MBにもなったし、今やダウンロード、スクラッチパッドの境界が
無くなって外部メモリも使えるようになって1MB以上のアプリも作れるようになったろ。

昔の10kB時代と比べたら全然気にしなくても良いようになってきたんではないのか？

481:デフォルトの名無しさん
07/02/23 13:55:32
>>476
0-127に加えて-1か128を128替わり使えばいいのではと

482:デフォルトの名無しさん
07/02/23 13:56:13
>>478
とりあえず新たにデータ型作るってのはどうよ

483:デフォルトの名無しさん
07/02/23 13:57:12
>>478
jarsで圧縮率を上げればjarサイズが半分になるぜ

484:デフォルトの名無しさん
07/02/23 21:57:02
static final は普通に、コンパイラでインライン展開することが
言語仕様で決まってなかったっけ。

485:デフォルトの名無しさん
07/02/23 22:04:07
今のJava MEではGenericsやアノテーションは
使えるのか？

486:デフォルトの名無しさん
07/02/23 22:05:35
>>484
決まってない。final で修飾されて、確実に定数式で初期化される変数だけ。

それに、ME とかの場合は static final な変数自体も節約したいんでしょ。

487:デフォルトの名無しさん
07/02/24 03:48:32
>>845
使えない。VM仕様がJITがオプション扱いでブートストラップクラスローダしかない1.4か1.3時代程度だったとオモ。

けどジェネリックスなんて使うケースないと思う。
MEじゃあるべき処理を平気でとっぱらうからアルゴリズムの使い回しとか不要。
他にも汎用データクラス作るんじゃなくて一つのクラスに全てのデータと処理をぶち込むからジェネリックスの立場がない・・・。

インターフェイスすら排除する世界だぜｗ

ところでこんなリスト見つけた。VM仕様関連の情報らしい。
URLﾘﾝｸ(www.ingrid.org)

488:デフォルトの名無しさん
07/02/24 12:23:48
>>487
ジェネリクスはコレクションを手軽に扱うためだけとおもっても十分な効果が出るよ

489:デフォルトの名無しさん
07/02/24 12:59:51
Java SE 5になってから大分高速化したのに携帯電話には
まだ搭載できないでいるのか・・・

しかもまたまた1.3レベルとは。assertも使えぬのか。

アノテーションくらいはつかえたほうがいいとは思うのだが。
コンパイル時には無視できるタイプのアノテーションはとくにあったほうが便利だろう？

それに、いくつかクラスやメソッドが増えているし。
制約上全部は使えないとは思うけど、利便性を考えると、1.3レベルってつらそう。

490:デフォルトの名無しさん
07/02/24 13:32:37
>>487
> URLﾘﾝｸ(www.ingrid.org)
古いね。デッドリンク多いし。

491:デフォルトの名無しさん
07/02/24 15:42:08
>>489
高速化したのはSunのJava SE 5の実装で、Javaっていう規格じゃないだろ。
ケータイって、SunのJVMが主流なの？

492:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/24 18:28:20
>>492
System.currentTimeMills()の値を引数にして
DateやCalenderを作っても正確にならない？

495:デフォルトの名無しさん
07/02/24 18:31:30
>>492
> >>491
> 主流はアプレックスのJBlend。
> 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。

遅いとかではなく、かれらがハードウェアリソースをケチっているだけだと
いってみたかったりする。
携帯電話をもう少し大型化して、JVMの部分を物理的に大きく専有するようにして、電池も
巨大化させれば携帯電話でも十分早くなるはずだ、と言ってみる。

ハードディスク搭載、とバッテリ寿命さえ延びれば、さらにその理屈もとおるはずだ、と言ってみる。

そして、連中は、独自実装で市場を独占したいだけに過ぎないのだ、
かつてのSonyがやってたような、独自製品で覆い尽くし、ライバル製品との
互換性をわざと奪うために標準Java実装から逃げているだけなのだ、と言ってみせる。

496:デフォルトの名無しさん
07/02/24 19:48:51
>>492
いやVectorとかでいいんだよ
それでも十分使い勝手がいい

中に何を格納するべきなのかをドキュメントに書かないとわからないってのは面倒だったりする

そういやJavaME用HotspotVMを開発したとかどっかのニュースみたな
携帯の用途だとhotspotよりはアーカイブ単位での丸ごとコンパイルのほうがよさそうだが

497:デフォルトの名無しさん
07/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
07/02/24 20:36:05
アサーションだから
>static final boolean DEBUG = false;
>public void assert(boolean flag, ...){
> if(DEBUG){
> if(!flag){
> ...
> }
> }
>}
みたいな感じか。細かいことだけど。

499:デフォルトの名無しさん
07/02/24 20:52:52
なるほどー。
今ならAspectJでもっと効率よくできるかな？

500:デフォルトの名無しさん
07/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
07/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:デフォルトの名無しさん
07/02/24 23:54:51
>>500
もうさ、メガアプリ限定にしてしまえばいいよ。
俺たちが作りたいソフトはこういうものだから、
ハードウェアをもっと強化しろ！

とハード屋に圧力をかけてさ。

マイクロソフトみたいに力がないと
Vistaみたいな激重Windowsを開発してハードウェア屋が
それに追従するってこと難しいかな。

今はハード基準で携帯電話開発を強いられているみたいだけど、
ソフト屋からハード屋になんとかして圧力かけられないかねえ。

「お前らハード屋がだらしないから携帯電話開発がしづらいんだ！
ハードのスペックを高めることを要求する！」
みたいにさ

503:デフォルトの名無しさん
07/02/24 23:58:12
>>500
> >>496
> いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。

java.nio.Bufferを実装したクラスを配列代わりに扱えば高速化するのでは？
と思ったら、あれJ2SE1.4からのものだった。

> >>497
> 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。

SoftBankもまともじゃないし、KDDIもまともじゃないし、Docomoもどいつもこいつも
独占欲だけは高いからねえ。

ハードウェア重視でソフトウェアをなめてかかっているところが、だらしないよ。
日本の有名な大手家電メーカーがインターネット産業ろくに力を注がず、Web2.0に
乗り遅れたことをも証明しているし。

504:デフォルトの名無しさん
07/02/25 00:04:27
>>502
とは言え、行き過ぎると Vista や PS3 の二の舞になると思うよ。

505:デフォルトの名無しさん
07/02/25 00:42:46
国内だとキャリア（←こいつが一番無関係ｗ）、世界的にはハード屋が頂点か。
どちらにしてもオープン標準のJava仕様がないがしろにされてるな。

まあ、ソフト屋ですら飼いならされてる現状じゃ仕方ないか。
仕様の地位をもっとこうW3C勧告の仕様並みに出来んかねぇ？（IEの糞実装さえなくなれば平和だからなアッチは）

ハードの方は十分にパワフルだと思うけどな・・・
翌々考えたら昔はメモリ以外今の携帯以下のハードと糞ＯＳでJavaが動いてたんだから。
win95よりce5のが安定してるしｗ
国内携帯は無駄な機能に溢れ返ってるからそれにシステムリソースとコストと
開発期間が圧迫されて一ソフトウェアどころじゃないだろうな。
またしても仕様の地位不足か・・・

SUNの苦労体質全部をJavaが担ってる気がするｗ

506:デフォルトの名無しさん
07/02/25 01:02:42
>>505
パワフルな割には容量が足りないってどういう事なんだろうなあと思うよ。
メモリもっと増やすべき。でないととてもパワフルじゃないな。

現実問題として電力消費が激しいと言う問題があるそうだ。

しかし省エネ型DRAMのようなメモリがもっと普及すれば解決できるんだとか。

つうか、携帯電話会社は、余計な機能にエネルギーを無駄に費やさず
Javaの部分にエネルギーを費やして欲しいな。
あらゆる機能をJavaを中心に動かせるようにすれば水平ポータビリティを
維持できるし、どの携帯電話でも同じように動くアプリを簡単に作れるようになる。

507:デフォルトの名無しさん
07/02/25 01:23:02
KDDIがBREWで水平ポータビリィティやろうとしてソフト屋・消費者から大ブーイング受けた結果
建前上JBlend on BREW（サービス名オープンアプリ/どこがオープン何だと小一時間・・・）のっけましたが？

Javaで水平ポータビリティ実現すればsunの当初の目的が実現するな。
その為にはベンダーに協力してもらわんとダメだが。

その前に日本の携帯ビジネスモデルを破壊しないと受け入れられないだろう。
4G携帯なんて出したらドコモが死守してソフトバンクが
嘘ばら蒔いてイーモバとウィルが歓迎するんだろうな。
KDDIはBREW動いて音楽と動画DL出来れば何でも良さそうだが。

ネイティブ開発は個人には不可能か敷居高いだろうしJava（MIDP）流行らんもんかね

508:デフォルトの名無しさん
07/02/25 01:38:36
つかネイティブ開発はCPの審査がウザイよ。
審査に金かかるわ時間もかかるわ。

509:デフォルトの名無しさん
07/02/25 06:56:24
今のケータイでJavaをやろうとすること自体が間違いなことに気づけ。

510:デフォルトの名無しさん
07/02/25 07:12:43
て事は昔の、今の携帯以下のスペックで動かしてたJava自体間違いだったって事か

511:デフォルトの名無しさん
07/02/25 10:59:44
Javaで何をするかが問題。
今の技術では、携帯に望みすぎ。

512:デフォルトの名無しさん
07/02/25 12:55:29
>>509
燃料電池またはＨＤＤが搭載されるもしくは
PDAなどもっと大型の携帯端末なら、
Javaをやる価値は少しはあるのではないかと言ってみる。

携帯キャリアメーカーもJavaに自分たちの収入源を
奪われるのを恐れて、わざとJavaの機能を制限して
Write Once, Run Anywhereの妨害をしているとおもうけどな。
彼らの、Javaの普及を妨害するやり方はつくづく陰湿だと思う。

513:デフォルトの名無しさん
07/02/25 13:37:18
>>510
CPUのクロックだけで比べても意味がないぞ

514:デフォルトの名無しさん
07/02/25 21:46:09
まあ、VMはハードウェアとＯＳを仮想化してるから下にパワーが無いとVMも非力になるな。

515:デフォルトの名無しさん
07/02/25 22:17:51
>>510
すごく間違いだと思うなあ。Java熱に浮かされてただけじゃないかな。

516:デフォルトの名無しさん
07/02/26 03:24:52
>>510
今に間違いじゃない日が来るって
おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
５年前に予想してたか？
>>512
わざとっていうか、自由はセキュリティリスクを持っているからな。
徐々に拡大してけばいいだろう
何でも出来る穴だらけの何かがデファクトになるのが怖いよ

517:デフォルトの名無しさん
07/02/26 04:23:39
>>516
>今に間違いじゃない日が来るって
それって、今は間違いってことじゃん。
間違いじゃない日がきてから実用化すればいいのに。
なんでJava以外の選択肢を考えないのかね。
Collectionも使えないなんて、そんなんJavaじゃねーよ。
道具は適材適所。そこまでしてJavaにこだわるのが分からん。

518:デフォルトの名無しさん
07/02/26 06:53:19
*7の頃から追っかけてるがあの頃の方が見向きもされなかったぞ。
それどころかボロクソに言われてた

昔はAWTすら使いもんにならなかった気がする。もっとスリムだったし。

519:デフォルトの名無しさん
07/02/26 08:18:20
Avalon・Quartz・Cairoて出そろったのになんでJavaだけJava2Dなんだよ。

新型レンダラまだー？

520:デフォルトの名無しさん
07/02/26 09:07:33
JOGLがあるよ。

521:デフォルトの名無しさん
07/02/26 10:50:29
3DはJOGLが1.0になったので使い物になった
ただ、フルスクリーン時にGLCanvasが描画されないプラットフォームがあるとかが気になる
GLJPanelは遅くてゲームなどでは実用にならないし

あと日本語ドキュメントが皆無なのがきついな
OpenGL部分はどうでもなるがそこ以外が追うのがきつい

JOGLがコアAPIになればJOGL自体の機能も充実してくると思われ

522:デフォルトの名無しさん
07/02/26 16:20:42
JOGLのコア化ってありえるか？
あるとしたら現行Java2Dのハードウェア支援コードとの統合くらいじゃない？

どちらにせよいつの時代もOpenGLはデスクトップ向けVGAのドライバ対応が中途半端だからな。
ワークステーション向けは知らんが。

523:デフォルトの名無しさん
07/02/26 16:59:41
>>516
> >>510
> 今に間違いじゃない日が来るって
> おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
> ５年前に予想してたか？
> >>512
> わざとっていうか、自由はセキュリティリスクを持っているからな。
> 徐々に拡大してけばいいだろう
> 何でも出来る穴だらけの何かがデファクトになるのが怖いよ

多重継承も演算子オーバーロードも何でもできますよとPRする
C++言語仕様じゃあるまいし。それはちょっと違うだろう。

Javaでできることはいっぱいあるのに、あえて彼らがそれをやらないのは
彼らが己の既得権益が破壊されるのを恐れているから。
日本企業はハードウェアに強い企業は多いけどソフトウェアには弱い
企業ばかりだからね。ソフト屋にハード屋をつぶされるのを恐れている。

その構図は、テレビ局などのメディアがインターネットを嫌っている理由に非常に良く似ている。
彼らがインターネットやGoogle、Web2.0を嫌っているのは、
彼らが苦労して長い時間をかけて培ってきたノウハウを破壊されるのを恐れているから。
彼らは小泉純一郎のような「痛みを伴う改革」や「格差社会」に自分たちが巻き込まれる
ことをひどく嫌い、ひどく恐れている。

524:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/26 17:21:02
>>523-524
マ板行け。

526:デフォルトの名無しさん
07/02/26 17:30:02
マ板ネタも含まれているかもしれないけどJava MEの将来に対する
要望も含まれているから、ここでもいいのではないかと

527:デフォルトの名無しさん
07/02/26 17:35:53
>>526
要望なら要望聞いてくれるところで言わんと意味無かろうが。

動機からして現状を変えたいというものではなく、
単なる現状の愚痴なわけだし、完全にマ板ネタだろ。
>>523-524 は技術的な話ですらないし。

528:デフォルトの名無しさん
07/02/26 22:03:34
表題みるかぎりSE専門かと

529:デフォルトの名無しさん
07/02/26 23:23:01
技術的な話も含まれているがのう。

要望ねえ。JCPか？

530:デフォルトの名無しさん
07/02/26 23:26:20
>>529
含まれてないよ。マ板池。

531:デフォルトの名無しさん
07/02/26 23:29:54
>>530
営業やってる連中とか、プログラマ卒業した連中とかだと
>>523-524 が技術的に見えるのかもしらん。

532:デフォルトの名無しさん
07/02/27 03:14:34
むしろBREW上のJAVAで話を広げて欲しかった。
というか、そろそろ携帯でJavaSE動かすことできそうなんだけど・・・
Mysaifuの取り組みには期待している

533:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/27 07:09:12
>>533
M1000ってPalmじゃなかったけ？
MIDPが使えるからkjavaじゃなくてMIDP for Palm OSなんだろうか。

536:デフォルトの名無しさん
07/02/27 12:07:15
>>532-535
キミら、次世代と関係ない話題は他所でやってくれんかね？

次世代っても、勝手な妄想とか勝手な要望とかは愚痴と変わらんのよ。
便所に「税金安くしてくれ」って書いて要望とか言わんでしょ。

537:デフォルトの名無しさん
07/02/27 19:04:27
て言ってもSE7って情報少ないな

538:デフォルトの名無しさん
07/02/27 20:21:12
これがSDKに内包されてjavaguiが広まないかなぁ

URLﾘﾝｸ(journal.mycom.co.jp)

539:デフォルトの名無しさん
07/02/27 21:17:25
それSwing普通に使える人にとってメリットがほとんどないぞ

フレームワークがはやったから作っただけというのが近い
struts以上に薄いラッパだし、SwingWorerとダブるところも多いし
これほどメリットがないフレームワークってのも珍しい

540:デフォルトの名無しさん
07/02/27 21:33:51
ポトペタツールが対応するか次第のよーな。

541:デフォルトの名無しさん
07/02/28 09:38:38
>>533
> >>524
> #if #else #endif が使えるC++のほうがまだケータイ向き。
> でもauの審査がクソ遅いのはなんとかしてほしい。マジで。

プリ糞セッサに依存している時点で設計が全然駄目じゃん。

> > そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
> それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。

Python載せられることのどこがいいの理解できない。

542:デフォルトの名無しさん
07/02/28 22:01:15
どこかで見たような・・

543:デフォルトの名無しさん
07/02/28 22:22:37
>>533
んー、まえもimodeスレかMIDPスレで書いたけど、#ifdefのような条件
コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だよね。C/C++の後追いだからちゃんと考えられてる。仕様書よんでごらん。
そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。まあ
マクロはないから文法ひっくりかえすような表記でコードは書けないけど、
それはC/C++でも行儀良くないからな。

544:543
07/02/28 22:31:04
スレ違いの話だけだとあれなんでSEの話もふっとく。

URLﾘﾝｸ(techon.nikkeibp.co.jp)
↑
OSGi(JSR232)はJavaMEの分野では静かに着々と浸透しているのに
SEへの導入(JSR291)は及び腰なんだよな、Sun。自分で旗振って
OSGi始めたのにいまさら梯子外すのはないよなあ。

545:デフォルトの名無しさん
07/03/01 09:21:12
>>543
>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん

だからそれはJ2SEのような環境が統一されている場合の話であって、
機種依存が激しい携帯ではなりたたないって。
VMですら機能やバージョンが違うのに。

>そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
>併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。

インライン展開があればプリプロセッサは必要ないという根拠が分からん。説明よろしく。

546:デフォルトの名無しさん
07/03/01 10:02:45
>>543
>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん

MEで一つのソースの中に複数ターゲット向けのコード混ぜたら絶望的なソースになるよ？

最低プロファイル・機種毎にソース分けんと確実に死ねる。

jadも分けんとたまにハマるから油断できん！

547:デフォルトの名無しさん
07/03/01 10:13:36
あー言い忘れたeclipseでリファクタリングしただけでエミュでは動いて実機では動かなくなるのがMEの世界だ。

システムが勝手に走らせる特定のスレッドの実行が一定時間以内に終わらないと強制終了とか。

実行時例外catchしてcatch節でコード実行すると問答無用で落とすとか（catchしても何もしなければ良かったり、ときにはcatchすら許してくれない）

あと実機じゃ機嫌悪いと動くコードもマジで動かん。
MEでプリプロセッサ使ったソースなんて保守以前の問題。

548:デフォルトの名無しさん
07/03/01 10:58:01
>>545
>だからそれはJ2SEのような環境が統一されている場合の話であって、
>機種依存が激しい携帯ではなりたたないって。
>VMですら機能やバージョンが違うのに。

つーか、J2SEでも、Sun/IBM VM間のクセの違いの吸収や、
Sun VMでもSwingの1.4, 5, 6での差を吸収させるのに、#ifdefは欲しい。

549:デフォルトの名無しさん
07/03/01 11:39:58
いやだからそういう次元じゃないとｒｙ
MEやれ

550:デフォルトの名無しさん
07/03/02 00:07:56
>>548
SEで、ifdefは勘弁して欲しい。
それなら、せめて其処のコードは別クラスに分けて設計してくれよ・・・

551:デフォルトの名無しさん
07/03/02 20:50:21
JDK7 build09
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)

何だろう？2回続けてサマリがないビルドだ・・・
まあ今回もupdateするけど～

552:デフォルトの名無しさん
07/03/02 21:32:24
>>551
>>470 のリンク先見たら前回のは出てる。

ビルド方法でトラブってて changes が自動生成できてないから、
後から手動で生成してるとか？それとも単に怠慢で遅れてるだけ？

553:デフォルトの名無しさん
07/03/03 07:27:48
フィールドのgenericTypeを取りたいんだが方法はある？
例：List<Integer> listのInteger

554:デフォルトの名無しさん
07/03/03 08:19:37
>>544
べつに無理にJava標準に含めることを早めなくても問題なかろ。

早めることよりもむしろ、理にかなってこそ導入すべきだが。
Javaを駄目にするおそれがあるとしてJavaに導入することをまだ認めていないだけだと思うぞ。
JCPは少なくとも、Java SE 1.3以降からの上位互換性をもの凄く気にしているようだから
下手にほいほいと導入するわけにはいかんでしょうや。

そう考えると、enum型の導入が遅くなった理由もなんとなくわかる。

OSGiはなぜかEclipse Communityががんばっているようだし。
Eclipseのプラグインフレームワークに導入されているが、
SunとIBMだもんね。そういうところでは決して仲がよいとはいえないしねえ。
SWTを巡る技術的な問題もあるし。Swingは遅いからSWTを作ったと主張してきたIBM
に不信感を抱いているのではないかな？

555:デフォルトの名無しさん
07/03/03 08:22:53
>>548
駄目だお前。
ソフトウェア工学をなめとる。
修行が足りんぞ。

556:デフォルトの名無しさん
07/03/03 08:24:07
>>553
get(i)

557:デフォルトの名無しさん
07/03/03 08:28:45
>>553
URLﾘﾝｸ(download.java.net)

558:デフォルトの名無しさん
07/03/03 08:50:51
>>557
$ cat Test.java
import java.util.List;
import java.util.ArrayList;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;

public class Test {
public static void main(String[] args) {
ArrayList<Integer> l = new ArrayList<Integer>();
Type type = l.getClass().getGenericSuperclass();
ParameterizedType pt = (ParameterizedType)type;
for (Type t: pt.getActualTypeArguments()) {
System.out.println(t);
}
}
}

$ java Test
E

ありゃ。

559:デフォルトの名無しさん
07/03/03 09:02:20
class IntegerList extends ArrayList<Integer> {}

public class Test {
public static void main(String[] args) {
Type type = IntegerList.class.getGenericSuperclass();
for (Type t: ((ParameterizedType)type).getActualTypeArguments()) {
System.out.println(t);
}
}
}
とすると
class java.lang.Integer
となるな。

560:デフォルトの名無しさん
07/03/03 11:03:18
>>553
List<Integer>　の　Integer　はコンパイル時に情報消えるよ。
>>559　みたいなのは特殊な例。

561:デフォルトの名無しさん
07/03/03 11:15:54
って、ローカル変数じゃなくてフィールドの宣言についてか。

public　class　test　{
　　　　public　List<Integer>　sample;
　　　　public　static　void　main(String[]　args)　throws　Exception　{
　　　　　　　　for　(Type　t:　((ParameterizedType)test.class.getField("sample").getGenericType()).getActualTypeArguments())　{
　　　　　　　　　　　　System.out.println(t);
　　　　　　　　}
　　　　}
}

>java　test
class　java.lang.Integer

562:デフォルトの名無しさん
07/03/03 11:21:52
>>558はgetClassしてる時点でどうなるかをかんがえればよろし

563:デフォルトの名無しさん
07/03/03 14:24:41
>>553
初心者質問スレ行けよ。

564:デフォルトの名無しさん
07/03/03 15:28:47
>>556-563
㌧

565:デフォルトの名無しさん
07/03/04 09:29:05
>>551
追記：
見た目で大きく変わるところ発見。
Javaのウィンドウのデフォルトアイコンがデュークのアイコンになってる！！
可愛いです。

デュークのライセンス変更で、こういう事になったのね
わかりにくいカップよりコレはいいな

566:デフォルトの名無しさん
07/03/05 16:02:11
invokedynamic 使えるかどうかプログラム側から判断するのって、どうすれば良いですか？

567:デフォルトの名無しさん
07/03/05 16:44:34
>>566
実行時に動的でも静的でも良いから invokedynamic 使ったクラス読み込んで、
エラー出たら使えないんじゃね？

そーいや、invokedynamic って今どーなってんだろ？
invokedynamic のオペランドとかの詳細あったっけか？

568:デフォルトの名無しさん
07/03/11 15:34:36
某スレの 288 へレス。
> クロージャよりは揉めずに入りそうな気がしてる。
ウソはいかん。javac の人なんかはイラネって言ってるし。

URLﾘﾝｸ(blogs.sun.com)
要は、プロパティに dot でアクセスしようとすると、
既存のフィールドアクセスと区別つかなくなるので、後付の面倒なルールを加える必要があるから嫌だそうで。
例えばフィールド宣言したコンパイル単位ではフィールドアクセスでそれ以外ではプロパティアクセスとか、
プロパティと同名のフィールド持てないとか、そんな感じのルール。
どんなルールで対処するにせよ、完全な互換性維持は無理だろうし。
もしくは "->" とかでプロパティにアクセスするとかだけど、これはこれでキモイから嫌なんだそうで。

URLﾘﾝｸ(weblogs.java.net)
ksl でプロパティの試験実装してた人とかも、
Access to property は setter getter で、って意見変えてるし。

569:デフォルトの名無しさん
07/03/11 17:20:57
>>568
そうか、キモイか・・・うん、キモイなぁ

dotを使うのは、駄目と言う点は全く賛成だが
表記方法さえ、決まればOKだと思ってるんだけどなぁ

俺は、個人的な好みは->はキモイけど、 : ならOKです。

570:デフォルトの名無しさん
07/03/11 17:41:54
::
.
.*
->
->*

いろんな言語のaccessor。あと何があったっけ？

571:デフォルトの名無しさん
07/03/11 17:48:11
>>569
オレ自身は "->" でもいいじゃん、とか思ってたりする。
他の人が "->" がキモイって言うのも理解できるんだけど。

URLﾘﾝｸ(jroller.com)
${classInstance.propertyName} みたいに ${} で括った部分では
式言語使えるようにすりゃええやん、ってのも出てるけど……
そこまでして dot に拘らんでも、と思わなくもない。

572:デフォルトの名無しさん
07/03/11 18:14:36
>>569
:: じゃなくて : なの？

class A { property Object b; }
class B { property Object c; }
class Hoge {
　A a; B b; Object c;
　boolean flag;
　Object method(){
　　return flag ? a : b : c;
　}
}
とかされると分かりにくくなるよーな気もする。
構文解析自体は結合順位とかがあるから出来ると思うけど。

573:デフォルトの名無しさん
07/03/11 18:15:17
dot人気ないね。
フィールドアクセスとプロパティのインターフェースを別のものにしたら、
単なるgetter/setterの省略表記になってしまってあまりうまみがないと
思うのは俺だけかな？

574:デフォルトの名無しさん
07/03/11 18:42:44
>>573
皆が納得できる上手いルールが作れれば dot でも良いと思うけど。
人気がないって言うよりも、>>568 のような追加ルールを決める部分を
誰もやりたがらないような気もする。
簡単なルールで互換性壊したりすれば既存のソース使えなくなった人から嫌われるだろうし、
なるべく互換性維持しようとすると、ルールが複雑になって
今度はコンパイラの作者とかから嫌われるだろうし。

>>132 のリンク先が紹介された後、"->" はキモい、dot が良いって言ってた連中の
blog 見た感じだと、>>568 みたいな問題を小さく考えてるか、
もしくは問題自体を理解してないような。

C# みたく最初から言語機能としてプロパティを持ってる言語ならともかく、
Javaの場合は既存のJavaBeansのプロパティがあって後付けしようとしてるんだから
getter/setter の省略表記と割り切った方が現実的じゃないかな？

575:デフォルトの名無しさん
07/03/11 22:38:47
>>572
あ、いや、: ←コロンを使うという意味だった。
Perl、Pnutsなんかで親しんでいる例からいくと、 :: で使うのを想定してた。
一つだと、 hogehoge==null？a : b;
とか、switchが混乱するから。

>>573
いや、むしろそれがいい。
見たら裏で何をしているかがよく分かる。
別に、dotではなくて :: でも可読性は落ちないと思う。

-> は、演算記号と紛らわしくて、嫌。

576:デフォルトの名無しさん
07/03/11 23:03:00
プロパティなんてそもそも本質的には冗長な機能なんだから、
どうせ使えるようにするならマイクロソフト系の言語と同じ記法でいいと思うんだがなあ。

577:デフォルトの名無しさん
07/03/11 23:08:52
> マイクロソフト系の言語と同じ記法でいいと思うんだがなあ。
具体的には？

578:デフォルトの名無しさん
07/03/12 03:22:06
C++で->使ってるから、->でいいや。

579:デフォルトの名無しさん
07/03/12 04:10:14
>>576
VBだとdotじゃなかったっけ？

580:デフォルトの名無しさん
07/03/12 08:32:28
>>577,579
VB,C#ともどっとだね。
仕様策定してる連中がドットを嫌う理由がよくわかんない。
どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
新しくプロパティの意味を持たせても別にいいと思うんだが。

581:デフォルトの名無しさん
07/03/12 08:50:48
>>580
C# だと、同名のプロパティとフィールドは同時に宣言できないんだっけか？
まぁ、そーゆー後付けのルール追加すりゃ出来るかもしれんけどさ。
Javaに、そんなルール後付けしたら互換性無くなるし。

なんでこんな簡単な事が理解できないのかわかんない。

582:デフォルトの名無しさん
07/03/12 08:55:00
>>581
プロパティ自体後付けじゃん…て思ったんだけど、
setter/getterペアにアクセスする演算子のことなのか。
プロパティ定義の構文も新しく作るのかと思ったよ。
C#の Property Hoge { ～ } みたいにさ。
だったら「そんなもんｲﾗﾈ」に一票だなあ

583:デフォルトの名無しさん
07/03/12 09:19:05
>>582
> プロパティ自体後付けじゃん…て思ったんだけど、
JavaBeans のプロパティ自体はあって、その構文糖を追加しなければならない。
だから、完全に後付けってわけでもない。
JavaBeansのプロパティや、それを使ってる既存のフレームワーク捨てるなら別だけど。

あとプロパティ定義の構文を新しく作っても、プロパティアクセスに dot 使えば問題は出る。
例えば、
class MyComponent implements java.beans.DesignMode {
　private boolean designTime;
　public boolean isDesignTime(){ return designTime; }
　public void setDesignTime(boolean f){ designTime = f; }
}
みたいな既存のコードがあるとする。

プロパティが追加されて java.beans.DesignMode が
interface DesignMode {
　public static final String PROPERTYNAME = "designTime";
　public abstract property designTime;
}
みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。

584:デフォルトの名無しさん
07/03/12 09:57:09
>>580
> 仕様策定してる連中がドットを嫌う理由がよくわかんない。
dot 使ったらフィールドアクセスとプロパティアクセスの区別がつかなくなると何度言えば……

585:デフォルトの名無しさん
07/03/12 10:02:47
>>580
> どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
ひょっとして、現存するソースコードに Beans のプロパティ持ってるものが
大量にあるって事がわかってない？

次ページ