[Java SE 7] 次世代Javaの動向 5 [dolphin]

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 13:00 / Filesize : 224 KB / Number-of Response : 992
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/
263 名前：261 mailto:sage [2007/08/09(木) 16:02:17 ]: javac -source 1.5 -target 1.4 Test.java
javac: リリース 1.5 のソースにはリリース 1.5 のターゲットが必要です。

と言われてしまった。偽情報スマソ。

一応、Retroweaverを使えば可能なようだが．．．
Retroweaver supports most 1.5 features while running on 1.4.
* generics
* extended for loops
* static imports
* autoboxing/unboxing
* varargs
* enumerations
* annotations

JDK1.4でコンパイルされたライブラリを、
JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．．
というかこれが無理なら何のためのerasure方式採用なんだよって感じだが。
264 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 16:02:53 ]: >>261
-target jsr14 だっけ？文書化されてないんだよね、これ。
265 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 16:05:35 ]: >>263
> JDK1.4でコンパイルされたライブラリを、
> JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．．
可能っちゃ可能だけど、パラメタ型の情報無いよ
266 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 16:14:57 ]: >>264
-target jsr14を使うと可能でした。ｔｈｘ。

Java の理論と実践: Java 5 の言語機能を以前の JDK で使う
www-06.ibm.com/jp/developerworks/java/library/j-jtp02277.shtml

列挙型以外はほぼ問題ないようだ。
267 名前：デフォルトの名無しさん mailto:sage [2007/08/09(木) 17:24:49 ]: >>266
JDK5以降のライブラリや、メソッドを使うときに注意。
Autoboxingなどはちゃんと処理される。
268 名前：デフォルトの名無しさん [2007/08/10(金) 01:25:21 ]: win32 apiとか触るの面倒だし、だれかjvm上で.netが動くの作ってくれないかな
C＃をインタプリタ実行するのでもいいからさ
269 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 01:26:53 ]: >>268
それはそれで凄まじいな

……考えてみるか。
270 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 01:51:45 ]: C# を Java バイトコードにコンパイルする方が楽じゃない？
271 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 02:08:05 ]: エスケープ解析は、*.javaに対して行っておくほうが実行効率がいいけど、その情報を*.classに残す手段がないので、実行時の最適化でしか使われていない
272 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 02:12:52 ]: >>249
>>247だが、実際にソースまで追って確認したわけじゃないので
そういう表現になっただけで、JITコンパイル段階でやってるのは
ほぼ間違いないよ。まあ、厳密に言えばインタープリタモードでも
やってる可能性もあるけど、メリットが考えられない。
273 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:03:50 ]: 手段がないわけじゃないと思うけど。
stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。

ただ、静的に解析しても効果が弱いと思う。
メソッドの非仮想化やインライン展開を終えた後にやる方がいい。
274 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:17:31 ]: >>273
それは、メソッドの非仮想化とインライン展開がエスケープ解析に与える影響がすごく大きいってこと？
そうは思えないんだけど。
275 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:46:33 ]: >stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。

これは上で出てきたstructをJava言語でサポートするんじゃなくて、
JVMでサポートするってのに実質的に近いんじゃないか？
276 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 03:55:03 ]: >>274
例えばさ、

public Object[] foo()
{
Vector v = makeVector();
v.add("bar");
v.add("hoge");
return v.toArray();
}
public Vector makeVector()
{
return new Vector();
}

みたいなコードがあったとするじゃない。 (例がやや作為的だけど、そこは目を瞑っていただきたい。)

いっけん v は foo の外にエスケープしてないように見えるけど、add とか toArray とかの中で this をどこかの static 変数に保存しているかもしれない。
誰も Vector クラスのソースを見たことあるわけじゃないし (あるかもしれないが)、 Vector がそういう変な実装になってないとは断言できまい？
そういうわけで、この時点では v をスタック上にアロケートしてしまうわけにはいかない。
(this をどこかの static 変数に保存したりできなくなってしまう。スタックは foo を抜けたら消滅するんだし。)

でも add とか toArray とか makeVector とか Vector コンストラクタを全部インライン展開できれば、v が foo の外にエスケープしてないかどうかがはっきりする。
エスケープしてないと判れば、もう別に Vector を new する必要なんかなくなって、 Vector の全フィールドをみんなスタック上に展開してしまえる。

makeVector は final じゃないから実はオーバーライドされてて他のクラスを返してるかもしれないが、これも非仮想化されてればインライン展開できる。

