トップページ⇒tech
994コメント251KB

【Java SE 7】 次世代Javaの動向 8 【dolphin】

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2009/04/14(火) 20:59:05
■■前スレッド■■
【Java SE 7】 次世代Javaの動向 ７ 【dolphin】
http://pc12.2ch.net/test/read.cgi/tech/1220531647/

■■過去スレッド■■
[Java SE 7] 次世代Javaの動向 6 [dolphin]
http://pc11.2ch.net/test/read.cgi/tech/1199330977/
[Java SE 7] 次世代Javaの動向 5 [dolphin]
http://pc11.2ch.net/tech/kako/1178/11789/1178925915.html
[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
http://pc11.2ch.net/tech/kako/1163/11639/1163986696.html
[mustang] 次世代Javaの動向 3 [dolphin]
http://pc8.2ch.net/test/read.cgi/tech/1157227790/
次世代Javaの動向　２
http://pc8.2ch.net/test/read.cgi/tech/1147881822/
【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc8.2ch.net/test/read.cgi/tech/1081698555/
0655デフォルトの名無しさん2009/11/27(金) 23:28:45
同意せざるを得ない
0656デフォルトの名無しさん2009/11/27(金) 23:33:48
Genericsが型指定と派生型受け入れを分けてるんだから、
varで型を勝手に決められたら意図しない動作になっちゃうぞ。
0657デフォルトの名無しさん2009/11/28(土) 00:22:08
>>654
突撃してきた。要は、フィールドに書くことを考えたらああなった、と個人的に解釈してる。
とは言え、ローカル変数用にvarも欲しい気はする。
0658デフォルトの名無しさん2009/11/28(土) 08:39:18
var の代わりに final でローカル変数限定再代入不可みたいに制限強くてもよかったんだが
0659デフォルトの名無しさん2009/11/28(土) 17:46:29
コーディングを楽にするだけの機能だろ、これ。
無くても死にはしない。有れば便利かな、って程度。
ＩＤＥの補完機能が無いとまともにコーディングするのは現実的では無い言語なんだから
どうでもいいよ。
ｊａｖａはＩＤＥと組み合わせて１つの言語と言っても過言ではない。
言語を拡張するならＩＤＥ側の都合も考えてもらわないとな。
0660デフォルトの名無しさん2009/11/28(土) 19:00:18
>>659
まぁ、そだな。実際、コード書くときは型指定なしにhoge = new Huga<Hige>();とか入力してクイックフィックスで補完してるし。
0661デフォルトの名無しさん2009/11/28(土) 20:06:23
diamond operator・・・
これならまだvarの方がマシだ。むしろいらない。
0662デフォルトの名無しさん2009/11/28(土) 20:13:18
>>660
むしろnew Huga<Hige>();だけ入力して補完(Ctrl+2, L)だな
0663デフォルトの名無しさん2009/11/29(日) 18:46:08
C#なんて実際、IDEのIntelliSenseが作りやすいようにシンタックス選んでるからね。
0664デフォルトの名無しさん2009/11/29(日) 18:50:07
JSFとかIDEのための規格とか普通にあるし、
今後ともIDEとの親和性を如何に向上させるかが焦点だろう。
EoDへ舵を切ったJavaは何だかんだでしばらくは安定。
0665デフォルトの名無しさん2009/12/02(水) 08:53:41
JDK 7 Milestone 5、並行処理とパフォーマンスに関してアップデートされたが、Feature Completeには至らず
http://www.infoq.com/jp/news/2009/12/jdk7m5

Mark Reinhold氏、Javaのクロージャについて語る
http://www.infoq.com/jp/news/2009/12/reinhold_closures_update
0666デフォルトの名無しさん2009/12/02(水) 12:07:10
中の人は忙しいんだろうな。
0667デフォルトの名無しさん2009/12/05(土) 19:50:38
jdk7 build77
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b77.html

いっぱいバグ取り
0668デフォルトの名無しさん2009/12/05(土) 21:39:04
報告ご苦労
0669デフォルトの名無しさん2009/12/08(火) 15:12:11
GolangはJavaの脅威になるかな。
0670デフォルトの名無しさん2009/12/08(火) 17:57:02
それはむしろScala
0671デフォルトの名無しさん2009/12/08(火) 18:04:13
XMLのサポートって結局無くなったんだろうか。
どんなものをイメージしてたんだろう。
0672デフォルトの名無しさん2009/12/08(火) 22:47:50
E4X
0673デフォルトの名無しさん2009/12/12(土) 16:14:28
Project Lambda: Straw-Man Proposal
http://cr.openjdk.java.net/~mr/lambda/straw-man/
0674デフォルトの名無しさん2009/12/13(日) 21:05:10
ちょこっと読んでみたけど、こんな大胆にクロージャ取り入れちゃうのかな
あくまで提案なんだよね
0675デフォルトの名無しさん2009/12/13(日) 22:11:45
まだ初期提案の仕様だね
0676デフォルトの名無しさん2009/12/13(日) 22:24:08
どうせ結局また却下だろ
0677デフォルトの名無しさん2009/12/13(日) 22:58:33
モジュール関係の主要JSRがのきなみinactiveになった。OSGi側に片寄せするらしい。
政治的な綱引き以前に、技術的にSunの動きが遅すぎたよなあ。
0678デフォルトの名無しさん2009/12/13(日) 23:06:34
SUNに期待しすぎ。
いつも最先端に触れていたいなら素直にMSに行けよ。
0679デフォルトの名無しさん2009/12/14(月) 00:36:10
MSはないだろｗ
0680デフォルトの名無しさん2009/12/14(月) 00:46:23
グーグルのアプリはまずMS-Windows対応がデフォだよね。
つまり世の中全ての情報はMS-Windowsありき。
0681デフォルトの名無しさん2009/12/14(月) 02:00:25
>>680
golang は Windows は後回しだったね。
0682デフォルトの名無しさん2009/12/14(月) 02:33:26
>>681
いちおう、Windows版のビルドはあるよ。
簡単にネイティブバイナリが吐けるってのは面白かった。
0683デフォルトの名無しさん2009/12/14(月) 02:38:17
あるよw
0684デフォルトの名無しさん2009/12/14(月) 04:45:13
Windowsでgolangって誰得。
まぁスレ違いだな
0685デフォルトの名無しさん2009/12/19(土) 06:31:25
>>673
いいね、これ
C#っぽい
これまでの変なのと違って実にいい
0686デフォルトの名無しさん2009/12/19(土) 09:50:19
組み込み系には力はいってないのか気になる

Jiniがどうなったのか気になる

Java家電は？
0687デフォルトの名無しさん2009/12/19(土) 09:54:40
Jiniは死亡
Java家電最大大手はBlu-rayでBD-Java必須
WebTVでJava使ってるのがある。
0688デフォルトの名無しさん2009/12/19(土) 17:10:13
あるねｗ
0689デフォルトの名無しさん2010/01/09(土) 21:34:24
ひょっとして過疎ってる？
JAVAって斜陽なの？
0690デフォルトの名無しさん2010/01/10(日) 04:38:39
今年が山田
0691デフォルトの名無しさん2010/01/10(日) 07:35:28
一時的に流行り物に流れてるだけだろ。
Java7は1年塩漬けらしいし、周囲もJava6への移行も済んでないし。
0692デフォルトの名無しさん2010/01/10(日) 18:07:19
ＯｒａｃｌｅのＳｕｎ買収はもう済んだんだっけ？
そのあたりが落ち着かないと未来図が描きにくい。
0693デフォルトの名無しさん2010/01/10(日) 18:31:33
欧州委員会がグダグダ文句付けてて一向に進んでない
買収が承認される前にSunが潰れかねない状況
0694デフォルトの名無しさん2010/01/10(日) 19:36:25
ECのせいで機会損失してるってオラクルが切れてたな
0695デフォルトの名無しさん2010/01/10(日) 23:14:28
富士通が買収して日本企業の一員となってくれればいい。（無理だろうけど）。
0696デフォルトの名無しさん2010/01/10(日) 23:19:27
おもしろそうだけど無理だろうな
0697デフォルトの名無しさん2010/01/10(日) 23:52:35
ハード部門だけ欲しいってことはあり得る。（スカラーCPUと命令セット的に）。
0698デフォルトの名無しさん2010/01/12(火) 15:36:48
海豚
0699デフォルトの名無しさん2010/01/19(火) 16:43:32
jdk7 build79
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b79.html

G1GC関連で修正＆追加多し
0700デフォルトの名無しさん2010/01/22(金) 12:58:04
EUが買収承認したな
0701デフォルトの名無しさん2010/01/23(土) 00:09:58
で。UTF8 の BOM で誤作動するバグは、いったいいつ治るんですか。
0702デフォルトの名無しさん2010/01/23(土) 00:21:24
UTF-8にBOM付ける方がバグだろｗ
0703デフォルトの名無しさん2010/01/23(土) 00:24:15
>>702
禿同
0704デフォルトの名無しさん2010/01/23(土) 02:17:01
マイ糞ソフトはとことん迷惑な存在だな
0705デフォルトの名無しさん2010/01/23(土) 14:46:30
>>702-703
ttp://unicode.org/faq/utf_bom.html#bom5
Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)?
A: Yes, UTF-8 can contain a BOM.
0706デフォルトの名無しさん2010/01/23(土) 15:57:03
>>705
うへー。
ラウンドトリップを保証するためだろうか。
0707デフォルトの名無しさん2010/01/23(土) 22:38:00
>>705
Unicodeコンソーシアムの仕様なんてただの文字列の話だろ
Javaでいえばjava.io.ReaderがBOMで始まる文字列を読めればいいだけだ
XMLとは別の話





