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 のプロパティ持ってるものが
大量にあるって事がわかってない？
586:デフォルトの名無しさん
07/03/12 11:37:56
だからさ、プロパティってのはgetter/setterペアのことじゃなくて
それとは別に新しい概念を持ち込むのかと思ってたって>>582に書いたでしょう。
何嬉しそうにツッコミいれてんだよ。
587:デフォルトの名無しさん
07/03/12 11:41:08
> 何嬉しそうにツッコミいれてんだよ。
いや、無知だなぁ、と思って。
588:デフォルトの名無しさん
07/03/12 11:51:08
>>587
どの辺が無知だったか教えてちょ。勉強するから。
589:デフォルトの名無しさん
07/03/12 11:56:57
>>588
このスレに出てるのだけでも、プロパティに関するリンク先読んでれば
beans と関係のない新しいプロパティを導入するとか思わんでしょ。普通。
590:デフォルトの名無しさん
07/03/12 13:21:21
>>589
そうだな。すまんかった。
591:デフォルトの名無しさん
07/03/12 20:35:44
>>583
>みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。
ここがよくわかんないんだけど、誰か解説して。
アクセッサがあればそちらを優先的に使う（あるいは逆にフィールドアクセスを優先する）というルールを決めればすむ話じゃないの？
で、583みたいな状況になったらコンパイラが警告を出してくれればそれでいいと思うんだけど。
592:デフォルトの名無しさん
07/03/12 20:47:38
>>591
> アクセッサがあればそちらを優先的に使う
それやったらコンパイルが通らん。
> フィールドアクセスを優先する
フィールドでプロパティを上書きできるようになるけど、それで良いんか？
593:デフォルトの名無しさん
07/03/12 20:56:24
× フィールドでプロパティを上書き
○ フィールドでプロパティを覆い隠し
594:デフォルトの名無しさん
07/03/12 21:00:25
>>592
> > アクセッサがあればそちらを優先的に使う
> それやったらコンパイルが通らん。
いや、コンパイルは通るかもしれんが……
例えば
> public boolean isDesignTime(){ return designTime; }
は public boolean isDesignTime(){ return isDesignTime(); }
に展開されるから実行時に StackOverflowError 吐いて死ぬ。
595:デフォルトの名無しさん
07/03/12 21:20:38
>>584
区別させないのがプロパティだろうに。
596:デフォルトの名無しさん
07/03/12 21:24:32
>>595
コンパイラが区別できないって意味なんだけど。
人間が区別しないとか、区別を意識させるべきでないってのとは別の話だよ。
597:デフォルトの名無しさん
07/03/12 22:11:17
>>596
まぁ互換性を維持してのプロパティの導入には実装上の困難を
解決できていないというのはいいんだが、だからといって
「できる方法で実装しちゃおう」となるとしたら賛成できないなぁ。
互換性の面から考えた場合、方法は大きく3種類に分類できて、
1.JavaBeansと相互に互換性のある方法
2.JavaBeansとは互換性がないが、バイトコードレベルでの
仕様変更を伴わない方法
3.バイトコードレベルで拡張する方法
このうち、3.を採用すると何でもありだから議論から除外するとして、
個人的には1.には拘らないから2.でうまいことやってくれないかなと
思うんだが。
598:デフォルトの名無しさん
07/03/12 23:05:53
>>597
1 の場合はともかく、2 や 3 の場合は コンパイラ実装するとか言語仕様追加する、
とかってのは一番楽な部分だからね。
JavaBeans を切り捨てるってのは、技術的というより政治的な問題だから、
ハッカー気質が強い人ほど、自分でコード書いたりする時間がなくなって
政治的な問題に時間を取られる、って予感があるので手を引きたがる。
2 の場合は機能を欲しがる人は居るかもしれんけど、
（2 をやれるだけの政治的立場とか確保してる人の中で）
やりたがる人は居ないと俺は思うから、たぶん実現できないと思う。
599:デフォルトの名無しさん
07/03/12 23:18:49
> JavaBeans を切り捨てるってのは
切り捨てるわけじゃないか……
でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか
標準API とかの setter/getter を新プロパティで置き換えるとかってなれば
厄介な政治的問題だってのは予想できるでしょ。
言語として 2 のプロパティ持ってても、
標準API は 2 のプロパティをサポートしませんとかなったら間抜けだし。
600:デフォルトの名無しさん
07/03/12 23:26:45
> でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか
こんな決定したら 袋叩きにあうような気もする。
メンテ面倒くさいし。
enum でも、似たような事やってたけどさ。
enum だと、自前の enum を定義するクラスが比較的少ないから
メンテが面倒って不満がそれほど大きくならんかっただけだと思うし。
601:デフォルトの名無しさん
07/03/12 23:30:42
XMLEncoderがenumに対応してないと気づいたときに、Javaは終わったと思った。
602:デフォルトの名無しさん
07/03/12 23:34:54
これ?
URLﾘﾝｸ(bugs.sun.com)
603:デフォルトの名無しさん
07/03/13 08:40:52
>>592
>それやったらコンパイルが通らん。
だから具体的に説明してくれって。頭の悪い俺でも分かるように。
>フィールドでプロパティを上書きできるようになるけど、それで良いんか？
これが問題になるのって、フィールドがnon privateのときだけだよね。
フィールドもアクセッサもpublicというのはちょっと考えにくいから、これでも別にいいと思うけど。
>>594
>例えば
>> public boolean isDesignTime(){ return designTime; }
>は public boolean isDesignTime(){ return isDesignTime(); }
>に展開されるから実行時に StackOverflowError 吐いて死ぬ。
これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。
展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
これなら大丈夫じゃない？
604:デフォルトの名無しさん
07/03/13 09:35:33
>>603
> これが問題になるのって、フィールドがnon privateのときだけだよね。
違う。例えば
class A{ public int field = 0; }
class B extends A{ private int field = 1; }
class C { public static void main(String[] args){
System.out.println( new B().field );
} }
とかだと A の field にアクセスできんでしょ？
つまり、private なフィールドでも public なプロパティを覆い隠せる。
ってか、言語仕様読んでも、なんで Ａ の field にアクセスできないのか
俺には良くわからんのだが…… 覆い隠しって単純名だけに作用するんじゃないんかな？
> これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。
そうだよ。だから無理だって言ってるじゃん。
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。
605:デフォルトの名無しさん
07/03/13 09:38:13
>>603
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
> これなら大丈夫じゃない？
package-private もしくは protected な フィールドと、
public なプロパティで問題起こるから解決になってない。
606:デフォルトの名無しさん
07/03/13 10:13:00
>>604
> 覆い隠しって単純名だけに作用するんじゃないんかな？
違うか。覆い隠しじゃなくて、隠蔽されたフィールドは継承されないから、
B のインスタンスからは A の field にはアクセスできないのか。
名前の章ばっかし見てたら理解できんかった。
607:デフォルトの名無しさん
07/03/13 10:17:35
どっちにしろ、今更プロパティを言語仕様に導入しようなんて考えるのが間違ってる。
608:デフォルトの名無しさん
07/03/13 12:25:26
間違い、とまでは思わないけどね。
609:デフォルトの名無しさん
07/03/13 13:47:17
>>603
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
これだと、他にも穴があるか。
class A implements Compareble<A>{
private int field; public long getField(){ return field; }
public int compareTo(A another){ return this.field - another.field; }
}
とかがコンパイルエラーになる、と。
610:デフォルトの名無しさん
07/03/13 15:00:26
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
(this).bar とかだと どうすんだろ？
611:デフォルトの名無しさん
07/03/13 16:53:37
ってか、そーゆールールなら
・フィールドが可視ならフィールドアクセス
・そうでなければ、プロパティがあるならプロパティアクセス
とかの方が良いような気もする。
それでも static なプロパティを許したりすると、同名のメンバークラスと衝突するし。
ってか、同名のフィールドが可視なら shorthand syntax for accessing properties
を使えないのって、本当に使いやすいかも結構問題のような？
612:デフォルトの名無しさん
07/03/13 19:42:20
何か激しく壊れてない？
URLﾘﾝｸ(download.java.net)
613:デフォルトの名無しさん
07/03/13 19:42:27
>>604
>違う
というのは勘違いということでいいのかな？
>そうだよ。だから無理だって言ってるじゃん。
だから『 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく』といっているんだけど。
>そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。
なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
614:デフォルトの名無しさん
07/03/13 19:48:30
>>613
＞なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
汚い設計。
わかりにくいです。
あとマルチスレッド周りで問題がでそうだな。
615:デフォルトの名無しさん
07/03/13 20:05:41
>>613
> というのは勘違いということでいいのかな？
いや、覆い隠しは勘違いだったけど、
private フィールドで public なプロパティを隠蔽できるから問題になるのは変わらない。
> 区別してないなら区別すればいいじゃん。
区別しても、 >>605、>>609、>>610 みたいな穴があるから、やるだけ無駄。
616:デフォルトの名無しさん
07/03/13 20:44:57
>>611
どっちかっつーと dot でプロパティアクセス許す場合、
フィールドと同名のプロパティを作れるってのが混乱の元だとか認識されてんのかも？
617:デフォルトの名無しさん
07/03/13 20:51:03
> あとマルチスレッド周りで問題がでそうだな。
問題でるかな？
618:デフォルトの名無しさん
07/03/13 20:53:23
>>613
> なんで無茶なの？
根本に近い方のルールを書き直すってのは、
既存のコンパイラを改変する時に多くの労力がかかりそうだってのは分かるでしょ？
だから無茶なの。
619:デフォルトの名無しさん
07/03/13 21:20:36
>>571
> ${classInstance.propertyName} みたいに ${} で括った部分では
> 式言語使えるようにすりゃええやん、ってのも出てるけど……
ksl の 課題追跡にあった
URLﾘﾝｸ(ksl.dev.java.net)
に似てるっちゃ似てるかも。
でも、ecmascript みたいに Java と同じく } でブロック終了する言語だと
対応とるの大変そうだなとか思った。その辺は EL だと楽だけど。
620:デフォルトの名無しさん
07/03/13 21:34:43
ヒアドキュメント＋式言語ってのが良さそう
Velocityが標準になるみたいな感じだが。
621:デフォルトの名無しさん
07/03/13 22:29:53
>>616
要は、今の仕様で
private int xxx;
というフィールドと
public int getXxx()
というメソッドが混在できる以上、フィールドの延長上のプロパティと
getter/setterの延長上のプロパティとは相容れないわけだ。
いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
関係もないことにすりゃ、それで解決すると思うんだけどね。
622:デフォルトの名無しさん
07/03/13 22:49:49
>>621
> いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
> 関係もないことにすりゃ、それで解決すると思うんだけどね。
仮に、それをやっても「解決する」のは言語仕様の問題だけで、
ライブラリ＆フレームワーク＆ユーザーコードの方に問題を押し付けてるのような。
それなら、ぶっちゃけ新しい言語作っちゃった方が速いと思う。
623:デフォルトの名無しさん
07/03/13 23:18:12
>>622
上の方でだれか言ってたけど、フレームワークのプロパティとは無関係な「Java言語プロパティ」
を作ってもいいんじゃないか。紛らわしいなら名前は変えてもいいけど。
そもそもなんでプロパティ構文が欲しいんだ。ドットネットが羨ましいんだろうか。
624:デフォルトの名無しさん
07/03/13 23:24:53
>>622
「問題」って、どんな問題かな？
別に既存コードの変更が迫られるわけじゃないっしょ？
625:デフォルトの名無しさん
07/03/14 00:09:08
>>623
むしろstructが羨ましいんじゃないか？
626:デフォルトの名無しさん
07/03/14 02:48:40
>>624
互換性を確保しつつ新プロパティを使おうと思ったら、
既存のプロパティと、新プロパティの両方管理しなきゃいけなくなる。
二重のコストを払う必要が出るんだから、普通は問題になる。
おまけに、フレームワークやライブラリが二重のコストに耐えかねて
既存のプロパティを捨てたら、やっぱり既存のコードを書き換える必要が出る。
直接コードの変更を迫ってないだけで、間接的にコードの変更を迫ってる。
627:デフォルトの名無しさん
07/03/14 07:18:35
>>626
プロパティが導入されたからといって、既存のコードを無理に
対応させることはないでしょ？別物なんだから。
それに例えば、ジェネリクスが導入されたとき、それに対応して
書き換えられたフレームワークはあったし、もちろんそれを利用
しているユーザーコードも書き換えられることがあったけど、
それは別に変更を余儀なくされて行ったわけじゃないよね？
628:デフォルトの名無しさん
07/03/14 07:52:01
>>627
> それに例えば、ジェネリクスが導入されたとき、それに対応して
Generics の場合は「JavaBeans とは無関係なプロパティ」導入と違って、
例えば Collection フレームワークを Generics対応に書き換えたら、
互換性が完全に無くなるってわけではなかったけど、
「JavaBeans とは無関係なプロパティ」の場合は、
「JavaBeansのプロパティ」のサポートをうちきれば互換性が無くなるし。
例えるなら enum の方が近いな。int enum と typesafe enum の両方を提供してるAPIがあって。
それにはコストがかかる。int enum だけ、typesafe enum だけを提供してるAPIもあるけど、
プロパティの場合は影響範囲も、統一的に扱う必要性も enum の時より大きいから
両方の提供がより大規模に起こるのは容易に想像できる。
「JavaBeansのプロパティ」と「JavaBeans とは無関係なプロパティ」は共存可能って話なんだろう？
互換性維持のためには「JavaBeansのプロパティ」が必要で、
新機能対応のためには「JavaBeans とは無関係なプロパティ」が必要で、
それを両方管理しようとすりゃコストはかかる。問題になるだろ、普通は。
629:デフォルトの名無しさん
07/03/14 08:10:26
定義はgetter/setterで行って、呼び出すときだけプロパティみたいにも使えるようにするのじゃダメ？
例えば、p=a.getXxx()をp=a.xxx、a.setXxx(p)を a.xxx=pとか。
630:デフォルトの名無しさん
07/03/14 08:37:50
>>629
それだと dot でやるのが面倒。
既存の getter/setter に使われてる「プロパティの名前」と
同名のフィールドが存在可能だから。
631:デフォルトの名無しさん
07/03/14 08:39:25
>>628
そのコストってのもフレームワークの作者とかはともかく開発者は関係ないね
632:デフォルトの名無しさん
07/03/14 08:44:16
>>631
何より、無駄にバグのリスクが増えるし、
標準APIとかでドキュメントの翻訳に時間がかかるようになるとも考えられるね。
633:デフォルトの名無しさん
07/03/14 08:45:07
>>631
開発者というより、末端ユーザだな
634:デフォルトの名無しさん
07/03/14 09:10:34
>>629
a.xxx と同名のフィールド a.xxx があった場合、扱いが面倒。
互換性を考えるなら >>611 あたりのルールが落としどころかとも思うけど、
public な同名のフィールド使えば、プロパティに触れなくする事ができたりするし、
完璧とはいいがたい。
言語仕様に書く文言も相当慎重に選ばないと、
デフォルトパッケージのクラスが import 出来なくなったみたいに、
言語仕様の文言から副作用がでる可能性も……
もっとも、import の方は意図しない副作用なのか意図的なものか、
ちゃんと知らんのだけど。
635:デフォルトの名無しさん
07/03/14 12:24:27
マルチコア対応は言語に乗っかるのか、VMに乗っかるのか・・・
636:デフォルトの名無しさん
07/03/14 12:37:32
>>627
Genericsは、既存の一般コードに関しては意味の変更なく使えたぞ
>>632
さすがにそのコストを考えるのは臆病すぎｗｗｗ
>>635
マルチコア対応って一体何なのか分からない。
なぁ、何でみんなdotにこだわるの？
別の記号にして、定義も全く別にすればスッキリ導入なんだけど？
バイトコードは拡張しないと駄目だろうけど。
637:デフォルトの名無しさん
07/03/14 12:48:08
>>636
> 別の記号にして、
dot 以外の記号はキモイから嫌らしい。
> 定義も全く別にすれば
既存の資産と協調して使えないので、導入しても嬉しさ半減。
> バイトコードは拡張しないと駄目だろうけど。
バイトコード拡張は必要ないでしょ。
クラスファイル仕様は弄るかもしらんけど。
638:デフォルトの名無しさん
07/03/14 12:50:02
>>635
マルチCPU対応のVMだったら、マルチコアも そのまま使えるんじゃない？
ってか、マルチコア対応を言語にのっけるってどーやるんだ……
639:デフォルトの名無しさん
07/03/14 13:13:07
そういやRhinoのLiveConnectは実装側で拡張されててJavaObjectのゲッタ(getXxx)・セッタ(setXxx)にJavaScriptObjectのプロパティ(xxx)からアクセス出来たな。
JavaBeans使ってたんだろうか？
結局JavaScriptObjectのプロパティからアクセスしようとした時JavaObject側にxxxってフィールドがあると衝突して使い物にならないから
LiveConnectには元々ない後付けされた機能なんて不完全だって言われてたな・・・。
オライリーのサイ本にも指摘されてたような。
640:デフォルトの名無しさん
07/03/14 13:39:56
>>626
阿呆だな。もっと簡単な問題があるよ。
>>624
JavaBenas のプロパティと別のプロパティなわけでしょ？
標準API とかの既存の interface に abstract な property を追加したら
既存のコードの中で、そのinterface を実装してて JavaBeans とは別のプロパティを
実装してないクラスがあれば、互換性に問題が出る。
互換性に配慮したら interface に迂闊にプロパティ追加できない。
それだと、たぶん使い物にならない。
641:デフォルトの名無しさん
07/03/14 13:48:02
>>627
具体的に言えば java.beans.DesignMode にプロパティ追加して
interface DesignMode {
public static final String PROPERTYNAME = "designTime";
boolean isDesignTime(); void setDesignTime(boolean f);
public abstract property designTime;
}
とかすると、既存の
class MyComponent implements java.beans.DesignMode {
private boolean designTime;
public boolean isDesignTime(){ return designTime; }
public void setDesignTime(boolean f){ designTime = f; }
}
みたいなコードを書き直す必要がある。
DesignTime とかだけならともかく、他の interface も property の追加に関しては慎重にならざるをえない。
よって interface で property にアクセスできない事が多くなる。
JavaBeans のプロパティと別の新プロパティを導入しても、
あんまし使い勝手がよくないだろうね。
642:デフォルトの名無しさん
07/03/14 14:10:45
なるほどいろいろ問題があるな。
結局 ->案が一番妥当だろう。
プロパティを定義する側はこれまでどおりgetXXX/setXXXを使用する。
プロパティを使用する側はgetXXX/setXXXと->XXXの両方が使える。
フィールドにXXXがあっても問題なし。
しかし、この程度のものならいらないな。
643:デフォルトの名無しさん
07/03/14 15:29:22
>>642
だよな。
いらないと思うよな。
644:デフォルトの名無しさん
07/03/14 15:41:27
あとはgetとsetを対にした定義文もほしいな
645:デフォルトの名無しさん
07/03/14 15:47:49
>>641
今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入するのだったらその書き換えはいらないよね？
646:デフォルトの名無しさん
07/03/14 16:03:21
>>645
だから、>>641 は
> 今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入
した場合に発生する問題だってば。
今Beansで「プロパティ」と呼んでいるもの、
要するに setter/getter呼び出す syntax sugar として
accessing properties な構文を入れるなら、>>641 の問題は発生しない。
647:デフォルトの名無しさん
07/03/14 16:36:28
>>646
なんで書き換えようとするの？そのままにしとけばいいじゃん。
648:デフォルトの名無しさん
07/03/14 16:56:32
>>647
>>641 をちゃんと読め。
649:デフォルトの名無しさん
07/03/14 17:45:12
>>648
ちゃんと読んでもわからないです。
何故 interface DesignMode に property designTime を追加してるの？
ひょっとして俺ｽｹﾞｰアホなこと訊いてる？
650:デフォルトの名無しさん
07/03/14 18:38:36
> ひょっとして俺ｽｹﾞｰアホなこと訊いてる？
うん。
651:デフォルトの名無しさん
07/03/14 22:27:50
>>641
あきれる。
isXXX()/getXXX()をgetterのインターフェースに用いたままプロパティを
実現しようとすることに問題があるから別のインターフェースを採用
しようという話なんだから、その例でinterfaceの方にisDesignTime()を
追加するという仮定自体がそもそもありえないし、仮に追加しても
何の影響もない。
652:デフォルトの名無しさん
07/03/14 22:35:24
dot以外の記号がキモイならdot二つのx..hogeでもいいよ。
653:デフォルトの名無しさん
07/03/14 23:25:14
>>652
孔明あらわる
654:デフォルトの名無しさん
07/03/14 23:56:34
>>651
俺もそんな気がしたんだけど、>>650 だそうです。
655:デフォルトの名無しさん
07/03/14 23:57:20
記号でわざわざ入力二回って耐えられなくない？
656:デフォルトの名無しさん
07/03/15 00:00:24
耐えられないなら++も--も使わずにプログラムを書いてくれ。
657:デフォルトの名無しさん
07/03/15 00:45:46
// << >> == && ||
↑これらも
つか==なしとか縛りきつくね？
658:デフォルトの名無しさん
07/03/15 00:47:52
VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。
FlashのActionScript(ECMAScript派生)もread onlyプロパティがあったが、dotだね。
dot以外を選択するのは、正直コンパイラ屋の都合でしかないと感じる。
メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。
659:デフォルトの名無しさん
07/03/15 01:30:43
ちょっと待てECMAScriptは全部プロパティだ
660:デフォルトの名無しさん
07/03/15 01:32:16
>>656-657
2chらしい模範解答だなｗ
661:デフォルトの名無しさん
07/03/15 01:52:21
IDEやJava用エディタならテンプレート機能が充実しているし
そんな構文糖は要らないってのも意見として尊重してほすぃ。
662:デフォルトの名無しさん
07/03/15 02:15:35
>>661
どうなんだろ、セマンティクスがハッキリするから
getter,setterが分かりやすくなるという点ではIDEも歓迎なのでは？
実現方法はともかく。
663:デフォルトの名無しさん
07/03/15 04:06:26
>>661
コードの読みやすさが上がるのであれば、新しい構文糖の導入も大いに結構じゃないかい？
664:デフォルトの名無しさん
07/03/15 07:43:28
>>651
あきれる。
> 仮に追加しても何の影響もない。
そんなは事ない。
665:デフォルトの名無しさん
07/03/15 07:47:20
>>651
>仮に追加しても何の影響もない。
追加したら、java.beans.DesignTime を実装している既存のクラスを書き換えなきゃいけなくなるだろう。
影響がないって、馬鹿じゃないのか？
666:デフォルトの名無しさん
07/03/15 07:48:08
>>665
× java.beans.DesignTime
○ java.beans.DesignMode
667:デフォルトの名無しさん
07/03/15 08:18:45
>>661
URLﾘﾝｸ(java.net) とか見ると、
property構文は、XML構文に次いで人気がないんだよね。
URLﾘﾝｸ(java.net) とかだと、
very important と、somewhat important をあわせても 1/4 ぐらいだったりする。
まぁ、この手の投票がちゃんと機能してるかはわからんし、
構文糖なら要らないってのと、重要度が低いってのは同じ意見じゃないんだけど。
668:デフォルトの名無しさん
07/03/15 08:34:05
>>658
> VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。
もし問題がないなら dot を使うのに反対の人はあんまし居ないと思うんだが。
同じクラスでフィールドと同名のプロパティが持てる言語を出してきて
わかりにくくないって言うんならともかく。
> メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。
それって、何か改善する？
669:デフォルトの名無しさん
07/03/15 09:09:07
>>668
> 同じクラスでフィールドと同名のプロパティが持てる言語を出してきて
> わかりにくくないって言うんならともかく。
それなら、同名のフィールドとプロパティが共存できて、
さらにフィールドもプロパティも dot でアクセスする言語がわかりにくくないって言わないと。
（dotじゃなくても良いけど同じ記号でアクセスする言語）
670:デフォルトの名無しさん
07/03/15 09:17:17
>>651
> その例でinterfaceの方にisDesignTime()を
> 追加するという仮定自体がそもそもありえないし
……。 isDesignTime() は元からあるメソッドですが。
671:649
07/03/15 10:23:39
>>670
おまえ逃げてないで俺の質問に答えろよ。
672:デフォルトの名無しさん
07/03/15 10:26:26
>>671
質問になってない。
673:649
07/03/15 10:31:39
>>672
答えになってない。
674:デフォルトの名無しさん
07/03/15 10:36:21
>>621
それだけじゃ解決しないね。
新プロパティ(dotでアクセス)と同名のフィールドが作れるなら
setter/getterのプロパティと同じ問題が起こるし、
C#みたく新プロパティと同名のフィールドが作れなくするなら、
標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。
これ以降は >>640 >>641 と同じ路線だな。
上記の書き換えを最小限に抑えようとすれば、
標準APIは極力 新プロパティを追加しない方向になるだろうから、
新プロパティの構文は言語仕様に定義されたが、
標準APIで 新プロパティが使えない、という本末転倒な事態が予測される。
つまり、使い勝手が悪い。
675:デフォルトの名無しさん
07/03/15 10:39:07
>標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。
標準APIが新プロパティを追加したら、
そのclass/interfaceを継承/実装して同名のフィールドを使っていたユーザコードの書き換えが必要になる。
676:649
07/03/15 10:42:44
やっとわかったよ。お互い説明が下手だと苦労するなｗ
677:デフォルトの名無しさん
07/03/15 11:02:59
>>675
まぁ、interface に「新プロパティ」を追加したら、
どっちみち そのinterface を実装しているクラスの書き換えが必要になる。
既存のコードは setter/getter は実装してても、
「新プロパティ」まで実装してて書き換えの必要がないってのは考えにくいから。
この書き換えを最小限に抑えようとすれば、
標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから
以下、>>674 と同文、と。
678:デフォルトの名無しさん
07/03/15 11:15:13
> 標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから
標準API は、既存の setter/getter を置き換えるものも含めて、
極力 abstract な新プロパティを追加しない方向になるだろうから
うーむ。既存の setter/getter は互換性のために残す事を想定してるから
置き換える、じゃないんな。まぁ、setter/getter を残しても残さなくても、
標準API に abstract な新プロパティを追加すれば同じだけど。
679:デフォルトの名無しさん
07/03/15 20:13:04
ゲーム関係に力を入れてけば自然とデスクトップ周りが強化されるからそっち系だな
OSを選ばないUDIライブラリとか、BGM周りはネイティブにディスパッチとかね。
標準であるかどうかってのがここらへんは大きい。
680:デフォルトの名無しさん
07/03/15 22:34:05
まずジョイパットか
681:デフォルトの名無しさん
07/03/15 23:05:33
ジョイパッドサポートは地味に大きいな
って10年前からいわれてるが
あとはJOGLも標準ではいってくれるといいのだが
今はプラットフォームごとに用意してあげないといかんからWindows以外はめんどくさい
本当は新世代専用GCコールもほしい
タイミングコントロールできて殿堂入りしないやつならアクション系もバリバリ使える
682:デフォルトの名無しさん
07/03/16 00:05:01
>>677
interfaceに追加したらそれを実装するクラスに影響があるのは、
「プロパティ」に限らず抽象メソッドでも同じだわな。
既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
↓
だから標準APIに「抽象メソッド」は追加できない
↓
「抽象メソッド」は標準APIに使えないから無意味
あほか。
683:デフォルトの名無しさん
07/03/16 00:22:54
>>682
> 既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
普通は、既存の interface に抽象メソッド追加するのは慎重にする。
逆に、 今までにない interface を作る時は自由に抽象メソッドを定義できる。
> 「抽象メソッド」は標準APIに使えないから無意味
安易に追加できないが、「使えない」とか「無意味」とはならない。
abstract な新プロパティも、抽象メソッドと同じで、
今までにない interface を作る場合は自由に定義できるだろうけど、
既存の interface に追加する場合は慎重にならざるを得ないだろう。
既存の interface 経由で使えない事が予想される新プロパティは
「使えない」とか「使い勝手が悪い」と言える。
684:デフォルトの名無しさん
07/03/16 00:26:00
>>683
△既存の interface -> ○標準APIの既存の interface
685:デフォルトの名無しさん
07/03/16 01:10:18
java.sql.Connectionなんか増えまくりだった気がするが。
古い実装のを呼ぼうとするとErrorでも出るかな
686:デフォルトの名無しさん
07/03/16 01:11:37
>>683
既存のinterfaceを安易に拡張できないってのは当然だね。
>既存の interface 経由で使えない事が予想される新プロパティは
なんで新プロパティに限って既存のinterface経由で使われることを
期待されなければならないんだろう？
687:デフォルトの名無しさん
07/03/16 01:16:08
>>682
> だから標準APIに「抽象メソッド」は追加できない
> ↓
> 「抽象メソッド」は標準APIに使えないから無意味
ここで飛躍してる。基本的には「追加できない」==「使えない」とはならない。
で、setter/getter とは無関係な新プロパティシステムを導入したとして、
その新プロパティを、標準APIの既存の interface で使いたいと言う場合は
・新プロパティを追加すれば、その interface を実装していたコードを変更する必要が出る。
・逆に新プロパティを追加しなければ、標準APIの既存の interface では新プロパティは使えない
で、俺は標準APIの管理者は後者を選択すると予想するので、
その場合は新プロパティは「標準APIの既存の interface経由では使えない」ので
使えないとか、使い勝手が悪いと言えるだろう。
仮に前者を選んだとしても、コードの変更を迫られるので無問題とはならない。
688:デフォルトの名無しさん
07/03/16 01:23:35
>>686
> なんで新プロパティに限って既存のinterface経由で使われることを
> 期待されなければならないんだろう？
限って？ 他では期待されてないんだっけか？
689:デフォルトの名無しさん
07/03/16 01:27:18
>>688
限ってないよな。Closure だって、Closure Conversion とかで
abstract なメソッドが一つだけの既存の interface に変換する事を考えてたりするし。
690:デフォルトの名無しさん
07/03/16 01:48:55
URLﾘﾝｸ(blogs.sun.com) のリストとかを見るに、
たいてい inteface と関係ないか、既存の interface との協調にも配慮してあるよーな。
691:デフォルトの名無しさん
07/03/16 05:18:23
>>681
新世代・・・・ああああNewGeneration用のGCってことか。
いや、殿堂入りが無いというより、tenureの32をいじれるようになった方がいいかな。
ある程度、コア数が増えて並行処理が速くなると、OldGenerationを少なくして
Newgenerationのtenureを32回より多くして、NewGenerationで運用したほうが
効率いいと思うんよねぇ。
昔、24CPUのマシン使った時、10GB程度のNewGenerationをParNewGCかけてたけど
確か0.5s程、ホンの一瞬だった。
692:デフォルトの名無しさん
07/03/16 07:42:00
>>688
class定義に影響する新機能としては例えばfunction-typeなんかがあるけど、
じゃあこれは既存のinterfaceに追加されて使われることを期待されてるの？
693:デフォルトの名無しさん
07/03/16 08:53:05
>>688
対抗馬である setter/getter の syntax sugar なプロパティなら
既存の interface経由で使えるしな。
それと比較しても 「使い勝手が悪い」といえるだろうね。
694:デフォルトの名無しさん
07/03/16 08:53:44
>>692
具体的に、どんな問題が出るんだ？
695:デフォルトの名無しさん
07/03/16 12:35:00
>>691
並列GCはデフォの状態よりスループットはいいけどレスポンスが大幅に悪化するぞ
あとGC稼動のタイミングをコントロールできる10msのGCとコントロールできない0.1msのGCだと前者のほうがいいわけで
696:デフォルトの名無しさん
07/03/16 13:50:53
>>695
今のマシンスペックならGCに0.1msもかからんよ。
ゲームならヒープサイズとスタックサイズの調整で2Dまでならストレスなく遊べる。
やっぱメモリ食いは収まらないけど。
取り合えずただのデスクトップツールとしては実用的じゃない？
ジョイパッド拾えるようになると同じ方向性で障害者用の入力補助装置の入力拾えそうでアクセシビリティ周りが格段に良くなって良いと思うけどな。
697:デフォルトの名無しさん
07/03/16 14:15:04
>>686
GCの時間はヒープサイズに綺麗に比例するのでなんともいえないよ
最近のマシン持っているけど0.5msきることは実際にゲームつくっていてまずない
新世代領域を少なくしてやっと0.2mくらいか
インクリメンタルGC（現在の実装は並列GC）だとレスポンス悪化してるし、
デフォのGCだとFullGCがいつかは必ず起きるし、おきたら使い物にならない
そもそもJava2DやJOGLなどライブラリによるGCはコントロールできなから
自分のコードでの調整は何も意味がない
0.1mが0.05mであっても同じこと
リアルタイム性ってのは早いかどうかじゃなく、コントロールできること、把握できることだから
698:デフォルトの名無しさん
07/03/16 15:41:40
>>571
まるでApache Antの記法だな
699:デフォルトの名無しさん
07/03/16 15:42:31
>>572
四項演算子か。
Checkstyleプラグインが警告しそうだな
700:デフォルトの名無しさん
07/03/16 19:54:46
>>693
既存のinterfaceに public int getHoge(); なんて追加したら
おんなじように「問題」は発生するが？
>>694
何の問題も出ないだろう。既存のinterfaceに追加したりしなけりゃ。
701:デフォルトの名無しさん
07/03/16 20:14:48
>>700
setter/getter の syntax sugar なプロパティであれば、
既存の interface で、既に宣言されている setter/getter で
プロパティにアクセスする分には問題は発生しない。
setter/getter と関係のない新プロパティシステムを導入した場合、
既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。
で、標準API みたいに変更すると影響範囲が大きい既存の interface は安易に変更できないから
新プロパティを追加したくても既存の interface には追加できず、
既存の interface からは、この新プロパティは使用できない可能性が高い。
故に setter/getter の syntax sugar よりも 「使い勝手が悪い」といえる。
702:デフォルトの名無しさん
07/03/16 21:11:41
相変わらず説明が下手だな。
703:デフォルトの名無しさん
07/03/16 21:19:01
さすがに読解力に問題があるだろう。
704:デフォルトの名無しさん
07/03/16 22:07:53
>>701
>既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。
既存の「getter/setter」と関係ないプロパティが前提なら、当然既存のinterfaceにも
存在しているわけがないだろう。ここでアクセスしようとしている「プロパティ」ってのは
何のことを言っているんだ？
もし「getter/setter」のことならば、それはプロパティとは関係のない単なるメソッドだから、
普通にメソッドとしてアクセスすればよい。
もし新たにプロパティを追加することを想定しているのならば、それはインターフェースの
拡張に他ならないから、他に影響が出るのは当然。それは別にプロパティに限らない。
705:デフォルトの名無しさん
07/03/16 22:18:48
>>704
> ここでアクセスしようとしている「プロパティ」ってのは
当然、setter/getter と関係ない新プロパティシステムのプロパティ。
で、プロパティの持つものは、既存の setter/getter で表わされるのと同じもの。
プロパティ導入の大きな動機の一つに、setter/getter を宣言するのも、
呼び出すのも冗長だという不満を解消するというものがある。
setter/gettter とは別の新プロパティシステムを使えば、
既存の interface にある、既存の JavaBeans のプロパティに対して、
setter/getter を呼び出すのが冗長だという不満を解消できない。
仮に Tiger で追加された Generics が、もし仮に既存の Collection API と協調できず、
List でも Map でもパラメタ型を取れなければ、使い勝手が悪いと評価されるだろう。
それと同じ。
706:デフォルトの名無しさん
07/03/16 23:00:03
あはははは。
foo.getBar()がfoo->barになっただけでどんな不満が解消するんだよ。
707:デフォルトの名無しさん
07/03/16 23:07:26
流れぶったぎるがJSR-296使ってみた奴居る？
708:デフォルトの名無しさん
07/03/16 23:08:42
>>706
なら、なんでプロパティが必要なんだ？
それに、最初出てきた案は setter/getter の syntax sugar なんだぜ？
709:デフォルトの名無しさん
07/03/16 23:18:32
>>703
わかってもらえない場合は、別の角度からの説明を試みるべきだと思う。
>>706
だよな。いらねーよな、こんなプロパティもどき。初心者が混乱するだけ。
710:デフォルトの名無しさん
07/03/16 23:22:40
>>709
普通は説明されなくてもわかるだろ。あんなの。
気づかない方が頭がおかしいんだよ。
711:デフォルトの名無しさん
07/03/16 23:35:01
>>710
「普通」とか言うけど、「使い勝手が悪い」っていう結論は主観が入り込んでるだろ？
712:デフォルトの名無しさん
07/03/17 00:10:42
->で全然問題なし
713:デフォルトの名無しさん
07/03/17 00:25:29
JavaBeans のプロパティと同名のフィールドを持てる事が問題ってところから
>>621 で
> いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
> 関係もないことにすりゃ、それで解決する
という意見が出た。
新プロパティシステムを作れば、フィールドと同名のプロパティを禁止できるからって話なんだろうけど、
>>674 のような問題も予想されるため、完全な解決とはならない。
結局、限定名のルールとかフィールドアクセスのルールが
ぎちぎちに詰め込まれているので dot でフィールドにアクセスする事と、
dot でプロパティにアクセスする事が相容れないと考えた方が良いみたい。
それとは別に、>>640、>>641 で言ったように setter/getter とは別の新プロパティシステムを導入する場合、
setter/getter の syntax sugar ならプロパティとしてアクセスできた情報の一部に
プロパティシステムを使ってアクセスできない事が予想される。
結局、「setter/getter とは別の新プロパティシステム」を導入しても
setter/getter のsyntax sugar で問題とされた事を解決できず、
さらに setter/getter の syntax sugar では出なかった問題も発生する。
まぁ、「setter/getter とは別の新プロパティシステム」の詳細を見ての評価じゃないけど
現在の情報からなら setter/getter の syntax sugar より「使い勝手が悪い」と言える。
714:デフォルトの名無しさん
07/03/17 00:28:20
>>713
どうでもいーけど長文ウザイ
715:デフォルトの名無しさん
07/03/17 10:20:14
説明が下手なんだからしょうがないよ。
716:デフォルトの名無しさん
07/03/17 10:22:41
説明されなくたって、既存のプログラムに新機能を追加して、
どんな影響が出るかを予見できないってのは技術者として拙いだろ。
717:デフォルトの名無しさん
07/03/17 10:30:57
じゃあレスする必要ないじゃんｗ
なんで一生懸命説明してんの？
718:デフォルトの名無しさん
07/03/17 10:33:03
>>716-717
次世代Javaと関係ない話題だな。 続きは他所行ってやれ。
719:デフォルトの名無しさん
07/03/17 12:59:19
>>718
たった2レス程度で…気が短いな
720:デフォルトの名無しさん
07/03/17 16:16:28
>>713
結局、getHoge()/setHoge()を使わない新プロパティシステムを導入しても、
既存のgetHoge()/setHoge()を使えないから使い勝手が悪いということかw
721:デフォルトの名無しさん
07/03/19 00:14:19
ふー、びっくりした。でも、反対派の意見はほぼ一点に集中している。
プロパティは既存の言語機能と干渉するから、導入の必要はないというもの。
それ、ほんとなのかなあ（ｒｙ
722:デフォルトの名無しさん
07/03/19 00:44:26
サイレントマジョリティの声を尊重してプロパティを導入することにしました。
当然のことだよね
723:デフォルトの名無しさん
07/03/19 00:51:13
>>721
既存の言語機能と干渉とかいう以前に、そもそも「そんなに必要な物なのか」って
ことがまずあるんじゃないか？
プロパティの仕組み導入の話が出てるのは、
「定義するのも使うのも既存のgetter/setterの仕組みだとめんどくさい」
という要望から来てるんだろうけど、
「めんどくさい」っていう理由だけで言語仕様変えてったらとんでもないことになる気がする。
相当面倒、ってのが、すごく簡単ってなるならまだ納得できなくもないけど、
IDE使ってる人の中にはgetter/setterがそこまで面倒とは思わない人もいるんじゃないかとも思う
ちなみに個人的にはgetter/setterの使用側は今のままで十分。
ただ、定義するのが面倒だから、アノテーションとかで自動でデフォルトのgetter/setterが
作成される仕組みができるぐらいでも満足だよ。
724:デフォルトの名無しさん
07/03/19 02:14:53
a = obj get foo;
obj set foo = 1;
725:デフォルトの名無しさん
07/03/19 08:54:34
>>722
>>667 の結果を見るに、
プロパティ要らないって意見の方が サイレントマジョリティで、
プロパティ欲しいと言ってる方が、声の大きい少数派。
726:デフォルトの名無しさん
07/03/19 11:47:22
>>721-722はネタなんで相手しなくていいです
727:デフォルトの名無しさん
07/03/19 12:23:09
>>724 はネタじゃないのか……
728:724
07/03/19 20:34:17
>>727
ネタです。
729:デフォルトの名無しさん
07/03/19 23:15:19
>>723
うむ。
プロパティ自体は特にそんなに欲しいものでもないが、自分で開発していて
コードの半分以上が意味のないgetter/setterで占められているクラスが
山のようにあるのを見ると、何かが間違ってる気がしてならない.。
730:デフォルトの名無しさん
07/03/19 23:21:52
あるBeanのプロパティ値ともうひとつのプロパティ値を足し算してその結果を格納とかめんどくさすぎ
同様にBigDecimalの演算もきっつい
731:デフォルトの名無しさん
07/03/20 00:51:51
>>730
プロパティに足し算して格納とかってそんなに使う？
俺、WEB開発系がメインだけど、プロパティに対して加算とかって
ほとんどしたことないし、BigDecimalも使ったことない。
きっとプロパティが必要な分野と、たいして必要とされない分野があるんだろうな。
732:デフォルトの名無しさん
07/03/20 01:17:10
getHoge()がめんどくさいから->でやらせろって言ってる人は、
やっぱりadd()がめんどくさいから演算子オーバーロード使わせろ
とか言うのかな。
733:デフォルトの名無しさん
07/03/20 02:00:33
BigDecimalは業務系はこれしか使わないというくらい使う
BigDecimalだけはStringのようにシンタックスシュガーとしてaddとかやってほしいな
プロパティの足し算引き算ってのは普通にあるっしょ
金額とか在庫とかいくらでも
特にO/RマッパやBeanBinding関係使うと頻発
734:しろうと
07/03/20 09:36:43
public class Foo {
public int bar;
}
じゃだめなん？
735:デフォルトの名無しさん
07/03/20 10:15:22
セット時やゲット時に加工が出来ないからダメ
それに定義のほうはどうにでもなるためたぶん問題になってない
736:デフォルトの名無しさん
07/03/20 22:24:23
VMがグリッドコンピュータに対応するのはいつだ？
737:デフォルトの名無しさん
07/03/20 22:34:18
VMがグリッドコンピュータのネイティブな基盤になればいいのに。
738:デフォルトの名無しさん
07/03/20 22:38:44
設定がないと動かないJVMは面倒だな。
グリッドとかは、アプリケーションの下で何らかのグリッド制御部が
動いていて、JVMのリソースとしてグリッドが見えるって前提だろうから
MVMが実現して、アプリケーションの起動とJVMの起動が分離するまでは
あんまり興味がないね。