・・・って思ってるんだけど、現実のJVMがどこまでやってるかは知らない (´･ω･`)
277 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 04:44:16 ]: >win32 apiとか触るの面倒だし
ここらへんあるから実質C#はマルチプラットフォームじゃないよね。
278 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 09:53:41 ]: >win32 apiとか触るの面倒だし
それだけだったら、win32 api を触らなくて済むようなGUIフレームワークとかを使えばいいだけと違うん？
279 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 09:56:34 ]: >>273
> ただ、静的に解析しても効果が弱いと思う。
> メソッドの非仮想化やインライン展開を終えた後にやる方がいい。

二行目は静的/動的と関係ないじゃん。
280 名前：278 mailto:sage [2007/08/10(金) 09:57:41 ]: って、.C# か・・・じゃあ GTK# とか・・・びみょかな・・・
281 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:35:35 ]: >>279
静的に＝.javaのコンパイル時にって意味で書きました
.javaコンパイル時に非仮想化・インライン展開とかできないでしょ
わかりにくくてごめんなさいね
この暑さでちょっと疲れてるんだ
282 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:49:09 ]: 出来ないことないじゃん。もうInner classあるんだから。
283 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:54:25 ]: Inner class って、なんか関係が？
284 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 11:59:12 ]: インナー・クラスの非仮想化・インライン展開はソース・コンパイル時に出来る。
285 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:21:17 ]: --- Outer.java ---
public class Outer {
class Inner {
int foo( ) { return 1; }
}
void bar( Inner inner ) {
System.out.println( inner.foo( ) );
}
}

インナークラスってこういうのでしょ。
inner.foo( ) をインライン展開するつもり？

--- Main.java ---
public class Main {
public static void main( String[] args ) {
Outer outer = new Outer( );
Outer.Inner inner = outer.new Inner( ) {
int foo( ) { return 2; }
};
outer.bar( inner ); // → 2 を出力する
}
}
286 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:42:11 ]: そもそもprivate:ならインライン展開し放題じゃない。
287 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 12:45:06 ]: それはまぁね。
288 名前：デフォルトの名無しさん [2007/08/10(金) 17:18:14 ]: で、実際デフォルトで（知らないところで）インライン展開はされているのか？
それも、メモリ上に展開なのか、ソースコード（.class）のバイト数が増加しているのか。
289 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:20:42 ]: > で、実際デフォルトで

（　ﾟдﾟ）ﾎﾟｶｰﾝ
290 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:45:00 ]: はいはい、あげあし君はさようならで
291 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 17:58:23 ]: 似たようなことを議論してるよ。
stack allocateについては、
アノテーションで指示するか、
ByteBufferでアドレッシングしてくれってことのようだ。
bugs.sun.com/bugdatabase/view_bug.do?bug_id=4820062
292 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:31:07 ]: >>291
そこの議論の対象はC/C++の struct で作られたような
データ構造にアクセスする事であって、
言語仕様的に stack allocated object が欲しい場合は
bugs.sun.com/bugdatabase/view_bug.do?bug_id=4213096
bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809540
どっちかにvoteしろって書いてあるよ
293 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:35:28 ]: C# だと各メンバに FieldOffset が指定できるよね
>>291 はそういう話じゃないの？
294 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 18:54:29 ]: >>292
で、君はそっちのREFをチェックしてからものを言ってるわけなのかな？
>>293
C#がどうしたって？
ざっとみてスタックがどうとか言う議論になってたから似たようなの出してみたのだけど。
295 名前：デフォルトの名無しさん mailto:sage [2007/08/10(金) 19:02:35 ]: いや、データをバイト列にパックする話とスタックアロケーションは別の問題だから。
296 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 03:07:02 ]: 君の都合にあわないからといって、いちいち相手にｹﾁをつけるところは君の悪い癖だな
297 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 16:11:19 ]: なあ、全員「デフォルトの名無しさん」じゃねえか
同一人物間でケンカ自演してるのってどうよ

って突っ込んでるオレも同一人物な訳だが
298 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 16:22:00 ]: 夏休み的なツッコミだな
299 名前：デフォルトの名無しさん mailto:sage [2007/08/11(土) 19:00:47 ]: ボケだろ、ボケ
300 名前：デフォルトの名無しさん mailto:sage [2007/08/13(月) 15:24:33 ]: ノリツッコミか
301 名前：デフォルトの名無しさん mailto:sage [2007/08/18(土) 04:47:25 ]: JDK7 build18
download.java.net/jdk7/changes/jdk7-b18.html
download.java.net/jdk7/binaries/

細かいバグ修正とか。
302 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 07:15:13 ]: java LnFっていずれocanからSwing new LnFと謳ってるNimbusになるのかね？
303 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 08:19:46 ]: Nimbusはスクロールバーがヤだ
304 名前：デフォルトの名無しさん [2007/08/19(日) 15:38:42 ]: 確かにへぼいな
305 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 16:52:27 ]: javaのスレでC#の話をするなボケども
306 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 17:31:28 ]: JSR 310ってどうよ
307 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 19:22:01 ]: >>302
Nimbusはごっつい雰囲気が強すぎて微妙ー
Aquaとかみたいな甘いデザインにしてくれと思う。

>>306
各所のブログでJSR 310は入れてほしくないと言われているな。
どうなんだろう・・・
308 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 19:34:49 ]: 使うことはあまりないだろうな。
309 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 20:46:56 ]: >>306
オレは JSR-310 スライドに入ってる

> What's wrong with Date?
> ・Uses two digit years from 1900
> ・January is 0, December is 11

のセンスを見て、なんだかなーと思った。
この辺って、たぶん Cの標準ライブラリの
struct tm と同じ方式になってるだけでしょ。
きちんと文書化してあれば大して問題になるとも思えんし……
310 名前：デフォルトの名無しさん mailto:sage [2007/08/19(日) 21:28:31 ]: >>306
https://jsr-310.dev.java.net/nonav/javadoc/index.html
311 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 17:49:33 ]: >>309
いや、正直、1月が0とかは文章にしていてもあり得ない。
使うたびにAPIをその仕様で設計したヤツに殺意を覚える。
ライブラリの使い方からCと違うんだから中途半端にわかりにくくしてるだけ。
312 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 18:02:22 ]: 文章化してあるから問題なしって・・・
313 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 18:56:22 ]: >>311
分かりにくいっても、C言語使った事あれば1月が0になる事もあるってのは予測可能だし。
不勉強な上に不注意な連中が躓く原因であるのは確かだろうけど、
たぶん、そういう連中は月フィールドが 1オリジンになったら Calendar と互換性なくなって躓くだろう。
ゼロから新しいAPIを作るならともかく、既存の Calendar と共存するつもりなら、
新しいクラスを作って、そのクラスの月フィールドを 1オリジンにしたぐらいじゃ幸せにはなれない。
314 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 19:37:12 ]: >>311
まぁ有り得ないとか殺意を覚えるってのは程度の差だからなんとも言えんけど。

オレとしては 1月を 1 にしたければ、とりあえずユーティリティメソッド1つ作れば良いと思うんだわ。
で、オレの感覚からすれば、ユーティリティメソッド1つで解決するような問題を掲げて
わざわざ新API作ろうって感覚の方が有り得ないんだわ。
スライド見て感じた事ってのはそーゆー事。
315 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 19:43:10 ]: 今から新しく作るんなら、enumにすればいいんじゃまいか。
public enum Month { JANUARY, FEBRUARY, ... }
316 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 21:05:04 ]: そして旧暦閏月で困ると。
317 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 21:21:43 ]: 閏月対応してるクラスってあったっけか？
318 名前：デフォルトの名無しさん [2007/08/20(月) 23:19:30 ]: Timeの方は刹那とかに対応しないかなと思ってみたりｗ
10^-18なんて精度表せないだろうが。単位として扱えたら面白そう。
319 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 23:25:25 ]: 誰が使うんだ、そんなもん……
320 名前：デフォルトの名無しさん mailto:sage [2007/08/20(月) 23:41:02 ]: ナノ時間取得はコストが高すぎるんだよな・・・
321 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 01:23:50 ]: >>319
坊さん用ソフト開発なプログラマｗ

24時間=30牟呼栗多=900臘縛=54,000怛刹那=6,480,000刹那という変換するとか。

スウォッチインターネットタイムも欲しいな。
322 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 01:33:32 ]: 坊さん用なら卒塔婆プリンタの方が喜ばれそうだが。

っつか、Wikipedia漁って適当な事言ってるだけじゃね？
323 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 08:50:41 ]: www.atmarkit.co.jp/news/200708/20/httpcomp02.png
　同じくフォーチュン1000企業のWebサイトを対象とした調査で、
アプリケーションサーバのシェアはASP/ASP.NETがトップで51.5％のシェアと2年前から7.9ポイントの上昇。
J2EE、JSP、WebLogic、WebSphere、TomCatなどのJavaプラットフォームが2位で12.7％。
そのほか、PHP（6％）、ColdFusion（3.2％）、Perl（1.9％）、Python（0.2％）などとなっている。

とりあえず、ASP.NETの普及が断トツに進んでいる。
Javaは新規プロジェクトで採用される可能性はほとんどなくなってきてるしな。
324 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 09:53:51 ]: そろそろJava終了のアナウンスがSunからあるのかな
まぁいい思い出になったよ
325 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 10:20:43 ]: >>323
ASPとASP.NET合計で51.5％か。意外に低シェアだな。

>>324
Sunあぼーんして、IBM & Google が実権を握ってくれる方が嬉しいなぁ。
326 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 10:23:58 ]: >>315
一応、Calendar.JANUARYとか定数ならあるよ。
そっち使うでしょ普通。
327 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 10:24:54 ]: あ、そっち使うでしょ、ってのは0とか1とかじゃなくて、って意味。
enumならなおよろしいけど、互換の問題がねぇ・・・。
328 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 13:37:56 ]: >>327
日付扱うときは、だいたいユーザー入力だから無意味。
プログラム中でJANUARYとか指定することなんてあまりないんじゃね？
329 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 16:31:57 ]: ユーザー入力を文字列として持ち回すと難儀だよね。

でも、WEBアプリにしろSwingにしろ、フレームワークとか
日付入力コンポーネントとかでDate型で最初から
扱える奴あるし、今時大概そうじゃないのかな。

プログラムの中で月決め打ちってのは確かにあまりないですね。
テストコードくらいか。
330 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 17:51:54 ]: >>314
いや、ラッパークラスを用意すればいいってのはユーザ側の対応になる。
それはつまり、現状のDate型の変更に依存する訳だし
自分が書いたコードはラッパークラスを必ず含まなくてはならなくなる。
それならコアAPIに入っててくれよ、と思わないか？

今のDate型の実装だと、実装者自身が作り直したいと考えても
仕方がないような作りが多々ある。Calendarを追加して手当したけど
時間、日時を扱う場面は多くある。
これだけJavaが使われてその問題点が明らかになったんだから
新しくより合理的なAPIができてもいいと思う。
言うなればJava3とでもいうものへのへの緩やかな変化。

基本的なモノだからこそ改良が重要になってくるとは思うんだ。
アトは失敗しないようにしっかりと作ろうってところだろうか。
331 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 18:15:12 ]: Calendarいらないってがんばっている人もいる。
tp://d.hatena.ne.jp/nowokay/20070628
tp://d.hatena.ne.jp/nowokay/20070630

これが本当に通ってくれれば
憂いなしで嬉しいな。
332 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 18:29:39 ]: つか、きしださんまで月間違ってるし！
333 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:05:53 ]: >>330
ラッパークラスで解決しようというのはダメだろ。
Calendar の set やら get をラップして 1月が1になるようにしても、
自分の目の届く範囲だけなら構わないけど、
第三者が作ったクラスに渡す場合には、そのまま渡したら 1ヶ月ずれる。
そんなゴミをコアAPIに入れられたら、 Calendar をやり取りする
メソッド作る場合に、必ず instanceof とかでチェックしなきゃいけなくなる。
334 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:08:21 ]: >>331
無理じゃね？

java.util.Date は Serializeable だし、
Date の TimeZone対応とかやったら、
シリアライズされたデータの互換性なくなるんじゃないか？
335 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:10:30 ]: W3C-DateTimeからRFC2822-DateTimeに用意に変換できるようなものが欲しい。
RFCのほうはCWFSのおかげでやたらパースがしにくい。
336 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 19:23:34 ]: >>330
> これだけJavaが使われてその問題点が明らかになったんだから
> 新しくより合理的なAPIができてもいいと思う。
あっても良いけど、closure とかに比べると優先度は低いよね。

それに「問題点」ってのも個人個人で違うわけで、1月が 0 なのがダメなのか、
setter の戻り値の型が void だから、1行に詰め込んで書けないのが問題なのか
それ以外なのか。

現状では愚痴とか不満は出てるけど、
それらを一つに纏めて、多くの人が納得でき、多くの人が幸せになれるような
解決策が提示されているかっていうと、少なくとも JSR-310 は違うと思う。
337 名前：デフォルトの名無しさん [2007/08/21(火) 20:22:16 ]: >>335
まえにjavascriptの実装がどっかのブログで公開されてたぞｗ
338 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 22:16:24 ]: >>336
いや、JSR-310はまだ固まってないし。
そういう動きがある、ということしか言えないと思う。
なんで、これからの頑張り次第でしょ、という話。

それとも、「日付関係の新しいAPIは要らないぜ」という話？
339 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 23:24:14 ]: >>338
1月が 1 と書けるようになっただけ、の Calendar みたいなクラス作られても
あっちのフレームワークでは互換性のために旧Calendar要求され、
こっちのフレームワークでは機能性のために新API要求され、
みたいに手間が増えるだけになる可能性が高い。

かと言って、Calendar が解決しなかったニッチな要求のためだけのAPI作ったら
わざわざ標準APIに突っ込む必要ないって話にもなるし。

既存のDate＆Calendarがある状況で
日付関係の新しいAPIを作るのは凄く難しいと思ってるんだけど、
1月が 0 なのがキモイみたいな事かかれると、
マトモなものが出来るのか心配になるって話。
340 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 23:27:03 ]: 動画再生用のSwingコンポーネントが標準化されたりしたら嬉しいのだけど、
JavaFX Scriptに合わせて対応してくれたりせんのかねぇ。
Flashは次のバージョンでH.264にも対応するとか発表してるし、
本気でRIA市場に乗り込むならここらへんを抑えてくれないと支持しにくい。
341 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 23:36:53 ]: つ JMF
342 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 23:38:58 ]: JRE以外にインスコしてもらえるわけないじゃんｗ
343 名前：デフォルトの名無しさん mailto:sage [2007/08/21(火) 23:51:58 ]: jarに全部突っ込んでマニフェストでパス指定するか。JWSでいいだろ。

けどJMFのH.264コーデックがまだIBMのプロプラライセンスものしかなかった気がする。
344 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 09:04:57 ]: >>339
相互変換はコンストラクタ一発なんだから問題ないんじゃね？
345 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 09:09:49 ]: SilverlightやFlashに比べて、JREはインストール面で不利すぎる気がするのですが
軽量プラグインとか出す予定はないのでしょうか？
346 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 09:24:14 ]: 何を削るかで揉める事必至だろうなぁ・・・
いっそのことJ2MEのランタイムを作ってそれを軽量プラグインにするとか
347 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 11:31:10 ]: 分割ロードの方が良さそうだなあ。
Javascriptは何でも一つのファイルにぶち込むのが流行ってきているけれども。
348 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 14:09:41 ]: >>345
Java Kernel と呼ばれているものを jdk6 update 4 で出す予定

weblogs.java.net/blog/enicholas/
weblogs.java.net/blog/forax/archive/2007/08/java_kernel_in.html
349 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 14:24:44 ]: >>344
Date と Calendar はコンストラクタ一発で変換できてないじゃん。

それと同じ事が起こる事は十分予測可能。
350 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 14:30:23 ]: >>349
っつーか、コンストラクタ一発で変換できても煩雑なのは変わらんのだがな。
351 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 20:01:17 ]: ”よく知られた日付型”がこれ以上混在されてもうざいだけだよ。
DateにCalendarにsql.Dateと、”よく知られた日付型”は、もう既に食傷気味です。
所詮は64bit unix epocと割り切ったユーティリティメソッドが拡充される方がよほど嬉しい。
352 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 21:21:02 ]: なるほど。
良くあるパターンに特化したユーティリティメソッドを用意してくれる方が
ありがたい気がする。
353 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 21:49:03 ]: JREのインスコなんてウィザードに従えば良いだけだろ。
それより、システム管理全体がside by sideへ以降してきてメンテにエンドユーザーの負担が掛かってると思う。
354 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 01:19:58 ]: JSR 310はいいと思う。
ユーティリティ・クラスとしても上出来。
355 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 03:08:43 ]: >>354
そうなん？

>>310 に JSR-310 のAPIリファ来てるけど、
これどんな時に便利なのかサンプルコードとか書いてくれん？

っつか、オレには Moment や Period のサブクラスが
年、月、日、時、分、秒と分かれてる必要性がイマイチわからん。
356 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 04:03:13 ]: タイムベースの処理が必要でそのフレームワークを自前で作らなきゃいけないときに下のライブラリとして使えそうだな。
357 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 04:06:51 ]: >>310がJSR-310のリンクになっていることに
今になってようやく気が付いた。

なんか黄色ナンバーの車を1日10台見たとか
ワーゲン見たとかその程度にちょっと幸せ。
358 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:11:21 ]: >>355
ぶっちゃけ、>>310より>>331の方が良いと思う……
359 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:43:24 ]: >>356
逆に言うと、それ以外の目的に使えなさそうじゃね？
360 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:46:22 ]: どっちがいいとかそういうもんじゃないだろ。
310はベースとなる時刻クラスを提供するんだから。
361 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:49:25 ]: 今のままだったら Date ＆ Calendar の方が下位層で
JSR-310 はそれに乗っかるだけの上位層になりそうだが
362 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:50:20 ]: （　ﾟдﾟ）ﾎﾟｶｰﾝ
363 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:52:26 ]: おまけに使用用途が酷く限定されている、と。
364 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 09:01:34 ]: >>360
んじゃ言い直そう。

JSR-310 のスライドにあがってる、
What is wrong with Date and Calendar?
の解決策としては、今のところ>>331の方が良さそうに見える。Date の
Could not be successfully localized とか Most methods deprecated、
SimpleDateFormat の Calendar cannot be directly formatted
は解決できそうだ。
365 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 09:25:39 ]: >>360
310が提供するベースとなる時刻クラスってどれよ？
366 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 11:36:39 ]: 文字列からのファクトリメソッドは、
別クラスにした方がいいんじゃないの？
L10N考えると劇重プロジェクトだし。

GNU dateコマンドみたいな時間指示を考えると、やること一杯ある。
367 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 11:46:17 ]: これはひどい

ベースとなる時刻クラス・・・ Instant かねぇ
でも CalendarDay や TimeOfDay との相互変換はできそうになく
既存の Date や Calendar との繋がりもない
どうやって使うんだこれ
368 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 00:25:02 ]: 310はまだ、かなりドラフトな感じだが、
PeriodとMomentとその実装クラスを細かく分けるのは、
安全でかつ読みやすくなるのでよいと思う

例えばMomentにMomentは追加できないがPeriodは追加できるとか
369 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 01:23:17 ]: Instant と fully defined な SingleMoment を区別する理由と、
Period と Interval を区別する必要とか、
Duration とか良く分からん。
Duration と Inteval はまだ出来てないみたいだけど。

>>368 も同意っちゃ同意なんだけど、
それって Moment と Period が別になってる理由にはなっても、
Moment や Period のサブクラスが年、月、日、時、分、秒と
細かく分かれてる理由にはならんよね。
370 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 01:58:25 ]: >> 369
>Moment や Period のサブクラスが年、月、日、時、分、秒と
>細かく分かれてる理由にはならんよね。
なんで?
Days days = ...;
days = days.plus(Days.days(3));
とか具体的な型が決まっていたら安全かつ読みやすいじゃん。

しかしメーリングリストだとなんかいろいろ提案とか出されたり、まだまだな感じがしてきた。
sunの中の人が書いてるが、
blogs.sun.com/yk/date/20070705
既存のAPIとの互換性とか国際化も考えると大変そうだね。
371 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:02:32 ]: >>369
後者については type safe のためとか？

もしくは、
Moment moment = build(dayOfMonth(1), hourOfDay(3));
とかやると、毎月 1日午前 3時をあらわすようになるとか……
372 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:05:26 ]: >>370
おいおい……

一見型安全かもしれないけど、
それだけだと、逆に Period で 1カ月と3日とか複合的な指定できなくなるんですけど……
373 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:10:03 ]: >>371
あぁなるほど。可変長引数のビルダーメソッドで纏めるとか
そーゆー場合には別々のクラスになってないとダメだな。

>>370
これはひどい
374 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:34:16 ]: >>372
Periodとしての一ヶ月というのは日数として組み合わせて扱えない気がするが。
375 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:37:46 ]: （　ﾟдﾟ）ﾎﾟｶｰﾝ
376 名前：374 mailto:sage [2007/08/24(金) 02:48:29 ]: 今のAPIを見る限り、複数のPeriodを組み合わせたPeriodというのはない気がする。
Monthsに関しては月によって日数は変わるので、months.plus(Days.days(3))みたいな計算は書けないと思うが。

しかしCalendarDayはplus(Period...)というのを持ってるので、一ヶ月と3日後とかを計算できると思う。ただMinutesとSecondsとの変換とかできそうな気がするのにできないように見えるのはよくわからない。
377 名前：デフォルトの名無しさん [2007/08/24(金) 02:51:08 ]: >>372
そーゆーのは、まだない Interval でやるって話なんじゃね？

しっかし、凄く分かりにくい API だな、これ。
そこそこ経験がある奴でもサンプルコードが無いと一行も書けないぞ。
378 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:55:09 ]: >>373
instanceof で比較するところを enum と switch で置き換えれば
良いだけだから、別々のクラスになってる必要は全くなかったりする。
379 名前：374 mailto:sage [2007/08/24(金) 03:03:40 ]: やっぱりわかりにくいのだろうか?

変換とかファクトリとかのメソッドがどこにあるかわからず、分かりにくい、というのはあるかもしれないが、
そもそも日付と時間の長さなどを区別して扱うこと自体が複雑で、結局intとかで扱っても値の種類を把握していないといけないのでは。

ある程度、単位を型でエンコードして分かりやすくすることで安全で読みやすいコードになる方がよいと思うのだが...
380 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 05:59:11 ]: Sun が NASDAQ での銘柄記号を SUNW から JAVA にかえるんだそうな。
blogs.sun.com/jag/date/20070823
blogs.sun.com/jonathan/entry/java_is_everywhere

いや、次世代Javaと関係ないけど。
っつーか、これジョークじゃないの？ 4月1日じゃないけどさ。
381 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 07:09:27 ]: Dateみたいな基本的なところに今から手を入れるのがアリなら、
Numberもどうにかしてくれんかな。
やっぱり Integer inherits Double であってほしいし、BigDecimalで
持っている四則演算メソッドはNumberすべてで使いたいが。
382 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 07:17:34 ]: >>380
JAVAの株があがったとか下がったとかが問題になってくるわけか。
そしたら、JAVAと大文字で書くやつはJavaのことを知らないという伝説が強くなるわけだ。
383 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 07:43:01 ]: >>381
Numerics関係は難しいんだよな、後からいじるの。
非互換の影響が大きすぎて。

仕様お目付け役だった、Guy Steeleさん、この辺が弱い。
384 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 16:04:46 ]: 元がSUNWならJAVAWにすればいいのにコンソール出ないし・・・。
385 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 16:57:17 ]: >>381
メソッド追加はありでも継承関係は変えられないだろうな
386 名前：デフォルトの名無しさん [2007/08/29(水) 21:26:22 ]: そろそろ deprecated のクラスやメソッドを一掃してほしい
387 名前：デフォルトの名無しさん mailto:sage [2007/08/29(水) 22:30:24 ]: Cloneable を Clonable に直してほしい
388 名前：デフォルトの名無しさん mailto:sage [2007/08/30(木) 02:13:33 ]: creat....
389 名前：デフォルトの名無しさん mailto:sage [2007/08/30(木) 23:47:25 ]: catch必須例外を堂々と無視できるプラグマを追加してほしい。
390 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 03:25:48 ]: アホか例外処理の意味ないだろ。
握り潰すことすら面倒くさいか？ｗ
391 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 12:32:21 ]: JDK7 build19
ttp://www.java.net/download/jdk7/changes/jdk7-b19.html
ttp://download.java.net/jdk7/binaries/

forumで話題になっていた
4811096 Allow mixing of heavy and lightweight components
が入った様子。
SwingとAWT混ぜるなっていうのが古い話になるわけだ。
あと、レポジトリ管理、Teamwareを完全撤廃？SCCSキーワードの削除ってのが結構あった。
公開してるのも、Subversionでだしね。OpenSolarisで採用してる、Mercurialはないんだろうか？
392 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 21:15:56 ]: >>390
めんどくさい。
どうでもいいコンソールプログラム書くときは
全部例外がトップレベルに流れて死んでくれていい。

あと、どうせならインタフェースの実装も堂々と無視できるプラグマも欲しい。
適当にnullとか0とかfalseとか、あるいはNotImplementedException投げるとか。

IDEにやらせればいいんだけどさ。
393 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 21:52:53 ]: >>392
お前はCの方が合ってるんじゃないか？
つーかその程度の捨てアプリならスクリプトで実装すれば良いだけじゃん。
394 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 22:32:46 ]: mainメソッドにthrows ExceptionってすればOK
395 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 02:07:00 ]: Javaの例外処理の面倒くささはMatzがどっかで言及してたね
396 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 02:21:10 ]: silentClose(Closeable) みたいなメソッド作るとか
使い捨てアプリ作る時は throws Exception つけるとかすれば
そこそこ改善すると思うんだけどね
397 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 02:29:38 ]: >>395
むしろその例外処理の面倒さがないからこそ
他の言語があぶなっかしくて使えない。
コード品質重視だと特に。
398 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 06:37:06 ]: むしろ投げる例外をdoc,code上で明文化されてないと何拾って良いか分からないだろ。拾えないと例外に対処できない。

throw,throwsでthrowable以外が飛んでくるのもおかしいし。
399 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 16:45:03 ]: ExceptionはThrowableである。以上。
400 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 09:52:45 ]: 例外処理の仕組みが問題というよりも
IOExceptionとかSQLExceptionのようなレベルの例外を
チェック例外にしてるのが問題だと思う
SpringやS2やHibernateなら、これらの例外をランタイム例外にラップしてくれるし
JavaEE5ではランタイム例外を多用してるけど
肝心の、JavaSEのコアなAPIがチェック例外だらけだからな

>>397
現実には、Javaのチェック例外記述のめんどくささに嫌気がさした開発者が
catch (Exception e) {
e.printStackTrace();
}
とか書いて、返って品質悪化するパターンの方が高い気がするorz
401 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 11:41:41 ]: あと InterruptedException も握りつぶされて困りやすいチェック例外だ

あー
InterruptedIOException とか、きっと知らんうちに IOException もろとも握りつぶしてる気がしてきた

try {
......
} catch (InterruptedIOException e) {
Thread.currentThread.interrupt();
} catch (IOException e) {
......
}

なんて、書いた覚えがないよ
402 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 11:50:49 ]: 例外のためのEffective Javaみたいなのがあれば読んでみたい。
こういうのはお習字の世界だから仕様としてどうこう変えるもんでもないし。
403 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:29:09 ]: >>400
IOExcepotionとかは>>396みたいなメソッドがあれば解決する問題

後半に関して言えば
そーゆー奴は面倒くさいので例外処理しないし
他人のために必要な例外関連のドキュメントも書かない
ので検査例外をあってもなくてもそれほど品質は変化しないと思うが
404 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:39:45 ]: 何が言いたいのやら・・・必死なことだけは解るが
405 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:48:59 ]: IOExceptionやSQLExceptionがチェック例外なのは当然だろ？
外部リソースに依存してんだから、チェックし無い方がどうかしてる。
DAOならそれらをcauseにして、DAOExceptionみたいに新たなチェック例外にくるむがよろし。
406 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:55:57 ]: closeが例外なげるバカなAPI
407 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:04:03 ]: close は flush を伴うからエラーが発生する可能性はある
408 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:07:19 ]: closeが例外なげるのがバカってどんだけゆとり脳なんだ
409 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:14:18 ]: 思うに、チェック例外をキャッチしないと
警告出すだけの仕様だったらどうなっていただろうか？
410 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:26:33 ]: throws SQLException って書いてないのに throw new SQLException() するような
混ぜるな危険メソッドが書き放題で検査例外の意味がなくなる。
それでいてソースに SuppressWarnings("ignorecheckedexception") とか
コンパイル時に -ignorecheckedexception とか必須だと手間がかかるだけ。

中途半端で役に立たないソリューションの見本だな。
411 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:30:17 ]: んなもんソースレビューで片付けろよ
412 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:44:28 ]: closeが検査例外を投げるバカなAPI
413 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:49:51 ]: >>411
第三者の作ったライブラリやフレームワーク使う時は
それらも全部ソースレビューすんの？
414 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:51:10 ]: 必ずソースが見れるとは限らんし
415 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:05:42 ]: >>405
IOExceptionとかって多くの場合リカバリできるの?
リソースの解放はfinallyでやるからチェック付き例外とは関係ないと思うし

なるべく例外がチェックできるべきだという意見は多い様に見えるが、一般的にそれらの例外がほとんどリカバリできる処理を書けないならば >>400の言うようにAPIの設計の問題では?
416 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:10:27 ]: ソケット使って読み書きしてる時にIOExceptionが発生したらリトライするとかあるよね
417 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:53:29 ]: >>416
そういう特定の事情のために、すべてのIO処理で面倒なコードを書かないといけないのはアホ
418 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:56:09 ]: というか、例外が出ないコードで例外の補足が必要になるのが、設計ミス
System.in.read()
とか
419 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:57:17 ]: 面倒っても、throws IOException を宣言するくらいのもの。
その場で対処しない例外は上へ送る。
420 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:02:53 ]: System.in.read() ってプラットフォーム側の標準入出力の実装方法によっては
例外が出る可能性があるんだが
421 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:10:33 ]: 俺としてはNumberFormatExceptionが実行時例外なのが許せないくらいなんだが。
外側のことは一切信用しないという性悪説プログラミングが心情だとね。
422 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:18:48 ]: 俺はUserTransactionのメソッドを使ってみたとき、
Javaのチェック例外は、API側が使い方を根本的に間違ってると痛感したよｗ
423 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:24:01 ]: >>412みたいな事を言う奴から間違ってると言われても
424 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:31:07 ]: >>419
それで上へ送った例外は結局どうなるわけ?
throws IOExceptionをまき散らして、
RuntimeExceptionになるか握りつぶされるぐらいじゃないの?

>>421
一切信用しないというのはいいが、それはどうやって処理される?
他の値で代用するのは多くの場合問題がある気がするし、
再度入力を促すことになると思うが、
可能な場合と不可能な場合(処理を中断するしかない場合)があると思う

...NumberFormatExceptionに関しては微妙な気がしてきた
RuntimeExceptionでよい場合も多いと思うが...
425 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:54:22 ]: 最近じゃ例外もAOPで処理するし、リソースはfinallyで閉じるからあまり関係ないしな
matz氏がブログで、例外をぎりぎりまで捕捉しないのがRuby流って書いてたけど
結局はそれがいちばん効率的で、開発者に都度catch処理を強制するよりも品質が上がるんだよね。
例外処理がなくても、異常終了で落ちるからテスト時にすぐわかるが、
catchで不用意に握りつぶされた例外はやっかいだし
426 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 17:06:07 ]: 何層か下のフレームワーク/ライブラリが投げてくる実装依存の例外もやっかいだけどな。

面倒くさいから検査例外は無い方が良いとか考えてる奴は、
例外関連のドキュメントなんて書かないから品質ズタボロのコードを量産する。
427 名前：424 mailto:sage [2007/09/02(日) 17:27:46 ]: >>425
アプリケーション(基本的なライブラリでない)でのチェック付き例外は有用と見られているはずだ
アプリケーションレベルではリカバするべき例外を決めることができて、チェック付き例外で強制できる

アスペクトを使うことでIO例外をアプリの例外へ変換とかはうまく書けるが、
各メソッドごとの例外処理を常にうまく分離して書けるわけではない

テスト時にすぐわかるというのは理由にならないはずだ
再現が難しい例外だってあるから
それよりも発生したときなにもできないことが多いというのが理由だと思う
428 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 17:28:11 ]: なんか次世代関係なくなってね？
JAVAの例外について勉強するスレとかたててそっちでやれ
429 名前：デフォルトの名無しさん [2007/09/02(日) 18:30:35 ]: 例外処理が煩わしいのであれば、
例外処理を包含したテンプレートパターンを適用して処理すればいい。
APIは面倒か面倒じゃないかではなく、安全か安全ではないかが重要。

APIは極力安全に使えるように「馬鹿向け」に作られているが、
本当の馬鹿にはその意味すらわからないらしいｗ
430 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 18:57:24 ]: わずらわしいどうの以前にその例外をどう扱うべきかというパターン自体が俺みたいな初心者にはわからない
使われる側でチェック例外を投げてから使う側で遺言を言ったあとRuntimeExceptionでラップするとか、
キャンセルなどの特殊な状況を処理するために使うとか、なんだろうか
431 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 21:40:59 ]: 捕捉する場所によって扱い方も異なるとしか言い様がないな。
ライブラリ書いてるなら、抽象的な例外でラップして投げなおすだろうし。
フレームワークならコントローラで一括処理で、それ以外では全部投げっぱなし。
432 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 21:49:00 ]: 個人的にはチェック例外＝病気の診断、ランタイム例外＝安楽死とか思ってる
で、今直せる見込みのない病人がいるとして、いろんな病院をたらいまわしたり（チェック例外のままthrowsしまくる）、
病気ではないとして放置したり（例外を握りつぶす）、
秘密裏に抹殺したり（System.exit(0)）、
するよりはランタイム例外にして安楽死させたほうがいいような気はするんだけどな。

でもそのあたりの常識やパターンやガイドラインみたいなものがないと実際何をやっていいのか分からないし、
ttp://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.htmlとか見る限り、
今のAPI仕様でそれが完璧に行われているかというとそうでもない気がする。
どう診断すればいい医者であるか、と言う問題についてはもっと語られてもいい気がする。
433 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 00:54:17 ]: 病気になったら即安楽死＝良い医者だと？
434 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 00:56:05 ]: スレ誘導しようとしたらいつのまにか例外処理スレが落ちてた。
435 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 04:46:11 ]: >>420
その程度ならRuntimeExceptionで十分
436 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 07:58:03 ]: >>435
その程度なら throws IOException 書いておけば十分。の間違いじゃね？
437 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 08:17:25 ]: >>435
もっかい ttp://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.html 読んでくれば？
438 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 08:53:56 ]: >>432
ロッド＝ジョンソンの本の説明が出てるな
自分も彼のJ2EE本読んで、チェック例外に対する見方を改めた口だ
439 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 11:17:45 ]: 例外処理がもれなくSystem.exit(0)オンリーなソースを
押し付けられた俺涙目
440 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 11:21:35 ]: 例外処理が全部 System#exit(int) ってのもアレだが、
異常終了してんのに 0戻すってのも相当アレだよな。
441 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 11:36:48 ]: 終了するというコードが正しく実行できたので正常！
と。
曲がった先の信号が青だから曲がれる、という理屈に似てます。
>>439
まあ握りつぶされるよりはいいんじゃないか？

例外処理に関しては、パッケージ単位とか、今度出来るはずのモジュール単位で
包括して処理できる仕組みがあったら便利じゃないかなぁと思う。
442 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 14:31:16 ]: >曲がった先の信号が青だから曲がれる、という理屈
これめちゃくちゃ危ないんだが・・・特に内輪差考えないで突っ込んで来る馬鹿な大型車とか。
443 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 22:43:55 ]: >>439
脈絡ないけど、exit()の前にfree()は要らないってのを思い出してしまった。
444 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 23:43:03 ]: >>432
一理あると思うが、マルチスレッドの場合はランタイム例外もきちんと
捕捉しとかないと握りつぶしたのとたいして変わらないことになるんだよな。
そのへん整合性あるガイドラインならいいんだが。

あと、安楽死というからには本当はやっぱり後始末もちゃんとしておきたいところ。
445 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 14:32:56 ]: あのfree論争ってさ、
「とりあえずfreeはしておくべき」的な教条的理想論
「どうせ終了と同時にメモリ開放するんだからいいじゃん、っていうかfreeしたって実際何もしてないのとほぼ同じだし」っていう感じの現実論
って理解でいいんだよな？そりゃ永遠に話は平行線だ罠
446 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 14:37:30 ]: 例外ってさ、単純な入力ミスで出るようなはっきりいって例外処理までしてやりたくないようなどうでもいい例外か
出てる時点でもうもうどうしようもない例外が多いような気がする
447 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:06:10 ]: 外部からの入力ミスなら対処しないとダメだろ。

使い捨てアプリ作ってんなら、throws Exception 付けといて良いだろうし。
448 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:16:29 ]: >>445
マトモな奴は、free論争なんかする暇があったら他の事をやる。
449 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:25:06 ]: >>445
>>448 の2つに直交する「どっちでもええがな」論があって、これが現実解。
450 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:46:51 ]: parseIntで数字じゃなかったときの処理を例外でやんないといけないとか、ひどすぐる。
451 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:05:21 ]: >>450
なら、どうしたら良いと思う？

parseInt の戻り型を long にして数字以外なら int の範囲外が返ってくるとか、
parseInt の戻り型を Integer にして数字以外なら null 返すとかしても、
例外よりマシになるとは思えないけど。
452 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:11:43 ]: ＞parseInt の戻り型を Integer にして数字以外なら null 返す
それやるとオートボクシングしたつもりがヌルポになったりすっからなあ

isValidInteger()みたいなチェックメソッドを作ってやるとかどうよ。二度手間だが
453 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:15:34 ]: >>452
安全なコードを書くためにそのメソッド使った
if文を書くことを強制しないといけない。

ならコンパイラでチェックしてやろうというのが
検査例外な訳で。

どこまで人間を信じるかだな。
454 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:15:42 ]: > isValidInteger()みたいなチェックメソッド
なんという銀の弾丸
455 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:18:36 ]: int[] parseInt(String)
返値は
　{ パースした数字, エラーコード }

俺もparseIntについては何とかならないかと思ってた。
parseできないってのは、想定内の状況だからExceptionにするのはどうかな、と感じてて
例外と言うより１状況として扱いたいと思ってる。
ただ、上のようにしても何かしっくり来ない。

Exception以外に、例外状況をメソッドの返りで扱えるようになればいいな、と思う。
Exception処理が重すぎるというのが元凶なんだが、
RuntimeExceptionでないものに関しては
parseIntのように、stackTraceなんて重いものは要らなくて、
その場で処理してしまう例外状況って多いじゃないですか。

何とかならないのかなぁ。
言語構造的に、Throwable一本ってのが簡単なのは分かるんだが・・・
456 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:25:02 ]: >>453
＞if文を書くことを強制しないといけない。
ここに関しては
Nullチェックに対するNullPointerException
Iterator#hasNext()に対するNoSuchElementException みたいなRuntimeException派生を投げれば済むと思うんだけど
二度手間なんだよね。このチェック。
457 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:29:35 ]: >>456
hasNextはそのチェック自体が軽いからいいけど
parseIntは、parseしちゃってるからねぇ・・・二度手間ですよねぇ・・・・
458 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:29:50 ]: >>455
> parseIntのように、stackTraceなんて重いものは要らなくて、
> その場で処理してしまう例外状況って多いじゃないですか。

parseInt の場合だと、
・ユーザー入力を parseIntした場合はユーザー入力が遅いのでExceptionが重くても問題ない。
・ファイル読み込んでparseIntした場合、パースできないケースは例外を使うべき状況なので問題ない。
だと思うが。
459 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:33:25 ]: 自己レス>>457
あ。parse結果をキャッシュできればいいのか。内部で。
って、コトは、staticメソッドじゃ駄目だな。
Stringのインスタンスメソッドになれば何とかなる、という所か・・・・
460 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:35:35 ]: >>456
要するに、検査例外だと
コードがごちゃーとするのがやだから
実行時例外にして欲しいって事でしょ？

どっちにしろ、人間をどこまで信じるかだな。
461 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:37:04 ]: >>460
paeseInt の話なら、NumberFormatException は実行時例外だが。
462 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:44:43 ]: >>455
最近の言語であるみたいにJavaが多値を返せる言語だったら良かった
んだけどなあと思う。

(int, StatusCode) parseInt(String input)

とか。

ちょっとキモイが

interface ParseResult { }
class ParseSucceed implements ParseResult { }
class ParseFailure implements ParseResult {}

というクラスを用意して、ParseResult型の値を返すとかどうだろう。
463 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:48:13 ]: >>462
後半、ただのEnumでよくね？
464 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:48:49 ]: そんなややこしいことやるくらいなら Integer を返して null かどうかで判定できればそれでいいよ
465 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:52:55 ]: >>464
だからそういうのやるとコードの変なところでヌルポが出そうで怖いんだって
オートボクシングするだけで出るし正体不明のバグ増やすだけ
466 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:56:38 ]: じゃあ @CheckForNull 付加で
467 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:57:55 ]: >>462
StatusCodeチェックしない場合はパースに失敗してても intの値が得られちゃうし、
その上現状よりキモくなってるしで、あんま良い事ないんじゃね？
468 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:02:33 ]: >>462
多値を返すという話はだーいぶ昔からBugParadeでやられてて
話に参加してみたものの結局、やらないよーという結論。

まあ、どうしてもやりたきゃ、今は配列をつかえってところ。
それなら俺は、配列に違う型を含められるようにしてくれ、と思い・・・
でも、その場合型チェックはコンパイル時には難しいわけで
Objectの配列使うのと変わらないわけで・・・・
じゃあ、じゃあstructがあったらいいんじゃ・・・・っていうと、
アレ？それってクラスじゃね？と・・・・

型チェックが緩くてもともと実行時にしか型がきまらない
スクリプト型言語なら、複数返値も考えることあんまり無くていいんだろうけどねぇ
469 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:24:54 ]: >>468
いやいや。型に厳しい関数型言語(MLやHaskell)などでは、
昔からタプルという形で多値が扱えたから、それと同等の
仕様にすればいいだけだと思うんだがな。
470 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:28:34 ]: >>463
実装は省いたけど、ParseSucceed型からはパーズ結果の値を、
ParseFailure型からは失敗の原因を取得できるようにする意図が
あったので、ただのEnumだとよくない
471 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:47:44 ]: >>469
>>455 だと Exception重いからException使わないようにしようって話でしょ。
タプルとか使って正常系の処理も重くしたら意味無いんじゃね？
472 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:55:24 ]: >>470
パフォーマンス上の理由なら、そんなもんいちいちnewして返すぐらいなら、例外投げればいいと思う。
単にコードを簡潔にしたいだけなら、
static boolean parseInteger(String text, AtomicInteger out);
みたいなのをどっかに用意してやればいい。
AtomicIntegerは、他に標準でintを参照渡しできるインターフェイスが無いからなんで、
適当なintをsetできるインターフェイスならなんでもいいと思う。

コードを簡潔にするっていっても、結局正しくパースできたかのチェックは必要なんだから、
例外で十分でしょ。
473 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 18:06:05 ]: しかし事前チェックが出来ないにもかかわらず実行時例外を投げてよろしいものだろうか
同じく文字列を解析して取得するタイプのClass#forNameが発行するClassNotFoundExceptionはキャッチ例外だよね？
474 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:31:41 ]: >>472
パーズ失敗というのは、自分にとっては正常系の処理なんで
例外使うのは違和感があるんだ。感覚的な問題なんだけど、
Map<K, V>#get(K key)がkeyがエントリに存在しない場合に
例外を投げられると嫌なのと似た理由で。
475 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:35:55 ]: >>474の補足だけど、Mapから値を取得しようとしたときにキーが存在しない場合
というのは、正常系の処理であることが多いから、もしもJavaのAPIの設計が、
例外投げるようになってたとしたらうっとおしいだろうなあということ
476 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:44:31 ]: parseIntの場合も、本音で言うと多値よりnull返す方が良いと思ってる。ただ、
現状のJavaでは、nullを許容する/しないを型で表現できないという欠点が
あるので、微妙なところではあるけど。
477 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:46:57 ]: はぁ？
478 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:55:41 ]: C#のNullableは安易にstructをサポートしたがために招いた失敗仕様の名残じゃないか
オートボクシングでラッパーオブジェクトと用意に相互変換可能な現状で、んなもん無用の長物
479 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:53:06 ]: 使用できる範囲は限定されるが
int parseInt( String numberInString, int defaultValue )があればよかった。
パーズこけたらデフォルト値を返す。
480 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:55:44 ]: そんなに1行で書きたいんですか
481 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:58:55 ]: ラッパークラスに例えばisConvertable(String)みたいなメソッドがないのがねぇ。
2回パースするくらいなら例外でいいっしょｗｗｗｗｗｗって設計思想はちょっと。。。。
482 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:59:23 ]: >>479
ドトネトのTryParseだな。
ttp://www.atmarkit.co.jp/fdotnet/dotnettips/408tryparse/tryparse.html
483 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:06:09 ]: >>482
Javaだと参照渡しがないし、標準でmutableなintのラッパークラスも無いから作りにくい。
484 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:08:38 ]: 俺はjava.util.prefs.Preferencesのget()を思い出した
485 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:13:18 ]: >>483
プリミティブを参照渡しさせない仕様なんだから
可変にしちゃったらラッパークラスにならないぞ
486 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:18:43 ]: >>483
つ java.util.concurrent.atomic.AtomicInteger

っても、atomicな更新のためのクラスだから
mutableなintのラッパークラスとして使うのはアレな感じもするけど
487 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:17:23 ]: org.omg.CORBA.IntHolder

CORBAのクラスなのがあれだが
488 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:25:19 ]: >>478
C#のNullableは単に値型でnull許容可能にするための代物。
俺が言ってるのは、値型/参照型区別無くある型の変数に
nullを許容する/しないを指定できる代物。しかも、nullableな型は
non-nullableの型にそのまま代入しようとしたらエラーになって
コンパイラによるチェックを強制されるようなの。具体的な言語で言うと、Nice
nice.sourceforge.net/
がそれをサポートしてる。使ってみればわかるけど、この機能はかなり便利。
489 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:36:14 ]: ウザいと思われるかもしれんけど、続けて書く。Niceで書くと定義はこんな感じで
書ける。

int? parseInt(String input) {//nullを含む可能性があるint型
　try {
　　return Integer.parseInt(input);
}catch(NumberFormatException e) {
　　return null;
　}
}

使用する方はこんな感じ。if(parsedValue != null)によるガードが無いと
コンパイルエラーになるのでNullPointerExceptionの心配は無い。

int? parsedValue = parseInt(inputValue);
if(parsedValue != null) {
　//parsedValueを使った処理
}
490 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:39:25 ]: この機能が無いからNullObjectが出来たんだな
491 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:45:26 ]: >>489
それ、何が嬉しいのか分からん。

parseInt だと実行時例外で例外処理を強制できないから、
nullチェック強制できる >>489 の方が良いって話？
492 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:47:05 ]: よく考えてみたらオートボクシングめんどくせえなｗ
これ
493 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:54:52 ]: >>491
パーズ失敗を例外で扱うのに反対で、返り値でパーズ失敗を扱いたいんだけど、
nullでパーズ失敗を表すとしたらNullPointerExceptionの危険性があるし、意図が
あいまいになる危険性もある。で、この機能があればnullを許容するという事を
明示できるし、NullPointerExceptionの危険性も無いから欲しいなあということ。
494 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:01:56 ]: コンパイルエラーを期待してって考えなら分からんでもない。
javaならメソッド側にアノテーションで実現することになりそうだ。

@NilExclude int parsedValue = parseInt(inputValue);
if (parsedValue != null) {
// このブロック以下でのみparsedValueへはアクセス可能
}
// このスコープでparsedValueへはアクセスできない

をコンパイルすると拡張構文よろしく等価コードに展開されるみたいな感じか。

int parsedValue = 0;
Integer parsedValue$ = parseInt(inputValue);
if (parsedValue$ != null) {
parsedValue = parsedValue$.intValue();
// ...
}
495 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:03:19 ]: 結論はおまえにはjavaは合ってないって事だな。
話聞いてると考え方が短いコードで実現させるタイプの動的言語の発想だ。
496 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:04:38 ]: で、何故parseInt()のパーズ失敗を例外で扱うのに反対かというと、parseInt()は
引数から返り値が一意に定まるので、たとえパーズ失敗でも例外的な状態と
言えないと考えるから。
497 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:06:27 ]: >>495
なんで動的言語が関係してくるの？むしろ静的にチェックできる機能が
欲しいって話をしてるわけで、動的言語とは対極の発想だよ。というか、
短いコードが好ましいってのは動的言語特有の発想でもないでしょ。
498 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:07:59 ]: > メソッド側にアノテーションで実現することになりそうだ。
メソッド側にってのは余計。構成してて放置したままだった。
499 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:15:42 ]: 契約的言語。
500 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:21:29 ]: アノテーションひとつで
if (n != null) { /* n アクセス */ } と
if (n == null) { return; } /* n アクセス */
のどちらかを選択（および強制）できるのなら歓迎かな。
@Overrideの親戚みたいなもんだ。
501 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:43:04 ]: 例外を「例外的な状態でのみ使うべき」というのは言葉が同じだからもっともらしく
聞こえてしまうだけで、何の助けにもならない方針。

www.boost.org/more/error_handling.html
boost.cppll.jp/HEAD/more/error_handling.html
502 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:48:46 ]: >>500
FindBugsをどうぞ
findbugs.sourceforge.net/manual/annotations.html
503 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:03:12 ]: >>493,496
単に自分の考えと合わないってだけ？
それって自前のクラスメソッド書いて、そっち使うんじゃダメなんか？

なんつーか、>>448-449 あたりが結論になりそうな話じゃねーかと。
504 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:14:56 ]: >>503
もちろん自前のクラスメソッド書いて使うことになると思うよ。
実際にJavaプログラム書くときの解決策としては。単に言語の
拡張まで含めて許されるならどういう設計にするのが良いかという思考実験。

あと、free論争とは文脈が違うので一緒にされるのはちと心外だな。
どういう方針でライブラリ設計をするかという話は使い勝手に関わって
くる。もちろん、ここで議論しても実際のJava APIの設計が改善されない
という意味では無益なのはそうだけど。
505 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:26:05 ]: >>496
理解できない
すべての失敗する引数はnullが返ることで一意に定まるということ?

例外的な状態かどうかはparseInt単体でなく、呼出し側がどうしたいかでも異なるはずだ
デフォルト値が定まる場合と定まらない場合、とか
んで、とりあえず保守的にパーズ失敗を例外として扱うと言う設計でよいと思う
checkedかどうかは微妙なとこだが
506 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:26:52 ]: 単に好き嫌いの問題で、パフォーマンスとか関係ないんでしょ？
free論争と大して変わらんと思うが。
507 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:30:33 ]: >>504
parseInt の使い勝手を改善する事により、Java での開発効率が 10％向上するんだ！
とか考えてるなら一生懸命考えるのも頷けるんだけど……

ぶっちゃけ瑣末な問題じゃね？
508 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:40:40 ]: 例外を握りつぶすユーティリティメソッド作ればOK。
509 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 02:03:58 ]: >>505
> すべての失敗する引数はnullが返ることで一意に定まるということ?
そういう意図で書いた。正確に言うと、外部の状態に依存せずに
入力*のみ*から返り値が決定される、ということ。その逆の
典型的な例としてはIOExceptionを発生させるような関数や
コンストラクタがある。これらの関数は入力だけでなく外部の
状態によって成功したり失敗したりする。

>>507
parseIntだけの問題として考えればぶっちゃけどうでもいいけど、
一般的な問題としてある関数が失敗を返り値で通知するか
例外で通知するか、というのは瑣末な問題じゃないと思う。
510 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:42:29 ]: ユーティリティメソッド作ればOKってのは、思考停止以外のなにものでもない。
511 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:46:39 ]: parseInt を改変しようとか考えるのは暇人以外のなにものでもない。
512 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:53:09 ]: >>511
そうか？
513 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 10:14:54 ]: >>511
つきあってた連中も暇人以外のなにものでもない。
514 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:20:14 ]: 改変は、ちゃんと考えてbugparadeにあげるなどすれば、なにがしかの影響は与えられる。
ここで改変について語るのも、そういったヤツのインスピレーションになることもあるだろうし、本人が書き込むこともあるだろう。
無駄ではないよ。
515 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:39:06 ]: なにがしかの影響って……
>>509 も parseInt に関してはどうでもいいって言ってるんだが。
そんな瑣末な問題に関わらせる事で
JDK開発者のモチベーションを下げたいって事か？

free論争ってさ、やってる当事者は引っ込みがつかなくなってるだけかと思ってたけど
案外、>>514みたいに「この議論は無駄ではない」とか思ってる人も居るのかも知れないね。
516 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:41:41 ]: parseIntの例外が例に挙がって
- コードを短く書きたい
- 例外で扱う状況とは思えない
という2点の争点があると思う。

さらに後者の視点は、
- 例外を扱うべき状況を設計の美しさから考える
- 例外を扱うべき状況をException処理の重さから考える
という2つの立場がある

俺は、parseIntに例外の記述が出てきてもいいが、重いException処理が
いやだなぁ、という点から、こういうのがあればいいんじゃないかと思う。

定義済Exception/ StaticException / 短距離Exception /LightWeightException ?

今、Exception処理が重いのは、Exceptionオブジェクトの生成にある（スタックトレース生成など）
つまり、生成処理をなくしてやれば大幅にパフォーマンスは改善するはず。
なので思い切って、stackTraceとかが空っぽのExceptionで
すぐ直上のcatch節で捉える決まりで、
さらにThrowの必要があるときは別のExceptionにしなくてはいけないようなもの。
気軽に例外が投げられるようになって、正常系の処理が例外でトリッキーに実装されるように
なっちゃうかもしれないけど、こういうのってどうですかね。
517 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:47:27 ]: >>515
相手にするから調子に乗るんだろ。ほっとけ。
518 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:05:24 ]: >>516
> 重いException処理がいやだなぁ、という点
いやなだけなのか。

これこれこういう使い方をすると、
（パーズ失敗する）parseInt の呼び出しがボトルネックになって困る、
そして、このような使われ方をする事が多いので標準APIを改善して欲しい、
ってんなら議論の余地もあるけど、それって単なる好き嫌いの問題じゃね？
519 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:39:29 ]: >>518
包丁一本で、何でも作るのって大変じゃないかな、って話です。

sourcepost.sytes.net/sourcepost/sourceview.aspx?source_id=29658
のコード書いて、Exception生成のコストを見てみました。
ウチのマシンでの結果です（かかった時間）
Try[1]:422
Try[2]:10469
Try[3]:78
Try[4]:10875
１つめが、Throwableを継承して、Overrideで色々ぶった切ったクラス。
２つめが、単なるException。
３つめが、単なるObject。
４つめが、NumberFormatException。
Objectのnewに比べて、Exceptionのが大幅に重い処理となっています。
NumberFormatExceptionもそうです。
もし、ファイルを読む処理をするときに、数字でないものも大量に含むフィールドがあれば
Exception処理が時間を食うことが予想されます。
Exceptionの機能を大幅にカットすれば、２桁のオーダーで処理を軽くすることができるわけです。
現在の仕組みを使って、実装するならこうなりますがシステムとしてサポートしてくれても
いいかなぁ、と思ったわけで。
520 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:53:24 ]: >>519
> 数字でないものも大量に含むフィールドがあれば
普通はフォーマットエラー吐いて終わりでしょ。
521 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 13:10:14 ]: 　　　　〃〃∩ 　_, ,_
　　　　　⊂⌒（　`Д´）　＜　ヤダヤダ！ parseInt が例外使っちゃヤダ！
　　　　　　｀ヽ_つ ⊂ノ
　　　　　　　　　　　　　　ジタバタ

　　　　　　〃∩
　　　　　⊂⌒(　　_, ,_）　＜　ぶっちゃけどうでもいいけど、やっぱりヤダヤダ……
　　　　　　｀ヽ_つ ⊂ノ
　　　　　　　　　　　　　　ﾋｯｸ...ﾋｯｸ...

　　　　　⊂⌒(　　_, ,_）
　　　　　　｀ヽ_つ ⊂ノ　　zzz…
522 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 13:56:24 ]: delphiのStrToIntDefみたいに、数値にできないときのデフォルト値が指定できればかなりいい
523 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:17:51 ]: >>520
何で？全部読んで例外をチェックしないと駄目かもしれないですよ。

いや、というか例外を使うなとかいう話ではなく、
パフォーマンスを気にして例外を使うべき場面を回避しようとするのは
本末転倒だから、例外を使わなきゃ駄目なときパフォーマンスが
落ちなければそういう誤解、というか誤用がなくなるんじゃないかと。
524 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:45:35 ]: >>523
「かもしれない」って……
要するに、今現在（パーズ失敗する）parseInt の呼び出しが
ボトルネックになって困ってるわけじゃないんでしょ。
単なる好き嫌いの問題にしか見えないが。