と思ったら
http://www.w3.org/TR/2008/REC-xml-20081126/#charencoding
UTF-8 MAY begin with the Byte Order Mark

orz
XML 1.0 Second Editionまではそんなこと書いてないのにThird Editionで追加してやがった
w3cめ、MSに買収されやがったか・・・
0708デフォルトの名無しさん2010/01/24(日) 08:01:52
仕様策定委員会とか標準化なんとか、というのは
けん制と足の引っ張り合いの場だからしょうがないね。
0709デフォルトの名無しさん2010/01/24(日) 08:05:15
>>707
Java6でも準拠してるのはXML 1.0(Second Edition)だから無問題





といいたいところだが、Javaが準拠してる「XML 1.0 Second Edition Specification Errata」で
>>707の記述が追加されてるからアウト
0710デフォルトの名無しさん2010/01/24(日) 08:54:00
全バイトBOMかチェックしなければいけないんじゃ、効率が悪くなりそうだな。
0711デフォルトの名無しさん2010/01/24(日) 09:09:13
？？
BOMとして扱われるのは先頭だけだよ
もし先頭以外で使ったらBOMではなくZERO WIDTH NON-BREAKING SPACE
ただしそれはXML的にはホワイトスペースではない
0712デフォルトの名無しさん2010/01/24(日) 09:37:33
>>711
だから、途中で使ったら無視するコードを入れなければならないから、
全byteチェックしなければならないじゃん。
まあ、BOMとは呼ばないのかもしれないけど。
0713デフォルトの名無しさん2010/01/24(日) 09:43:29
それとも、UTF-8 にZERO WIDTH NON-BREAKING SPACE が入ってたら、
(String の内部文字コードの)UTF-16に変換するときにはそのままスルーでいいのかな？
0714デフォルトの名無しさん2010/01/24(日) 09:45:25
当然、普通の文字の一つとして扱われるだけ
0715デフォルトの名無しさん2010/01/24(日) 10:16:24
>>701
http://bugs.sun.com/view_bug.do?bug_id=6378911
BOM読み飛ばすように変えたら既存アプリで問題でたから元に戻したらしい。
0716デフォルトの名無しさん2010/01/25(月) 17:51:18
>>715
そんなぁ。
そのせいで問題出てるアプリはスルーなのかな。
0717デフォルトの名無しさん2010/01/30(土) 12:21:28
JDKダウンロードしたら、インストール画面のバーが赤くなってた。
前からそうだっけ？
0718デフォルトの名無しさん2010/01/31(日) 15:00:09
Oracleのコーポレートカラーになった、のかも
0719デフォルトの名無しさん2010/01/31(日) 15:19:45
faviconもオラクルになっちゃったしなぁ
0720デフォルトの名無しさん2010/02/01(月) 12:31:36
オラクルレッドに浸食されつつありまさーね。

