07/05/12 08:25:15
前スレ
[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
ｽﾚﾘﾝｸ(tech板)
[mustang] 次世代Javaの動向 3 [dolphin]
ｽﾚﾘﾝｸ(tech板)
次世代Javaの動向 ２
ｽﾚﾘﾝｸ(tech板)
【Java】次世代Java・J2SE1.6の動向【Mustang】
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
07/05/12 08:33:09
まだ5も消化しきれてないのに7なんて・・・・
3:デフォルトの名無しさん
07/05/12 10:29:46
Java FXはFlashみたいな、
瞬間起動→アプリごとの独自スプラッシュだしてnow loading→実行
ができないときついと思う。実際に動くまでが同じぐらいでも、
スプラッシュなしだと体感が長い。
4:デフォルトの名無しさん
07/05/12 11:46:22
乙
5:デフォルトの名無しさん
07/05/12 15:26:03
アプレットって何でいつまで経ってもブラウザ止めちゃうんだろう。
Flashみたいに瞬間起動できるようにならんもんかね。
6:デフォルトの名無しさん
07/05/12 16:29:11
>>5
> アプレットって何でいつまで経ってもブラウザ止めちゃうんだろう。
> Flashみたいに瞬間起動できるようにならんもんかね。
企業サイトでFlash使ったページがあると、必ずskipを押す。
どうせろくな情報がないんだし。
勝手に起動するまえに、起動させるかどうかを必ず聞いて欲しい。
そういう構造だったら、多少遅くても許せる。
7:デフォルトの名無しさん
07/05/12 17:08:43
>>6
そんな個人の好みの話じゃなくてさ。
> 多少遅くても許せる。
↑こう思ってない人の方が圧倒的に多いんだから。
8:デフォルトの名無しさん
07/05/12 17:12:23
ふーん
どんな割合なの？
9:デフォルトの名無しさん
07/05/12 17:13:11
>>7
だからこそFlashにもJavaアプレットも、
瞬間起動できて
(かつ|または)
起動前に起動させるかどうか聞く
というようになってほしい気もする。
>>5>>6>>7のいずれとも別人の横レスすまそ。
10:デフォルトの名無しさん
07/05/12 17:14:20
>>8
蕎麦粉八割、つなぎが二割。ジャマイカ？
11:デフォルトの名無しさん
07/05/12 17:14:28
>>8
FlashとAppletの普及率通りなんじゃね？
12:デフォルトの名無しさん
07/05/12 17:16:14
>>8
ググレ！
13:デフォルトの名無しさん
07/05/12 17:16:17
具体的には？
14:デフォルトの名無しさん
07/05/12 17:18:43
>>8
daemon だよもん
stdio.h スタジオエッチ
15:デフォルトの名無しさん
07/05/12 17:21:16
>>8
一割より低いみたい
男性が多くて耐えられない…
ｽﾚﾘﾝｸ(prog板)
16:デフォルトの名無しさん
07/05/12 17:43:27
>>8
何の割合？
17:デフォルトの名無しさん
07/05/12 17:46:01
>>1
スレタイの右側、Dolphinは止めて、JavaFXにすればよかったのに・・・
18:デフォルトの名無しさん
07/05/12 17:49:06
>>16
Java SE と Java PG の割合。
19:デフォルトの名無しさん
07/05/12 17:50:48
>>17
JavaFXはコケる可能性高いと思ったんじゃね？
とりあえず、dolphinで良いと思うけど。
20:デフォルトの名無しさん
07/05/12 17:53:03
>>19
いやいずれにせよdolphinは止めた方がいいだろ？dev.javaのプロジェクト名もjdk7に変えられて
sunがdolphinというコードネームを捨てようとしているのに
書いてたら混乱するだけでしょ
21:デフォルトの名無しさん
07/05/12 17:57:16
>>20
誰も混乱しないと思うけど。
仮にJavaFX のコードネームが dolphin になってて紛らわしいとか、
仮にMicrosoft が dolphin ってコードネームの製品作り始めてて混乱するとか、
そーゆーのがあれば変えた方が良いかも知れんけど。
22:デフォルトの名無しさん
07/05/12 18:00:48
次世代Javaの動向の前に今発生してるバグを解決しろ
23:デフォルトの名無しさん
07/05/12 18:02:45
>>22
再現条件を詳しく。
24:デフォルトの名無しさん
07/05/12 18:03:34
コード名dolphinが使われなくなっていっても
そのへんは旧称dolphinで通じるだろうし、
とりたてて混乱はないんじゃないの。
関係ないがTEIKADEを思いだした。
25:デフォルトの名無しさん
07/05/12 18:06:19
>>23
うむ
言葉が足りんかった
正しくは↓
おまいら次世代Javaの動向の前に今発生してるバグを解決しろ
26:デフォルトの名無しさん
07/05/12 18:08:42
>>25
もうちょいkwsk!!
27:デフォルトの名無しさん
07/05/12 18:19:31
>>26
だ～か～ら～。「事件は現場で起こってるんじゃない！会議室でアッーー
28:デフォルトの名無しさん
07/05/12 18:23:28
会議室でのグダグダがデスマを招いている事実
29:デフォルトの名無しさん
07/05/13 07:55:24
FX Scriptの format as 文はほしいと思ったJavaPG特有だろうなｗ
現状、インタプリタのコンパイルがとてつもなく遅いから早く、javaバイトコード吐いて欲しいけど
30:デフォルトの名無しさん
07/05/13 14:41:32
>>25
具体的にどれが問題か挙げないと話にならないだろ。
バグ報告見てこいって言うのかい？
31:デフォルトの名無しさん
07/05/13 15:17:02
>>30
「おまいら次世代Javaの動向の前におまいらが書いた糞プログラムにあるバグを解決しろ」
だろ？
32:デフォルトの名無しさん
07/05/13 15:22:26
Silverlightより先に発表したかった
33:デフォルトの名無しさん
07/05/14 23:04:31
お願いですから、Windows LaFをまじめに作って下さい。＞SUN
WindowsだけでClassic、XP、Vistaと3つもあって、面倒なのはわかるけど。
いくらサードパーティのLaFがあるとかいっても、ファーストパーティ標準添付のLaFが
ショボかったら初見でアウトなのよ。
34:デフォルトの名無しさん
07/05/14 23:28:29
>>33
どこが違うってのをスクリーンショット取って送ってあげるとか、
どこを直せば良いってのをパッチ書いて送ってあげるとかした方が建設的じゃね？
ってか、ここで愚痴っても改善されないと思うよ。
35:デフォルトの名無しさん
07/05/14 23:32:27
それいったら２ｃｈなりたたんがま
36:デフォルトの名無しさん
07/05/14 23:37:38
>>35
ヲチだけでも十分成り立ちますがな。
37:デフォルトの名無しさん
07/05/15 08:32:32
>>35
>>33は最初からSun宛てに話してるからなｗ
38:デフォルトの名無しさん
07/05/15 09:15:19
>>37
ここSunの窓口じゃねーし。
39:デフォルトの名無しさん
07/05/15 10:16:28
直接相手に苦情を言えないヘタレの巣窟＝2ch
40:デフォルトの名無しさん
07/05/15 10:29:52
>>39
愚痴ならマ板行ってやれ。あっちはそーゆー板だし。
41:デフォルトの名無しさん
07/05/15 13:50:07
>>38
37だが何故それを俺に言う？
42:デフォルトの名無しさん
07/05/15 18:36:52
>>41
そいつは前にもいた嫌われ者だからほっとけ。
43:デフォルトの名無しさん
07/05/15 21:55:26
Javaも終わりだな
次は何だ？
44:デフォルトの名無しさん
07/05/15 22:13:46
マシン丸ごとJava仮想化ブームでむしろ鉄板化してるんだが・・・
45:デフォルトの名無しさん
07/05/15 22:16:20
次はRuby
RubyやるとJavaが古臭く感じる
46:デフォルトの名無しさん
07/05/15 22:17:40
まぁそりゃ
今まで使ってたJavaとは違うからなぁ
47:デフォルトの名無しさん
07/05/15 22:38:15
クロージャー登場で少しは変わるんじゃない？
48:デフォルトの名無しさん
07/05/15 23:08:45
クロージャーでどんな風に変わるの？
49:デフォルトの名無しさん
07/05/16 01:12:27
クロージャーって何？
50:デフォルトの名無しさん
07/05/16 01:42:49
>>49
源頼朝の弟。
それは九郎じゃー。
51:デフォルトの名無しさん
07/05/16 02:07:35
>>49
スレストのことだよ
52:デフォルトの名無しさん
07/05/16 02:26:54
>>45
そこでJRubyですよ
53:デフォルトの名無しさん
07/05/16 03:42:35
>>44
OS抜きで直接JavaVMを動かす方が速くて当たり前なんだけど、JRockitって流行？
まぁ、携帯＆固い系のサーバーサイド＆Blu-rayと既に確固たる地位を築いたのでどうでも良いけど。
54:デフォルトの名無しさん
07/05/16 07:14:27
携帯もBlu-rayもMEだろ。鯖側ってEEの事か？
そういや前にプロパティで騒いだがアノテーションじゃだめ？
int prop;
@set(prop) public void setProp(int x){
prop=x;
}
@get(prop) public int getProp(){
return prop;
}
これで問題無くない？
55:デフォルトの名無しさん
07/05/16 10:07:06
Java SE 7の「プロパティ」が見えてきた - setter/getterのないJavaへ
URLﾘﾝｸ(journal.mycom.co.jp)
boundキーワードが良くわからん。さらなる解説へのポインタきぼんぬ
56:デフォルトの名無しさん
07/05/16 11:09:56
>>55
なにがよくわからんのかがよくわからん。
get、setの書き方、ローカルキーワードとか、C#のプロパティと同じですね。
それに、boundと#演算子でのリフレクション情報取得か。
57:デフォルトの名無しさん
07/05/16 14:00:16
>>55
boundプロパティなら setter が呼ばれた時に、
プロパティ変更される前に java.beans.PropertyChangeListener にイベントを送る。
bean には対になる vetoableプロパティってのがあって、
こっちはプロパティが変更された後に
java.beans.VetoableChangeListener にイベントを送る。
58:デフォルトの名無しさん
07/05/16 14:05:43
>>57
おいおい、逆だよ。逆。
vetoable はプロパティが変更される前に
登録された java.beans.VetoableChangeListener を呼ぶ。
VetoableChangeListener がプロパティの変更を
拒否したい場合は PropertyVetoException を投げる。
boundプロパティはプロパティを変更した後に
java.beans.PropertyChangeListener を呼ぶ。
で、>>55 のプロパティ案には、前者に対応する機能はない。
59:デフォルトの名無しさん
07/05/16 14:20:35
>>56
# つかって Property<B,T> 取れるってのは
もう一つの closure の草案である FCM の影響なんだろね。
URLﾘﾝｸ(docs.google.com)
60:デフォルトの名無しさん
07/05/16 14:23:47
>>55
URLﾘﾝｸ(www.y-adagio.com)
61:デフォルトの名無しさん
07/05/16 19:31:45
何々？
やっとゲッターセッターから解放されるって
まだ開放されてなかったんかYO──！！！
62:デフォルトの名無しさん
07/05/16 20:44:26
# 演算子か・・・・
↑って、書いたらなんかコメントアウトされてる気分ヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノ
63:デフォルトの名無しさん
07/05/16 21:02:01
>>59
で、Property<B,T> 自体は URLﾘﾝｸ(bean-properties.dev.java.net) の影響っぽい。
これ、プリミティブ型のプロパティと相性悪そうだけど……
64:デフォルトの名無しさん
07/05/16 22:53:50
オートボクシングがあるじゃん
65:デフォルトの名無しさん
07/05/17 00:35:53
例えば java.beans.XMLEncoderで既存(int&gettrer)のbeanを出力した
java.beans.XMLDecoderで新しい(Integer＆Property)beanに復元するときとか
型変わっちゃうしさ。
66:デフォルトの名無しさん
07/05/17 17:38:15
URLﾘﾝｸ(journal.mycom.co.jp)
この新型JREに少しだけ期待してみる。
67:デフォルトの名無しさん
07/05/18 21:55:15
setXxxやらgetXxxを自動で作るわけじゃないみたいだね。
とすると、property対応フレームワーク以外で使うときには依然としてsetXxx/getXxx作る必要がありそう。
68:デフォルトの名無しさん
07/05/18 22:20:23
自動で作られるメソッドの名前は "プロパティ名$set" "プロパティ名$get" らしいね。.
69:デフォルトの名無しさん
07/05/19 10:03:31
なんて中途半端なんだ・・・
70:デフォルトの名無しさん
07/05/20 16:11:06
synth lafって全然流行んないね。JDKにsunのデモすら無い。
1.4時代のwinXP/GTK+ system lafがsynthなんだからあれ公開すれば良いのに・・・。
71:デフォルトの名無しさん
07/05/20 16:35:22
>>70
Nimbusじゃダメなん？
72:デフォルトの名無しさん
07/05/20 21:13:27
MOPが仕様に入らないかなwkwk
73:デフォルトの名無しさん
07/05/22 00:01:12
>>70
synth以外のLaFが流行ってるかのような書き方だな。
勉強のために作ってみました、程度の物を除外すると、まともなLaFなんて、
10程度だと思うけど。とても流行ってるとはいえない。
deviantartとかにカテゴリができるぐらいになればいいんだけど。無理か。
74:デフォルトの名無しさん
07/05/22 13:10:11
synthのxml吐くGUIツールはdev.java.netに３つくらいホストされてるけど、
やっぱカスタムlafはsynth以外が多い。てかXULフレームワークがあったよ。
海外製のSwingアプリケーションはlaf自前ってのが多い。（javaとシステムと独自の選択式だが）
75:デフォルトの名無しさん
07/05/27 12:51:27
MVMってどうなってんだ？
研究中？
76:デフォルトの名無しさん
07/05/28 20:56:05
hore
URLﾘﾝｸ(www.jp.arm.com)'%E3%83%9E%E3%83%AB%E3%83%81%E3%82%BF%E3%82%B9%E3%82%AF%20java'
77:デフォルトの名無しさん
07/05/31 20:56:32
また１．４かよ・・・・・orz
78:デフォルトの名無しさん
07/06/01 11:10:03
JDK7 build13
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
79:デフォルトの名無しさん
07/06/14 21:56:00
>>3
Java6でできるよスプラッシュ
URLﾘﾝｸ(www.javainthebox.net)
もういないだろうけど
80:デフォルトの名無しさん
07/06/22 14:18:44
JDK7 build14
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
81:デフォルトの名無しさん
07/06/25 21:00:29
>>80
Want to open a Frame without activating it
URLﾘﾝｸ(bugs.sun.com)
フォーカスを取らずにフレームをオープンできるようになったのか・・・
何か使い道あるかな？
82:デフォルトの名無しさん
07/06/26 02:18:28
URLﾘﾝｸ(bugs.sun.com)
↑のバグ修正情報などを RSS かなんかで取得できませんか？
join SDN すれば、たぶんどうにかして特定のバグを追っかけたり
できるんでしょうけど、できれば join しないで見たいなぁと。
83:デフォルトの名無しさん
07/06/29 01:54:26
>>82
RSSで何をみる？新しく登録されたもの？
joinしたらvoteもできるぞ。
84:82
07/06/29 02:47:38
>>83
RSS で、新しく登録されたバグ、登録されたバグについての変更
が見れたらいいなぁと思います。
85:デフォルトの名無しさん
07/07/07 00:40:40
JDK7 build15
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
ビルドペースあがってきた？
86:デフォルトの名無しさん
07/07/12 01:38:18
最近ネタないね
87:デフォルトの名無しさん
07/07/12 01:53:12
そーいや、invokedynamic ってもう実装されたの？
88:デフォルトの名無しさん
07/07/12 15:43:33
マルチタスク対応って7で実装されるのか？
89:デフォルトの名無しさん
07/07/12 16:30:29
たしか使用策定は済んでるんじゃなかったけ？
Java Cardならすでに実装されててMIDP3.0が対応中（MIDP3.0自体策定中）。
jdk7はJAMに期待。Libletみたいな使い方をするんだろうね。
90:デフォルトの名無しさん
07/07/13 23:46:55
ODFとか対応しないのかな？
91:デフォルトの名無しさん
07/07/21 13:38:09
JDK7 build15
JDK7 build16
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
92:デフォルトの名無しさん
07/07/24 10:34:30
7っていつ頃リリースを予定しているの？
93:デフォルトの名無しさん
07/07/24 14:36:08
>>92
JDKのメジャーバージョンのリリースが 18～24ヶ月毎って話からすれば
JDK6のリリースが2006年 12月第一週だから、
JDK7のリリースは2008年 6月～12月ぐらいになる。
個人的には、JDK7は機能てんこもりだから遅れ気味になるんじゃないかと予想。
94:デフォルトの名無しさん
07/07/24 15:06:50
確かに。
JAMだってまだ乗ってないし。
95:デフォルトの名無しさん
07/07/24 15:38:04
>>91
何かさ・・・・コンパネが・・・・びろーんって・・・縦に・・・伸びてない・・・(；・∀・)？
96:デフォルトの名無しさん
07/07/24 21:40:33
来年秋って話だったから、再来年の春くらいになるんじゃね～の？
97:デフォルトの名無しさん
07/07/25 00:56:49
>>95
普段は JRE7入れてないから気付かなかった。
入れてみたら、なった。
うちだと、コンパネの天辺もタブも画面外にあって操作できない。
URLﾘﾝｸ(bugs.sun.com)
これと同じかな？ Image file attached って書いてあるけど見られないんだよね。
98:デフォルトの名無しさん
07/07/25 04:07:24
来年以降か。機能がたくさん追加されるから楽しみだな。
99:デフォルトの名無しさん
07/07/26 01:49:13
俺はどれだけ構文が汚されるのか気になって仕方が無い。
これだけ、getter,setterの糞規約が定着したところでpropertyが普及するのかどうか…。
100:デフォルトの名無しさん
07/07/26 12:25:00
Javaのクロージャは期待できるけどなぁ…
delegateを無理に拡張している冗長構文のクロージャより大分改善されている。
101:デフォルトの名無しさん
07/07/26 23:59:44
>>100
Collectionライブラリもクロージャ対応されてくるかなぁ？
Streamとか、JDBCもクロージャ対応になったら、今のソースとガラッと変りそう。
102:デフォルトの名無しさん
07/07/27 00:24:21
java.util.Collections にクロージャ対応な staticメソッドが追加される予感……
103:デフォルトの名無しさん
07/07/27 00:43:27
これから6勉強しようかって思ってるのに・・・
104:デフォルトの名無しさん
07/07/27 01:44:31
別に覚えた内容が損になるわけじゃないぜ
105:デフォルトの名無しさん
07/07/27 01:48:37
>>103
勉強しとけ。
106:デフォルトの名無しさん
07/07/27 02:35:04
>>101
with(InputStream s: new FileInputStream("c:/test.txt")){
System.out.println(s.read());
}
みたいなことが書けたり
List<Integer> list = Arrays.asList(1, 2, 3, 4);
int sum = Collections.reduce(
list, {Integer x, Integer y => x + y});
とすると10が得られたり
Lock lock = ....;
withLock(lock){
//いろいろロックされる処理
}
と書けたりする予定らしい。
107:デフォルトの名無しさん
07/07/27 07:50:44
こういうのって結局Cのプリプロセス処理と同じなんだよね。
108:デフォルトの名無しさん
07/07/27 09:43:44
>>107
Cのプリプロセッサみたいにコンテキスト考えずに
ただ置換するだけのものとは全然違うよ
109:デフォルトの名無しさん
07/07/27 14:52:46
違いを見せたいのは分かるが、たいした差はない。
110:デフォルトの名無しさん
07/07/27 14:55:54
ようするにシンタックスシュガーっていいたいんだろ。
それをCのプリプロセス処理と同じというのは問題あるがな。
111:デフォルトの名無しさん
07/07/27 22:54:16
単なる置き換え。マクロと同じってことがいいたいんだろう。
そういわれると辛いところだが…
112:デフォルトの名無しさん
07/07/27 23:03:57
プリプロセッサは別の言語仕様として存在してるのが問題なんだろ。
D言語とかはC++のカオスさをうまく言語仕様に馴染ませてて感心した。
113:デフォルトの名無しさん
07/07/28 08:27:49
まあ、でもそれはCore2Duoって8086と同じだよね、っていう感じで、だから何？ってなるんだよね。
仕組み的に同じ系統だからって、便利さは全く違ったりするわけだ。
114:デフォルトの名無しさん
07/07/28 11:10:24
自分で実装するわけにもいかないからね。
便利なのは使わせてもらおっと
115:デフォルトの名無しさん
07/07/28 11:58:04
>>107>>110
アホですね。
116:デフォルトの名無しさん
07/07/28 12:03:17
Ｇｅｎｅｒｉｃｓの話？
117:デフォルトの名無しさん
07/07/28 14:00:46
どこからその話が・・・
118:デフォルトの名無しさん
07/07/28 15:07:58
>>106
またC#のパクリか
119:デフォルトの名無しさん
07/07/28 15:18:52
クロージャーがC#にしかないと思ってんのか。
120:デフォルトの名無しさん
07/07/30 12:02:37
scriptは何が追加されるんだろう。
121:デフォルトの名無しさん
07/07/30 13:43:25
script乱立しすぎでわけわかんね
122:デフォルトの名無しさん
07/08/01 07:29:47
jdk6ではjavascriptが使えるけど、javaファイルも同じようにスクリプトとして使えるのかな。
123:デフォルトの名無しさん
07/08/01 10:38:25
標準添付はされていない
124:デフォルトの名無しさん
07/08/01 11:36:20
標準ではないのか。次バージョンに期待するよ。
125:デフォルトの名無しさん
07/08/01 12:09:03
>>124
いまのところ、標準添付される雰囲気はないね。
標準添付できるような質のJavaスクリプトエンジンってあるのかな？
126:デフォルトの名無しさん
07/08/01 14:14:13
標準添付のスクリプトエンジンの方が
野良スクリプトエンジンより品質悪かったりするけど……
127:デフォルトの名無しさん
07/08/01 15:02:46
>>125
つ Pnuts・・・
128:デフォルトの名無しさん
07/08/01 17:08:04
スクリプトだし、質とか速さとかどうでもいいよ。
とりあえず、Javaが動くスクリプトエンジンを実装してくれ。
129:デフォルトの名無しさん
07/08/01 17:13:49
言語としてのJavaならスクリプトエンジン作るよりも
コンパイラAPIの拡充の方が良い。
メソッド宣言時のシグネチャだけみたいな細かい単位で
構文解析＆名前解決してくれればそれで良い。
ツール作る時とか、そっちの方が都合良いし。
130:デフォルトの名無しさん
07/08/01 18:31:03
そんなこといってちゃ、いつまでたってもjavax.scriptでJavaはサポートされないよ。
自分の都合だけで考えるのもいいけどね。
131:デフォルトの名無しさん
07/08/01 20:05:04
俺は両方欲しいぜ、ベイベ
わがままな、俺の願いを聴いてくれよ
イエー
132:デフォルトの名無しさん
07/08/01 20:15:11
>>126
具体的には？
133:デフォルトの名無しさん
07/08/01 21:04:43
何につかうんだよそんなもの
134:デフォルトの名無しさん
07/08/01 21:36:56
>>130
標準添付されないというだけで、javax.scriptでJavaはサポートされてるわけだが。
135:デフォルトの名無しさん
07/08/01 22:35:59
>>132
具体的にはって標準添付されてんのRhinoしかないじゃないか。
136:デフォルトの名無しさん
07/08/01 22:37:07
標準で入ってないと意味ないし、無駄な努力なのだが。
137:デフォルトの名無しさん
07/08/01 22:40:17
SPI使えるんだから、クラスパスに含めるだけで新しいスクリプト言語使えるようにできるんだが……
138:デフォルトの名無しさん
07/08/01 22:42:38
おれは、C言語をスクリプトで実装して欲しいぜ！
それもC99を！
139:デフォルトの名無しさん
07/08/01 22:45:08
>>137
ん？俺が無知なだけなのか・・
140:デフォルトの名無しさん
07/08/01 23:13:33
まあ実際無知なんだろうな。
141:デフォルトの名無しさん
07/08/02 05:09:30
>>135
いや、オレもRhinoしか添付されてないと思ってたのだが、それだと野良スクリプトエンジンの方が品質がいいってのがひっかかる。
Rhinoよりいいスクリプトエンジンって何だ？
142:デフォルトの名無しさん
07/08/02 05:10:04
>>136
いらん。
143:デフォルトの名無しさん
07/08/02 12:28:23
>>141
普通にビルドしたRhino。
144:デフォルトの名無しさん
07/08/02 14:28:20
>>141
つ Pnuts
145:デフォルトの名無しさん
07/08/03 00:08:05
>>138
個人的にはFORTRANが良い
146:デフォルトの名無しさん
07/08/03 00:12:18
たしかSunがFortressっての開発中だったと思う。
並列計算に特化したJavaとFortranを参考にしたスクリプトっての。
147:デフォルトの名無しさん
07/08/03 00:12:52
>>144
pnutsそんなにいい？
まだこなれてない感じバリバリなんだけど。
yieldの挙動とか。
148:デフォルトの名無しさん
07/08/03 04:44:27
あんま関係ない話で恐縮なんだけど、javax.script バブルの火付け役が php だって噂は本当なん？
149:デフォルトの名無しさん
07/08/03 06:10:32
msのcliに対抗するため
150:デフォルトの名無しさん
07/08/03 06:16:58
C言語やC#にある値型の struct はいつサポートされるの？
151:デフォルトの名無しさん
07/08/03 08:37:18
>>148
script言語の共通基盤になるチャンスを見逃すわけがない。
javascript, php, python, ruby実装環境をごっそり頂きかも知れない。
コンパイラ基盤もちらほら出てきているし。
152:デフォルトの名無しさん
07/08/03 12:00:15
>>150
なぜそんなものが必要なのか？理由を明確に
153:デフォルトの名無しさん
07/08/03 12:54:23
リンゲージがその関数内であるオブジェクトに対して、イチイチnewしないで済むことが言語として保障されることになる。
154:デフォルトの名無しさん
07/08/03 13:02:33
>>153
コンパイル時に最適化情報がバイトコードに埋め込めればいいんだよね～
そしたら、ガンガンエスケープ解析できる
155:デフォルトの名無しさん
07/08/03 13:28:43
>>151
いや、知り合いから
「php を java vm 上で動かそうって話が最初で、そのあと他の軽量言語が追従した」
って話を聞いたんだけど、本当なのかなって。
156:デフォルトの名無しさん
07/08/03 13:54:15
>>154
そういう小手先解析よりも、普通に言語としてサポートしろってこと。
struct Point {
double a,b
};
どう考えても需要あるだろ。
157:デフォルトの名無しさん
07/08/03 13:56:16
>>155
それだけ需要があるなら、PHPがまずサポートされるはずじゃないか？
VMで他の言語が動けばいいのであって、どうでもいいけど。
158:デフォルトの名無しさん
07/08/03 14:24:28
>>156
その程度なら不要。
値型の利点は、newが必要とかより、
代入が必ずコピーになることによって、
同一オブジェクトに対応する変数が一つであることを保障できることだと思うんだが。
159:デフォルトの名無しさん
07/08/03 16:26:23
>>158
需要の論点ではPointで示したが、利点としては例えが悪かった。
では必ずコピーになる利点のために導入するのではどうだ？ほしいだろ？
160:デフォルトの名無しさん
07/08/03 16:41:03
いや別に
161:デフォルトの名無しさん
07/08/03 17:45:57
値型が導入されたら、今度はポインタ演算を欲しがるに違いない
162:デフォルトの名無しさん
07/08/03 19:10:24
C#はstructの導入に失敗したからNullableが出来たんでしょ
恥ずかしい実装まで追従する必要ないから、別に要らないなぁ
どうしてもってのならByteBufferをラップすりゃいいし
163:デフォルトの名無しさん
07/08/03 19:34:17
値型ってメモリ効率に関する利点のために導入するもんだろ。
164:デフォルトの名無しさん
07/08/03 19:36:02
それが理由ならエスケープ解析が導入されたから今後は不要でしょ
165:デフォルトの名無しさん
07/08/03 21:11:05
>>161 それはない。
166:デフォルトの名無しさん
07/08/03 21:17:46
>>164
複雑じゃなくていいから、普通にCと同じのでいいよ。
メソッドもCの関数ポインタみたいに、staticのみでいい。
エスケーポ解析よりも言語に導入のほうが楽だと思うけど、そうでもないのか
まあ、そのうちちゃっかり導入されるんだろうけど。
167:デフォルトの名無しさん
07/08/03 22:14:07
JDK7 build17
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
168:デフォルトの名無しさん
07/08/04 00:41:24
いまさら導入されても、C の register 変数と同じ運命をたどる予感。
169:デフォルトの名無しさん
07/08/04 02:00:02
register にも、一応アドレスを取れないという効果はあるんだぞ！
170:デフォルトの名無しさん
07/08/04 07:19:54
>>157
PHPみたいなどうでもいい言語をまずサポートする必要性がみあたらない。
171:デフォルトの名無しさん
07/08/04 08:47:45
structのメモリー効率のよさってのは、オブジェクト廃棄時のコスト云々じゃなくて、
newに頼ってオブジェクト生成するときのコストがまったくないってことだろ。
関数呼び出しでスタックに自動生成されるのであって、newによるオーバーヘッドは
かからないいってこと。
172:デフォルトの名無しさん
07/08/04 08:51:14
オブジェクトがほかのメソッドに伝播される可能性を考えると、エスケープ解析で自動的にやってくれるのが一番効率がよさそうだな。
173:デフォルトの名無しさん
07/08/04 08:52:09
structは、コピーによって、ここのオブジェクトの同一性の確保も
そのとおり利点ではあるが、エスケープ解析の小手先技なんぞに頼らないで
優先的に言語でサポートするのが妥当だろ。
assert, enumとかよりも先にさ。
Javaの文法は、結局Cの文法を真似てるだけってことを忘れて、
「エスケープ解析もできる俺ってすごいだろ」っていい気になってるだろ？
174:デフォルトの名無しさん
07/08/04 08:52:42
エスケープ解析ってのはそれをやるんだよ。
C#のstructと同じような最適化がされることになり、
逆にC#2.0で対応するはめになったNullableのようなstructの欠点も無い
175:デフォルトの名無しさん
07/08/04 08:54:47
>>171
まあ、メリットはあっても、それが"大きく"効いてくるのはかなり特殊なケースで、
そういうのが大量にある応用の時は、ハイバネでいい、ってのが今の流れなんじゃないの?
176:デフォルトの名無しさん
07/08/04 08:55:56
JavaのenumはCのenumとは違うぞ。
定数そのものに振る舞いを持たせることが出来るし、
なおかつタイプセーフだ。
177:デフォルトの名無しさん
07/08/04 08:57:25
メモリーの効率とかじゃなくて、
structを使いたいプログラマーの切実な要望には答えられないのかね？
そういうエスケーポ解析の新技術はどうでもいいからさ。
178:デフォルトの名無しさん
07/08/04 08:58:34
>>173
で、エスケープ解析に比べたstructの利点ってなんなの？
179:デフォルトの名無しさん
07/08/04 08:58:58
structの欠点の無いむしろメリットとなるようなカラクリがあれば導入されるかもな。
180:デフォルトの名無しさん
07/08/04 09:02:12
ちなみに、structなど値型を使いたい場面は、
forや関数呼び出しで100万回以上まわす。
そういう小型オブジェクトの短期生成は、newでは向いてないし、役不足だろ。
またエプケール解析とかいうのか？
GCの新技術はJava以外のVM使うスクリプトにもメリットあるだろうが、
そういうのは使うほうからみてどうでもいいから、まずはJava言語で導入しろ。
181:デフォルトの名無しさん
07/08/04 09:02:38
>>177
メモリーの効率とかじゃないなら、structを使いたいっていう切実な要望っていうのは、新技術以上にどうでもいいんじゃないかと思う。
182:デフォルトの名無しさん
07/08/04 09:03:54
>>180
使う方から見てどうでもいいのがstructだと結論づいてるのに何を・・・
183:デフォルトの名無しさん
07/08/04 09:04:17
>>176
使うほうからすれば、C,Javaどちらのenumも同じ。
いつ使えるようになったかといえば、Javaはサポート遅すぎ。
184:デフォルトの名無しさん
07/08/04 09:04:37
>>180
エスケープ解析で十分です。どうもありがとうございました。
185:デフォルトの名無しさん
07/08/04 09:05:49
>>183
全然違うっての。お前のいう「使う人」って誰だよ。お前限定じゃねーか。
お前はCだけ使ってろ。
186:デフォルトの名無しさん
07/08/04 09:06:52
>>181
きみ、structとclassは実質同じってことを知ってるのか？
187:デフォルトの名無しさん
07/08/04 09:08:35
>>186
C++のデフォルトアクセスレベルの話で言ってる？
同じものなら要らないだろ
188:デフォルトの名無しさん
07/08/04 09:09:11
structを否定するってことは、classつまり、構造体型（集合型）を否定しているようなものだけど・・
君の理解じゃ、ポインタがどうとかってあたりで止まってるんだろうな。
189:デフォルトの名無しさん
07/08/04 09:09:20
>>186
だから、なに？メモリ効率以外に、structの利点ってあるの？
190:デフォルトの名無しさん
07/08/04 09:10:21
>>188
なんで？
きみ、エスケープ解析の意味ちゃんとぐぐってる？
191:デフォルトの名無しさん
07/08/04 09:15:05
なんか、エスケープ解析をわかってないやつがいるみたいなんで書いておくけど
for(int i = 0; i < 10; i++){
Point p = new Point();
p.x = i * 2:
p.y = i * 4;
System.out.println(p.x + ":" + p.y);
}
が
for(int i = 0; i < 10; i++){
int px = i * 2:
int py = i * 4;
System.out.println(px + ":" + py);
}
に最適化される技術な。
192:デフォルトの名無しさん
07/08/04 09:34:02
まとめると、「エスケープ解析の意味がわかんないやつが暴れてましたとさ」でいいの？
193:デフォルトの名無しさん
07/08/04 10:12:30
>>180
エプケール解析て…これは釣りだろ。
それから値型もnewされることに変りはないぞ。
194:デフォルトの名無しさん
07/08/04 10:20:21
Java版のaptみたいなのがそろそろ出てきてもいい頃合だね。
各種IDEやmavenの資産、そしてJAMの登場によって下地は十分のはず。
JDKに同梱されれば、環境構築のコストが激減しそう。
195:デフォルトの名無しさん
07/08/04 11:09:02
SunがOpenSolaris用のパッケージ配布機構を発表したぞ。
ZFSに基づくサービス、実装らしい。
Sun、『OpenSolaris』でバイナリパッケージ配布モデル採用へ
URLﾘﾝｸ(japan.internet.com)
196:デフォルトの名無しさん
07/08/04 11:55:05
またエスケープ解析が得意の彼か
彼の言い分も一理あるが、単純に彼は自分の技術を自慢したいだけだから、ほっとけ
197:デフォルトの名無しさん
07/08/04 11:55:58
>>193
そもそも struct とか言う奴は大抵釣り。
198:デフォルトの名無しさん
07/08/04 12:01:23
JOGLやjinputとかをJDKから簡単に取り寄せられたら便利だね
199:デフォルトの名無しさん
07/08/04 12:18:37
下手にやると複数バージョンのjarが入り混じってカオスになるけどね
200:デフォルトの名無しさん
07/08/04 12:25:12
>>196
そういう話は、的確な議論してから言ったほうがいいと思う。
201:デフォルトの名無しさん
07/08/04 13:47:09
struct ： スタックに値を割り付ける
エスケープ解析 ： スタックにオブジェクトを割り付ける最適化手法
オブジェクトが対象のエスケープ解析の勝ちでおｋ
structは時代遅れの産物
202:デフォルトの名無しさん
07/08/04 14:13:45
>>196
自分の視点でしか判断できないのが彼のような技術者ってもんだし、
他人の要望とかまったく無視で自分の技術一点張りだな、こいつは。
つまりは、一人でコソコソとエスケーポ解析してろってこったな。
あー、ねくら、ねくら
203:デフォルトの名無しさん
07/08/04 14:17:20
>>201
おまえはばかか？勝手にしこってろ。嫌ならCをべんこうしなおせな。
204:デフォルトの名無しさん
07/08/04 14:22:58
>>202
C C++ アセンブラのときでも、小手先技使って最適化大好きって輩がいるけど、こういう根っからの技術者って人の話聞かないしね。こういうねくらは、あんまり表にしゃしゃり出てこないで中にこもって解析していて欲しいよ。
205:デフォルトの名無しさん
07/08/04 14:31:59
有能な学生をいじめたらだめれす！
206:デフォルトの名無しさん
07/08/04 14:36:57
>>201
おまえのその論理だと、Java標準のlong doubleなどプリミティブ型は時代遅れなのか？
そして解析手法を駆使する方が今風なのか？
おまえ、そんなことしてるよりコンパイラ作ってみろ。そうすれば分かる。
207:デフォルトの名無しさん
07/08/04 14:39:43
>>206
暇ならコンパイラとVMに struct実装して OpenJDKあたりにパッチ送ってみれば？
どれぐらいメモリ効率が良くなるかみたいなデータも示せば採用されるかもよ？
208:デフォルトの名無しさん
07/08/04 14:46:21
>>206に コンパイラやVMを書き換えるだけのスキルがあるとは思えないが
209:デフォルトの名無しさん
07/08/04 17:08:16
ひさびさに高品質の夏厨があらわれたな。
210:デフォルトの名無しさん
07/08/04 21:46:11
>>173
＞「エスケープ解析もできる俺ってすごいだろ」
惚れました
211:デフォルトの名無しさん
07/08/05 00:44:29
>>191みたいな馬鹿に突っ込める奴は、
ここにはいないのかｗｗｗ
エスケープ解析とは、ソースコードを解析してバイトコードの最適化を行う話じゃない。
Javaのコンパイラはソースコードとバイトコードの対応付けが規定されているので、
そもそもバイトコードの最適化はありえない。
メソッド内で生成されたインスタンスが、
メソッドの外へ「逃げるか逃げないか」を判断する技術だ。
returnや引数やフィールドに参照が渡されるコードがあれば、
「メソッドの外に逃げる」と判断されて、
インスタンスはヒープに確保される。
逆に「メソッドの外に逃げない」と判断されたら
インスタンスはスタックに確保される。
わかったかいｗｗｗ？>>191
212:デフォルトの名無しさん
07/08/05 00:44:39
くそ天皇 くそ天皇 くそ天皇 くそ天皇
いい加減死ねっつってんだろ屑ニートくそ天皇が
相変わらず病的な粘着っぷりだな屑ニートくそ天皇が
毎日毎日毎日粘着出来て良いでちゅねくそ天皇
くそ天皇さっさと死にやがれゴミが
東京に在住している精神病珍米糞ニートくそ天皇君の末路
さっさと精神病院逝くか首吊って逝くか選べや糞天皇が
早く死ねよ糞ニート天皇が
粘着精神病屑ニート天皇君は自らニートくそ天皇であると公言しました
さっさと死ねやくそ天皇が
早く死ねっつってんだろ屑ニートくそ天皇が
お前みたいなゴミクズ天皇は息してるだけで空気が汚れるからさっさと死ねや
とっと死に晒せや糞ニート天皇が
213:デフォルトの名無しさん
07/08/05 01:22:48
>>211
引数に渡すだけでもエスケープと判断されるのか。
オブジェクトの生存期間がスタックのそれに制限されているだけじゃだめなのね。
214:デフォルトの名無しさん
07/08/05 01:30:19
渡したメソッドがインライン展開されてれば大丈夫
渡した先でそのオブジェクトがどこに保持されて生き延びるかわからんからね
215:デフォルトの名無しさん
07/08/05 01:32:40
>>213
引数がListで、そのListに生成したインスタンスを追加したりとか。
216:デフォルトの名無しさん
07/08/05 01:33:12
>>214
それってつまり実行して見るまで分からんってこと？
217:デフォルトの名無しさん
07/08/05 01:35:41
エスケープ解析の間違ったネタが書き込まれているし・・・
それに誰も突っ込まないし・・・
そもそもエスケープ解析は次世代ネタじゃないし・・・
終わってね？
218:デフォルトの名無しさん
07/08/05 01:38:48
当時の流れて下手に突っこんだら粘着に餌与えるだけだけどな
219:デフォルトの名無しさん
07/08/05 01:40:32
>>216
HotspotVMは実行時にコンパイルするんだから大丈夫
220:デフォルトの名無しさん
07/08/05 09:39:23
>>211はここを見るべき
URLﾘﾝｸ(www-06.ibm.com)
221:デフォルトの名無しさん
07/08/05 10:18:29
>>220
おまえ191だろｗｗｗ
そんな記事は知ってるわ。
そもそもインライン化とエスケープ解析は違う。
222:デフォルトの名無しさん
07/08/05 13:22:13
>>211
> Javaのコンパイラはソースコードとバイトコードの対応付けが規定されているので、
> そもそもバイトコードの最適化はありえない。
（ ﾟдﾟ）ﾎﾟｶｰﾝ
223:デフォルトの名無しさん
07/08/05 14:45:58
>>221
そうだね、エスケープ解析した結果として、スタックアロケーションしたりインライン化したりするんだね。
違う階層の言葉だったね。
224:デフォルトの名無しさん
07/08/05 14:47:26
if(true)が無視されてバイトコードに埋め込まれないのは、バイトコードの最適化といわないのかな。
225:デフォルトの名無しさん
07/08/05 14:54:08
メソッドに仮実装がある場合で、その処理を通さずメソッドの先頭で値だけ返したい場合とか
if (true) を未到達エラー回避にたまに使うな。C#はboolを変数化しなきゃいけなくて面倒だ。
ああ、まるで脱線した話題だけどね。
226:デフォルトの名無しさん
07/08/05 14:59:07
インライン化はエスケープ解析の結果じゃないけど、まぁいいや。
もうちょっとスレタイトルにふさわしい話題ないの
227:デフォルトの名無しさん
07/08/05 15:02:44
ならクロージャとJAM以外で見所のある機能があれば紹介して。
228:デフォルトの名無しさん
07/08/05 15:03:08
template萌えな私を叱ってください。
229:デフォルトの名無しさん
07/08/05 16:24:56
JITは標準のコンパイル結果に対して最適化するように動くので、
バイトコードへコンパイルするときは、
明らかな最適化が可能なもの意外は何もしないよ。
バイトコードへコンパイルする時に、
Javacが生成しない最適化されたバイトコードを生成すると、
JITは最適化の対象外になるからかえって遅くなる。
Javacを無視してバイトコード生成するのはJikesぐらい
230:デフォルトの名無しさん
07/08/05 16:29:39
ん？javacって最適化方針まで規格化されてるの？
231:デフォルトの名無しさん
07/08/05 16:31:19
規格化なんかされてないでしょ。
特定の実装の話じゃないの？
232:デフォルトの名無しさん
07/08/05 16:33:24
javacが生成しない最適化されたバイトコードって話がどこからでてきたのかがわからん
233:デフォルトの名無しさん
07/08/05 17:44:13
そもそも今のjavaの動的コンパイル技術はJITじゃなくてHotSpotだろ。
>>141
jdkのRhinoはMozillaのRhinoコードが実行できないほどの超絶劣化品。
あれらのエンジン間に互換性はないよ？
Rhinoの実装ライブラリがsun.*パッケージに移動されてるから
Rhinoに含まれるセキュリティーライブラリがどの常に利用できるとも限らんし、
バイトコード吐かないから常にインタプリタモードで動いて遅いし。
E4Xないし。上げ出したら切りがない。
234:デフォルトの名無しさん
07/08/05 21:45:36
>>233
HotSpotは、実行時間食ってる箇所を見つけてJITコンパイルする。
もしくは、あんまし実行されない箇所のJITコンパイルを抑制する。
大雑把な議論をする場合はJITでもHotSpotでもどっちでも良い。
変な拘り持ってる奴を相手にするんでなければ。
235:デフォルトの名無しさん
07/08/05 22:06:34
3回動くとコンパイルが走ると感覚的に判断してるから、
ベンチマーク前は、10回は回してからやってる。
server vmってのは何時間も動かすと更に最適化されたりするんだろうか
236:デフォルトの名無しさん
07/08/06 03:18:49
>>234
でもそれって最適化方法が同じ実装の場合に限られない？
サーバー向けVM製品とかの中にはHotSpotと同じ適応型最適化コンパイルするけどVM実装の都合で
あえて変わったタイミングでコンパイルしたりする奴居るよ。
>変な拘り持ってる奴を相手にするんでなければ。
てのはこいつらのこと？
237:デフォルトの名無しさん
07/08/06 08:15:35
>>235
感覚に頼んじゃなくて -XX:+PrintCompilation とか -Xbatch とか使ったほうがいいと思うけど
238:デフォルトの名無しさん
07/08/06 09:30:04
>>236
一切JITコンパイルしない最適化方法の事をJITって言ってたら
話が通じなくなるから問題だけど、タイミングが変わるぐらいなら問題ないでしょ。
239:デフォルトの名無しさん
07/08/06 11:41:02
>>236
> あえて変わったタイミング
kwsk
240:デフォルトの名無しさん
07/08/06 16:57:02
>>239
たまたま見つけたんで製品名は知らんが
アプリケーションが１度走り出したら負荷のかかるGC/動的コンパイルを
徹底的に発生させないために実行初期にとっとと見切りプロファイルしてマシン語吐いちゃってシステムの稼働を優先させるタイプのVMをどっかで見た。
でも、実行初期段階からボトルネック見つけたりパフォーマンスを平均化する技術を使ってるらしくAOTじゃないみたい。
民生用じゃないVMなんかはそういう変わった実装見るよ。
>JITコンパイルしない最適化方法の事をJITって言ってたら
MEベンダの中にはただのインタプリタ最適化を"独自の"JIT技術と呼んでるところもあるんだなｗ
漁ると結構変なVMっていっぱい。
あと、JITをただの動的コンパイル（OR最適化）のことだと思ってる奴とか。
241:デフォルトの名無しさん
07/08/06 17:00:03
語義的には Just In Timeで何かしてたら、なんでもJITになるわな。
242:デフォルトの名無しさん
07/08/06 17:23:51
JITコンパイラと名乗ってなければ、
> ただのインタプリタ最適化を"独自の"JIT技術と呼んでる
なんの問題もないだろ。
243:デフォルトの名無しさん
07/08/07 15:30:39
JSR-308に関してこんなん見つけた。
URLﾘﾝｸ(pag.csail.mit.edu)
正式リリースからは削除予定だけど、JDK7の開発期間中は暫定的に、
/*@Readonly*/ Object x;
みたいのがあると、アノテーションとして認められるらしいんだけど、
これJDK6以前とJDK7以降で共用のライブラリ書くとき便利だから
言語仕様として残して欲しかったり……
JMLみたいな既存のツールが既に/*@...... */ ってタイプのコメント使ってるので
言語仕様に組み込むのはダメって話らしいんだけど。
244:デフォルトの名無しさん
07/08/08 03:26:00
コメントに書くのは邪道。
245:デフォルトの名無しさん
07/08/08 19:26:13
>>243
そーゆー事やりたいんだったら、JDK7以降用にソースを書いておいて、
Tree API とか使ってアノテーション落とした方が良いかもね。
246:デフォルトの名無しさん
07/08/09 11:58:02
エスケープ解析って、*.javaを解析するのか、*.classを解析するのかどっちなの？
247:デフォルトの名無しさん
07/08/09 12:35:59
>>246
.javaはまず無い。バイトコードにスタックにオブジェクトアロケーション
する命令なんか無いんだから。おそらくバイトコードをJITコンパイルする
段階でエスケープ解析していると思われる。
248:デフォルトの名無しさん
07/08/09 13:00:12
>>243
> @Readonly Object x;
> if (x instanceof Date) { ... } // error: incompatible annotations
> if (x instanceof @Readonly Date) { ... } // OK
> Object y;
> if (y instanceof Date) { ... } // OK
> if (y instanceof @NonNull Date) { ... } // error: incompatible annotations
これ必要なんだろか？ 型アノテーションってインスタンス毎に
ついてるわけじゃなくてerasureなgenericsと同じような扱いでしょ。
こんなん付けても無駄に長くなるだけなんじゃ……
249:デフォルトの名無しさん
07/08/09 13:10:08
エスケープ解析って、
＞バイトコードをJITコンパイルする 段階
の技術だったのか。よくわかった。
ただ、「思われるとか」憶測で語っているのはどうかと。
250:デフォルトの名無しさん
07/08/09 13:32:15
思われなくても、JITコンパイル時の処理です。
251:デフォルトの名無しさん
07/08/09 13:47:33
>>248
if (list instanceof ArrayList<String>) { ... }
とかはコンパイルエラーになるのにな。
一貫性がないっつーか……
252:デフォルトの名無しさん
07/08/09 13:49:34
>>250 よくよくわかった。
253:デフォルトの名無しさん
07/08/09 14:00:37
>>243
なんつーか互換性重視だった 1.5 までと、
どっちかっつーと互換性軽視 機能追加重視の最近の風潮で
ねじれが出てるような気もする。
こんぐらい無節操に機能追加される（予定だ）とプリプロセッサ使いたくなるよな。
>>245 のも発想的にはプリプロセッサだし……
254:デフォルトの名無しさん
07/08/09 14:30:29
アノテーション使わなければ、互換性あるんだからいいんじゃね？
255:デフォルトの名無しさん
07/08/09 14:36:28
どの互換性を軽視だって？
256:デフォルトの名無しさん
07/08/09 14:45:12
>>255
write once compile any version が出来ない、
もしくは無理にやろうとすると、新機能使えなくて不便になるって話。
257:デフォルトの名無しさん
07/08/09 15:03:26
内部でクロージャが使えない、とかは我慢すれば良いとしても
古いバージョンもサポート対象に入ってて JSR-308みたいのが使えないと
新バージョンで使う時に型情報が減るからな。
258:デフォルトの名無しさん
07/08/09 15:22:20
>>256
（ ﾟдﾟ）ﾎﾟｶｰﾝ
259:デフォルトの名無しさん
07/08/09 15:38:30
>>256
まぁ、言語として複数バージョンに対応するための配慮なんかは一切無いな。
#ifdef 使えばソース汚くても複数バージョンに対応できるみたいな救済策もないし。
260:デフォルトの名無しさん
07/08/09 15:39:23
相手に合わせようとするのは、JAVAらしくないな。
逆に、相手がJAVA（JVM）に合わせろってところにJAVAの互換性がある。
261:デフォルトの名無しさん
07/08/09 15:40:54
>>256
クラスワーキング・ツールキット: 古いJVMでJ2SE 5.0の機能を使う
URLﾘﾝｸ(www-06.ibm.com)
JavaのGenericsに関しては、上位互換性(下位互換性ではなく！)を満たすために
Erasure方式で実現したから、コンパイルオプション指定でJDK1.4でも動くはずだが。
262:デフォルトの名無しさん
07/08/09 15:40:54
>>257
まず型ありきの言語で型情報減るのは痛いよな。
263:261
07/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:デフォルトの名無しさん
07/08/09 16:02:53
>>261
-target jsr14 だっけ？ 文書化されてないんだよね、これ。
265:デフォルトの名無しさん
07/08/09 16:05:35
>>263
> JDK1.4でコンパイルされたライブラリを、
> JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．．
可能っちゃ可能だけど、パラメタ型の情報無いよ
266:デフォルトの名無しさん
07/08/09 16:14:57
>>264
-target jsr14を使うと可能でした。ｔｈｘ。
Java の理論と実践: Java 5 の言語機能を以前の JDK で使う
URLﾘﾝｸ(www-06.ibm.com)
列挙型以外はほぼ問題ないようだ。
267:デフォルトの名無しさん
07/08/09 17:24:49
>>266
JDK5以降のライブラリや、メソッドを使うときに注意。
Autoboxingなどはちゃんと処理される。
268:デフォルトの名無しさん
07/08/10 01:25:21
win32 apiとか触るの面倒だし、だれかjvm上で.netが動くの作ってくれないかな
C＃をインタプリタ実行するのでもいいからさ
269:デフォルトの名無しさん
07/08/10 01:26:53
>>268
それはそれで凄まじいな
……考えてみるか。
270:デフォルトの名無しさん
07/08/10 01:51:45
C# を Java バイトコードにコンパイルする方が楽じゃない？
271:デフォルトの名無しさん
07/08/10 02:08:05
エスケープ解析は、*.javaに対して行っておくほうが実行効率がいいけど、その情報を*.classに残す手段がないので、実行時の最適化でしか使われていない
272:デフォルトの名無しさん
07/08/10 02:12:52
>>249
>>247だが、実際にソースまで追って確認したわけじゃないので
そういう表現になっただけで、JITコンパイル段階でやってるのは
ほぼ間違いないよ。まあ、厳密に言えばインタープリタモードでも
やってる可能性もあるけど、メリットが考えられない。
273:デフォルトの名無しさん
07/08/10 03:03:50
手段がないわけじゃないと思うけど。
stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。
ただ、静的に解析しても効果が弱いと思う。
メソッドの非仮想化やインライン展開を終えた後にやる方がいい。
274:デフォルトの名無しさん
07/08/10 03:17:31
>>273
それは、メソッドの非仮想化とインライン展開がエスケープ解析に与える影響がすごく大きいってこと？
そうは思えないんだけど。
275:デフォルトの名無しさん
07/08/10 03:46:33
>stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。
これは上で出てきたstructをJava言語でサポートするんじゃなくて、
JVMでサポートするってのに実質的に近いんじゃないか？
276:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/08/10 04:44:16
>win32 apiとか触るの面倒だし
ここらへんあるから実質C#はマルチプラットフォームじゃないよね。
278:デフォルトの名無しさん
07/08/10 09:53:41
>win32 apiとか触るの面倒だし
それだけだったら、win32 api を触らなくて済むようなGUIフレームワークとかを使えばいいだけと違うん？
279:デフォルトの名無しさん
07/08/10 09:56:34
>>273
> ただ、静的に解析しても効果が弱いと思う。
> メソッドの非仮想化やインライン展開を終えた後にやる方がいい。
二行目は静的/動的と関係ないじゃん。
280:278
07/08/10 09:57:41
って、.C# か・・・ じゃあ GTK# とか・・・ びみょかな・・・
281:デフォルトの名無しさん
07/08/10 11:35:35
>>279
静的に＝.javaのコンパイル時にって意味で書きました
.javaコンパイル時に非仮想化・インライン展開とかできないでしょ
わかりにくくてごめんなさいね
この暑さでちょっと疲れてるんだ
282:デフォルトの名無しさん
07/08/10 11:49:09
出来ないことないじゃん。もうInner classあるんだから。
283:デフォルトの名無しさん
07/08/10 11:54:25
Inner class って、なんか関係が？
284:デフォルトの名無しさん
07/08/10 11:59:12
インナー・クラスの非仮想化・インライン展開はソース・コンパイル時に出来る。
285:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/08/10 12:42:11
そもそもprivate:ならインライン展開し放題じゃない。
287:デフォルトの名無しさん
07/08/10 12:45:06
それはまぁね。
288:デフォルトの名無しさん
07/08/10 17:18:14
で、実際デフォルトで（知らないところで）インライン展開はされているのか？
それも、メモリ上に展開なのか、ソースコード（.class）のバイト数が増加しているのか。
289:デフォルトの名無しさん
07/08/10 17:20:42
> で、実際デフォルトで
（ ﾟдﾟ）ﾎﾟｶｰﾝ
290:デフォルトの名無しさん
07/08/10 17:45:00
はいはい、あげあし君はさようならで
291:デフォルトの名無しさん
07/08/10 17:58:23
似たようなことを議論してるよ。
stack allocateについては、
アノテーションで指示するか、
ByteBufferでアドレッシングしてくれってことのようだ。
URLﾘﾝｸ(bugs.sun.com)
292:デフォルトの名無しさん
07/08/10 18:31:07
>>291
そこの議論の対象はC/C++の struct で作られたような
データ構造にアクセスする事であって、
言語仕様的に stack allocated object が欲しい場合は
URLﾘﾝｸ(bugs.sun.com)
URLﾘﾝｸ(bugs.sun.com)
どっちかにvoteしろって書いてあるよ
293:デフォルトの名無しさん
07/08/10 18:35:28
C# だと各メンバに FieldOffset が指定できるよね
>>291 はそういう話じゃないの？
294:デフォルトの名無しさん
07/08/10 18:54:29
>>292
で、君はそっちのREFをチェックしてからものを言ってるわけなのかな？
>>293
C#がどうしたって？
ざっとみてスタックがどうとか言う議論になってたから似たようなの出してみたのだけど。
295:デフォルトの名無しさん
07/08/10 19:02:35
いや、データをバイト列にパックする話とスタックアロケーションは別の問題だから。
296:デフォルトの名無しさん
07/08/11 03:07:02
君の都合にあわないからといって、いちいち相手にｹﾁをつけるところは君の悪い癖だな
297:デフォルトの名無しさん
07/08/11 16:11:19
なあ、全員「デフォルトの名無しさん」じゃねえか
同一人物間でケンカ自演してるのってどうよ
って突っ込んでるオレも同一人物な訳だが
298:デフォルトの名無しさん
07/08/11 16:22:00
夏休み的なツッコミだな
299:デフォルトの名無しさん
07/08/11 19:00:47
ボケだろ、ボケ
300:デフォルトの名無しさん
07/08/13 15:24:33
ノリツッコミか
301:デフォルトの名無しさん
07/08/18 04:47:25
JDK7 build18
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
細かいバグ修正とか。
302:デフォルトの名無しさん
07/08/19 07:15:13
java LnFっていずれocanからSwing new LnFと謳ってるNimbusになるのかね？
303:デフォルトの名無しさん
07/08/19 08:19:46
Nimbusはスクロールバーがヤだ
304:デフォルトの名無しさん
07/08/19 15:38:42
確かにへぼいな
305:デフォルトの名無しさん
07/08/19 16:52:27
javaのスレでC#の話をするなボケども
306:デフォルトの名無しさん
07/08/19 17:31:28
JSR 310ってどうよ
307:デフォルトの名無しさん
07/08/19 19:22:01
>>302
Nimbusはごっつい雰囲気が強すぎて微妙ー
Aquaとかみたいな甘いデザインにしてくれと思う。
>>306
各所のブログでJSR 310は入れてほしくないと言われているな。
どうなんだろう・・・
308:デフォルトの名無しさん
07/08/19 19:34:49
使うことはあまりないだろうな。
309:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/08/19 21:28:31
>>306
URLﾘﾝｸ(jsr-310.dev.java.net)
311:デフォルトの名無しさん
07/08/20 17:49:33
>>309
いや、正直、1月が0とかは文章にしていてもあり得ない。
使うたびにAPIをその仕様で設計したヤツに殺意を覚える。
ライブラリの使い方からCと違うんだから中途半端にわかりにくくしてるだけ。
312:デフォルトの名無しさん
07/08/20 18:02:22
文章化してあるから問題なしって・・・
313:デフォルトの名無しさん
07/08/20 18:56:22
>>311
分かりにくいっても、C言語使った事あれば1月が0になる事もあるってのは予測可能だし。
不勉強な上に不注意な連中が躓く原因であるのは確かだろうけど、
たぶん、そういう連中は 月フィールドが 1オリジンになったら Calendar と互換性なくなって躓くだろう。
ゼロから新しいAPIを作るならともかく、既存の Calendar と共存するつもりなら、
新しいクラスを作って、そのクラスの月フィールドを 1オリジンにしたぐらいじゃ幸せにはなれない。
314:デフォルトの名無しさん
07/08/20 19:37:12
>>311
まぁ有り得ないとか殺意を覚えるってのは程度の差だからなんとも言えんけど。
オレとしては 1月を 1 にしたければ、とりあえずユーティリティメソッド1つ作れば良いと思うんだわ。
で、オレの感覚からすれば、ユーティリティメソッド1つで解決するような問題を掲げて
わざわざ新API作ろうって感覚の方が有り得ないんだわ。
スライド見て感じた事ってのはそーゆー事。
315:デフォルトの名無しさん
07/08/20 19:43:10
今から新しく作るんなら、enumにすればいいんじゃまいか。
public enum Month { JANUARY, FEBRUARY, ... }
316:デフォルトの名無しさん
07/08/20 21:05:04
そして旧暦閏月で困ると。
317:デフォルトの名無しさん
07/08/20 21:21:43
閏月対応してるクラスってあったっけか？
318:デフォルトの名無しさん
07/08/20 23:19:30
Timeの方は刹那とかに対応しないかなと思ってみたりｗ
10^-18なんて精度表せないだろうが。単位として扱えたら面白そう。
319:デフォルトの名無しさん
07/08/20 23:25:25
誰が使うんだ、そんなもん……
320:デフォルトの名無しさん
07/08/20 23:41:02
ナノ時間取得はコストが高すぎるんだよな・・・
321:デフォルトの名無しさん
07/08/21 01:23:50
>>319
坊さん用ソフト開発なプログラマｗ
24時間=30牟呼栗多=900臘縛=54,000怛刹那=6,480,000刹那という変換するとか。
スウォッチインターネットタイムも欲しいな。
322:デフォルトの名無しさん
07/08/21 01:33:32
坊さん用なら卒塔婆プリンタの方が喜ばれそうだが。
っつか、Wikipedia漁って適当な事言ってるだけじゃね？
323:デフォルトの名無しさん
07/08/21 08:50:41
URLﾘﾝｸ(www.atmarkit.co.jp)
同じくフォーチュン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:デフォルトの名無しさん
07/08/21 09:53:51
そろそろJava終了のアナウンスがSunからあるのかな
まぁいい思い出になったよ
325:デフォルトの名無しさん
07/08/21 10:20:43
>>323
ASPとASP.NET合計で51.5％か。意外に低シェアだな。
>>324
Sunあぼーんして、IBM & Google が実権を握ってくれる方が嬉しいなぁ。
326:デフォルトの名無しさん
07/08/21 10:23:58
>>315
一応、Calendar.JANUARYとか定数ならあるよ。
そっち使うでしょ普通。
327:デフォルトの名無しさん
07/08/21 10:24:54
あ、そっち使うでしょ、ってのは0とか1とかじゃなくて、って意味。
enumならなおよろしいけど、互換の問題がねぇ・・・。
328:デフォルトの名無しさん
07/08/21 13:37:56
>>327
日付扱うときは、だいたいユーザー入力だから無意味。
プログラム中でJANUARYとか指定することなんてあまりないんじゃね？
329:デフォルトの名無しさん
07/08/21 16:31:57
ユーザー入力を文字列として持ち回すと難儀だよね。
でも、WEBアプリにしろSwingにしろ、フレームワークとか
日付入力コンポーネントとかでDate型で最初から
扱える奴あるし、今時大概そうじゃないのかな。
プログラムの中で月決め打ちってのは確かにあまりないですね。
テストコードくらいか。
330:デフォルトの名無しさん
07/08/21 17:51:54
>>314
いや、ラッパークラスを用意すればいいってのはユーザ側の対応になる。
それはつまり、現状のDate型の変更に依存する訳だし
自分が書いたコードはラッパークラスを必ず含まなくてはならなくなる。
それならコアAPIに入っててくれよ、と思わないか？
今のDate型の実装だと、実装者自身が作り直したいと考えても
仕方がないような作りが多々ある。Calendarを追加して手当したけど
時間、日時を扱う場面は多くある。
これだけJavaが使われてその問題点が明らかになったんだから
新しくより合理的なAPIができてもいいと思う。
言うなればJava3とでもいうものへのへの緩やかな変化。
基本的なモノだからこそ改良が重要になってくるとは思うんだ。
アトは失敗しないようにしっかりと作ろうってところだろうか。
331:デフォルトの名無しさん
07/08/21 18:15:12
Calendarいらないってがんばっている人もいる。
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(d.hatena.ne.jp)
これが本当に通ってくれれば
憂いなしで嬉しいな。
332:デフォルトの名無しさん
07/08/21 18:29:39
つか、きしださんまで月間違ってるし！
333:デフォルトの名無しさん
07/08/21 19:05:53
>>330
ラッパークラスで解決しようというのはダメだろ。
Calendar の set やら get を ラップして 1月が1になるようにしても、
自分の目の届く範囲だけなら構わないけど、
第三者が作ったクラスに渡す場合には、そのまま渡したら 1ヶ月ずれる。
そんなゴミをコアAPIに入れられたら、 Calendar をやり取りする
メソッド作る場合に、必ず instanceof とかでチェックしなきゃいけなくなる。
334:デフォルトの名無しさん
07/08/21 19:08:21
>>331
無理じゃね？
java.util.Date は Serializeable だし、
Date の TimeZone対応とかやったら、
シリアライズされたデータの互換性なくなるんじゃないか？
335:デフォルトの名無しさん
07/08/21 19:10:30
W3C-DateTimeからRFC2822-DateTimeに用意に変換できるようなものが欲しい。
RFCのほうはCWFSのおかげでやたらパースがしにくい。
336:デフォルトの名無しさん
07/08/21 19:23:34
>>330
> これだけJavaが使われてその問題点が明らかになったんだから
> 新しくより合理的なAPIができてもいいと思う。
あっても良いけど、closure とかに比べると優先度は低いよね。
それに「問題点」ってのも個人個人で違うわけで、1月 が 0 なのがダメなのか、
setter の戻り値の型が void だから、1行に詰め込んで書けないのが問題なのか
それ以外なのか。
現状では愚痴とか不満は出てるけど、
それらを一つに纏めて、多くの人が納得でき、多くの人が幸せになれるような
解決策が提示されているかっていうと、少なくとも JSR-310 は違うと思う。
337:デフォルトの名無しさん
07/08/21 20:22:16
>>335
まえにjavascriptの実装がどっかのブログで公開されてたぞｗ
338:デフォルトの名無しさん
07/08/21 22:16:24
>>336
いや、JSR-310はまだ固まってないし。
そういう動きがある、ということしか言えないと思う。
なんで、これからの頑張り次第でしょ、という話。
それとも、「日付関係の新しいAPIは要らないぜ」という話？
339:デフォルトの名無しさん
07/08/21 23:24:14
>>338
1月が 1 と書けるようになっただけ、の Calendar みたいなクラス作られても
あっちのフレームワークでは互換性のために旧Calendar要求され、
こっちのフレームワークでは機能性のために新API要求され、
みたいに手間が増えるだけになる可能性が高い。
かと言って、Calendar が解決しなかったニッチな要求のためだけのAPI作ったら
わざわざ標準APIに突っ込む必要ないって話にもなるし。
既存のDate＆Calendarがある状況で
日付関係の新しいAPIを作るのは凄く難しいと思ってるんだけど、
1月が 0 なのがキモイみたいな事かかれると、
マトモなものが出来るのか心配になるって話。
340:デフォルトの名無しさん
07/08/21 23:27:03
動画再生用のSwingコンポーネントが標準化されたりしたら嬉しいのだけど、
JavaFX Scriptに合わせて対応してくれたりせんのかねぇ。
Flashは次のバージョンでH.264にも対応するとか発表してるし、
本気でRIA市場に乗り込むならここらへんを抑えてくれないと支持しにくい。
341:デフォルトの名無しさん
07/08/21 23:36:53
つ JMF
342:デフォルトの名無しさん
07/08/21 23:38:58
JRE以外にインスコしてもらえるわけないじゃんｗ
343:デフォルトの名無しさん
07/08/21 23:51:58
jarに全部突っ込んでマニフェストでパス指定するか。JWSでいいだろ。
けどJMFのH.264コーデックがまだIBMのプロプラライセンスものしかなかった気がする。
344:デフォルトの名無しさん
07/08/22 09:04:57
>>339
相互変換はコンストラクタ一発なんだから問題ないんじゃね？
345:デフォルトの名無しさん
07/08/22 09:09:49
SilverlightやFlashに比べて、JREはインストール面で不利すぎる気がするのですが
軽量プラグインとか出す予定はないのでしょうか？
346:デフォルトの名無しさん
07/08/22 09:24:14
何を削るかで揉める事必至だろうなぁ・・・
いっそのことJ2MEのランタイムを作ってそれを軽量プラグインにするとか
347:デフォルトの名無しさん
07/08/22 11:31:10
分割ロードの方が良さそうだなあ。
Javascriptは何でも一つのファイルにぶち込むのが流行ってきているけれども。
348:デフォルトの名無しさん
07/08/22 14:09:41
>>345
Java Kernel と呼ばれているものを jdk6 update 4 で出す予定
URLﾘﾝｸ(weblogs.java.net)
URLﾘﾝｸ(weblogs.java.net)
349:デフォルトの名無しさん
07/08/22 14:24:44
>>344
Date と Calendar はコンストラクタ一発で変換できてないじゃん。
それと同じ事が起こる事は十分予測可能。
350:デフォルトの名無しさん
07/08/22 14:30:23
>>349
っつーか、コンストラクタ一発で変換できても煩雑なのは変わらんのだがな。
351:デフォルトの名無しさん
07/08/22 20:01:17
”よく知られた日付型”がこれ以上混在されてもうざいだけだよ。
DateにCalendarにsql.Dateと、”よく知られた日付型”は、もう既に食傷気味です。
所詮は64bit unix epocと割り切ったユーティリティメソッドが拡充される方がよほど嬉しい。
352:デフォルトの名無しさん
07/08/22 21:21:02
なるほど。
良くあるパターンに特化したユーティリティメソッドを用意してくれる方が
ありがたい気がする。
353:デフォルトの名無しさん
07/08/22 21:49:03
JREのインスコなんてウィザードに従えば良いだけだろ。
それより、システム管理全体がside by sideへ以降してきてメンテにエンドユーザーの負担が掛かってると思う。
354:デフォルトの名無しさん
07/08/23 01:19:58
JSR 310はいいと思う。
ユーティリティ・クラスとしても上出来。
355:デフォルトの名無しさん
07/08/23 03:08:43
>>354
そうなん？
>>310 に JSR-310 のAPIリファ来てるけど、
これどんな時に便利なのかサンプルコードとか書いてくれん？
っつか、オレには Moment や Period のサブクラスが
年、月、日、時、分、秒と分かれてる必要性がイマイチわからん。
356:デフォルトの名無しさん
07/08/23 04:03:13
タイムベースの処理が必要でそのフレームワークを自前で作らなきゃいけないときに下のライブラリとして使えそうだな。
357:デフォルトの名無しさん
07/08/23 04:06:51
>>310がJSR-310のリンクになっていることに
今になってようやく気が付いた。
なんか黄色ナンバーの車を1日10台見たとか
ワーゲン見たとかその程度にちょっと幸せ。
358:デフォルトの名無しさん
07/08/23 08:11:21
>>355
ぶっちゃけ、>>310より>>331の方が良いと思う……
359:デフォルトの名無しさん
07/08/23 08:43:24
>>356
逆に言うと、それ以外の目的に使えなさそうじゃね？
360:デフォルトの名無しさん
07/08/23 08:46:22
どっちがいいとかそういうもんじゃないだろ。
310はベースとなる時刻クラスを提供するんだから。
361:デフォルトの名無しさん
07/08/23 08:49:25
今のままだったら Date ＆ Calendar の方が下位層で
JSR-310 はそれに乗っかるだけの上位層になりそうだが
362:デフォルトの名無しさん
07/08/23 08:50:20
（ ﾟдﾟ）ﾎﾟｶｰﾝ
363:デフォルトの名無しさん
07/08/23 08:52:26
おまけに使用用途が酷く限定されている、と。
364:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/08/23 09:25:39
>>360
310が提供するベースとなる時刻クラスってどれよ？
366:デフォルトの名無しさん
07/08/23 11:36:39
文字列からのファクトリメソッドは、
別クラスにした方がいいんじゃないの？
L10N考えると劇重プロジェクトだし。
GNU dateコマンドみたいな時間指示を考えると、やること一杯ある。
367:デフォルトの名無しさん
07/08/23 11:46:17
これはひどい
ベースとなる時刻クラス・・・ Instant かねぇ
でも CalendarDay や TimeOfDay との相互変換はできそうになく
既存の Date や Calendar との繋がりもない
どうやって使うんだこれ
368:デフォルトの名無しさん
07/08/24 00:25:02
310はまだ、かなりドラフトな感じだが、
PeriodとMomentとその実装クラスを細かく分けるのは、
安全でかつ読みやすくなるのでよいと思う
例えばMomentにMomentは追加できないがPeriodは追加できるとか
369:デフォルトの名無しさん
07/08/24 01:23:17
Instant と fully defined な SingleMoment を区別する理由と、
Period と Interval を区別する必要とか、
Duration とか良く分からん。
Duration と Inteval はまだ出来てないみたいだけど。
>>368 も同意っちゃ同意なんだけど、
それって Moment と Period が別になってる理由にはなっても、
Moment や Period のサブクラスが 年、月、日、時、分、秒と
細かく分かれてる理由にはならんよね。
370:デフォルトの名無しさん
07/08/24 01:58:25
>> 369
>Moment や Period のサブクラスが 年、月、日、時、分、秒と
>細かく分かれてる理由にはならんよね。
なんで?
Days days = ...;
days = days.plus(Days.days(3));
とか具体的な型が決まっていたら安全かつ読みやすいじゃん。
しかしメーリングリストだとなんかいろいろ提案とか出されたり、まだまだな感じがしてきた。
sunの中の人が書いてるが、
URLﾘﾝｸ(blogs.sun.com)
既存のAPIとの互換性とか国際化も考えると大変そうだね。
371:デフォルトの名無しさん
07/08/24 02:02:32
>>369
後者については type safe のためとか？
もしくは、
Moment moment = build(dayOfMonth(1), hourOfDay(3));
とかやると、毎月 1日午前 3時 をあらわすようになるとか……
372:デフォルトの名無しさん
07/08/24 02:05:26
>>370
おいおい……
一見型安全かもしれないけど、
それだけだと、逆に Period で 1カ月と3日とか複合的な指定できなくなるんですけど……
373:デフォルトの名無しさん
07/08/24 02:10:03
>>371
あぁなるほど。可変長引数のビルダーメソッドで纏めるとか
そーゆー場合には別々のクラスになってないとダメだな。
>>370
これはひどい
374:デフォルトの名無しさん
07/08/24 02:34:16
>>372
Periodとしての一ヶ月というのは日数として組み合わせて扱えない気がするが。
375:デフォルトの名無しさん
07/08/24 02:37:46
（ ﾟдﾟ）ﾎﾟｶｰﾝ
376:374
07/08/24 02:48:29
今のAPIを見る限り、複数のPeriodを組み合わせたPeriodというのはない気がする。
Monthsに関しては月によって日数は変わるので、months.plus(Days.days(3))みたいな計算は書けないと思うが。
しかしCalendarDayはplus(Period...)というのを持ってるので、一ヶ月と3日後とかを計算できると思う。ただMinutesとSecondsとの変換とかできそうな気がするのにできないように見えるのはよくわからない。
377:デフォルトの名無しさん
07/08/24 02:51:08
>>372
そーゆーのは、まだない Interval でやるって話なんじゃね？
しっかし、凄く分かりにくい API だな、これ。
そこそこ経験がある奴でもサンプルコードが無いと一行も書けないぞ。
378:デフォルトの名無しさん
07/08/24 02:55:09
>>373
instanceof で比較するところを enum と switch で置き換えれば
良いだけだから、別々のクラスになってる必要は全くなかったりする。
379:374
07/08/24 03:03:40
やっぱりわかりにくいのだろうか?
変換とかファクトリとかのメソッドがどこにあるかわからず、分かりにくい、というのはあるかもしれないが、
そもそも日付と時間の長さなどを区別して扱うこと自体が複雑で、結局intとかで扱っても値の種類を把握していないといけないのでは。
ある程度、単位を型でエンコードして分かりやすくすることで安全で読みやすいコードになる方がよいと思うのだが...
380:デフォルトの名無しさん
07/08/24 05:59:11
Sun が NASDAQ での銘柄記号を SUNW から JAVA にかえるんだそうな。
URLﾘﾝｸ(blogs.sun.com)
URLﾘﾝｸ(blogs.sun.com)
いや、次世代Javaと関係ないけど。
っつーか、これジョークじゃないの？ 4月1日じゃないけどさ。
381:デフォルトの名無しさん
07/08/24 07:09:27
Dateみたいな基本的なところに今から手を入れるのがアリなら、
Numberもどうにかしてくれんかな。
やっぱり Integer inherits Double であってほしいし、BigDecimalで
持っている四則演算メソッドはNumberすべてで使いたいが。
382:デフォルトの名無しさん
07/08/24 07:17:34
>>380
JAVAの株があがったとか下がったとかが問題になってくるわけか。
そしたら、JAVAと大文字で書くやつはJavaのことを知らないという伝説が強くなるわけだ。
383:デフォルトの名無しさん
07/08/24 07:43:01
>>381
Numerics関係は難しいんだよな、後からいじるの。
非互換の影響が大きすぎて。
仕様お目付け役だった、Guy Steeleさん、この辺が弱い。
384:デフォルトの名無しさん
07/08/24 16:04:46
元がSUNWならJAVAWにすればいいのにコンソール出ないし・・・。
385:デフォルトの名無しさん
07/08/24 16:57:17
>>381
メソッド追加はありでも継承関係は変えられないだろうな
386:デフォルトの名無しさん
07/08/29 21:26:22
そろそろ deprecated のクラスやメソッドを一掃してほしい
387:デフォルトの名無しさん
07/08/29 22:30:24
Cloneable を Clonable に直してほしい
388:デフォルトの名無しさん
07/08/30 02:13:33
creat....
389:デフォルトの名無しさん
07/08/30 23:47:25
catch必須例外を堂々と無視できるプラグマを追加してほしい。
390:デフォルトの名無しさん
07/08/31 03:25:48
アホか例外処理の意味ないだろ。
握り潰すことすら面倒くさいか？ｗ
391:デフォルトの名無しさん
07/08/31 12:32:21
JDK7 build19
URLﾘﾝｸ(www.java.net)
URLﾘﾝｸ(download.java.net)
forumで話題になっていた
4811096 Allow mixing of heavy and lightweight components
が入った様子。
SwingとAWT混ぜるなっていうのが古い話になるわけだ。
あと、レポジトリ管理、Teamwareを完全撤廃？SCCSキーワードの削除ってのが結構あった。
公開してるのも、Subversionでだしね。OpenSolarisで採用してる、Mercurialはないんだろうか？
392:デフォルトの名無しさん
07/08/31 21:15:56
>>390
めんどくさい。
どうでもいいコンソールプログラム書くときは
全部例外がトップレベルに流れて死んでくれていい。
あと、どうせならインタフェースの実装も堂々と無視できるプラグマも欲しい。
適当にnullとか0とかfalseとか、あるいはNotImplementedException投げるとか。
IDEにやらせればいいんだけどさ。
393:デフォルトの名無しさん
07/08/31 21:52:53
>>392
お前はCの方が合ってるんじゃないか？
つーかその程度の捨てアプリならスクリプトで実装すれば良いだけじゃん。
394:デフォルトの名無しさん
07/08/31 22:32:46
mainメソッドにthrows ExceptionってすればOK
395:デフォルトの名無しさん
07/09/01 02:07:00
Javaの例外処理の面倒くささはMatzがどっかで言及してたね
396:デフォルトの名無しさん
07/09/01 02:21:10
silentClose(Closeable) みたいなメソッド作るとか
使い捨てアプリ作る時は throws Exception つけるとかすれば
そこそこ改善すると思うんだけどね
397:デフォルトの名無しさん
07/09/01 02:29:38
>>395
むしろその例外処理の面倒さがないからこそ
他の言語があぶなっかしくて使えない。
コード品質重視だと特に。
398:デフォルトの名無しさん
07/09/01 06:37:06
むしろ投げる例外をdoc,code上で明文化されてないと何拾って良いか分からないだろ。拾えないと例外に対処できない。
throw,throwsでthrowable以外が飛んでくるのもおかしいし。
399:デフォルトの名無しさん
07/09/01 16:45:03
ExceptionはThrowableである。以上。
400:デフォルトの名無しさん
07/09/02 09:52:45
例外処理の仕組みが問題というよりも
IOExceptionとかSQLExceptionのようなレベルの例外を
チェック例外にしてるのが問題だと思う
SpringやS2やHibernateなら、これらの例外をランタイム例外にラップしてくれるし
JavaEE5ではランタイム例外を多用してるけど
肝心の、JavaSEのコアなAPIがチェック例外だらけだからな
>>397
現実には、Javaのチェック例外記述のめんどくささに嫌気がさした開発者が
catch (Exception e) {
e.printStackTrace();
}
とか書いて、返って品質悪化するパターンの方が高い気がするorz
401:デフォルトの名無しさん
07/09/02 11:41:41
あと InterruptedException も握りつぶされて困りやすいチェック例外だ
あー
InterruptedIOException とか、きっと知らんうちに IOException もろとも握りつぶしてる気がしてきた
try {
......
} catch (InterruptedIOException e) {
Thread.currentThread.interrupt();
} catch (IOException e) {
......
}
なんて、書いた覚えがないよ
402:デフォルトの名無しさん
07/09/02 11:50:49
例外のためのEffective Javaみたいなのがあれば読んでみたい。
こういうのはお習字の世界だから仕様としてどうこう変えるもんでもないし。
403:デフォルトの名無しさん
07/09/02 13:29:09
>>400
IOExcepotionとかは>>396みたいなメソッドがあれば解決する問題
後半に関して言えば
そーゆー奴は面倒くさいので例外処理しないし
他人のために必要な例外関連のドキュメントも書かない
ので検査例外をあってもなくてもそれほど品質は変化しないと思うが
404:デフォルトの名無しさん
07/09/02 13:39:45
何が言いたいのやら・・・必死なことだけは解るが
405:デフォルトの名無しさん
07/09/02 13:48:59
IOExceptionやSQLExceptionがチェック例外なのは当然だろ？
外部リソースに依存してんだから、チェックし無い方がどうかしてる。
DAOならそれらをcauseにして、DAOExceptionみたいに新たなチェック例外にくるむがよろし。
406:デフォルトの名無しさん
07/09/02 13:55:57
closeが例外なげるバカなAPI
407:デフォルトの名無しさん
07/09/02 14:04:03
close は flush を伴うからエラーが発生する可能性はある
408:デフォルトの名無しさん
07/09/02 14:07:19
closeが例外なげるのがバカってどんだけゆとり脳なんだ
409:デフォルトの名無しさん
07/09/02 14:14:18
思うに、チェック例外をキャッチしないと
警告出すだけの仕様だったらどうなっていただろうか？
410:デフォルトの名無しさん
07/09/02 14:26:33
throws SQLException って書いてないのに throw new SQLException() するような
混ぜるな危険メソッドが書き放題で検査例外の意味がなくなる。
それでいてソースに SuppressWarnings("ignorecheckedexception") とか
コンパイル時に -ignorecheckedexception とか必須だと手間がかかるだけ。
中途半端で役に立たないソリューションの見本だな。
411:デフォルトの名無しさん
07/09/02 14:30:17
んなもんソースレビューで片付けろよ
412:デフォルトの名無しさん
07/09/02 14:44:28
closeが検査例外を投げるバカなAPI
413:デフォルトの名無しさん
07/09/02 14:49:51
>>411
第三者の作ったライブラリやフレームワーク使う時は
それらも全部ソースレビューすんの？
414:デフォルトの名無しさん
07/09/02 14:51:10
必ずソースが見れるとは限らんし
415:デフォルトの名無しさん
07/09/02 15:05:42
>>405
IOExceptionとかって多くの場合リカバリできるの?
リソースの解放はfinallyでやるからチェック付き例外とは関係ないと思うし
なるべく例外がチェックできるべきだという意見は多い様に見えるが、一般的にそれらの例外がほとんどリカバリできる処理を書けないならば >>400の言うようにAPIの設計の問題では?
416:デフォルトの名無しさん
07/09/02 15:10:27
ソケット使って読み書きしてる時にIOExceptionが発生したらリトライするとかあるよね
417:デフォルトの名無しさん
07/09/02 15:53:29
>>416
そういう特定の事情のために、すべてのIO処理で面倒なコードを書かないといけないのはアホ
418:デフォルトの名無しさん
07/09/02 15:56:09
というか、例外が出ないコードで例外の補足が必要になるのが、設計ミス
System.in.read()
とか
419:デフォルトの名無しさん
07/09/02 15:57:17
面倒っても、throws IOException を宣言するくらいのもの。
その場で対処しない例外は上へ送る。
420:デフォルトの名無しさん
07/09/02 16:02:53
System.in.read() ってプラットフォーム側の標準入出力の実装方法によっては
例外が出る可能性があるんだが
421:デフォルトの名無しさん
07/09/02 16:10:33
俺としてはNumberFormatExceptionが実行時例外なのが許せないくらいなんだが。
外側のことは一切信用しないという性悪説プログラミングが心情だとね。
422:デフォルトの名無しさん
07/09/02 16:18:48
俺はUserTransactionのメソッドを使ってみたとき、
Javaのチェック例外は、API側が使い方を根本的に間違ってると痛感したよｗ
423:デフォルトの名無しさん
07/09/02 16:24:01
>>412みたいな事を言う奴から間違ってると言われても
424:デフォルトの名無しさん
07/09/02 16:31:07
>>419
それで上へ送った例外は結局どうなるわけ?
throws IOExceptionをまき散らして、
RuntimeExceptionになるか握りつぶされるぐらいじゃないの?
>>421
一切信用しないというのはいいが、それはどうやって処理される?
他の値で代用するのは多くの場合問題がある気がするし、
再度入力を促すことになると思うが、
可能な場合と不可能な場合(処理を中断するしかない場合)があると思う
...NumberFormatExceptionに関しては微妙な気がしてきた
RuntimeExceptionでよい場合も多いと思うが...
425:デフォルトの名無しさん
07/09/02 16:54:22
最近じゃ例外もAOPで処理するし、リソースはfinallyで閉じるからあまり関係ないしな
matz氏がブログで、例外をぎりぎりまで捕捉しないのがRuby流って書いてたけど
結局はそれがいちばん効率的で、開発者に都度catch処理を強制するよりも品質が上がるんだよね。
例外処理がなくても、異常終了で落ちるからテスト時にすぐわかるが、
catchで不用意に握りつぶされた例外はやっかいだし
426:デフォルトの名無しさん
07/09/02 17:06:07
何層か下のフレームワーク/ライブラリが投げてくる実装依存の例外もやっかいだけどな。
面倒くさいから検査例外は無い方が良いとか考えてる奴は、
例外関連のドキュメントなんて書かないから品質ズタボロのコードを量産する。
427:424
07/09/02 17:27:46
>>425
アプリケーション(基本的なライブラリでない)でのチェック付き例外は有用と見られているはずだ
アプリケーションレベルではリカバするべき例外を決めることができて、チェック付き例外で強制できる
アスペクトを使うことでIO例外をアプリの例外へ変換とかはうまく書けるが、
各メソッドごとの例外処理を常にうまく分離して書けるわけではない
テスト時にすぐわかるというのは理由にならないはずだ
再現が難しい例外だってあるから
それよりも発生したときなにもできないことが多いというのが理由だと思う
428:デフォルトの名無しさん
07/09/02 17:28:11
なんか次世代関係なくなってね？
JAVAの例外について勉強するスレとかたててそっちでやれ
429:デフォルトの名無しさん
07/09/02 18:30:35
例外処理が煩わしいのであれば、
例外処理を包含したテンプレートパターンを適用して処理すればいい。
APIは面倒か面倒じゃないかではなく、安全か安全ではないかが重要。
APIは極力安全に使えるように「馬鹿向け」に作られているが、
本当の馬鹿にはその意味すらわからないらしいｗ
430:デフォルトの名無しさん
07/09/02 18:57:24
わずらわしいどうの以前にその例外をどう扱うべきかというパターン自体が俺みたいな初心者にはわからない
使われる側でチェック例外を投げてから使う側で遺言を言ったあとRuntimeExceptionでラップするとか、
キャンセルなどの特殊な状況を処理するために使うとか、なんだろうか
431:デフォルトの名無しさん
07/09/02 21:40:59
捕捉する場所によって扱い方も異なるとしか言い様がないな。
ライブラリ書いてるなら、抽象的な例外でラップして投げなおすだろうし。
フレームワークならコントローラで一括処理で、それ以外では全部投げっぱなし。
432:デフォルトの名無しさん
07/09/02 21:49:00
個人的にはチェック例外＝病気の診断、ランタイム例外＝安楽死とか思ってる
で、今直せる見込みのない病人がいるとして、いろんな病院をたらいまわしたり（チェック例外のままthrowsしまくる）、
病気ではないとして放置したり（例外を握りつぶす）、
秘密裏に抹殺したり（System.exit(0)）、
するよりはランタイム例外にして安楽死させたほうがいいような気はするんだけどな。
でもそのあたりの常識やパターンやガイドラインみたいなものがないと実際何をやっていいのか分からないし、
URLﾘﾝｸ(www-06.ibm.com)とか見る限り、
今のAPI仕様でそれが完璧に行われているかというとそうでもない気がする。
どう診断すればいい医者であるか、と言う問題についてはもっと語られてもいい気がする。
433:デフォルトの名無しさん
07/09/03 00:54:17
病気になったら即安楽死＝良い医者だと？
434:デフォルトの名無しさん
07/09/03 00:56:05
スレ誘導しようとしたらいつのまにか例外処理スレが落ちてた。
435:デフォルトの名無しさん
07/09/03 04:46:11
>>420
その程度ならRuntimeExceptionで十分
436:デフォルトの名無しさん
07/09/03 07:58:03
>>435
その程度なら throws IOException 書いておけば十分。の間違いじゃね？