それに、誤用とか誤解とか言われても……
>>509の理論がいつでもどこでも通用する例外のガイドラインとはとても思えないし、
使い勝手、堅牢性、パフォーマンス、好き嫌いとか色々な要素が絡んでくるから
いつでもどこでも誰にでも通用する例外のガイドラインを作るのは難しいだろうし。
525 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:47:32 ]: ということは例外はこれまでどおりフィーリングとわずかなドキュメントで判断していくしかないのかね
526 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 15:21:46 ]: >>524
>>523 ≠>>509です。
parseIntはあくまで例です。
確かにちょっと誤解されそうなレスでした・・・

誤用というのは、Exceptionを使うまいとして
ごちゃごちゃとしたコードになってしまうような状況を指してます。
具体的にカチッとした基準に基づいた「ごちゃごちゃ」ではありませんが。

私は、parseIntに関わらず、Exception処理が軽くなればいいな、という話をしているつもりでした。
527 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 15:36:41 ]: >>526
parseInt で例外生成コストが下がると嬉しいか？

それに、parseInt で Exceptionを使うまいとして
ごちゃごちゃとしたコードになるって、どんな状況？

あと、俺は Exception処理が軽くなれば良いって要望に対する返答が
「例外的な状況以外で例外使うな」って話なんだと理解してるんだが。
例外って濫用すれば goto より悲惨なスパゲッティコード書けるしね。
528 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 17:31:04 ]: パースの失敗は十分、例外的状況に値すると思うが・・・。
例外処理の乱用がスパゲッティーコード招いてるんじゃなくてそういうコード書いてる自分がスパゲッティー作ってるんだと思う。