XML に BOM 入ってるとプロローグに変な文字入ってるぜとか言われる奴?
あれって Sun JDK だけじゃね。IBM JDK は問題なかったと思う。

んで半年ぶりに来たんだけど何か進展あった?
0721デフォルトの名無しさん2010/02/01(月) 12:57:41
あれってクリムゾンがダメなだけでXercesはおkじゃね？
つまりJ2SE1.4まではダメでTigerからおkじゃね？
0722デフォルトの名無しさん2010/02/01(月) 16:24:24
>>719
不評だったのか今度はコーヒーカップになったｗ
0723デフォルトの名無しさん2010/02/03(水) 00:06:39
じきにOracle, IBM, Open系に３分裂するんじゃねえかな。ちと心配だ。
0724デフォルトの名無しさん2010/02/03(水) 00:57:40
GoogleがAndroidでJavaもどき使ってるから乗っ取られちゃうかもよ
0725デフォルトの名無しさん2010/02/03(水) 01:35:55
何が心配だって？
0726デフォルトの名無しさん2010/02/03(水) 07:29:53
結局はj2sdk1.4でソースコード書いとくしかないんだろ
0727デフォルトの名無しさん2010/02/03(水) 22:06:16
Java SE 7は高速化する、Oracle JRockit技術マージ
http://journal.mycom.co.jp/news/2010/02/02/038/index.html
0728デフォルトの名無しさん2010/02/07(日) 22:22:18
JavaがCの速度を上回るってことはありえる？
0729デフォルトの名無しさん2010/02/07(日) 22:32:43
処理によってはすでに上回ってる。
0730デフォルトの名無しさん2010/02/07(日) 22:35:07
似たようなコード書いてJavaの方が速いだのどうのというのは意味がない
Cで速い書き方したらCの方がどうやっても速いに決まってる
0731デフォルトの名無しさん2010/02/07(日) 22:51:48
そりゃインラインアセンブラ使えば負けっこない
0732デフォルトの名無しさん2010/02/07(日) 23:58:03
アセンブラ書いたらそれはCじゃないだろと。

