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

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

1:デフォルトの名無しさん
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技術と呼んでる

なんの問題もないだろ。

次ページ