アプリケーションかミドルウェア側の設計でどうにかなると思うんだが？
529 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 17:37:48 ]: >>527
InterruptExceptionって例外的だと思う？
スレッドのキャンセルを実装しようと思ったら普通に出るけど
530 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 18:49:35 ]: >>528
設計っつーか、実装で吸収できるでしょ。
531 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:19:45 ]: 便利なら便利なほうがいい。
532 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:24:49 ]: 何を便利と感じるかは人によって違う、と。

かと言ってなんでも標準APIに入れたら標準APIメンテする人間の負担が増えて
バグが増えたり放置されたりといった悪影響も考えられる、と。
533 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:47:42 ]: NICEのnullableってのは興味深いネタだったけど、
それと一緒に語られたparseIntの仕様には何の興味も湧かなかった。
つーことで、イディオム補完型（保証型）のアノテーションの充実を期待したい。
534 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:32:33 ]: >>445
終了前のfreeは害っていうのがいるだろ。
535 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:55:31 ]: そんなものは無い
536 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 22:37:51 ]: blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx
537 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 22:39:06 ]: blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx
538 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:14:55 ]: parseIntで100近くもダベれるお前らに脱帽
539 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:53:35 ]: >>536
低脳な質問で悪いんだけど
「クリティカルで速度が要求される場面での数値チェックは、例外を使わないのが無難っぽいです。」

って言ってるけど、じゃぁどういう処理が望ましいんだろうな。
俺も、試しに同じ用なプログラムを10000000回処理をぶん回してみたが、
正直それほど有意差は認められなかった。

----以下結果----
StringUtils.isNumeric() : boolean で不正な文字かどうかを検知
1回目 451 ms
2回目 401 ms

Integer.parseInt() : 例外で不正な文字かどうかを検知
1回目 42822 ms
2回目 42771 ms
540 名前：デフォルトの名無しさん [2007/09/08(土) 01:03:04 ]: >>539
例外を使ってるバージョンが100倍近く遅いんだが、それは
有意な差じゃないの？
541 名前：デフォルトの名無しさん [2007/09/08(土) 01:05:19 ]: あ、もちろん実際にparseIntが使われる局面で1000000万回も
呼ばれることは無いだろうから、そういう意味では例外を使っても
いいんだろうけど、有意な差が無いってのは変でないの？ってこと
542 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:05:27 ]: >>539
ネタにマジレス。

まず数値チェックに parseInt 使って
> クリティカルで速度が要求される場面
が具体的にどういう場面なのかってのを特定するのが先決。

それをしないで「どういう処理が望ましいか」を考えても時間の無駄。
543 名前：デフォルトの名無しさん [2007/09/08(土) 01:07:45 ]: 間違った。1000000万回 -> 1000万回
544 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:12:44 ]: >>538
まだまだ続くよ
545 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:59:22 ]: 巫女巫女ナース巫女巫女ナース♪
546 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 02:32:19 ]: ｢まだまだ　いくよぉ～｣だな
547 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 03:09:27 ]: もうちょっとだけ続くのじゃ
548 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 07:03:01 ]: つうか、例外は制御構造の要だろ
ttp://d.hatena.ne.jp/smeghead/20070309/baka
549 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 08:05:55 ]: 多値にしてもnullableにしても、
失敗をnullで表すのはちょっと古いんじゃないかな。

多値なら失敗(false)したら(undef, false)とundefみたいな値を返す方がいいと思う。
550 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 10:19:24 ]: >>544,547
続けるなよ……
551 名前：519 mailto:sage [2007/09/08(土) 14:09:14 ]: >>536
ちょっと待て、ほとんど俺が書いたコードじゃねえかそれ。
ちなみに、おれじゃねえぞ。そのblog
552 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 14:18:22 ]: >>549
undefがnullとどう違うのかわからん
553 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 15:06:37 ]: >>552
お前はそもそもnullは何をモデル化したと考えてるんだ？
554 名前：かつのり mailto:sage [2007/09/08(土) 16:03:23 ]: 本人降臨っす。

>>519
実験用にパクらせていただきましたｗ

ちなみにStringUtils.isNumeric()は微妙ですね。
Integer.parseIntの高速版とするなら、
Integerとしての要件を満たさなければいけません。

正規表現のパターンを予めキャッシュしておいて、
そのパターンでマッチングするのが一番早いのかな。
555 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 16:29:24 ]: NumberUtils#isNumberもあるけどlong型とかでも判定しちゃうな
556 名前：519 mailto:sage [2007/09/08(土) 17:34:45 ]: >>554
ああ、バッチでファイル読む時は俺もそうしてるなぁ
どうせ桁数制限とか入る事が多いし
557 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 17:52:06 ]: Patternのcompileってホントにコンパイルしてるの？
558 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:01:25 ]: >>557
コンパイルの意味を、パースして実行用データ作っとくって意味なら、コンパイルしてるんじゃねぇの？
559 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:21:18 ]: たしかに最適化オプション付きであるとはいってないからね。
Strategyパターンとか駆使してガチガチに最適化されたPatternを返して欲しいとこだ。
560 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:03:46 ]: Javaの正規表現はDFAでしょ？確か。
DFAはバックトラックしなくていいから、
最適化は高速化ではなく使用メモリのレベル。
遷移テーブルとかその辺。

下手な自前のマッチングコードを書くより早いよ。正規表現は。
561 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:55:04 ]: >>560
Javaの正規表現はNFA。実装読んでみるべし。
最近の言語に組み込みの正規表現ライブラリの多くはNFA(または
その変種)を採用してる。理由はNFAじゃないと扱いづらい機能
(後方参照など)があるため。
562 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 19:56:36 ]: ちなみに各言語における正規表現ライブラリの実装がどのように
なっているかの概要を知りたい場合は、詳説正規表現がオススメ
563 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 22:35:20 ]: >561
そか。情報サンクスコ
564 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 19:28:16 ]: DFAじゃあ不便すぎる。
565 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 21:49:32 ]: DFAはNFAから変換できるけど、NFAにしておく意義としては、
NFAのまま何かの機能を追加するってこと？
バックトラックする際に後方参照も同時にサポートするためなのか。
566 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 22:28:17 ]: >>560
> 下手な自前のマッチングコードを書くより早いよ。正規表現は。

んなわけねーだろ。正規表現遅すぎだ。計測してねーだろ。
ただ、Web アプリとかでせいぜい項目が数百程度の
入力チェックや変換程度なら速度差は計測不能。
567 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 22:41:57 ]: >>566
単純な文字パターンの検証なら正規表現の方が遅いだろうけど、
ごく一般的な業務システムプログラマが、
自前で複雑な検証コードを書くよりは速い。
きちんとロジックを書ける人なら速いんだけど。
568 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:18:56 ]: 文脈的に parseInt でパーズ成功/失敗を予め判定するためのコードでしょ。

>>554が言うように Intergerとしての要件を満たす、
文字列が数字で構成されてるかだけじゃなくて最大値や最小値チェックもするなら
正規表現つかうより自前でやった方が早く書けるんじゃねーの？
569 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:23:20 ]: 最大値や最小値をチェックする時点で、成功/失敗を予め判定するどころか、すでに値が求まってる気がする
570 名前：デフォルトの名無しさん mailto:sage [2007/09/09(日) 23:56:08 ]: >>566 >>567 >>568

>>560は正規表現エンジンがDFAで実装されてる場合の
話をしてると思うよ。その場合なら、下手に自前の
コード書くより早いというのは間違いでもなんでもないよ
571 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:01:33 ]: > ちなみにStringUtils.isNumeric()は微妙ですね。
> Integer.parseIntの高速版とするなら、
> Integerとしての要件を満たさなければいけません。

だからなぁ…… 最大値/最小値チェックしないなら
ほとんどStringUtils.isNumeric()で用足りるんじゃね？
572 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:01:37 ]: >>565
そういうこと。NFAのままにしておけば、「非正規な」機能である後方参照
やその他もろもろ、比較的容易に追加できる
573 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 00:13:43 ]: >>569
例外使わないだけで 100倍程速くなるそうだから、
変換処理が 2回やる事によって 2倍の時間かかっても大した問題じゃないんじゃね？

まぁ、場合によっては大した問題になるかもしれんが。
そんなん問題になってから考えりゃいいっしょ。
574 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 01:42:54 ]: 正規表現使うほうが１００倍速いよ。実装が。
575 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 20:17:24 ]: C#の正規表現はグループに名前を付けられるみたいだね
576 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 21:14:45 ]: >>574
StringUtils.isNumeric()では足りない部分までIntegerの要件を満たすかチェックするんだったら
正規表現でやるのは面倒くさそうだが。
577 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 22:50:21 ]: 正規表現のスレでやれよ。ここには関係ないから。
578 名前：デフォルトの名無しさん mailto:sage [2007/09/10(月) 23:04:10 ]: >>576
桁数制限してIntegerの半分以上の範囲捨てるなら簡単だけどな
579 名前：デフォルトの名無しさん mailto:sage [2007/09/12(水) 00:32:10 ]: >>575
正規表現のマッチング処理高速化のためにコンパイルすると、
メモリリークするとかＭＳＤＮのドキュメントに書いてあるけどな。
580 名前：デフォルトの名無しさん mailto:sage [2007/09/12(水) 00:53:38 ]: >>579
それドトネト1.1のころの制限じゃない？
581 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 10:08:16 ]: なんと言う次世代
582 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 10:59:42 ]: 次世代試作機・・・。
583 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 13:48:51 ]: Javaを拡張するのではなく、OSを拡張するというのはJSRにならんのかね？
例えばjinputをJava標準にするための下地にするためにとか。
584 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 14:16:31 ]: JDK7 build20
download.java.net/jdk7/binaries/
download.java.net/jdk7/changes/jdk7-b20.html
585 名前：デフォルトの名無しさん mailto:sage [2007/09/15(土) 19:49:01 ]: そういやjdk7が出来たらOpenJDK6をOpenJDK7ベースで再構築してOpenJDK6をGPL2で配布するらしいな。
将来的には公式バイナリも完全にOpenJDKからビルドするらしい。
586 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 12:58:01 ]: ７は変な機能増えすぎ
もっとシンプルに保てよ
587 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 13:16:10 ]: クロージャというか関数導入するならperl見たいな複数戻り値の関数もできるようにしてくれ
588 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 14:09:47 ]: 多値返せたらいいのにと思うことはよくある
589 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:38:35 ]: 時々、妙に多値希望の人っているよね
そういう人はロートルだと思っておｋ？
590 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:39:53 ]: 多値が返せる言語ってあるの？
591 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 15:44:03 ]: Perlしかしらない。
ただstateとvalueみたいな多値が欲しいがために
ReultFooみたいなクラスを書くのはなんだかなぁと思うときは多い。
592 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 16:23:13 ]: lispまでいくと多値というよりリストか
Object[]のシンタックスシュガーで十分なんだけどな
C#のstructなんかよりずっと有用
593 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 17:16:56 ]: pythonのtupleみたいなの。
まあ、Object[]でもいいけど。