ビルド時にCPU最適化を行うネイティブコード出力型と
実行時にCPU最適化を行うバイトコード出力型との違いが、
ベンチマークに現れるようになったのはJavaのコンパイラ屋の良い仕事のおかげだな。
0733デフォルトの名無しさん2010/02/08(月) 01:03:02
実行時にできるなら、静的にもできるじゃない。って話にならないか?
今のJITコンパイラは、そこまで実行環境の特性に合ったコードを吐き出せるの?
JavaランタイムがCで超えられないレベルのコードで組まれている、
とかでもない限り上回るのは流石に無理じゃないかなあ。
0734デフォルトの名無しさん2010/02/08(月) 01:06:26
それにJavaで実行時に最適化できるならCでもできるわなw
0735デフォルトの名無しさん2010/02/08(月) 01:20:19
Server VMの実行時最適化情報は、静的なC言語のコンパイルでは入手不可能なものだ。
最適化がより包括的に行われるからCと同じにはならないよ。
0736デフォルトの名無しさん2010/02/08(月) 01:28:48
ていうか、ビルド時の最適化じゃ環境ごとにコンパイルしなおさなきゃいけないし。
LLVMが実用的になってきたらCでもJITできるようになるかもしれんけど
0737デフォルトの名無しさん2010/02/08(月) 01:35:59
レベル低い奴の相手をするほどヒマじゃない
0738デフォルトの名無しさん2010/02/08(月) 01:38:49
こんな時間にレスしてるってことはそうとう暇なんだろ
言い逃げにしても馬鹿すぎる・・・
0739デフォルトの名無しさん2010/02/08(月) 01:54:47
忙しすぎて現実逃避してる可能性は・・・ないか。
0740デフォルトの名無しさん2010/02/08(月) 17:58:15
VS2008からCコンパイラが吐くのは中間コードで、リンカがネイティブコードの生成をするようになってる。
これは、関数単位でのコード生成では最適化に限界があるから。
その考えを進めれば、より高度な最適化として、入力データにあわせたコード最適化があり、それは
静的最適化では決して到達できないものだというのは容易に理解できる。
0741デフォルトの名無しさん2010/02/08(月) 18:32:49
まぁ、世の中の流れはJITでしょ
0742デフォルトの名無しさん2010/02/08(月) 20:17:21
コードが抽象的であればあるほど最適化の可能性が広がる、ってところかね。
0743デフォルトの名無しさん2010/02/09(火) 08:17:49
リンカーがコード生成と最適化をするなんて
最適化のバグが怖いね
コンパイラの-Oxオプションみたいな
0744デフォルトの名無しさん2010/02/09(火) 09:16:56
Profile-Guided Optimizationsだがプロファイル取るのが面倒でつかわねぇ。
プロファイルなしでも一応効果はある。
0745デフォルトの名無しさん2010/02/09(火) 20:35:24
そこでJNIですよ。
0746デフォルトの名無しさん2010/02/17(水) 02:51:27
>>742
インタープリタ＋JITは強いよねえ。
ソースコードを使ってJIT出来るから。
v8がそう。
0747デフォルトの名無しさん2010/02/17(水) 07:49:07
>>746
しったか乙
0748デフォルトの名無しさん2010/02/17(水) 19:27:15
>>746
Javaも.NETもソースコードレベルよりも最適化された形(定数の展開とか)で中間言語が残ってるわけだが。
0749デフォルトの名無しさん2010/02/17(水) 19:30:44
中間言語へのコンパイルはいつでもできるんだから最適化の幅だけでいえば
ソースコードそのままの方が広いに決まってるだろ
0750デフォルトの名無しさん2010/02/17(水) 20:54:10
プリミティブな命令列のほうが最適化しやすいんでない?
0751デフォルトの名無しさん2010/02/17(水) 20:59:53
ソースコードそのままだと構文木作成の手間もかかるしなぁ
0752デフォルトの名無しさん2010/02/17(水) 21:03:39
顧客のイメージをそのままJITコンパイルが最速
0753デフォルトの名無しさん2010/02/17(水) 22:00:10
イミフ
0754デフォルトの名無しさん2010/02/17(水) 23:42:08
誰しもが夢に見るドキュメントからコード生成ｗ
■ このスレッドは過去ログ倉庫に格納されています