- 1 名前：デフォルトの名無しさん [2007/05/12(土) 08:25:15 ]
- 前スレ
[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
pc11.2ch.net/test/read.cgi/tech/1163986696/
[mustang] 次世代Javaの動向 3 [dolphin]
pc8.2ch.net/test/read.cgi/tech/1157227790/
次世代Javaの動向 ２
pc8.2ch.net/test/read.cgi/tech/1147881822/
【Java】次世代Java・J2SE1.6の動向【Mustang】
pc8.2ch.net/test/read.cgi/tech/1081698555/
- 82 名前：デフォルトの名無しさん [2007/06/26(火) 02:18:28 ]
- bugs.sun.com/bugdatabase
↑のバグ修正情報などを RSS かなんかで取得できませんか？
join SDN すれば、たぶんどうにかして特定のバグを追っかけたり
できるんでしょうけど、できれば join しないで見たいなぁと。
- 83 名前：デフォルトの名無しさん mailto:sage [2007/06/29(金) 01:54:26 ]
- >>82
RSSで何をみる？新しく登録されたもの？
joinしたらvoteもできるぞ。
- 84 名前：82 mailto:sage [2007/06/29(金) 02:47:38 ]
- >>83
RSS で、新しく登録されたバグ、登録されたバグについての変更
が見れたらいいなぁと思います。
- 85 名前：デフォルトの名無しさん mailto:sage [2007/07/07(土) 00:40:40 ]
- JDK7 build15
ttp://download.java.net/jdk7/changes/jdk7-b15.html
ttp://download.java.net/jdk7/binaries/
ビルドペースあがってきた？
- 86 名前：デフォルトの名無しさん [2007/07/12(木) 01:38:18 ]
- 最近ネタないね
- 87 名前：デフォルトの名無しさん mailto:sage [2007/07/12(木) 01:53:12 ]
- そーいや、invokedynamic ってもう実装されたの？
- 88 名前：デフォルトの名無しさん [2007/07/12(木) 15:43:33 ]
- マルチタスク対応って7で実装されるのか？
- 89 名前：デフォルトの名無しさん mailto:sage [2007/07/12(木) 16:30:29 ]
- たしか使用策定は済んでるんじゃなかったけ？
Java Cardならすでに実装されててMIDP3.0が対応中（MIDP3.0自体策定中）。
jdk7はJAMに期待。Libletみたいな使い方をするんだろうね。
- 90 名前：デフォルトの名無しさん mailto:sage [2007/07/13(金) 23:46:55 ]
- ODFとか対応しないのかな？
- 91 名前：デフォルトの名無しさん mailto:sage [2007/07/21(土) 13:38:09 ]
-
JDK7 build15
JDK7 build16
download.java.net/jdk7/changes/jdk7-b16.html
download.java.net/jdk7/binaries/
- 92 名前：デフォルトの名無しさん mailto:sage [2007/07/24(火) 10:34:30 ]
- 7っていつ頃リリースを予定しているの？
- 93 名前：デフォルトの名無しさん mailto:sage [2007/07/24(火) 14:36:08 ]
- >>92
JDKのメジャーバージョンのリリースが 18〜24ヶ月毎って話からすれば
JDK6のリリースが2006年 12月第一週だから、
JDK7のリリースは2008年 6月〜12月ぐらいになる。
個人的には、JDK7は機能てんこもりだから遅れ気味になるんじゃないかと予想。
- 94 名前：デフォルトの名無しさん mailto:sage [2007/07/24(火) 15:06:50 ]
- 確かに。
JAMだってまだ乗ってないし。
- 95 名前：デフォルトの名無しさん mailto:sage [2007/07/24(火) 15:38:04 ]
- >>91
何かさ・・・・コンパネが・・・・びろーんって・・・縦に・・・伸びてない・・・(；・∀・)？
- 96 名前：デフォルトの名無しさん [2007/07/24(火) 21:40:33 ]
- 来年秋って話だったから、再来年の春くらいになるんじゃね〜の？
- 97 名前：デフォルトの名無しさん mailto:sage [2007/07/25(水) 00:56:49 ]
- >>95
普段は JRE7入れてないから気付かなかった。
入れてみたら、なった。
うちだと、コンパネの天辺もタブも画面外にあって操作できない。
bugs.sun.com/bugdatabase/view_bug.do?bug_id=6581482
これと同じかな？ Image file attached って書いてあるけど見られないんだよね。
- 98 名前：デフォルトの名無しさん mailto:sage [2007/07/25(水) 04:07:24 ]
- 来年以降か。機能がたくさん追加されるから楽しみだな。
- 99 名前：デフォルトの名無しさん mailto:sage [2007/07/26(木) 01:49:13 ]
- 俺はどれだけ構文が汚されるのか気になって仕方が無い。
これだけ、getter,setterの糞規約が定着したところでpropertyが普及するのかどうか…。
- 100 名前：デフォルトの名無しさん mailto:sage [2007/07/26(木) 12:25:00 ]
- Javaのクロージャは期待できるけどなぁ…
delegateを無理に拡張している冗長構文のクロージャより大分改善されている。
- 101 名前：デフォルトの名無しさん mailto:sage [2007/07/26(木) 23:59:44 ]
- >>100
Collectionライブラリもクロージャ対応されてくるかなぁ？
Streamとか、JDBCもクロージャ対応になったら、今のソースとガラッと変りそう。
- 102 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 00:24:21 ]
- java.util.Collections にクロージャ対応な staticメソッドが追加される予感……
- 103 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 00:43:27 ]
- これから6勉強しようかって思ってるのに・・・
- 104 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 01:44:31 ]
- 別に覚えた内容が損になるわけじゃないぜ
- 105 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 01:48:37 ]
- >>103
勉強しとけ。
- 106 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 02:35:04 ]
- >>101
with(InputStream s: new FileInputStream("c:/test.txt")){
System.out.println(s.read());
}
みたいなことが書けたり
List<Integer> list = Arrays.asList(1, 2, 3, 4);
int sum = Collections.reduce(
list, {Integer x, Integer y => x + y});
とすると10が得られたり
Lock lock = ....;
withLock(lock){
//いろいろロックされる処理
}
と書けたりする予定らしい。
- 107 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 07:50:44 ]
- こういうのって結局Cのプリプロセス処理と同じなんだよね。
- 108 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 09:43:44 ]
- >>107
Cのプリプロセッサみたいにコンテキスト考えずに
ただ置換するだけのものとは全然違うよ
- 109 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 14:52:46 ]
- 違いを見せたいのは分かるが、たいした差はない。
- 110 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 14:55:54 ]
- ようするにシンタックスシュガーっていいたいんだろ。
それをCのプリプロセス処理と同じというのは問題あるがな。
- 111 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 22:54:16 ]
- 単なる置き換え。マクロと同じってことがいいたいんだろう。
そういわれると辛いところだが…
- 112 名前：デフォルトの名無しさん mailto:sage [2007/07/27(金) 23:03:57 ]
- プリプロセッサは別の言語仕様として存在してるのが問題なんだろ。
D言語とかはC++のカオスさをうまく言語仕様に馴染ませてて感心した。
- 113 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 08:27:49 ]
- まあ、でもそれはCore2Duoって8086と同じだよね、っていう感じで、だから何？ってなるんだよね。
仕組み的に同じ系統だからって、便利さは全く違ったりするわけだ。
- 114 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 11:10:24 ]
- 自分で実装するわけにもいかないからね。
便利なのは使わせてもらおっと
- 115 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 11:58:04 ]
- >>107>>110
アホですね。
- 116 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 12:03:17 ]
- Ｇｅｎｅｒｉｃｓの話？
- 117 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 14:00:46 ]
- どこからその話が・・・
- 118 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 15:07:58 ]
- >>106
またC#のパクリか
- 119 名前：デフォルトの名無しさん mailto:sage [2007/07/28(土) 15:18:52 ]
- クロージャーがC#にしかないと思ってんのか。
- 120 名前：デフォルトの名無しさん mailto:sage [2007/07/30(月) 12:02:37 ]
- scriptは何が追加されるんだろう。
- 121 名前：デフォルトの名無しさん mailto:sage [2007/07/30(月) 13:43:25 ]
- script乱立しすぎでわけわかんね
- 122 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 07:29:47 ]
- jdk6ではjavascriptが使えるけど、javaファイルも同じようにスクリプトとして使えるのかな。
- 123 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 10:38:25 ]
- 標準添付はされていない
- 124 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 11:36:20 ]
- 標準ではないのか。次バージョンに期待するよ。
- 125 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 12:09:03 ]
- >>124
いまのところ、標準添付される雰囲気はないね。
標準添付できるような質のJavaスクリプトエンジンってあるのかな？
- 126 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 14:14:13 ]
- 標準添付のスクリプトエンジンの方が
野良スクリプトエンジンより品質悪かったりするけど……
- 127 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 15:02:46 ]
- >>125
つ Pnuts・・・
- 128 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 17:08:04 ]
- スクリプトだし、質とか速さとかどうでもいいよ。
とりあえず、Javaが動くスクリプトエンジンを実装してくれ。
- 129 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 17:13:49 ]
- 言語としてのJavaならスクリプトエンジン作るよりも
コンパイラAPIの拡充の方が良い。
メソッド宣言時のシグネチャだけみたいな細かい単位で
構文解析＆名前解決してくれればそれで良い。
ツール作る時とか、そっちの方が都合良いし。
- 130 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 18:31:03 ]
- そんなこといってちゃ、いつまでたってもjavax.scriptでJavaはサポートされないよ。
自分の都合だけで考えるのもいいけどね。
- 131 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 20:05:04 ]
- 俺は両方欲しいぜ、ベイベ
わがままな、俺の願いを聴いてくれよ
イエー
- 132 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 20:15:11 ]
- >>126
具体的には？
- 133 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 21:04:43 ]
- 何につかうんだよそんなもの
- 134 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 21:36:56 ]
- >>130
標準添付されないというだけで、javax.scriptでJavaはサポートされてるわけだが。
- 135 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:35:59 ]
- >>132
具体的にはって標準添付されてんのRhinoしかないじゃないか。
- 136 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:37:07 ]
- 標準で入ってないと意味ないし、無駄な努力なのだが。
- 137 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:40:17 ]
- SPI使えるんだから、クラスパスに含めるだけで新しいスクリプト言語使えるようにできるんだが……
- 138 名前：デフォルトの名無しさん [2007/08/01(水) 22:42:38 ]
- おれは、C言語をスクリプトで実装して欲しいぜ！
それもC99を！
- 139 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 22:45:08 ]
- >>137
ん？俺が無知なだけなのか・・
- 140 名前：デフォルトの名無しさん mailto:sage [2007/08/01(水) 23:13:33 ]
- まあ実際無知なんだろうな。
- 141 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 05:09:30 ]
- >>135
いや、オレもRhinoしか添付されてないと思ってたのだが、それだと野良スクリプトエンジンの方が品質がいいってのがひっかかる。
Rhinoよりいいスクリプトエンジンって何だ？
- 142 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 05:10:04 ]
- >>136
いらん。
- 143 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 12:28:23 ]
- >>141
普通にビルドしたRhino。
- 144 名前：デフォルトの名無しさん mailto:sage [2007/08/02(木) 14:28:20 ]
- >>141
つ Pnuts
- 145 名前：デフォルトの名無しさん [2007/08/03(金) 00:08:05 ]
- >>138
個人的にはFORTRANが良い
- 146 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 00:12:18 ]
- たしかSunがFortressっての開発中だったと思う。
並列計算に特化したJavaとFortranを参考にしたスクリプトっての。
- 147 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 00:12:52 ]
- >>144
pnutsそんなにいい？
まだこなれてない感じバリバリなんだけど。
yieldの挙動とか。
- 148 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 04:44:27 ]
- あんま関係ない話で恐縮なんだけど、javax.script バブルの火付け役が php だって噂は本当なん？
- 149 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 06:10:32 ]
- msのcliに対抗するため
- 150 名前：デフォルトの名無しさん [2007/08/03(金) 06:16:58 ]
- C言語やC#にある値型の struct はいつサポートされるの？
- 151 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 08:37:18 ]
- >>148
script言語の共通基盤になるチャンスを見逃すわけがない。
javascript, php, python, ruby実装環境をごっそり頂きかも知れない。
コンパイラ基盤もちらほら出てきているし。
- 152 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 12:00:15 ]
- >>150
なぜそんなものが必要なのか？理由を明確に
- 153 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 12:54:23 ]
- リンゲージがその関数内であるオブジェクトに対して、イチイチnewしないで済むことが言語として保障されることになる。
- 154 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:02:33 ]
- >>153
コンパイル時に最適化情報がバイトコードに埋め込めればいいんだよね〜
そしたら、ガンガンエスケープ解析できる
- 155 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:28:43 ]
- >>151
いや、知り合いから
「php を java vm 上で動かそうって話が最初で、そのあと他の軽量言語が追従した」
って話を聞いたんだけど、本当なのかなって。
- 156 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:54:15 ]
- >>154
そういう小手先解析よりも、普通に言語としてサポートしろってこと。
struct Point {
double a,b
};
どう考えても需要あるだろ。
- 157 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 13:56:16 ]
- >>155
それだけ需要があるなら、PHPがまずサポートされるはずじゃないか？
VMで他の言語が動けばいいのであって、どうでもいいけど。
- 158 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 14:24:28 ]
- >>156
その程度なら不要。
値型の利点は、newが必要とかより、
代入が必ずコピーになることによって、
同一オブジェクトに対応する変数が一つであることを保障できることだと思うんだが。
- 159 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 16:26:23 ]
- >>158
需要の論点ではPointで示したが、利点としては例えが悪かった。
では必ずコピーになる利点のために導入するのではどうだ？ほしいだろ？
- 160 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 16:41:03 ]
- いや別に
- 161 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 17:45:57 ]
- 値型が導入されたら、今度はポインタ演算を欲しがるに違いない
- 162 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 19:10:24 ]
- C#はstructの導入に失敗したからNullableが出来たんでしょ
恥ずかしい実装まで追従する必要ないから、別に要らないなぁ
どうしてもってのならByteBufferをラップすりゃいいし
- 163 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 19:34:17 ]
- 値型ってメモリ効率に関する利点のために導入するもんだろ。
- 164 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 19:36:02 ]
- それが理由ならエスケープ解析が導入されたから今後は不要でしょ
- 165 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 21:11:05 ]
- >>161 それはない。
- 166 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 21:17:46 ]
- >>164
複雑じゃなくていいから、普通にCと同じのでいいよ。
メソッドもCの関数ポインタみたいに、staticのみでいい。
エスケーポ解析よりも言語に導入のほうが楽だと思うけど、そうでもないのか
まあ、そのうちちゃっかり導入されるんだろうけど。
- 167 名前：デフォルトの名無しさん mailto:sage [2007/08/03(金) 22:14:07 ]
- JDK7 build17
ttp://download.java.net/jdk7/changes/jdk7-b17.html
ttp://download.java.net/jdk7/binaries/
- 168 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 00:41:24 ]
- いまさら導入されても、C の register 変数と同じ運命をたどる予感。
- 169 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 02:00:02 ]
- register にも、一応アドレスを取れないという効果はあるんだぞ！
- 170 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 07:19:54 ]
- >>157
PHPみたいなどうでもいい言語をまずサポートする必要性がみあたらない。
- 171 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:47:45 ]
- structのメモリー効率のよさってのは、オブジェクト廃棄時のコスト云々じゃなくて、
newに頼ってオブジェクト生成するときのコストがまったくないってことだろ。
関数呼び出しでスタックに自動生成されるのであって、newによるオーバーヘッドは
かからないいってこと。
- 172 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:51:14 ]
- オブジェクトがほかのメソッドに伝播される可能性を考えると、エスケープ解析で自動的にやってくれるのが一番効率がよさそうだな。
- 173 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:52:09 ]
- structは、コピーによって、ここのオブジェクトの同一性の確保も
そのとおり利点ではあるが、エスケープ解析の小手先技なんぞに頼らないで
優先的に言語でサポートするのが妥当だろ。
assert, enumとかよりも先にさ。
Javaの文法は、結局Cの文法を真似てるだけってことを忘れて、
「エスケープ解析もできる俺ってすごいだろ」っていい気になってるだろ？
- 174 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:52:42 ]
- エスケープ解析ってのはそれをやるんだよ。
C#のstructと同じような最適化がされることになり、
逆にC#2.0で対応するはめになったNullableのようなstructの欠点も無い
- 175 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:54:47 ]
- >>171
まあ、メリットはあっても、それが"大きく"効いてくるのはかなり特殊なケースで、
そういうのが大量にある応用の時は、ハイバネでいい、ってのが今の流れなんじゃないの?
- 176 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:55:56 ]
- JavaのenumはCのenumとは違うぞ。
定数そのものに振る舞いを持たせることが出来るし、
なおかつタイプセーフだ。
- 177 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:57:25 ]
- メモリーの効率とかじゃなくて、
structを使いたいプログラマーの切実な要望には答えられないのかね？
そういうエスケーポ解析の新技術はどうでもいいからさ。
- 178 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:58:34 ]
- >>173
で、エスケープ解析に比べたstructの利点ってなんなの？
- 179 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 08:58:58 ]
- structの欠点の無いむしろメリットとなるようなカラクリがあれば導入されるかもな。
- 180 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:02:12 ]
- ちなみに、structなど値型を使いたい場面は、
forや関数呼び出しで100万回以上まわす。
そういう小型オブジェクトの短期生成は、newでは向いてないし、役不足だろ。
またエプケール解析とかいうのか？
GCの新技術はJava以外のVM使うスクリプトにもメリットあるだろうが、
そういうのは使うほうからみてどうでもいいから、まずはJava言語で導入しろ。
- 181 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:02:38 ]
- >>177
メモリーの効率とかじゃないなら、structを使いたいっていう切実な要望っていうのは、新技術以上にどうでもいいんじゃないかと思う。
- 182 名前：デフォルトの名無しさん mailto:sage [2007/08/04(土) 09:03:54 ]
- >>180
使う方から見てどうでもいいのがstructだと結論づいてるのに何を・・・
|
 |