>>591みたいな
型に名前つけるのが面倒なんだよ。
594 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 19:17:12 ]: Pair<A, B> みたいなクラスを作って使いまわすとか
595 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 19:48:49 ]: 最近は多値返せる言語増えたよ。
javaだとどうせバイトコードレベルでは配列になるんだろうね。
596 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:16:58 ]: public const<String, Boolean> getResult() {
return const { "おｋｗｗｗｗ", true };
}

こんな感じで死にキーワードを流用できないものか
597 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:20:27 ]: >>596
それだったら Pair<A, B> で良いじゃん。
598 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:26:16 ]: 普通のGenericsは可変長じゃねー
599 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:36:13 ]: じゃ、

static <A, B> Pair<A, B> tuple(A a, B b)
static <A, B, C> Triple<A, B, C> tuple(A a, B b, C c)
static <A, B, C, D> Quadruple<A, B, C, D> tuple(A a, B b, C c, D d)

みたいにすれば？
600 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:49:41 ]: こらこら。Javaにrefやoutはないでしょ。
尤もCommonsLangあたりにはあっていいクラスだとは思うけど
601 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:52:29 ]: ref や out って、どこの話だ？
602 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:52:37 ]: 多値よりも Ref<T> のほうがまだ使い勝手が良さそうな気がする。
603 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:53:37 ]: ああ、ファクトリメソッドか、俺の勘違い。
>>601 C#
604 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:55:55 ]: >>603
いや、レス番の話。
このスレのどこで ref や out の話が出てんのか、と。
605 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:57:38 ]: 俺が>>601をクラス定義と勘違いしただけだって。
606 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 20:59:21 ]: あ、>>599ね。あかん、おねむの時間っぽい。
607 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:03:13 ]: >>599 にも ref や out があるようには見えんが……
608 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:04:09 ]: どう勘違いしたのかくらい考えろ馬鹿ちん
609 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:07:16 ]: なんだ、勘違いか。なら考えても無駄だな。
610 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:09:24 ]: 遅かれ速かれ多値はサポートしてくれるものと思いたい。
611 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:10:54 ]: JVM系LLで多値サポートしてたら、そっち使えって話になるんじゃね？
612 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:15:23 ]: var rand = new Random();
int n = rand.nextInt();
みたいな書き方も需要あるから、多値もJSRには上がるとは思う。
613 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:17:32 ]: bugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792
will not be fixed になってる。
614 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:23:36 ]: >>612
どうだろね？

型推論ですら、変数宣言時の型指定を省くのは Java 的じゃないってんで
G<T> g = new G();
みたいに、初期化子の方のパラメタ型指定を省けるようにしようって
論調の方が強いみたいだけど。今までの
G<T> g = factoryOfG();
みたいな型推論とも一貫性あるってのが良いらしい
615 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:28:40 ]: G<T> g = new(); みたいなのもどっかで見たな。
616 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:31:31 ]: 極力interfaceで受け取れいうてる今までとの親和性の問題もあるし、
今後の拡張はローカルキーワードで行きたいって思惑もあるから
早い段階でサポートするならそっちかもな

>>615
みたけど流石にそれはないｗ
617 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:42:13 ]: varの方はGraphicsEnvironment.getLocalGraphicsEnvironment()とか長すぎるから何とか汁って考えもあったはず
618 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:47:32 ]: >>617
つ static import
619 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:49:48 ]: staticじゃなきゃ役にたたねーけどね
620 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:52:21 ]: メソッド名が長いのはメソッド名のalias導入とかせんと解決せんのでは？
621 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 21:54:22 ]: 関係ないけど、メソッド名ってたしか長さ制限あったよね
622 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:00:53 ]: static importはユーティリティメソッドに
沢山依存してる状態じゃないと返って面倒なだけ
623 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:05:31 ]: 名前空間が汚れる。
624 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:06:13 ]: まあ、結局のところD言語はvarで解決としたみたいだからJavaもそうなるよ。
プロパティ問題も馬鹿なことやらないで、素直にC#風にしたしね。
625 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 22:26:52 ]: > プロパティ問題も馬鹿なことやらないで、素直にC#風にした
ソースは？
626 名前：デフォルトの名無しさん mailto:sage [2007/09/16(日) 23:43:33 ]: >>590
Common Lisp, Scheme(R5RSから)

(define (foo) (values 1 2))
(set!-values x y (foo))

(set!-values q r (quotient&remainder 10 3))

スタックフレームの返値を格納するスロットが一つ増えるだけだから、
tupleやlistやarrayを箱にする方法より性能がいい。
627 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:01:39 ]: >スタックフレームの返値を格納するスロットが一つ増えるだけだから、
それやると VM の変更が必要にならんか？

> tupleやlistやarrayを箱にする方法より性能がいい。
その辺の性能あげるためにエスケープ解析とか頑張ってるんじゃね？
628 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:02:35 ]: >>627
VMの変更っつーか、VM仕様の変更じゃね？
629 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 00:07:16 ]: >>625
docs.google.com/View?docid=dfhbvdfw_1f7mzf2
これの事じゃね？

でも、これbeansのプロパティと互換性ないし、
フィールドとプロパティの名前がかぶった場合どうなるかって部分も甘いような。
630 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 12:14:51 ]: 多値はいつか実現して欲しいね。
引数は0個以上なのに、結果は0か1に制限されているのは不便。

>>589
他の言語で使うと癖になるから、粘着的なw要望が続くんだと思う。
631 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 12:20:52 ]: >>630
なんつーか、Perlとかで初めてsplitの結果を複数の変数に
まとめて入れる表現見たとき便利だと思ったわけで、
こういうのって、返値は配列として扱ってるじゃない。

配列の返値を、各変数に代入するシンタックス糖分があればいいんじゃないかな？
632 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 13:34:05 ]: > スタックフレームの返値を格納するスロットが一つ増えるだけ

> 配列の返値を、各変数に代入するシンタックス糖分があればいい

この二つって全然別の要求なわけで……
633 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 13:35:18 ]: >>630
粘着的な要望する奴は口だけ動かして手を動かさんからなぁ……
634 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:09:07 ]: >>632
多値って一口に言っても、考えてる事が微妙に違うからなぁ……
635 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:49:27 ]: とりあえず配列でやっておけばいいんじゃないの？
636 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:52:17 ]: >>635
Object[]を使えばいいじゃんって意味？その場合、複数種類の型を内包する配列を扱うことになるから、
言語的なサポートが欲しいって言ってるんじゃない？
637 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:53:20 ]: >>633
このスレに要望出しても意味ねえんだけどな
638 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:54:47 ]: 型の問題があるなら、引数のほうに値をうけとる配列として渡すとかね。
639 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 14:58:05 ]: >>637
要望だした時点で気持ちよくなってんじゃないかと。
要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？
640 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:48:10 ]: ゆとりのやつって、直接的な効果がなければ意味ねぇとかよく言うよね。
間接的な効果を想像できないんだよね。
641 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:53:01 ]: あるあるｗ
ちょっとたとえを出して、それを否定できただけで、全てを否定ｗ
642 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 15:53:48 ]: 間接的な効果に期待（するだけ）しかできないんだったら
> 要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？
って評価は正しいような。
643 名前：デフォルトの名無しさん mailto:sage [2007/09/17(月) 17:26:43 ]: はいはい、ここは次世代Javaのスレですよっと

JSR-310 に generics版なるものが出来ていた。
https://jsr-310.dev.java.net/nonav/generics/index.html
https://jsr-310.dev.java.net/servlets/ReadMsg?list=dev&msgNo=726
> The basic theory is to define a class for each of the basic concepts -
> Day, Month, Year, Hour, Second etc, and then utilise those in other
> ways. These are TimePart subclasses.
>
> Instead of having a dedicated Seconds class that holds only seconds,
> there is a single TimeAmount class that is generified:
>
> Standard design:
>　 Seconds s = seconds(3);
> Generics design:
> 　TimeAmount<Second> s = seconds(3);
>
> Similarly, the field classes such as DayOfMonth are removed with a
> single generified TimeField class:
>
> Standard design:
> 　DayOfMonth dom = dayOfMonth(3);
> Generics design:
> 　TimeField<Day, Month> dom = dayOfMonth(3);

個人的に generics版にするなら var dom = dayOfMonth(3); タイプの型推論が欲しいような。
644 名前：デフォルトの名無しさん [2007/09/17(月) 20:18:05 ]: blogs.wankuma.com/kacchan6/archive/2007/09/17/96592.aspx
645 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 08:41:40 ]: generics版は、入力めんどすぎだな
646 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 16:45:33 ]: ドキュメント簡潔で理解しやすいしこっちのほうが好きなのは俺だけか

それはそうと９月の第三月曜日とか毎月第五土曜日（と、第五土曜日が存在するかチェックする方法）とか
どうやって入力するんだろう？この程度のことがいちいち煩雑なのは嫌なんだけど。
曜日指定できそうなCalenderDayのDayOfWeekは引数がなぜかint型だし。
曜日関係はまだまだこれからなのかね？
647 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 20:37:07 ]: あれだ。
カレンダー用のXPathみたいなの作って
W3C標準にすればいいんじゃね？
648 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 21:04:02 ]: CQL

CalendarQueryLanguage

ばばーん >>647 がただ今鋭意作成中です
649 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:12:45 ]: >>647
Structured Calendar And Time Markup Language
略してSCATML。それのAPIがSCATMLAPI。
650 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:19:52 ]: 31日や2月29日みたいなTimeFieldやTimeViewって
カレンダーが背後にあるクラスに受け入れられるまで、意味のあるカレンダーデータかどうかわかんないわけだよな。
ついでにPeriodを加算するみたいな日付計算もできない。
それなら『カレンダーが背後にあるクラス』をインターフェース化しておいたほうがいいんじゃないかと思ったり。
最初はCalendricalがそうかと思ったんだけどなんか違うっぽいな。
651 名前：デフォルトの名無しさん mailto:sage [2007/09/18(火) 23:54:39 ]: やっぱCalendricalか。何故かTimeViewやTimeFieldに継承されているけどこれは何かの間違いだな。

weekOfMonthが作れるようになったりTimeField同士を結合してTimeViewを作ったりできねえかな。
そしたら今年の９月の第３月曜日とかでも楽に指定できるのに。難しいのかこれは。
652 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 00:00:02 ]: TimeAmountで期間データの変換が相互に可能になってるっぽいが
Second～DayはともかくDay～Foreverのデータはカレンダーないと変換できないような。
いちいちUnsupportedOperationException投げるつもりかいな
653 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 02:32:47 ]: こんな感じで書けないかな
static import javax.time.Moments.*

...

TimeView<Day,Year> leapyearday = build(MonthOfYear(2), dayOfMonth(29));
CarenderYear year = now().currentYear();

List<CalenderDay> lyds = new ArrayList<CalenderDay>();
for(int i = 0; i < 10; i++){
　　CarenderDay tmp = CalenderDay(year.plus(i), leapyearday);
　　if(!tmp.wasRolledGenerate())
　　　　lyds.add(tmp);
}
654 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 02:54:46 ]: >javax.time.Moments.*
パッケージ名だけ見たらとてつもなく抽象的すぎて何に使って良いかわかりづらいな。
655 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 03:17:56 ]: TimeUtilsとかの方がいいよな。常識的に考えて。
そのうち変わると思うが
656 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 11:16:37 ]: >>654
time.Momentsってそんなにわかりにくいかな？
657 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 13:15:14 ]: 個人的にクラス名変えるならこんな感じ
時刻系
TimeView＞TimeExpression：時刻表現
Calendrical＞ScaledTime：カレンダー評価済み時刻表現
TimeField＞TimeField：即値時刻表現

期間系
Period＞Period：期間
TimeAmount＞PeriodField：即値期間

単位系
TimePart＞Unit：単位

その他
Moments＞TimeUtils：ユーティリティクラス

うーん、イマイチ。
658 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 16:48:46 ]: クラス名・変数名に迷ったら書き込むスレ。Part10
ttp://pc11.2ch.net/test/read.cgi/tech/1180146315/

ここにお願いしてみては
659 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 18:46:41 ]: >>656
今のクラス名だと高精度の時間取得APIとも取れるし、時系列系APIのフレームワークとも取れる。

名前から想像できる用途が曖昧で冗長といった印象。
名前からすると一見汎用性がありそうだけど、
けど中身はカレンダーAPIの上位API程度の印象も受ける。

そのため、今のカレンダーAPIとの関係も分かりづらい。
そうなると移行や使い分けが難しいかと。

要するに何のために作ったのか分からん、と・・・。
660 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 19:01:06 ]: どう見ても完全に置き換えるものとして使うようにできてるだろ。
互換性を意識しないといけない場合以外は全部移行していいようにするんじゃないのか？
まだOverViewには入ってないがフォーマッティングやパーシング用のクラスも作るらしいし。
661 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 19:22:46 ]: java.util.concurrent.TimeUnit も忘れないであげて
662 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 13:05:43 ]: JSR 277とJSR 291は議論が熱いね。
www.infoq.com/jp/osgi
663 名前：デフォルトの名無しさん mailto:sage [2007/09/22(土) 10:54:13 ]: OSGi関係は熱そうだね。
関わってるところ多いし、影響が大きそう
664 名前：デフォルトの名無しさん mailto:sage [2007/09/24(月) 18:48:55 ]: JDK7、機能はすごい魅力的なんだが、リリースが一年以上先か・・・。
堅実なのはいいことだけど、もうちょっと早くならんかなあ。
665 名前：デフォルトの名無しさん mailto:sage [2007/09/25(火) 01:28:48 ]: 目玉機能とされてるJSR-277もまだだし
Closureに至ってはJSRすらないしなぁ。

これでリリースまでに全部つっこんできたら十分早いと思うが。
666 名前：デフォルトの名無しさん mailto:sage [2007/09/27(木) 22:46:13 ]: 業界的にはまだバージョン4が多数だから早い感じもする。
667 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 00:51:19 ]: テンプレート(1.5)、クロージャ(1.7)とくれば、最後に来るのは…マクロ！(1.9予定)

すべての言語は最後はlispの一部を再実装する事になるのかと思うと、複雑な気分だな。
668 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 01:00:50 ]: バージョン4なんかない。
669 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 02:22:08 ]: >>668
R4のことだろ？
670 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 04:08:52 ]: RhinoR4？ライセンスが・・・ｗ
671 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 10:11:40 ]: 最後はevalだな。
672 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 11:10:22 ]: OSGiじゃないのか？
673 名前：デフォルトの名無しさん mailto:sage [2007/09/28(金) 14:32:28 ]: JDK7 build21
download.java.net/jdk7/binaries/
download.java.net/jdk7/changes/jdk7-b21.html
だって。
ようやくコンパネの縦長が直った。
674 名前：デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:06:09 ]: OSGiかなにかのプラグイン機構がJava SEに入るまでまだ一年位あるので、
Javaのスクリプトで代わりをできないかと思ったんですが、
次を読むと普通にできそうですね。
（つまりJavaプログラム実行中に動的に実行コードを入れ替えたい。）

JavaからRubyスクリプトを実行する
codezine.jp/a/article/aid/1647.aspx?p=3

個人的にプラグイン機構の重要度がかなり下がりました。
675 名前：デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:14:59 ]: 普通にクラスローダを使えばいいだけじゃないの？
676 名前：デフォルトの名無しさん mailto:sage [2007/10/09(火) 15:26:11 ]: クラスローダは難しい・・・
昔OSGiを使ってたときですらクラスローダで苦労した。
確か、setContextClassLoader辺りとか頻発した。
（OSSのライブラリでこれが設定できないので、プラグインから使うために
　ソースを書き換える必要が発生したこともあった。）
記憶が薄れてるけどOSGiが無いとさらに倍以上苦労する感じだったと思う。
677 名前：デフォルトの名無しさん mailto:sage [2007/10/10(水) 02:31:03 ]: URLClassLoaderで簡単にJARファイルからクラスを読み込めるから、
プログラム実行中に動的に実行コードを入れ替えるのは簡単だと思うけどな。
678 名前：デフォルトの名無しさん mailto:sage [2007/10/10(水) 08:53:59 ]: >>674
Rubyてw
Javascript使えよ。最初からSEに入ってんだから。
679 名前：674 mailto:sage [2007/10/10(水) 13:46:54 ]: 助言？ありがとうございます。

>>677
setContextClassLoaderは、Jar内のファイルを読むために
基盤とプラグインのJarのClassLoaderを切り替える
のに使ってたんだったと思いますが、
URLClassLoaderを使うと簡単にできそうな気がします。

>>678
JRubyは速いと言う記事が目に入ったので
条件反射で調べてみたのですが、
JavaScriptでいいですね。Rubyは殆ど知らないし。
680 名前：674 mailto:sage [2007/10/10(水) 13:49:23 ]: ちなみにやりたい事は、
UMLのステートチャート図で状態遷移を定義しXMLを生成する
（このエディタは自作する）
実行時はXMLに従って、各状態と遷移時の処理を行う。
基本的に、ステートパターンで実現する。
こんな感じの多目的に使えるフレームワーク作り。

