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

[mustang/Java SE 6] ..

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 みたいな穴があるから、やるだけ無駄。

次ページ