と言う感じで、DIコンテナで普通にできそうですね…。
それが一番早いなｗ
681 名前：デフォルトの名無しさん mailto:sage [2007/10/10(水) 16:20:30 ]: >>677
具体的にどういうコードになるの？
クラスローダーは複雑で言ってる事が見えてこない…
682 名前：デフォルトの名無しさん mailto:sage [2007/10/10(水) 16:44:08 ]: >> 681
丁度いいページがあったので勝手にリンクさせてもらいます。
ttp://homepage3.nifty.com/satoshis/java/memo.html#extension
683 名前：デフォルトの名無しさん mailto:sage [2007/10/11(木) 03:45:19 ]: JRubyは本家と比べて早いって意味だ。
まあ、宗教は自由だぜ！
684 名前：デフォルトの名無しさん mailto:sage [2007/10/11(木) 09:54:50 ]: >>682おお、そういうことか！
685 名前：デフォルトの名無しさん [2007/10/13(土) 23:07:55 ]: そろそろクロージャの仕様決まった？情報まだぁ
686 名前：デフォルトの名無しさん mailto:sage [2007/10/13(土) 23:23:22 ]: www.javac.info/
www.javac.info/closures-v05.html
www.javac.info/consensus-closures-jsr.html

あたりは動いてないね。JCPのJSRのリストにも登録されてないみたいだし。
他の場所では動いてるのかも知らんけど
687 名前：デフォルトの名無しさん mailto:sage [2007/10/13(土) 23:49:45 ]: ああ、いろいろプロポーズはあるみたいだけどそれが採用されそう。
688 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 01:16:57 ]: 簡単に読み書きできることが重視されるJavaでは導入が難しいのかも。

クロージャに結びつけた変数に対して破壊的操作を行うプログラムを書いちゃうと、
非常に理解が難しいプログラムになる。と某所で言われていた。
689 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 01:28:27 ]: staticメソッドとクロージャを組み合わせて制御文みたいなのを作れるのは面白いと思ったけど
フォールスルーしないswitch文みたいなのは無理かね
690 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 02:13:48 ]: クロージャ、クロージャ言うけどクロージャ導入しても元々クロージャに書き換えるようなメソッドなら
コンパイル時にインライン化されてるだろうから人がクロージャ書く意味ってあるか？

JavaScriptも使うからクロージャは大好きだが・・・。
691 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 02:20:41 ]: うん、無理っぽいな。できたとしてもがcaseに指定された値が定数かどうかを判別するすべがないから意味ないし

String line;
while ((line = br.readLine()) != null)
みたいなループをfor eachLine(String line : br)みたいには直せそうだ。あんまりいい例じゃないが

>>690
コストが低いからクロージャを使うわけじゃないだろ
692 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 03:35:29 ]: いいかげんプリプロセッサとはいわんからせめて#ifdefを導入しろよ
693 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 03:46:15 ]: ＞＞６９０
わかりやすいから使うんじゃないのか？
いい加減いちいち無名クラスを宣言するのめんどうになってきたよ。
694 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 04:47:24 ]: もう関数型のパラダイム全部入れちゃえばいいじゃんｗ
695 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 05:53:53 ]: どうせこうなるんなら最初からいれちゃえばよかったのに
696 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 13:56:40 ]: クロージャが、多重継承のようにうまく使えば有用だが弊害もある機能だったらどうするんだ？
Javaはハッカー向け言語ではなく一般向け言語なんだし、彼らが誤用しにくい機能であるか検証しなければならない。
697 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 14:24:52 ]: どのように有用？
別に一般向けでないが？
自分で使いこなせればよいだけだし？
おまえ、キモイ顔しているんだろうな。
698 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 14:27:52 ]: >>692
既にあるにはあるだろう。
699 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 14:50:31 ]: 根本的には関数型言語のパラダイムを中途半端に取り入れるのが不味いんだろうな。
だれか、両方を統合するようなアイデアを発明してくれればいいんだが。
700 名前：デフォルトの名無しさん [2007/10/14(日) 15:46:57 ]: ところで、>>696は一体全体何を主張したかったのだろうか…謎は深まるばかりだ…
701 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 16:55:18 ]: >>699
命令型と関数型で、破壊的代入の在る/無しという根本的な前提が異なっているからなぁ。
この大きく異なる前提を乗り越えて上手く使える機構が欲しいね。
702 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 17:07:59 ]: 不変なオブジェクトを渡すか防衛的コピーして渡すか変更不可能なビューを渡すかすればいい話なんじゃないのか
Immutableオブジェクトを作るときと同じじゃん
703 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 17:09:24 ]: その違いがなくなると、命令型と関数型の垣根がなくなってしまうし、いくら欲しくても乗り越える事はできなだろう。
704 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 18:53:24 ]: >>688
int な変数を final int[] みたいに似非参照化して
内部クラスや匿名クラスで使えば結局同じ事になるけど、
記述が容易になると初心者が躓く可能性が高いとかそーゆー話？

docs.google.com/View?docid=k73_1ggr36h
CICE とかの public int みたいな構文糖の方が良いって話か？
705 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 18:54:47 ]: こんなん考えてみた。
public static <R, T, throws E>
R log(T t, Class<T> clazz, { T => R throws E } block) throws E {
　　T proxy = Proxy.newProxyInstance(t.getClass().getClassLoader(),
　　　　　　　　　　　　　　　　new Class[]{ clazz },
　　　　　　　　　　　　　　　　new InvocationHandler(Object obj, Method method, Object args)){
　　　　　　　　　　　　　　　　　　StringBuilder sb = new StringBuilder(obj + " : " +method + " : ");
　　　　　　　　　　　　　　　　　　for(Object o : args){ sb.append(o).append(" , "); }
　　　　　　　　　　　　　　　　　　System.out.println(sb);
　　　　　　　　　　　　　　　　　　return method.invoke( obj, args );
　　　　　　　　　　　　　　　　}
　　System.out.println("Logging Start : " + t );
　　R r = block.invoke(proxy);
　　System.out.println("Logging End : " + t );
　　return r;
}

で、使い方
log(List logList : list, List.class){
　　//処理
}

これでこのブロックの中でだけ特定の変数のメソッド呼び出しのログが取れるはず
ちょっといじれば特定のアノテーションのついているメソッドの呼び出しだけに反応するようにもできると思う
706 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 19:27:18 ]: そんなに難しく考えなくともecma-262とかScalaがあるじゃないか。
両立は可能だ。
707 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 19:48:05 ]: >>705
return method.invoke( obj, args );じゃなくて
return method.invoke( t, args );だわ
そういやobjはプロキシインスタンスだった
708 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 19:49:58 ]: >>704
void hoge(){
　public int total;
　array.each{int item => total += item;}
　System.out.println("合計は" + total);
}
とすると
void hoge(){
　final int total[] = new int[1];
　array.each(new EachRunner(){
　　public void run(int item){
　　　total[0] += item;
　　}
　}
　System.out.println(合計は" + total[0]);
}
と変換されるという案が出てたはず。
709 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 19:53:00 ]: >>708
CICEとBGGAごっちゃになってねーか？
710 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 20:54:04 ]: >array.each{int item => total += item;}
こういう文は見慣れない奴はインデントに困るだろうな。

array.each{ int item =>
total += item;
}
711 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 21:15:14 ]: array.each(
　　{int item => total += item;}
);

こういうインデントは？
712 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 21:35:40 ]: >>711みたいに>>710のインデントを知らん奴がいるから混乱するんだ。
713 名前：デフォルトの名無しさん [2007/10/14(日) 21:50:42 ]: >>712
インデントにうるさいおまえと一緒だと疲れる
714 名前：デフォルトの名無しさん [2007/10/14(日) 22:33:45 ]: インデントにうるさい言語があったよな。おまえはそれを使ってればいい
715 名前：デフォルトの名無しさん mailto:sage [2007/10/14(日) 22:53:03 ]: ぱいそん
716 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 01:28:48 ]: 複人数開発でインデントにうるさいのは当たり前だろ。
コーディング規約なんだから。
717 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 01:54:18 ]: インデントなんか IDE が勝手にするだろ。
保存時に規約に沿うように自動フォーマット。
気にすんのはエディタ使ってるおっさんだけだ。
718 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 11:38:51 ]: 改行位置は勝手にやってくれなくないか？
719 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 11:50:20 ]: 今時のIDEならやってくれなくなくない？
720 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 12:53:26 ]: Eclipse使えば自動フォーマットもすごいカスタマイズできるよ。
改行の位置も、(俺はコードの単位を明示的に分けたいから有効にはしないけど）
設定すればできる、と思う。
721 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 16:43:38 ]: 既にインデントは「する」ものじゃなくて「される」ものだろ。
人間がやるのは、内容の記述だけで、その整形は完全にIDEまかせ。
でも、eclipseできれいにインデントできないって理由で、仮引数へのアノテーションをためらう本末転倒な俺ガイル
722 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 17:03:49 ]: 細かい事気にしすぎ。
723 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 17:35:52 ]: >>721
見やすさのためのインデントはそれでいいんだけど、
Pythonのようなインデント自体が括弧の役割をする言語ではまた別の話だよね。
724 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 17:38:12 ]: 人の書いたプログラムなど見ないで済むように偉くなれ。
725 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 17:39:06 ]: >>723
とは言っても、Pythonでも見やすいインデント、というのはあるわけで。
726 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 18:05:18 ]: ト・コ・ロ・デ

JDK7 build22
ttp://download.java.net/jdk7/changes/jdk7-b22.html
ttp://download.java.net/jdk7/binaries/

SwingWorkerのスレッドプールを使う処理が書き直されたらしい。
シャットダウンフックを使うようになったとかなんとか。
727 名前：デフォルトの名無しさん [2007/10/15(月) 18:40:16 ]: Javaは原則フリースタイル系統の言語だし、インデントはどうでもいいと思うが？
コーディング規約が別にあるとかいうならそれに従うまでだし。
728 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 20:45:32 ]: Cとかに比べれば相当コーディング規約はしっかりしてると思うが
729 名前：デフォルトの名無しさん mailto:sage [2007/10/15(月) 21:48:21 ]: しっかりしているのは認めるが、しかしそれは言語仕様ではない。
インデントも含めて、コーディング規約も次世代に入れて欲しいと願っているのだろうか。
730 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 01:17:12 ]: >シャットダウンフックを使うようになったとかなんとか。
使い方によってはwinでコケまくりだな。

昔よくフォーラムで流れたjavawからシャットダウンフックが起動しないってのが復活するんじゃない？
731 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 03:00:16 ]: >>729
そこまですると、やり過ぎではなかろうかと思う。
俺はとりあえず括弧とif, for, whileの書式さえ統一されてればいいと考えてる。
732 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 03:16:45 ]: まあもういいんじゃないか。そのコーディングとらやの話は。
733 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 10:56:12 ]: 20年以上前、ACM SIGPLAN Noticeでも、
インデントの話は禁止になったことがある。
734 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 14:07:05 ]: ↓↓↓次世代Javaの動向↓↓↓
735 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 14:11:07 ]: 命名規則とインデントはどうやっても宗教戦争になっちゃうからね。
736 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 17:12:35 ]: まあもういいんじゃないか。そのコーディング虎屋の話は。
737 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 21:26:53 ]: コーディングとらやの羊羹
738 名前：デフォルトの名無しさん mailto:sage [2007/10/16(火) 21:53:01 ]: とらやの話か。
739 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 01:35:40 ]: 虎屋の話と聞いて飛んできますた。
740 名前：デフォルトの名無しさん [2007/10/17(水) 01:51:43 ]: どうしてこうも人は争いの種を作ってしまうんだろうか
741 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 01:56:03 ]: Javaの世界なのにJava以外の前提（CやC＋＋）を持ち出したのが原因。
742 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 01:58:35 ]: 人は人、自分は自分。偉い人には分からないのです。
743 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 02:23:48 ]: 誰もC/C++の話はしてないが
744 名前：デフォルトの名無しさん [2007/10/17(水) 02:37:55 ]: で、次世代はどーくるわけよ？
745 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 05:04:25 ]: >>742 偉い人には分かるんじゃないか？ん？
746 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 07:58:18 ]: 俺はJavaの標準コーディング規約には満足してるけどな。
C#の、先頭を大文字にする記法や、プライベートフィールドの先頭にアンダーバーを付ける記法に比べれば、
よっぽどスマートだよ。
747 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 08:49:20 ]: Rubyを侮辱するのは止めてください。
748 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 11:36:31 ]: ﾜﾛﾀ、Rubyのコーディング規約はそうなってるのかｗ
749 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 12:23:57 ]: 規約でなく、言語仕様だね。@で始まるとメンバフィールドになる。
750 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 13:07:54 ]: 大文字で始まるとimmutable。> Ruby
751 名前：デフォルトの名無しさん [2007/10/17(水) 15:10:32 ]: C#はVCと同じくMSのキモサモサが良く出ている言語だと思う
752 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:05:50 ]: C#で画面を作るとコントロールを描画している過程が見えるからなぁ
753 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:13:23 ]: C#出たころからｺﾞﾃｺﾞﾃとJavaにいろんな機能がつき始めたよな
754 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:16:12 ]: 最近のJavaは美しくないというか崩れてきてる感があるな
755 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:21:23 ]: genericsとannotation(とprintf)くらいで十分だったのにな
静的型言語でgenericsなしとかﾊﾞｶじゃないかと思ってたが今はいらんのつけすぎ
756 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:38:36 ]: まぁでも早くC#に追いついて欲しいとは思うし難しいところだ
757 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 16:38:40 ]: >>754 具体的にどこ？
>>755 といっても数年後にはクロージャとかenumとか使うようになるよ。
758 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 17:27:17 ]: 今だに使われるFORTRAN77は不滅だよ
759 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 17:32:40 ]: >>754
なんとなくだがいいたいことはわかる。初期の頃の簡潔さは失われつつあるからな。
それでも、頻繁にクロージャ用無名クラスを作ってるようなら、クロージャを導入する意味はあると思う。
760 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 19:16:44 ]: クロージャは必須だろ。
プロパティは辞めて欲しいが。
761 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 20:38:25 ]: プロパティを作ってほしいとも思うが、セッターゲッターと互換性のないプロパティ作られるのも困る
762 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:15:11 ]: セッターゲッターと互換性あるプロパティって何？？？
763 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:20:36 ]: obj.property = value; が obj.setProperty(value); に、
value = obj.property; が value = obj.getProperty(); に、
展開されるような構文糖プロパティの事じゃね？
764 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:31:18 ]: バージョンアップする限りJavaは肥大し続ける。

Java自体が陳腐化するか、
言語として互換性を捨て新たな言語に生まれかわらないとな。
765 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:39:36 ]: どれだけ互換性捨てるかにもよるけど、新たな言語に生まれ変わらせるぐらいなら
Javaを捨てて、JVM用の新言語を立ち上げた方が既存のプログラムに影響少ないし
過去のしがらみ捨ててドラスティックに変えられるしで、良いと思うがね。
766 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:47:09 ]: それはまだとっておこう。
767 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 22:49:25 ]: 新たな言語になったって、
バージョンアップのたびに肥大化し続けるのは変わらんだろうし、
時間が経つにつれ陳腐化するのは止められないだろうし。
768 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 23:10:19 ]: Javaのクロージャで拘束変数の扱いはどうするつもりだろ？
楽なのは匿名クラスと同じでstatic finalな定数だけにするか、
拘束変数は必ずコピーにする方法なのだけど。
769 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 23:37:14 ]: 草案によって違う。

本命っぽい BGGA だと、
www.javac.info/closures-v05.html の Closure Literals にある
> All free lexical bindings (中略) are bound at the time of evaluation of the closure literal
> to their meaning in the lexical context in which the closure literal appears.

CICEだと、docs.google.com/View?docid=k73_1ggr36h
の III. Local Variables From the Enclosing Scope あたり、

FCM だと、docs.google.com/View?docid=ddhp95vd_6hg3qhc
B. Common rules and mechanisms にある
> Local variables from the enclosing scope may be accessed, both read and write
770 名前：デフォルトの名無しさん mailto:sage [2007/10/17(水) 23:51:32 ]: BGGA だと、受け取り側が java.lang.RestrictedFunction しかうけとらねーよと明示しておけば、
final がついてない局所変数使ってるクロージャリテラルは変換できなくてコンパイルエラーになる
とか、そーゆー制限も考えられてるみたいだけど。
771 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 02:47:35 ]: レキシカルクロージャがいいな。

javaはVMも言語もクラスファイル仕様も互換性確保は相当なものだが、ライブラリ詰め込みすぎが悪い。

#rubyは言語界のモルモン教
772 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 03:08:54 ]: どの辺りがモルモンしてる？
773 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 11:08:02 ]: 製作者がモルモン教徒
774 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 18:24:15 ]: というかruby信者がモルモン信者と同じ臭いがする。
775 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 20:37:37 ]: Macユーザーで、はてなユーザーで、rubyユーザーでケータイがMEDIA SKINあたりだったら、
もう半径5mには入りたくない感じ。
聞きたくもない長所の押し売りをえんえんと聞かされそう。
776 名前：デフォルトの名無しさん [2007/10/18(木) 20:49:07 ]: それ、なんて宗教？
777 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 21:13:55 ]: >>775
プログラマーはあんましMAC使わないとおもうんだが。
778 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 21:16:36 ]: MacもWindowsも使う。

どれかしか使わないというのが、言語論争と同じく不毛な流れかな？
javaもrubyもperlもpythonも適材適所に使えばいいじゃない
779 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 21:45:47 ]: >>778
たしかに其れが一番かっこいい。
780 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 21:59:27 ]: rubyはperlとpythonのパラダイムに影響受けてるからそっちの分野に食い込んでくるんだよ無理やり。
rubyの影響を受けたGroovyは言語が止まってるから問題ないが。

結局、JRubyとGroovyとJythonはScripting APIに組み込まれるのかね？
要らん気がする・・・。
781 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 23:46:52 ]: JavaFXは偉大
782 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 23:47:28 ]: なにが？
783 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 00:04:32 ]: 手元にあればmac使いたけどな。
だけどwinの方が安いからmac使う機会がないだけ。
784 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 00:13:40 ]: 普通にlinux使えよ
785 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 00:16:36 ]: linuxは普通なのか？
786 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 00:58:05 ]: MacメインでWindowsも使うJava好きのモルモン信者ですが、何か？
787 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 01:23:42 ]: >>777
おいおい、Macはちょっとバージョンアップが遅いとは言え、
JREがプレインストールだし、JDKもインストールCDに付いているぞ。

Javaアプリを配布する環境としては優秀なのだ。
まだ、↓だけどな。
$ java -version
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)
788 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 01:46:49 ]: アホ。釣られんな。
789 名前：デフォルトの名無しさん [2007/10/19(金) 02:05:16 ]: >>777
君、アタマ悪イッショ。
オンモ二デテミ。
君ノ馬鹿サガ…
790 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 02:54:19 ]: アホ。釣られんな。
791 名前：デフォルトの名無しさん mailto:sage [2007/10/19(金) 09:53:36 ]: モルモンっていうと家畜の内臓がどうしても思い浮かぶ
792 名前：デフォルトの名無しさん [2007/10/19(金) 23:47:33 ]: 未だに1.6が出てなかったのか…＞Mac
793 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 00:26:03 ]: 酷い話でしょ？コミュニティに任せた方がいいような気がするよ。
794 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 00:34:37 ]: MacでJavaってそんなに使われてる？
795 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 00:46:49 ]: V2Cを動かすのに必須。
これが無くなるとMacを捨てなくては・・・とまでいう重要ソフト。
796 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 01:00:03 ]: fx＋bbs2chreaderでいいじゃない
797 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 01:04:06 ]: icedteaだっけ？フリー版のないのか
798 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 01:06:55 ]: Java SE 6 Update N
https://jdk6.dev.java.net/6uNea.html

ブラウザプラグインの書き直し
ajaxian.com/archives/ken-russell-on-the-new-java-plugin

この辺りの改良でクライアントサイドの勢いがついてほしい所だな。
799 名前：デフォルトの名無しさん mailto:sage [2007/10/20(土) 11:18:05 ]: java6のSwingは、結構Windowsのクライアントサイドでも戦える形になってきたかなと思う。
5と6での差異なんて、数ドット単位のデザインの違いが主なんだけど、その数ドットの差が大きい。
あとはスプリットボタン、シェブロンあたりのウィジェットが追加されればなー。
800 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 00:47:19 ]: >>798
> The JVM also runs in its own OS process,
> so if the JVM crashes it doesn’t affect the browser.

へー、便利じゃんって、オイッ！
801 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 01:14:37 ]: このJVMは独自のプロセスでも動くので、
JVMがクラッシュしたとしてもブラウザには影響を与えません。

そんなに変か？
802 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 10:03:06 ]: 今まで、さんざんブラウザを巻き沿いにしてきたみたいだよなw
803 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 10:18:23 ]: 巻き添えっていうか、一気に重くなってその負荷で落ちたように見えることは多かったけど。
ブラウザとは別のプロセスで実行できるってセキュリティ的に大丈夫なんだろうか。
ただでさえVistaでUACとかいうややこしいシステムをとってるのに。
804 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 10:27:36 ]: ↑大丈夫だからやったんじゃないかね
805 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 11:47:14 ]: >>803
まずくなる理由が見つからんが…
806 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 12:25:31 ]: >>803
Javaアプレットは、なぜネットワークからダウンロードしてきたコードを実行しても
安全なのか知りたければ、「バイトコードベリファイア」「サンドボックスシステム」
について調べてみるといい。
そうすれば、別プロセスで動作させても安全な理由がわかる。
807 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 12:27:37 ]: >>805
Vistaで導入された鬱陶しい機能の一つに、UACとかいうのがある。
これは、セキュリティ対策のために、ブラウザの権限を制限するもんだ。
だから、ブラウザ上から呼び出されたプロセスには、なにかと制限がかかる可能性がある。
特に、ローカルのリソースにアクセスするようなのは、実行できないかもしれない。

まあ、>>804のいうようにわかってやってるはずだから、対策がないわけがないんだけどね。
808 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 17:03:53 ]: >>807
>Vistaで導入された鬱陶しい機能の一つに、UACとかいうのがある。
>これは、セキュリティ対策のために、ブラウザの権限を制限するもんだ。

それはIE7の「保護モード」であって、UACではない。
809 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 18:32:03 ]: >>808
そうだった。
今思い浮かんだんだが、もしかして保護モードを回避するために別プロセスに分けたのか？
だとしたら、俺が言ってたことはまるで逆だったのか。
810 名前：デフォルトの名無しさん [2007/10/21(日) 19:18:12 ]: ↑だからここは君の浅知恵を披露する場ではないようだが
811 名前：デフォルトの名無しさん mailto:sage [2007/10/21(日) 20:14:23 ]: なんで次世代Javaスレに猿が混じっているのか不思議
812 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 10:35:00 ]: ↑猿の脳みそを持つ男
813 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 11:58:57 ]: ↓ご立派な人登場。
814 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 14:32:22 ]: 呼んだ？
815 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 16:23:51 ]: おいおい、俺を差し置いてか？

ゴスリンが、JDK on Mac OS Xについて少し喋ってる。
blogs.sun.com/jag/
816 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 16:52:06 ]: イヤ待て、もっと大変な事言ってないか？
オレには、MacOSXにZonesが載るって書いてるようにも読めるぞ。
流れ的にそう明言してないが・・・
817 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 18:52:08 ]: >>816
Zonesってなに？
818 名前：デフォルトの名無しさん mailto:sage [2007/10/22(月) 18:59:43 ]: スレ違いだが、
Solaris:BSD:Linux≒Zones:Jail:Vserver
819 名前：デフォルトの名無しさん [2007/10/22(月) 22:37:44 ]: ｚ
820 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 04:27:30 ]: sunはJava SEの後につく数字をマイナーバージョンとリンクさせているように見えるけど、
メジャーバージョンが上がる時にはどうするつもりなんだろう。
Java 2 SEとかにするのかな
821 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 06:18:24 ]: >>820
予想
java version "1.6.0_0x"
java version "1.7.0_0x"
java version "1.8.0_0x"
java version "1.9.0_0x"
・・・わくわく
java version "1.10.0_0x"
・・・なんじゃそりゃ～
822 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 08:57:17 ]: >>820
Java 2 Platform, Standar Editionとかぶりすぎ
>>821
そういうマイナーバージョンの桁上がりの問題じゃないからw
823 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 10:17:44 ]: メジャーバージョンが上がるときの対策
・Javaのあとに新しいバージョンだとわかるようなコード・名前・別名をつける
・Java自体の名前がかわる
・何事もなかったかのようにバージョン表記統一
824 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 14:30:33 ]: >>821
前にlinuxのソフトウェアでndiswrapperっていうのを使ってたんだが、
使用してるバージョンが1.7で、最新のバージョンが1.21だったのを1.2.1だと勘違いして
なんでバージョンダウンしてるのかすごい悩んだことがある。
825 名前：デフォルトの名無しさん mailto:sage [2007/10/23(火) 16:31:30 ]: SunOSとSolarisは、
Solaris 7から、SunOS 5.X=Solaris Xって関係で、
5ってのはkernelのメジャー番号。Xは共通の連番。

だからこれからJava/JDKも7, 8, 9, 10, 11と連番が上がっていって、
JVMの実装が大きく変わった時に、
連番とは関係なくJDKのメジャー番号が1→2と予想。
826 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 19:07:24 ]: JDK7 build23
ttp://download.java.net/jdk7/changes/jdk7-b23.html
ttp://download.java.net/jdk7/binaries/

なんか今回は実質的な進捗なさげだな。
「ソースのスペースを掃除したよ」って。
なんか行き詰まってるときの作業だろ。

でも2週間に1ビルドのペースが出てきたのは評価したい。
827 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 21:05:23 ]: クロージャのプロトタイプ発表とかどうとかは、どうだった？
828 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 23:07:29 ]: クラス注釈に@RAIIとかサポートされたらいいな。
必ずスタックに乗るように解釈させて、スコープ抜けると必ずfinalizeされる。
メンバ内も含めてthisが代入または引数にされた場合は、コンパイルエラーとするとか。
829 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 23:20:54 ]: ７は5よりもいろいろと、てこもりで楽しみだな。
830 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 01:50:16 ]: >>828
C言語のregisterとかと同じで、最初のうちは最適化義務はなく将来対応するとか言っておいて、
そのうち最適化が進化したので必要ないから無視するよってなるような気もする。
831 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 05:06:57 ]: なんかもうJavaはIDE前提の言語として突き進んでほしいなあ。
言語仕様もとにかくIDEでサポートしやすい方向で。
832 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 09:24:07 ]: >>828
finalizeされるタイミングを陽に指定できることは除いて、
今やescape解析の仕事です。
そんな時代遅れなものが入るわけがない。
>>831
馬鹿丸出し。
833 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 11:27:07 ]: >>832
ゴスリングのこの発言があったタイミングで
バカ丸出しと脊髄反射するほうがバカ丸出し
www.atmarkit.co.jp/news/200711/07/techday.html
834 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 11:50:46 ]: そんなの知ってるw
その解釈こそ馬鹿丸出しじゃん。
IDEで出来ることは、IDEでやればいいんだから。
言語を糞仕様にする必要はない。
835 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 13:04:43 ]: >>194
Jakarta JJarのことか？
MavenにもJJarは同梱されているんだが
836 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 13:19:03 ]: SunはSolaris向けのIPSを発表したしなあ。
opensolaris.org/os/project/pkg/documents/

最近、言語ごとにパッケージ管理/配布システムがあって困惑気味です。
837 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 19:31:56 ]: ここにはエスケープ解析を研究してる奴いるから聞きたいことあれば聞いとけ。
838 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 20:58:50 ]: Googleで検索すればすぐでてくる内容しか書かれてないのに研究だと？
839 名前：デフォルトの名無しさん mailto:sage [2007/11/11(日) 06:30:11 ]: クロージャの演算子 => , {int=>int}は他のなかったのかな？もう決定ぽいけど。
{int x=>x+1}とかぱっと見どうかと
840 名前：デフォルトの名無しさん mailto:sage [2007/11/12(月) 15:07:20 ]: lambda見なれてしまったから、他はなんでも違和感がある。
だからどうでもいい感じ。lambdaキーワードはあり得ないし。
Haskellみたいに\ってのもどうかと思うしさ。
841 名前：デフォルトの名無しさん mailto:sage [2007/11/12(月) 23:40:09 ]: >>839
1.5がでるときにGenerics見て、こんなのJavaじゃねぇって書き込みがいくつかあったよな
今、そんなこと言ってる奴いないだろう。慣れればそれが普通に見えてくるはず
842 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 00:10:57 ]: プロパティのアクセス演算子は
c->p=x
x=c->p
で決定なのか？
843 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 00:40:12 ]: >>842
いつの情報だ、それは。
844 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 01:03:03 ]: 結局Javaっていっても現状Web用途がメインなんだから
Servlet&JSPのほうがもっと良くなってほしい。

JSPがダメすぎてどうにもならない。
845 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 01:08:22 ]: JSP、JSF、VelocityServlet、Wicket・・・好きなもの使え。
846 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 01:10:41 ]: >>844
ここはSEのスレなんだよ。
そんな呆けだから(ry
847 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 01:36:26 ]: >>843
え、古かった？
じゃ、今はなんだよ
848 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:20:28 ]: >>846

ていうか標準のView仕様くらいもうSEに含めろっちゅう話やねん。
JSPにしても単なる条件分岐記述するのに別ライブラリダウンロードさせるってどないやねんって話やねん。

スクリプティングサポートする暇あったらテンプレートエンジンサポートしたほうが人気出るねん。
849 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:29:59 ]: スクリプトレットの存在も知らなければ
テンプレートエンジンはスクリプトエンジンのひとつに過ぎないという実態も知らないのか？
テンプレートエンジンなんぞとっくにサポートされてるっての
850 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:39:48 ]: >>849

おい、JSP2.1の時代にスクリプトレット使ってんのかよ・・・
851 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:41:43 ]: お前が使いたいだけだろ、お前って御託だけで使い分けもできないのな
852 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:45:42 ]: Java系の開発者って世の中のニーズが読めないやつばっかだよな・・・
853 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:51:53 ]: 典型的なかまってちゃんだな、JCPのこと調べたらJavaは諦めてPHPでもやっとけ
854 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 02:59:26 ]: どっちにしろDerbyなんかSEに組み込むより、Viewのほうが先だろ・・・常識的に考えて・・・
855 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 03:01:41 ]: かまってちゃんとわがままちゃんって同じ匂いがするんだよな。２ｃｈの経験上
856 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 04:23:08 ]: >>848
頭悪～
Web制作板に行きなよ。
このスレはまだ早いよ。
857 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 15:25:07 ]: >>82
これには何かぐっと来たぞ
858 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 01:06:38 ]: >>854
ViewならSwingがあるじゃねぇか。
859 名前：デフォルトの名無しさん mailto:sage [2007/11/15(木) 01:08:16 ]: お前らこれ以上XSLTさんを泣かすな
名実ともにSEのViewだろ
860 名前：デフォルトの名無しさん mailto:sage [2007/11/16(金) 18:41:58 ]: 名実が伴っているなら泣くこともないだろうw
861 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 18:53:57 ]: Extension Methods とか出てる。
gafter.blogspot.com/2007/11/closures-prototype-update-and-extension.html

どうなんだろ？嬉しい事は嬉しいけど、これって名前空間汚れるような。
これが許されるなら、クロージャも closure.invoke(argument);
じゃなくて closure(argument); したい。
862 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 19:04:27 ]: D言語にある機能だってのは知ってるけど、この機能の初出って何だろうね
863 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 19:14:58 ]: そう書くことで綺麗に気持ちよく書けるものはどれくらいあるのかね
864 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 19:27:54 ]: >>863
java.util.List みたいな published interface にメソッド追加するのが主な目的ってのはいわずもがなだけど。
他の使い道ってなんかあるかね？
865 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 19:44:36 ]: 例えばこんな感じのがあれば、それなりに便利だと思うよ。
int UnicodeUtils.getCodePointCount(Charsequence src, int off, int len);
int UnicodeUtils.getCodePointCount(char[] src, int off, int len);
int UnicodeUtils.getCodePointAt(Charsequence src, int index);
int UnicodeUtils.getCodePointAt(char[] src, int index);
866 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 20:02:23 ]: >>865
char[] はともかくとして、String も StringBuilder も StringBuffer も、
codePointCount や codePointAt を持ってるはずだぞ。
CharSequence で持ってないのって java.nio.CharBuffer ぐらいか？
867 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 20:02:25 ]: こんなダサイの入れるくらいなら、
Haskellのtype classとかC++のconceptみたいな
generic programming支援の機構を入れて欲しいわ。
868 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 20:24:34 ]: interfaceで扱う事に意味があるんじゃないの。例えばC#だけど
List<E>.ForEach(delegate(E)) みたいなのがあるけど、IList<E>じゃ使えなくて困惑したことがある。

重複したときはエラーかオリジナルのオーバーロードどちらを優先するんだろう。
interfaceのままでもリフレクションで解決とかもいいけど、それは遅くなるか。
869 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 20:35:45 ]: >>868
それは published interface の話じゃなくて？

そーいや、C# は 3.0 で extension method 入るんじゃなかったか？
870 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 20:59:46 ]: static importはIDEと相性が悪い印象があってあまり使われてないけど
これが導入されたらIDEに第一引数でサーチいかせる感じで使われ出すんじゃないかな。
871 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 21:29:37 ]: やっぱpublished interfaceにメソッド追加（したように見せかける）以外に使い道ないんじゃ？
872 名前：デフォルトの名無しさん mailto:sage [2007/11/23(金) 21:56:47 ]: 内部構造はまったくいじれないしな
873 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 22:09:42 ]: Javaってプライドとかないの？
874 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 22:19:37 ]: ttp://java.sun.com/javase/ja/6/docs/ja/api/index-files/index-16.html
無いね。Java7 でもきっと無い。
875 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 22:19:46 ]: Javaのプライドって何のプライドよ？
876 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 23:24:42 ]: 言語としてのプライド
877 名前：デフォルトの名無しさん mailto:sage [2007/11/25(日) 23:27:34 ]: なんかアホの子が出現してるな
878 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 11:50:05 ]: >>861
> これって名前空間汚れるような。

その点、リンク張られているExpanderの方がまだいいね。
879 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 13:59:55 ]: >>875
Java使いが集まって、大晦日に闘う。
880 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 14:17:23 ]: Gosling緊急参戦！

とかなら見に行く。
881 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 14:50:30 ]: >>879
冗談としては面白くないけど
本当にやったら面白そうだな、それ。
882 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 17:48:38 ]: >>881
想像したらわろた
883 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 18:07:02 ]: >>879
何で戦うんだよwwwコーディングかwww
884 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 19:52:13 ]: JavaOne Tokyoのときみたいに、プロレス
885 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 22:05:45 ]: そうね、ここはコーディングでといいたいところを
ぐっとこらえて、総合ルールでやってもらった方が
盛り上がるね！
886 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 23:12:33 ]: じゃあ多重継承もfriendも属性も継続もありでいいんだな。
887 名前：デフォルトの名無しさん mailto:sage [2007/11/26(月) 23:14:37 ]: 属性って？ annotation じゃダメなん？
888 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 10:35:10 ]: >>880
Goslingが和太鼓たたきながら、
「本物のプログラマでてこいや！」
889 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 11:18:22 ]: 本物のプログラマはPascalを使わない―――Javaも使わない。きっと。
890 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 18:39:40 ]: 本物のプログラマだなんてガキみたいなこと言ってるうちは、
その本物のプログラマなるものにはなれんだろうな
891 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 18:57:17 ]: 何を使うんだろう。やっぱりLisp？
892 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 19:37:41 ]: >>890
本物のプログラマネタくらいは知っておこうぜ、本物のプログラマならｗ
ググればすぐに出てくるよ
893 名前：デフォルトの名無しさん mailto:sage [2007/11/27(火) 19:37:47 ]: ホンモノのプログラマになる極意は、ホンモノの真似をしないことである
894 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 17:06:57 ]: ふるいネタだな。キッシュを食わないとかいうヤツだっけ。
895 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 22:21:39 ]: ホンモノのプログラマはデスマーチで2chに書く暇などありません。

偽者の人生が楽しい
896 名前：デフォルトの名無しさん mailto:sage [2007/11/28(水) 23:07:44 ]: 業務が設計中心になってからはデスマはないなぁ。
設計工程に現役プログラマが携わらないことの危険性が
頭でもなく心でもなく体で理解したｗ
897 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 01:38:43 ]: よほどヘボいSEとやってたんだな。
898 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 13:16:30 ]: プログラマーは設計書が全然上がってこねーぞと文句を言っているはず
デスマの原因作ってるのはお前だｗ
899 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 21:09:42 ]: ↑こいつ文盲？
900 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 21:13:46 ]: うん
901 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 22:11:53 ]: 宣言側の拡張メソッドだってさ。
digital-sushi.org/entry/declaration-site-extension-methods/

ユーザ側で拡張すると、メソッド名の衝突とか面倒くさいって話らしいけど。
902 名前：デフォルトの名無しさん mailto:sage [2007/11/29(木) 22:25:27 ]: 宣言側でやっても
interface A { void method() import static SomeClass.method; }
interface B { void method() import static AnotherClass.method; }
class C implements A, B { }

があって、

C c = new C();
c.method();

したとき、どっちのメソッド呼ぶかって曖昧さが残るわな。
903 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 01:37:50 ]: 曖昧な場合はコンパイルエラーになるだけ
904 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 02:11:30 ]: >>901
馬鹿馬鹿しい…
905 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 02:20:12 ]: >>903
いや、use-site でも declaration-site でも曖昧なケースが出てくるのは同じじゃねーかって話。
906 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 22:05:42 ]: LINQのような糖構文がほしい・・・

やっぱいらない
907 名前：デフォルトの名無しさん mailto:sage [2007/11/30(金) 23:13:41 ]: ハイバーネートだかなんだかのO/R マッピング使ったらええんとちゃう？
俺もLINQはいらんけど、varはほしいな。
908 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 14:03:49 ]: JDK7 build24
ttp://download.java.net/jdk7/binaries/
ttp://download.java.net/jdk7/changes/jdk7-b24.html

あれ？変更点からっぽ？
909 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 16:32:16 ]: >>906
今更だが、糖衣構文を糖構文とは略しないでしょ。
910 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 17:05:48 ]: syntax sugarを糖構文と訳すのはアリだと思うが。
911 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 17:08:07 ]: >>910
マジすか・・・。略語じゃなくて訳の違いだったわけか。
912 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 18:35:49 ]: 「糖衣構文」と「構文糖」は聞いたことあるけど「糖構文」はあまりないな。
913 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 18:35:52 ]: >>910
うーん、それはやめた方がいいと思う。
糖衣構文がうざければ、シンタックス・シュガーでいいし。
914 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 21:23:36 ]: >>908
JDK6u3と比べて、アプリケーションのメモリ消費量が減っているような気がする。
915 名前：デフォルトの名無しさん mailto:sage [2007/12/11(火) 01:19:49 ]: Java SE 6 Update N Early Access build 08キタ。新しいJava Plug-Inが入った模様。

JDK 6u10 build b08
https://jdk6.dev.java.net/6uNea.html
download.java.net/jdk6/6u10/promoted/b08/changes/jdk6uN-b08.html
916 名前：デフォルトの名無しさん mailto:sage [2007/12/11(火) 13:13:20 ]: >>908
b23 と b24 は TeamWare から Mercurial にリポジトリを移動しただけで、全く同じものらしい。
weblogs.java.net/blog/kellyohair/archive/2007/12/openjdk_mercuri_7.html

フォーラムで出てた。
forums.java.net/jive/thread.jspa?threadID=34125&tstart=0
917 名前：デフォルトの名無しさん mailto:sage [2007/12/11(火) 13:17:01 ]: >>905
あれって use-site でというか、static import で use-site extension methods やると
既存の static import 使ってるコードで問題出るかもって話じゃないの？
918 名前：デフォルトの名無しさん mailto:sage [2007/12/11(火) 13:56:19 ]: >>916
ナルホド。開発者の使ってる環境が知りたいな。GUI無しかな？
Teamwareとコマンドラインの体系は似てるし、CUIベースでかな？
それとも開発者は、Netbeans使ってるから最近出てきたMercurialのプラグイン使ってる？
919 名前：デフォルトの名無しさん mailto:sage [2007/12/21(金) 12:17:34 ]: まだ草案レベルにもなってない例外関連のアイデアらしい
www.javac.info/Multicatch.html
www.javac.info/Rethrown.html

multicatchは欲しい。
multicatchがあれば、rethrownはいらないような気もする。
920 名前：デフォルトの名無しさん mailto:sage [2007/12/21(金) 12:32:25 ]: "Exception1 | Exception2" って型ができるのかとおもうと、おらわくわくして（ｒｙ
型とか安全なのかな。とりあえず実現できなくはないと思うけど。
921 名前：デフォルトの名無しさん mailto:sage [2007/12/21(金) 12:47:57 ]: 基本的には「複数の catch節をくっつける」ってアイデアで
型安全どーするの？とかの問題は先送りされてるんじゃね？

Exception1 | Exception2 って型も共通の親クラスのメソッドしか
呼べないんじゃないかと思ってる。下手にcatch節以外でも
Exception1 | Exception2って型が使いたいとか騒ぐと、
仕様考える連中が面倒になってポシャるんじゃないかなとか思ったり思わなかったり。

っつーか、Rethrown はその辺が面倒になったから出てきたアイデアなんじゃ？
922 名前：デフォルトの名無しさん mailto:sage [2007/12/21(金) 16:49:50 ]: catch(Exception1 | Exception2 ex) { ex.Foo(); }

から

catch(Exception1 ex) { ex.Foo(); }
catch(Exception2 ex) { ex.Foo(); }

は機械的に作れるから、まあ何とかなるんじゃない？
923 名前：デフォルトの名無しさん mailto:sage [2007/12/21(金) 17:24:21 ]: 複数の例外型について handler_pc の位置を共通にするようにするんかと思ってた。

VM仕様で handler_pc はユニークにしろ、とかって制約ついてたっけ？
924 名前：デフォルトの名無しさん mailto:sage [2007/12/23(日) 21:24:10 ]: ConcurrentHashMap<CustomKey<Exception, Handler>, Executor<Runnable>> とかすればいいと思うよ。
925 名前：デフォルトの名無しさん mailto:sage [2007/12/29(土) 10:41:26 ]: www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java
クロージャ入れるのも一苦労じゃ
926 名前：デフォルトの名無しさん mailto:sage [2007/12/29(土) 11:01:42 ]: おれクロージャいらねぇ派だがどうせ新機能入れるなら個人的には多値返却かAda風の型定義がほしいかな。
927 名前：デフォルトの名無しさん mailto:sage [2007/12/29(土) 12:01:37 ]: 皆でScalaへGO!
928 名前：デフォルトの名無しさん mailto:sage [2007/12/29(土) 12:28:15 ]: そーいや、ム板にscalaスレあったっけ？
929 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 00:05:55 ]: C#3.0さわってみたが進化してるなあ。
lambda関数が int a => return a + 10 みたいな感じでインラインに書けたりと、
スクリプト言語ラブな人は嬉しい機能がどっさり。
思わず浮気しそうになる・・・。
930 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 00:22:31 ]: >>929
> lambda関数が int a => return a + 10 みたいな感じでインラインに書けたりと、
これreturn要らないんじゃ？

BGGAのクロージャの構文、セミコロンがついたりつかなかったりで
局所リターン文だったり単なる式文だったりっつーのはバグの原因になりそうな。
ラムダ式っぽく使うならreturn書きたくないってのもわかるんだけど……
その点、C#の構文はよくできてると思う。
931 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 00:55:17 ]: その程度ならecma262で十分。
932 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 01:05:59 ]: >>930
それだけじゃなくて、C#3.0のラムダ式で int a みたいにパラメタ型を明示する場合はパラメータリストに括弧が必要なはず。
933 名前：デフォルトの名無しさん [2007/12/30(日) 03:15:35 ]: >>926
それだとクラスを返しても全く同じだけど、どう違いをみせたいわけ？
934 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 10:22:01 ]: >>933
戻り値のためにクラスをわざわざ定義するのがめんどいんじゃね？
シンタックスシュガーとしてやってくれると、ちょっと便利かもね、と。
935 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 10:52:00 ]: >>928
ちょっと前に探したときは見当たらなかった。
936 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 11:09:29 ]: JVM系で残っているスレはこれだけだと思う。

Jython、Groovy、JRuby - どれが一番効率的？
pc11.2ch.net/test/read.cgi/tech/1100563765/
Java系スクリプト言語Groovy
pc11.2ch.net/test/read.cgi/tech/1080052050/

落ちないようにJVM系は統一して欲しいなあ。
Scalaは、Javaとの連携除いても、結構いい型システム持っているけど、
単独ではすぐに落ちちゃうと思う。
937 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 16:42:52 ]: >>934
同じくタプルとかも賛成なんだけど、どうもそういうのはJavaぽくないみたい。
面倒だしとかじゃ「違う言語で」とかだから、だから「どう違いをみせたいわけ？」って聞いてる。

少なくとも君の要求ていどならわざわざ文法とか複雑にしなくとも、
Object[] func()
でこと足りるしｗ
938 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 16:58:01 ]: 多値用のGenericsを標準で用意してくれると嬉しいんだけどね。
こっちで用意してもいいけど、それ専用のjarってのもちょっとね。
939 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 18:28:14 ]: 前も出たなこの話題w
俺にいわせりゃ多値引数はあるのに多値返却がないのはおかしいんだけどな
クロージャとかの方が違う言語でやってほしいよ。javaがシンプルさとかけ離れていく
940 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 18:44:28 ]: クロージャって匿名クラスで作るんだろ？
クロージャの生成側のローカル変数は、その時点で固定になるのかな？
941 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 19:08:51 ]: >>940
そのやりかたが2つくらい出てきてどっちにするかまだ決まってなかったんじゃなかったっけ？
942 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 19:23:38 ]: >>769 あたりか。
943 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 19:32:57 ]: あら、割と近めにあったのね。すまんこつ。
944 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 19:35:51 ]: 可変長引数を多値引数って言うのは初めてみたかも。
945 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 20:18:52 ]: 可変長引数のこと言ってたのか。
946 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 20:21:18 ]: たぶん。

いや、はじめてみた言葉だから間違ってるかも知らんけど。
947 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 20:32:39 ]: すまん今作った＞多値引数
とっさに出てこなかったんだよ
948 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 20:39:13 ]: オーバーロードのことじゃなくて？
949 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 20:44:29 ]: 単純に引数を複数渡せるってだけの話だろ
950 名前：デフォルトの名無しさん mailto:sage [2008/01/01(火) 03:36:41 ]: >>949が正解だろ。
単純に引数(インプット)には複数の値を渡せるのに、
返値(アウトプット)が一つしか返せないのはおかしい、という話。

そもそも、大元の関数型言語が(厳密には違うが)一入力一出力だったのを、
手続き型言語で使いやすいよう多入力にしたのが原因。
OOPの思想が確立したときに多出力にすればよかったのだが、折しもCベースのC++が主流だったのでそのまま。
またCPUの最適化の関係もあり、ずるずるとJava, C#・・・と今に至る。

もしJavaで多出力をサポートするなら、
rubyやpythonの返値の扱い（タプル関連)で、シンタックスシュガーが複雑になりすぎてる感があるので、(特にruby)
Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。
951 名前：デフォルトの名無しさん mailto:sage [2008/01/01(火) 10:04:29 ]: 単純に引数1個に制限すれば、対称になって>>950の気は済むってこと？
952 名前：デフォルトの名無しさん mailto:sage [2008/01/01(火) 13:43:46 ]: もはや return は継続の呼び出しで良くね？
953 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 13:56:26 ]: ＞Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。

結局それかよ。それを策定するのが難しいからないんだろ！
おまえが考えて提案したらどうだ？当然英語はできるよな？
面倒って言うのが理由なら、あまり期待しないほうがいいじゃないか。
それと>>950はツッコミどころが多すぎだけど、
JavaはC++辺りと違って理念が実稼動重視（現実的)だから。

>>951もいいと思うよ。でも

Object[] func(Object[]);

で十分。JDK1.0 OK
有用であるが、使うかどうかは任意。
954 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 14:05:23 ]: >>953書いて思ったけど、
というか普通にポインタ(C, C++)理解してるかってことに行き着くと思うよ。
本質的には、ポインタとかデータ構造とかそういうところ。
955 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 16:52:28 ]: ポインタ関係ないな。
参照でいい。
956 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 17:21:18 ]: It is assumed that many value return was realized by JAVA and on earth wants to do what?
957 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 19:02:07 ]: 新年早々とんだ釣りだw
958 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 19:15:55 ]: そうするに偉そうなこといってる>>953はようやくポインタを理解したガキだってこと？
Object[]で戻していいが型の安全を言語側で保証できたらいいねって話なんだが
959 名前：デフォルトの名無しさん [2008/01/02(水) 19:33:42 ]: >>958
痛いおまえはｗｗ晒しあげｗｗ
960 名前：デフォルトの名無しさん [2008/01/02(水) 19:42:24 ]: また宗教ですか？
961 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 19:49:45 ]: >>958
当然英語はできるよな？
962 名前：958 mailto:sage [2008/01/02(水) 19:59:22 ]: おいおいなんだこれ('A`)
>JavaはC++辺りと違って理念が実稼動重視（現実的)だから。
>というか普通にポインタ(C, C++)理解してるかってことに行き着くと思うよ。
こういうのはスルーして俺に総ツッコミかよw
963 名前：デフォルトの名無しさん [2008/01/02(水) 20:00:23 ]: ストールマンのお友達ですか？
964 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 20:03:50 ]: >>958
>>962
英語は当然できるんですか？
965 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 22:57:58 ]: 953 名前：デフォルトの名無しさん[sage] 投稿日：2008/01/02(水) 13:56:26
＞Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。

結局それかよ。それを策定するのが難しいからないんだろ！
おまえが考えて提案したらどうだ？当然英語はできるよな？

961 名前：デフォルトの名無しさん[sage] 投稿日：2008/01/02(水) 19:49:45
>>958
当然英語はできるよな？

964 名前：デフォルトの名無しさん[sage] 投稿日：2008/01/02(水) 20:03:50
>>958
>>962
英語は当然できるんですか？

>>953が何を言ってるのかはさっぱりわからんが、他人の英語の能力に並々ならぬ関心があることだけはわかった。
966 名前：デフォルトの名無しさん mailto:sage [2008/01/02(水) 23:04:05 ]: >>953
> それと>>950はツッコミどころが多すぎだけど、
> JavaはC++辺りと違って理念が実稼動重視（現実的)だから。

C言語のソースがそのままコンパイルできるC++を差し置いてJavaのどこが”実稼働重視(現実的)”なんだww
もしかしてC++をまったくさわったことがないんだろうか？

それと>>950のツッコミどころとやらを説明よろしくww
967 名前：958 mailto:sage [2008/01/02(水) 23:23:15 ]: ああそういう話ね
>>613で出てるけどbugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792で多値はwill not be fixedになってるのよ
で、その理由がjavaはシンプルであるべきだーと。

当然コメントには
ジェネリクスも加わったし昔のシンプルなjavaじゃないじゃん、とか
配列のシンタクスシュガーならJVMに変更いらないだろ、とか
可変引数があるのに戻り値が複数取れないのはおかしい、とかもうすでに散々出てるわけよ。

でそれを踏まえた上での>>939(俺)の
＞クロージャとかの方が違う言語でやってほしいよ。javaがシンプルさとかけ離れていく
だったわけよ

英語が堪能な>>953はそれを踏まえた上で
>結局それかよ。それを策定するのが難しいからないんだろ！
>おまえが考えて提案したらどうだ？当然英語はできるよな？
と言ってるんだよな？（>>950は俺じゃねーけど）
968 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 00:35:05 ]: 他でやれよもう。
969 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 01:59:17 ]: 苦労じゃのう
970 名前：デフォルトの名無しさん [2008/01/03(木) 06:43:34 ]: ストールマンじゃないです。
ゴズリンと友達です。
971 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 06:48:51 ]: 英語で会話できるようになるのは、日本人の夢なのです！
ジーニアス、ジーニアス！
972 名前：デフォルトの名無しさん [2008/01/03(木) 06:51:34 ]: >>966を読んでみても、相当痛いやつだなということだけは分かるw
30台は間違えないねｗ

この様子ならすぐ1000行くけど？どうする？やっちゃう？
973 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 07:30:05 ]: >>962
>>966
おまえに勝ち目はないなｗ
そろそろ目を覚ませよｗ
974 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 07:40:36 ]: 馬鹿の方が声がでかいのは、ゴミ溜めではよくあること。
975 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 09:02:58 ]: それをどうするかが問題なんじゃないか？
976 名前：デフォルトの名無しさん [2008/01/03(木) 10:55:17 ]: また宗教ですか？
977 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 11:32:48 ]: 英語は出来て当然です。
978 名前：958 mailto:sage [2008/01/03(木) 12:24:52 ]: ごめんなさい勝ち目はありませんでした。
今目を覚ましました。
979 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 12:30:35 ]: 次スレ
[Java SE 7] 次世代Javaの動向 6 [dolphin]
pc11.2ch.net/test/read.cgi/tech/1199330977/
980 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 12:43:57 ]: 「間違いない」を「間違えない」と書くやつがまだいるのか
どこの方言だ？
981 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 15:46:40 ]: >>978
早ｗ
982 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 15:57:34 ]: 英語は出来て当然です。
983 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 15:58:57 ]: 今目ってなに？
984 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 15:59:01 ]: 技術書の英語は読みやすいからな
詩を書けと言うと無理だが
985 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 16:08:34 ]: 英語って読むだけじゃなくて書けないとダメなんじゃないか？おじさん英語じゃあるまいしw
986 名前：デフォルトの名無しさん mailto:sage [2008/01/03(木) 19:00:42 ]: >>984
Full in care, car was to became miss note.
987 名前：デフォルトの名無しさん mailto:sage [2008/01/05(土) 01:02:20 ]: This if a pen.
988 名前：デフォルトの名無しさん mailto:sage [2008/01/05(土) 01:54:33 ]: >>986
To be,To be,Ten made To be
989 名前：デフォルトの名無しさん mailto:sage [2008/01/05(土) 16:28:25 ]: エリート狂想曲ﾅﾂｶｼｽ
990 名前：デフォルトの名無しさん mailto:sage [2008/01/06(日) 10:35:13 ]: てｓｔ
991 名前：デフォルトの名無しさん mailto:sage [2008/01/06(日) 23:36:15 ]: あれで夢精を覚えた

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef