2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

現世代Javaの動向 1

1 :デフォルトの名無しさん:2006/06/14(水) 20:56:29
次世代もいい、だが現世代もしっかり把握しておこうではないか?

派生元
次世代Javaの動向 2
http://pc8.2ch.net/test/read.cgi/tech/1147881822/

J2SE1.4やJavaSE 5.0などの現在リリースされているJavaについて
検討、反省、うだうだするスレです。

参考リンク
http://java.sun.com/j2se/1.5.0/ja/docs/ja/
http://java.sun.com/j2se/1.4.2/ja/download.html

2 :デフォルトの名無しさん:2006/06/14(水) 21:28:35
現世代は1.3.1だろ

3 :デフォルトの名無しさん:2006/06/14(水) 23:30:07
マジレスすると5.0

4 :デフォルトの名無しさん:2006/06/15(木) 00:36:22
参考:
JDK1.5.0_07
ttp://java.sun.com/j2se/1.5.0/ja/download.html
JDK1.4.2_12
ttp://java.sun.com/j2se/1.4.2/ja/download.html
JDK1.3.1_18 (Mustangリリースまでの命)
ttp://java.sun.com/j2se/1.3/ja/download.html

5 :デフォルトの名無しさん:2006/06/15(木) 07:47:59
5.0より1.4の言語仕様が好きな俺が来ましたよ。

6 :デフォルトの名無しさん:2006/06/15(木) 07:51:59
変態め

7 :デフォルトの名無しさん:2006/06/15(木) 08:13:07
>>5
ああ、テンプレートの採用とか?

8 :デフォルトの名無しさん:2006/06/15(木) 11:28:49
じゃあ、Genericsのイカした活用方法でも晒してくれ。

9 :デフォルトの名無しさん:2006/06/15(木) 11:49:28
うだうだする目的のスレはマ板にたてろと

10 :デフォルトの名無しさん:2006/06/15(木) 16:32:34
現世代Javaってことで、Java EE 5の話題なんてどうだ?

11 :デフォルトの名無しさん:2006/06/15(木) 21:25:12
Persistence APIって、結局なんなのかよく分かってない。
ObjectPersistenceにも使えるのかな??

12 :デフォルトの名無しさん:2006/06/17(土) 19:39:31
HashMap<String,HashMap<String,Object>> map = new HashMap<String,HashMap<String,Object>>();

13 :デフォルトの名無しさん:2006/06/17(土) 22:02:49
>>11
hibernateのこと

14 :デフォルトの名無しさん:2006/06/17(土) 22:09:24
てかさ、シリアライズって黎明期からあるのに
何を今更パーシステンスなんだろうって気もする

15 :デフォルトの名無しさん:2006/06/17(土) 22:10:49
>>13
ちょっとちがうのではないか?

16 :デフォルトの名無しさん:2006/06/18(日) 01:32:18
>>14
シリアライズは永続化するための必要条件だが必要十分条件では無い

17 :13:2006/06/18(日) 04:09:28
>>14
シリアライズと、ORマッピングは、まったく違うよ。
むしろ、シリアライズとORマッピングを同一視していたために傷口が広がったというようなことがどこかに書いてあった。

> 15
CriteriaとProjectionのところは違うね。

18 :デフォルトの名無しさん:2006/06/26(月) 20:23:34
揚げ

19 :デフォルトの名無しさん:2006/07/01(土) 11:40:56
CMP で全部リモートインターフェースでやって DTO を使ってた場合、

サーブレット → セッションBean → CMPエンティティBran

の都合二回シリアライズをやってる?

20 :デフォルトの名無しさん:2006/07/02(日) 04:11:26
何か、java.sun.com派手にデザイン変更されたね

21 :デフォルトの名無しさん:2006/07/02(日) 09:15:57
>>20
なんか日本語版がどこにあるかわからなくなった。

22 :デフォルトの名無しさん:2006/07/03(月) 15:46:36
漏れにはどこも変わってないように見える

23 :デフォルトの名無しさん:2006/07/03(月) 17:01:08
>>20
これで派手なのか?今まで通り普通にダイブできますが。何か。

24 :デフォルトの名無しさん:2006/07/04(火) 21:03:22
時給1000円でJava教えてくださるかたを募集します
場所 所沢(池袋・高田馬場から直通)

i−want−to−study−java@hotmail.co.jp
(アドレスは全角で書いてあるので半角に直してください)
よろしくおねがいします

25 :デフォルトの名無しさん:2006/07/07(金) 02:22:50

メールしたら監禁されてSPAM送信の手伝いさせられる悪寒


26 :24:2006/07/17(月) 21:29:23
教える対象は超初心者です。

専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です

27 :デフォルトの名無しさん:2006/07/17(月) 21:33:10
手動スクリプトってところがまたきもいな
あからさまな業者なのに失礼とも思わないゴミ

28 :デフォルトの名無しさん:2006/07/17(月) 21:40:13
超初心者=不法労働者=日本語通じねえ
とかだったらワロスwww

普通の人が欲しけりゃ、普通の募集かけるわな
ニートか、特殊な事情の人が欲しいって訳なんだろ?
どう考えても普通の仕事じゃねえな・・・怖いもの見たさを煽ってんのか?
・・・確かに見てみたいがっっw

29 :デフォルトの名無しさん:2006/08/30(水) 23:38:15
Genericsにはtypedefやある程度の型推論が欲しいと思うんだが、どう思う?

30 :デフォルトの名無しさん:2006/08/31(木) 00:18:17
>>29
俺も欲しいとは思うが、Javaにのせるのはどうなんだろうか?
識者の意見求む。

31 :デフォルトの名無しさん:2006/08/31(木) 00:21:19
>>30
新しい言語を作るならそれでよい。

問題は、後方互換性なんよね。全くレガシーって奴は厄介ですよ。

32 :デフォルトの名無しさん:2006/08/31(木) 00:38:34
>>31
サンクス
なるほど、後方互換性を取るのは難しそうですね、どちらも。
確かに、いまさらCloneableをClonableにする、なんて言われても・・・
って、これはEclipseのリファクタリング機能で何とかなるか。
まだ学生ですし、自分*だけ*の場合は、ですが。

33 :デフォルトの名無しさん:2006/08/31(木) 00:57:58
そこは類義語機能をつければ良いんじゃね?

34 :デフォルトの名無しさん:2006/08/31(木) 01:05:37
と、言いますと?

35 :デフォルトの名無しさん:2006/08/31(木) 01:27:10
interface Clonable extends Cloneable {}
を導入して、今後はみなClonableで書いていくようにする、と取り決めると、
どんな問題が起こるかな。

36 :デフォルトの名無しさん:2006/08/31(木) 01:30:15
>>35
導入されていないバージョンのJDK使うとClassNoFoundError。

37 :デフォルトの名無しさん:2006/08/31(木) 01:37:45
逆に
interface Cloneable extends Clonable {}
だと、instanceof Cloneableで判定してるところで通ってたものが通らなくなるな。

38 :デフォルトの名無しさん:2006/08/31(木) 15:52:04
typedefだけならいけるんじゃね?
typedefした結果、名前がかぶるならコンパイルエラーにするとかして。

39 :デフォルトの名無しさん:2006/08/31(木) 17:11:35
型推論って何ですか?

40 :デフォルトの名無しさん:2006/08/31(木) 23:19:50
すみません・・・型推論ってどういうものなんでしょうか?

41 :デフォルトの名無しさん:2006/09/01(金) 19:45:09
本当にすみません・・・

42 :デフォルトの名無しさん:2006/09/02(土) 00:32:04
誰か・・・

43 :デフォルトの名無しさん:2006/09/02(土) 00:37:46
>>7
Genericsはテンプレートとは呼ばぬ

44 :デフォルトの名無しさん:2006/09/02(土) 00:39:39
>>8
それなら、
SourgeForceに公開されている
Commons Collections wigh Generics のソースコードを参照するといい。

そのうち、Jakarta Commons CollectionsがGenericsに対応するぞ。


それと、Effective JavaのJava5対応版が出ればかなーり、
Genericsのノウハウについて身に着けられそうだ。


45 :デフォルトの名無しさん:2006/09/02(土) 00:45:35
>>32
広報互換性だけでなく、
Typesafeの問題もあるし


46 :デフォルトの名無しさん:2006/09/02(土) 00:46:51
>>38
typedefは面倒なことになるから導入しない方がいい。
C++の二の舞に。

47 :デフォルトの名無しさん:2006/09/02(土) 01:05:02
>>46
面倒なことって?

48 :デフォルトの名無しさん:2006/09/02(土) 01:12:52
>>47
覚えなきゃならん

49 :デフォルトの名無しさん:2006/09/02(土) 01:37:17
便利だと思いますけどね、typedef
もし、
HashMap<String, LinkedHashMap<String, List<String>>>
なんてあると悲惨だし。

50 :デフォルトの名無しさん:2006/09/02(土) 02:13:00
>>48
もっと大事な問題がある。

>>47
ストラウストラップが警告していたことだ。
その弊害は複数人で開発するときに起きる。
各々がtypedef宣言した型の定義が異なると
名前を書き直す手間が生まれ、面倒な自体に陥る。

typedefを導入するなら、typedefで定義した型が
重複してエラーにならないように名前空間も同時にtypedefに導入すべきだろう、
と思ったが、やっぱりそれでも混乱の元。

あらかじめチーム内でルールを決めていればいいが、
他社が作ったtypedef定義を使うときに自社で定義した型名が重複することがあり
面倒な事態が起きる。これが2社程度ならどうにかなる可能性があっても、
三社、四社となると非常にとんでもない苦労を強いられる。

>>49
その程度でtypedefを導入するなら、新たにラッパークラスで宣言した方がいい。

51 :デフォルトの名無しさん:2006/09/02(土) 02:50:42
ふーん、そうなのか。
で、今ではそのtypedefの難題をどうやって解決したの?

52 :デフォルトの名無しさん:2006/09/02(土) 10:05:54
>>50
クラス内のみで有効、つまりprivateなtypedefのみなら混乱は起きないんじゃ?
ラッパークラスは大げさすぎるし、たしかIBMの記事でtypedefの変わりに
ラッパー使うな、ってのがあったはず。
あぁ、これかも
ttp://www-06.ibm.com/jp/developerworks/java/060310/j_j-jtp02216.shtml

53 :デフォルトの名無しさん:2006/09/03(日) 01:02:37
あげ

54 :デフォルトの名無しさん:2006/09/03(日) 01:50:28
JAVAはバージョン違いで動かないし要らない。


55 :デフォルトの名無しさん:2006/09/03(日) 10:43:23
>>50
それって、別にtypedefに限った話ではなく、名前がつくものはなんでも当てはまるよね。
クラス名だって十分重複する可能性がある。
それにJavaにはpackageがあるんだから、typedefによる名前の重複はほとんど起きないと思うよ。

typedefは、>>49が書いたように、Genericsによって複雑になった型を簡略化できる利点がある。
おれは>>50が主張する欠点はtypedefに限った話じゃないと思うから、それよりは>>49の利点のほうに一票。


56 :デフォルトの名無しさん:2006/09/03(日) 11:41:03
>>55
typedefを使う型にpackageを使うのか。
実際にどうやって宣言するのかここに書いてくれないか?
副作用が見えてくるぞ。

57 :デフォルトの名無しさん:2006/09/03(日) 11:41:58
>>54
それは他の言語でも同様。
Javaではそういった事態に困る確率は
他のどの言語よりも低い。

58 :デフォルトの名無しさん:2006/09/03(日) 12:12:30
>>50
C++とJavaの違いをもっと良く勉強してください。

59 :デフォルトの名無しさん:2006/09/03(日) 13:16:29
package jp.example;

// importは省略

public typedef Map<String, List<String>> HeaderMap; // ;はいらないかな?

public class Hoge {
  HeaderMap getHeaders() { ... }
}

60 :デフォルトの名無しさん:2006/09/03(日) 13:18:26
getHeadersにpublic付け忘れた・・・orz
で、なにか問題になるか?HeaderMapクラスがあったら、とかは却下な。

61 :デフォルトの名無しさん:2006/09/03(日) 13:22:07
package jp.example;

// importは省略

public class Hoge {
  public typedef Map<String, List<String>> HeaderMap;
  public HeaderMap getHeaders() { ... }
}

こうかも

62 :sage:2006/09/03(日) 14:13:17
>>61
読みやすさより書きやすさを優先してるように見える
一般にコードは書かれた回数より読まれる回数が多いはず
タイプ量を短くするためだけに新たな型名を定義するようなものは既存のJavaにはない気がするし
Hogeの使い方を知るためにHeaderMapの定義を見ないといけないのはつらい
Fuga.setHeaders(Hoge.HeaderMap m)とか伝染するとさらにつらい
Fuga.setAnotherHeaders(Map<String,List<String>> m)があったりして記述が一貫しなくなるのもつらい

63 :デフォルトの名無しさん:2006/09/03(日) 14:15:58
>>58
お前が勉強しろよ

64 :デフォルトの名無しさん:2006/09/03(日) 14:17:38
>>59
そのHeaderMapを外部から使うときは
import宣言でやるってことか。


よさそうに見えるが・・・



何か落とし穴があるような気がしてならない。

65 :デフォルトの名無しさん:2006/09/03(日) 14:22:52
>>62の言う落とし穴も揚げられる。

ほかに揚げられるのは、
演算子オーバーローディング問題と
同じかな。

66 :あげあげ:2006/09/03(日) 15:57:34
なら>>52の案はどうよ?
引数や戻り値には感染しないように禁止しておいて、内部で使うだけ。
結構な妥協案だけど、これなら問題ないんでね?

67 :デフォルトの名無しさん:2006/09/03(日) 17:05:43
>>66
staticのやつ?

68 :デフォルトの名無しさん:2006/09/03(日) 17:32:48
>>67
なんだそれ?
いや、typedefはクラス内でしか有効じゃなくて、クラス外には見せないようにする。

public class Hoge {
 typedef Map<String, List<String>> HeaderMap; // これはprivate
 // このメソッドはエラー
 public HeaderMap func1() { ... }
 // このメソッドはOK
 private HeaderMap func2() { ... }
 // これもOK
 public void func3() {
  HeaderMap map = func2();
  ...
 }
}

69 :デフォルトの名無しさん:2006/09/03(日) 21:00:02
>>68
それならpackage privateでもいいかもしれないね。

70 :デフォルトの名無しさん:2006/09/03(日) 22:43:09
ときに、全ての言語はlispに向かう、って真なのかねぇ
クロージャなんて普及しないと思うんだが喜んでる奴いる?

71 :デフォルトの名無しさん:2006/09/03(日) 23:20:32
>>70
> ときに、全ての言語はlispに向かう、って真なのかねぇ
たぶん偽だろうね。ああいう言説ってLisp厨の戯言にしか聞こえない
レキシカルスコープやクロージャ、GCなどをLisp系言語が最初に取り入れたのは
事実だろうけど、だからといってそれらの特徴がLispの専売特許のように言われても困る

ただ、クロージャ自体はいろいろと便利で使い道も多いので、あった方が良いと思う
例えば、クロージャのある言語だと、スコープを抜けたらファイルのクローズ処理を
自動的にやってくれるライブラリが作れて便利だけど、現在のJavaだとそういうのがしづらい
(無名クラスを使えばできなくは無いが記述が冗長)ので、finallyで明示的にクローズしなくちゃ
ならなくてめんどいとか

72 :デフォルトの名無しさん:2006/09/04(月) 07:29:47
クロージャがあると汎関数作るのが簡単になるから欲しい。
利用する側にとっても便利。いちいち無名クラスというのも…

>>71
後、汎関数もLispが先駆者で、Javaはこっちの方面は拒んで、
クラスに属するメソッド主義だったけど、クロージャを導入すると、
クラスから独立した汎関数の世界にちょっと足を踏み込んだことになる。


73 :デフォルトの名無しさん:2006/09/04(月) 12:16:32
59じゃないけど typedef 擁護派

>>62
>読みやすさより書きやすさを優先してるように見える
いや、読みやすさも向上する。
HashMap<String, LinkedHashMap<String, List<String>>> が HogeMap になるんだから、読みやすくなるじゃん。

>一般にコードは書かれた回数より読まれる回数が多いはず
>タイプ量を短くするためだけに新たな型名を定義するようなものは既存のJavaにはない気がするし
ないから提案してるんじゃん。既存のJavaにはないからってアイデアを否定するのってどうよ?

>Hogeの使い方を知るためにHeaderMapの定義を見ないといけないのはつらい
定義をみるなんて一瞬じゃん。
それなら、HeaderMapがtypedefじゃなくてclassで定義したとしても、定義を見ないといけないのはおなじだろ。

>Fuga.setHeaders(Hoge.HeaderMap m)とか伝染するとさらにつらい
意味不明

>Fuga.setAnotherHeaders(Map<String,List<String>> m)があったりして記述が一貫しなくなるのもつらい
別につらくない。typedefが導入されているC言語では、そのような批判聞いたことない。


74 :デフォルトの名無しさん:2006/09/04(月) 12:58:14
>>73
> >Hogeの使い方を知るためにHeaderMapの定義を見ないといけないのはつらい
> 定義をみるなんて一瞬じゃん。

そこが(ry
でっかいファイルだと一瞬とはいかんと思う。
それから、他のファイルにまたがってるとなおさら

75 :デフォルトの名無しさん:2006/09/04(月) 13:35:58
C++の標準ライブラリのtypedefの使い方を見れば、
うまく使われたtypedefが可読性を向上させるのが分かると思う。
特にGenericsの時に。


76 :デフォルトの名無しさん:2006/09/04(月) 15:53:33
本来は、typedefは型を再定義することだから、読みやすいとか言うのとは、焦点がずれてる。
要求すべきは別名化 aliasとかじゃないかな?


77 :デフォルトの名無しさん:2006/09/04(月) 17:04:14
>>74
そんな巨大なクラス作んないし

78 :デフォルトの名無しさん:2006/09/04(月) 17:21:25
>>74
どんなチープな開発環境だよ
IDEの支援さえあればどんな巨大なクラスだろうと定義を見るのは一発だ

79 :デフォルトの名無しさん:2006/09/04(月) 18:15:22
>>76
typedefとどう違うの?

80 :デフォルトの名無しさん:2006/09/04(月) 18:33:39
>>76
ずれてない。
だれも「typedefは読みやすさのためにある」とは言っていない。

81 :デフォルトの名無しさん:2006/09/04(月) 18:37:08
>>77-78
問題はC#のような変な仕様にならないことなんだが。

typedefで定義したものについて、さらにGenericsでパラメタライズ
するとかになったら・・・

それに対してさらにtypedefで再定義することもありえるんだな?
で、tytpedefで定義した型をGenericsのパラメタ型にするってことも
ありえるんだな。

混乱の元になりそうなのだが。
そのあたり、どう解決するのか? IDE使っても限度があると思うぞ。



82 :デフォルトの名無しさん:2006/09/04(月) 18:39:31
>>77
それはそうだが、
クラスが100あるとき、
100もの、あるいは200, 300ものtypedefで再定義した型を
作ることになると思うのだが。
一つのクラスにつきtypedefで5つの型を再定義したとすると、
クラスが100あると500ものtypedefによる再定義された型が出てくると言うことか。

>>78
巨大なクラスは作らない方がいいぞ。
しっかり分割統治してな。


83 :デフォルトの名無しさん:2006/09/04(月) 18:57:52
>>82
自分ではそんなに作らんよ
ただ、字句解析のコード書くのに、StateパターンやInterpreterパターンなんて使ってられんし
クラス数が膨大になりすぎて、そっちのほうが管理できん

84 :デフォルトの名無しさん:2006/09/04(月) 19:01:48
>>81
それは使い方にもよるだろう。
そんな変態的な使い方をして、読みやすくなるコードもあるはずだし
STLやBoostのコードを読んでるとよく分かるけどな
あ、あとsuperないのにtypedefで代用、とかな

#さすがにそこまで自由度の高いtypedefはいらないけどね

85 :デフォルトの名無しさん:2006/09/04(月) 19:46:43
>>76
>>本来は、typedefは型を再定義することだから、読みやすいとか言うのとは、焦点がずれてる。
>>要求すべきは別名化 aliasとかじゃないかな?

C/C++のtypedefは、型に別名(alias)をつけるだけ。たとえば
typedef std::basic_string<char> stringA;
typedef std::basic_string<char> stringB;
で、コンパイラはstringA型とstringB型は同じ型として扱う。
だから焦点がずれていない。まさに要求どおりじゃないの。

86 :デフォルトの名無しさん:2006/09/04(月) 20:04:34
>>83
Stateはenumで実現できまいか?

87 :デフォルトの名無しさん:2006/09/04(月) 20:21:21
>>85 お前の知識が多いのは分かったから、引用をよく読んでみろよ。お前、よく相手の話を聞かないとかいわれるだろ?

88 :デフォルトの名無しさん:2006/09/04(月) 20:26:22
>>79>>80>>85 お前のようなゴミはもういらん!もう半島に帰れ!

89 :デフォルトの名無しさん:2006/09/04(月) 20:31:25
>>86
Stateパターンとenumは根本的に違うぞ
もちろんenumは使ってるけど、それはStateパターンじゃない。
しかも、enumったって、enumにメソッド持たせるんじゃなくて、
switchで分岐させてるだけだし

まぁ、字句解析はOOPできない典型例かもしれん
だれか解決策ないか?

90 :デフォルトの名無しさん:2006/09/04(月) 20:32:32
>>85みたいに無駄に型名を増やすのは
まさにtypedefを悪用している例なんだよな

91 :デフォルトの名無しさん:2006/09/04(月) 20:34:32
>>90
>>85はあくまで例えだろう
実際にあんな単純な状態にはならんよ

92 :デフォルトの名無しさん:2006/09/04(月) 20:38:25
>>71 72
高階関数はおれも好き。でも型あり言語じゃ魅力半減じゃね?
javaで書く時は冗長でもアホでも分かるように書く癖がついちまったよ

93 :デフォルトの名無しさん:2006/09/04(月) 20:41:17
>>91 お前が原因だな!わかったから巣に帰れ!

94 :デフォルトの名無しさん:2006/09/04(月) 21:05:35
>>93
何の原因だよ・・・

95 :デフォルトの名無しさん:2006/09/04(月) 23:12:55
おれも何の原因なのか気になる

96 :62:2006/09/04(月) 23:21:23
>>73
読みやすさというのは理解が容易という意味で書いた
大抵の場合IDEで解決できるが,IDEが使えない状況もあるだろう
むしろIDEではHogeMapと書くとHashMap<...>に置き換えてくれるような機構があればいいんじゃないだろうか

>ないから提案してるんじゃん。既存のJavaにはないからってアイデアを否定するのってどうよ?
新たな機構を提案すること自体を否定してるわけじゃない
typedefを否定している

>それなら、HeaderMapがtypedefじゃなくてclassで定義したとしても、定義を見ないといけないのはおなじだろ。
サブクラスには可読性の問題解決のためでない意味があるべき

>>Fuga.setHeaders(Hoge.HeaderMap m)とか伝染するとさらにつらい
>意味不明
定義を見る先が他のクラスになるから
Map<...>を使うときはHoge.HeaderMapを使うべきかMap<...>を使うべきか判断に迷うのも嫌

>>Fuga.setAnotherHeaders(Map<String,List<String>> m)があったりして記述が一貫しなくなるのもつらい
>別につらくない。typedefが導入されているC言語では、そのような批判聞いたことない。
こんな状況は起こりえないからつらくないということ?

また,
typedefで(書きやすさのためでなく)抽象化を突き詰めるとあらゆる型をtypedefするほうがいいことになる

結局,複雑になるだけでいいことはあまりない
どうしてもやるならvar型とかで型推論の方がまだいいと思う(これが理解しやすいとは思えんけど)

97 :デフォルトの名無しさん:2006/09/04(月) 23:47:40
なんで10文字20文字程度の記述の節約という、どうでもいいような理由で
言語仕様の一貫性をぶち壊しにするようなリスクの高い仕様を盛り込みたが
るんでしょうか。

10年前ならともかく、コード補完付のIDEがただで使える状況で何がつらいんだ
と小一時間(ry
おまえら1000人規模の大規模開発やったことあるのかと小一時間(ry

98 :デフォルトの名無しさん:2006/09/05(火) 00:00:56
もうすでに、Javaもいろんな人が使う言語になってしまったからじゃないでしょうか?
今後さらに人が増えて、とんでもない溶融があると思います。
そして分化して独立して・・
そんなもんなんでしょう。

99 :デフォルトの名無しさん:2006/09/05(火) 00:04:32
>>92
別に魅力半減はしないけどな。MLとかの型あり関数型言語使ったこと無い?
MLやHaskellでは、高階関数は当たり前のように使われてるよ

100 :デフォルトの名無しさん:2006/09/05(火) 00:09:47
>>96
> どうしてもやるならvar型とかで型推論の方がまだいいと思う(これが理解しやすいとは思えんけど)
C# 3.0で入る予定の
 var hoge = new Hoge();//hogeはHoge型
みたいなやつのこと?
これなら別に理解しにくく無いと思うけどなあ
実装するのもすごく簡単で、コンパイラを数行弄るだけで実現できる機能だし

101 :62:2006/09/05(火) 01:04:16
>>100
たぶんそう

理解しにくいというのは,IDEとかの支援がない状態で読むとき,
頭の中でvarを展開しなければならないということ
var hoge = make();
var fuga = hoge.getAttr();
...
ローカル変数だけで使えるなら
型安全だし,シンプルに見えるのはいいのだが,
明示的に書くよりはわかりにくい
(rubyのコードとか見てるとわかりにくいと感じる)

ところで
List makeList() {
var l = new ArrayList(); //この時点ではArrayList
...
l = new LinkedList(); //lはListでないと駄目だとわかる
...
return l; //この行でlがListと確定
}
こういうのもコンパイラを数行いじるので対応できるものなの?


102 :デフォルトの名無しさん:2006/09/05(火) 01:40:53
>>101
確かに、var宣言された変数がメソッド呼び出しの返り値で初期化される
場合は、若干わかりにくいかもね。でも、ローカル変数で閉じてる限りは
大した差は無いと思う

> List makeList() {
> ...
> return l; //この行でlがListと確定
> }
> こういうのもコンパイラを数行いじるので対応できるものなの?

上のようなコードでちゃんと推論しようと思うと、さすがに数行いじるだけじゃ対応できない
自分が考えていたのは(おそらくC# 3.0のも)、var宣言の時点で初期化式の型で宣言される
ことが確定するようなもの。つまり、上のようなコードは
 l = new LinkedList();// lはArrayList型なのでLinkedList型の値を代入できない
の時点でエラーになる。実用上、これで不便になるケースはたぶんほとんど無いと思う。

103 :デフォルトの名無しさん:2006/09/06(水) 06:35:51
>>96
>むしろIDEではHogeMapと書くとHashMap<...>に置き換えてくれるような機構があればいいんじゃないだろうか
それだと読みやすさは変わらんだろ。>>73でちゃんと「読みやすさが向上する」と書いているのに、よくわからんレスだな。

>新たな機構を提案すること自体を否定してるわけじゃない
>typedefを否定している
自分で書いたのをよく読め。否定する理由を>>62で「既存のJavaにはない気がする」と書いてるじゃん。
既存のJavaにはないからってアイデアを否定するのってどうよ?

>サブクラスには可読性の問題解決のためでない意味があるべき
ほんとに自分の都合のいいように話をもっていくな。おまえが指摘した点は、typedefだけでなくサブクラスでもあてはまる。
サブクラスを使うときには問題としていなかったことを、typedefのときだけ問題として取り上げることがおかしいという指摘をしているだけ。サブクラスの他の機能は関係ない。

>定義を見る先が他のクラスになるから
>Map<...>を使うときはHoge.HeaderMapを使うべきかMap<...>を使うべきか判断に迷うのも嫌
なんで迷うの?わざわざtypedefしてるんだからそれを使えばいいじゃん。

>こんな状況は起こりえないからつらくないということ?
おまえのように恣意的に使わない限りは、そんな状況は起こりえない。
おまえC言語使ったことないだろ。

>また,typedefで(書きやすさのためでなく)抽象化を突き詰めるとあらゆる型をtypedefするほうがいいことになる
いいわけないだろ。typedefを使ったほうがいいときだけ使えばいい。勝手に極論するな。

>結局,複雑になるだけでいいことはあまりない
おまえのような、意図的に間違った使い方なら複雑になるわな。

あれか、おまえもやっぱりJavaにはない機能はぜんぶ否定するJava絶対主義者か。
そんなやつに限って、Javaにその機能が導入されるといきなりマンセーしだすんだよな。


104 :デフォルトの名無しさん:2006/09/06(水) 07:47:15
はい、はい。
ここでやっても意味無いから、むこうでやってね。

105 :デフォルトの名無しさん:2006/09/06(水) 11:18:56
こんにちは。fondaのアプレット設置しようと思っていたのですが、
これって、有料なんでしょうか?
翻訳してみたところモノによって異なるようなのですが、
どれが無料で、どれが有料なのかわかります?
詳しく調べないで、勝手に設置したら、著作権とかヤバイですか?
http://www.fouda.de/html/home/

106 :デフォルトの名無しさん:2006/09/06(水) 14:42:56
>>103
まわりくどいから簡潔に説明して。
二人だか何人だかしらないけど
一体どういう議論をしてんだか。

typedefマンセーだかなんだか知らないけど

107 :デフォルトの名無しさん:2006/09/06(水) 14:45:12
>>105
ダウンロードしたファイルにREADMEとかlicense.txtとか入ってないのか?
それ読めば解ると思うが、なかったらサイト見ろ

108 :デフォルトの名無しさん:2006/09/17(日) 22:20:56
そもそもJavaってもっともっと馬鹿な連中がネットワークプログラミングしても困らない様にって進化してきた言語だろ
あんまり複雑な機能加えるなよ
やりたきゃ既存の言語でつくってJNIするなり、Webサービスにするなりすれば良いじゃん

109 :デフォルトの名無しさん:2006/09/17(日) 22:34:03
>>108
お利巧さんな君は何をしているのかな?

110 :デフォルトの名無しさん:2006/09/17(日) 23:22:17
何も作れないからひがんでるんじゃないか

111 :デフォルトの名無しさん:2006/09/17(日) 23:29:42
>>108はJavaスレに「ドトネト厨きーきー」のAA張ってJavaスレを荒らしている奴だろ。

112 :デフォルトの名無しさん:2006/09/17(日) 23:31:15
>>110
そうかもな。
奴は昔はVBが得意だったらしいが。
2chでDelphiプログラマと喧嘩して、そしてJavaプログラマとも喧嘩して
C#死滅スレで大暴れした末に、演算子オーバーロードをつけられないJavaは糞だとか
なんだと連呼したものの、結局C#を普及させることはできずに失敗し
今はJavaスレを荒らすようになってしまった。



113 :デフォルトの名無しさん:2006/09/19(火) 11:10:29
Javaのenumはキモイ

114 :デフォルトの名無しさん:2006/09/19(火) 12:15:22
ぜんぜん。使いやすいけど

115 :デフォルトの名無しさん:2006/09/19(火) 13:04:07
>>112
自己紹介乙(プ

116 :デフォルトの名無しさん:2006/09/19(火) 15:10:52
わろたVBマンセーしてることが自己紹介かw

117 :デフォルトの名無しさん:2006/09/19(火) 23:58:25
わけあってちょいと現場を離れてた。
今度戻るけど、世の中、Javaと.NET系ではどっちの方が仕事多い?

118 :デフォルトの名無しさん:2006/09/20(水) 00:06:59
>>117
場所による
ただ値段的にはJava>.NETなのはほぼ確実

ここの所客から.NETにすればもう何割か減らせません?って聞いてくるケースが多いから.NET=安いってイメージらしい

119 :デフォルトの名無しさん:2006/09/20(水) 00:20:54
結局 commons-lang の Enum 使ってる。

120 :デフォルトの名無しさん:2006/09/20(水) 01:23:54
>>117-118

値段がJavaのほうが上だということが確実だって話は始めて聞いた。
仕事はJavaのほうが確実に多いが。

.NETの価値は薄いと考えている客が多いのか。
それはマイクロソフトにとっては痛い話なんだろうな。



121 :デフォルトの名無しさん:2006/09/20(水) 10:29:07
マイクロソフトのマーケティングの失敗だな
Javaと.NETじゃ大して難易度変わらないのに

122 :デフォルトの名無しさん:2006/09/20(水) 10:37:35
JavaじゃなくてUnix Serverが高いと思われてるような希ガス

123 :デフォルトの名無しさん:2006/09/20(水) 11:40:04
>>117です。
いろいろアドバイスありがとさん。
Javaの方が仕事的には減ることはなさそうな印象を受けました。
ただ、私のまわりの中小ITはVB.NETの話が多いですね。
VB.NETの市販本買って読んだら、文法はJavaにそっくり。
とりあえず、昔覚えたJavaから復活していきます。

また、何か追加情報があったらカキコんでください。ヨロシク!!

124 :デフォルトの名無しさん:2006/09/20(水) 11:44:08
最後の一行がなければさぁ……

125 :デフォルトの名無しさん:2006/09/20(水) 12:01:44
>>123
> VB.NETの市販本買って読んだら、文法はJavaにそっくり。

それC#の方の.NETちゃうんかと

126 :デフォルトの名無しさん:2006/09/20(水) 12:43:47
そりゃ、「”無料の”Eclipseを使うよりもVS.NETを買ったほうが作りやすく安上がりです。」
みたいなマーケティングしてるんだから.NETの方が安上がりって思うだろ普通


127 :デフォルトの名無しさん:2006/09/20(水) 13:36:21
それはとんでもなく裏目にでたな。

マイクロソフトのマーケティングが
今、オープンソースの台頭によって逆効果になってしまったわけか。

128 :デフォルトの名無しさん:2006/09/20(水) 13:37:28
しかもVS.NET2003Expressも慌てて一年間限定で無償で配布してしまった。
Eclipseが出てから何もかも変わってしまったな。
IBM恐るべし



129 :デフォルトの名無しさん:2006/09/20(水) 13:48:42
だってVSって有償なのにEclipseにも及ばんし
つーかNetBeansにも及ばんし
ぶっちゃけIDEとしてはショボいし

130 :デフォルトの名無しさん:2006/09/20(水) 14:50:36
昔、Javaの仕事が一段落した時に
上司がVBできる人を探していて
俺はできるけどできないと言った
他の奴ができるといってVB部隊に
行ったけどそれ以来見ていない

131 :デフォルトの名無しさん:2006/09/20(水) 22:28:06
VB.NET は言語そのものは悪くないんだが
案件の内容がひどそうなイメージがある。

132 :デフォルトの名無しさん:2006/09/21(木) 00:23:48
>>130
そんなことあったな。
2001年春のこと、まだServlet/JSPが普及していなかった時代。
CGI + Perlの10倍以上のパフォーマンスを出すこともできると
もてはやされたあのServlet。

ServletプログラミングができるけどASPはできないと言ったんだ。
でもう一人の奴はASPができるけどServletをやってみたいって言っていたが
ASPができるといったために、「じゃ、ASPのほうお願いね」
とか言われて彼はASPをやらされた。まだまだ当時新鮮だった
Servlet/JSPの仕事を与えられる俺のことを羨ましがっていた。

133 :デフォルトの名無しさん:2006/09/21(木) 00:26:34
>>131
ひどいっていうか、VBとVB.NETは同じだからVBしかできない奴を
かぎ集めてもなんとかなるだろうという甘い考えを持っている上司やVB厨が
いたから酷いことになったんだろうな。
「.NET構想」と「Javaは廃れてこれからC#が流行る!」というM$の宣伝に騙されて
VBからVB.NETへ移行しようとしたVB厨は、VB慣れしすぎてC#やJavaのような
言語が取っつきにくて躓いたってわけだ。
Perl厨やPHP厨やRuby厨がJavaをやり出したら同じような躓きを覚えるんだろうな。





134 :デフォルトの名無しさん:2006/09/21(木) 14:13:11
スクリプト言語とJavaはライバル関係にはない

135 :デフォルトの名無しさん:2006/09/21(木) 15:25:12
でも人は使いまわすからねー

136 :デフォルトの名無しさん:2006/09/21(木) 16:17:34
ちょっと2,3ヶ月の応援がずるずると2,3年になるのはよくあること
2,3年もVBやスクリプト言語やったら戻れないだろう
もう経歴書からはVB屋・スクリプト屋としか思われない
身の振り方は後々のことまでよく考えてしないとな

137 :デフォルトの名無しさん:2006/09/21(木) 16:41:00
マ板行けよ。

138 :デフォルトの名無しさん:2006/09/21(木) 16:55:12
スクリプト屋の特徴は、
Design by Contractを守ることができないことなんだな

139 :デフォルトの名無しさん:2006/09/21(木) 19:19:24
スクリプト系の言語とJavaとの違いってなんなの?
同じじゃん。

140 :デフォルトの名無しさん:2006/09/21(木) 19:36:36
Java,C++.C#,D言語は型にがっしり硬い言語
静的型付け言語であるケースが多い。

Ruby, PHP, Perl, VB, JavaScriptなどは一般に型が軟らかい言語。
そして動的型付け言語であるケースが多い


こういう違いがある。


141 :デフォルトの名無しさん:2006/09/21(木) 20:34:09
昔はGCがあるかないかとか、すぐ実行結果が出る出ない(コンパイル必要)だったけどね。

142 :デフォルトの名無しさん:2006/09/21(木) 21:03:44
今じゃPerl6にもGCがつくからねえ。

C++やD言語と同列に並べるにはCGがあるなし
区別は苦しい。

コンパイル必要不要も今じゃ苦しい。
ソフトウェア工学という観点から見ないと。

143 :デフォルトの名無しさん:2006/09/21(木) 21:21:07
なんだかんだ言っても顧客がどう見るかじゃない?
ソフトウェア工学という観点からなんて顧客は聞きもしないよ

144 :デフォルトの名無しさん:2006/09/21(木) 21:25:10
だが、顧客がプログラマであった場合は、そうもいかない。

実際に、C++とかJavaとかでプログラミングをするのはソフトウェア工学
に熟知しているものだからな。

スクリプト言語だと動的言語としてのソフトウェア工学にこだわりを
持つことになるだろうが。


145 :デフォルトの名無しさん:2006/09/21(木) 23:16:40
Javaはリフレクションとかアノテーションからして
スクリプトじゃない代表格C++と比べればより動的じゃないの?

146 :デフォルトの名無しさん:2006/09/21(木) 23:17:37
ソフトウェア工学に熟知とかありえんwww
どうせ日経なんとかの受け売りに決まっている

147 :デフォルトの名無しさん:2006/09/21(木) 23:35:36
>>145
なんかちがような気がする。
それだったらC++のほうが柔軟性がきくので動的だと思う
Javaは定められた文法規則を厳重に守らないと逝けないから

148 :デフォルトの名無しさん:2006/09/21(木) 23:54:59
Javaは、C/C++の文法にとてもよく似せて作ってあるけど、動的とどう関係しているのかな?
>>147

149 :デフォルトの名無しさん:2006/09/22(金) 00:17:49
アノテーションは動的とはあまり関係ない。
修正→コンパイルが必要と言う意味では静的。
Java では virtual/override が存在せず、
final 指定されてない同名メソッドを無条件で上書きするところが
動的な性質の最たるものの一つに感じる。
正直、virtual/override が欲しい。

とりあえずDI+強い型付以外の開発はもうやりたくない。

150 :デフォルトの名無しさん:2006/09/22(金) 01:01:25
>>149
> Java では virtual/override が存在せず、
> final 指定されてない同名メソッドを無条件で上書きするところが
> 動的な性質の最たるものの一つに感じる。
> 正直、virtual/override が欲しい。

おいおい、@Overrideアノテーションがあるだろ。
virtualはいらないけど。

しかしそれが、動的なのかねえ

151 :デフォルトの名無しさん:2006/09/22(金) 01:19:31
普通「C++とJavaだとJavaの方が動的」という文脈では
・「動的」といったら実行時解決のこと
・「静的」といったらコンパイル時解決のこと
を指すわけなんだが、君は何アホなこといってんの?

152 :デフォルトの名無しさん:2006/09/22(金) 02:25:10
型付けを見たらC++のほうがJavaより動的なんだが。

153 :デフォルトの名無しさん:2006/09/22(金) 02:26:55
>>152
君も何アホなこといってんの?

154 :デフォルトの名無しさん:2006/09/22(金) 03:41:19
Javaではコンパイル時に型整合性チェックは行うが
利用するコードは実行時のライブラリに応じて動的解決される
結局は型チェックは行っており、メッセージ投げてみればわかるべ、という
Objective-Cほど動的ではないと言える

中庸を目指した設計だからな

155 :デフォルトの名無しさん:2006/09/22(金) 05:41:19
>>144
Javaはスクリプト言語じゃないと区別したいのは分かるが、
virtaul/overrideのキーワード有無とかJavaに対しての不満の方が強いみたいで、
ソフトウェア工学とか意味不明なところからスクリプトとJavaを区別しようとしてるから、
行き詰まるんじゃないかな?

156 :デフォルトの名無しさん:2006/09/22(金) 05:47:40
>>153 君の方がアホっぽいけど、気がつかないか?

157 :デフォルトの名無しさん:2006/09/22(金) 13:31:15
静的型付けと動的型付けの意味も分からんとは

158 :デフォルトの名無しさん:2006/09/22(金) 14:36:15
dynamic_cast 使ってる?

159 :デフォルトの名無しさん:2006/09/22(金) 14:44:17
refrection API使ってる?

160 :デフォルトの名無しさん:2006/09/22(金) 14:45:46
C++とJavaのいいとこ取りすると、どんな言語が生まれるんだろうね。

161 :デフォルトの名無しさん:2006/09/22(金) 15:14:48
>>160
φ

162 :デフォルトの名無しさん:2006/09/22(金) 15:36:19
C++/CLI。
結果良くなったかどうかはワカンネ。


163 :デフォルトの名無しさん:2006/09/22(金) 15:46:31
>>162
結局MSに持ってかれたってことか?
とにかくワロタ

164 :デフォルトの名無しさん:2006/09/23(土) 03:03:12
実行時にクラスファイルをロードしてしまうJavaはかなり動的だと思う。
しかもパッケージ=フォルダ。
rubyだってrailsでやっと動的ロードを手に入れたくらいなのに

165 :デフォルトの名無しさん:2006/09/23(土) 03:12:09
>>160
D言語

166 :デフォルトの名無しさん:2006/09/23(土) 03:13:30
>>164
だからそれは「動的型付け」とは関係ないと何度いったら(ry

一度作ったクラスの仕様を変える事ができてしまうのが
動的型付け。

たとえばクラスに有るはずがないフィールドやメソッドを追加したり

167 :デフォルトの名無しさん:2006/09/23(土) 03:40:31
>>166
それは動的型付けの副作用でしかない。
フィールドやメソッドを実行時に追加したいだけなら、AOPでも事足りる。

168 :デフォルトの名無しさん:2006/09/23(土) 04:00:53
と、いうけど、まじでソースコード
読みにくくなるんだよね。

Ajaxのソースコードなんかとくにひどいもんだ


169 :デフォルトの名無しさん:2006/09/23(土) 07:44:57
>>166
おしい!実におしい!!

170 :デフォルトの名無しさん:2006/09/23(土) 09:17:23
文字列がコードになるのが動的と思っていたけど、違う?

171 :デフォルトの名無しさん:2006/09/23(土) 17:17:24
動的っていったら、プログラムの実行時になにかすること。
静的っていったら、プログラムの実行前になにかすること。

違う?

172 :デフォルトの名無しさん:2006/09/23(土) 17:31:04
JMXってなににつかうん?サーバ監視だけ?

173 :デフォルトの名無しさん:2006/09/23(土) 17:45:50
>>172
じゃないの?他に使い道ある?
っていうか今頃この辺が整備されるって遅すぎ

174 :デフォルトの名無しさん:2006/09/24(日) 11:24:15
>>166
動的/静的型付けの違いは、式の型がコンパイル時に決まるかどうかだから、
メソッドの追加は関係ない。

だいたい、その説明だと
たいていの言語はソース書き換えてコンパイルすればメソッド追加できるから
たいていの言語は動的型付けになっちゃうよ。

175 :デフォルトの名無しさん:2006/09/24(日) 11:46:49
あほですか?
メソッドが追加されたらクラス、つまり型が変わるだろ。

それだけでも動的なのに、
どう変わるかも実行時にしか分からないかもしれない。

176 :デフォルトの名無しさん:2006/09/24(日) 12:33:16
>>175
「あほ?」とはずいぶんと強気だけど
「メソッドが追加されたらクラス、つまり型が変わるだろ」
どういうこと?まったく意味が分からんけど?

177 :デフォルトの名無しさん:2006/09/24(日) 15:55:31
Genericsでちょっと疑問に思ったんだけど。
メソッド単体でのGenericsって引数なしだと何もできない気がする。

<T> <T> get();

これ動かないよね?
Tをnewすることもキャストすることもできないんだから。

178 :デフォルトの名無しさん:2006/09/24(日) 16:03:49
キャストはできるか

179 :デフォルトの名無しさん:2006/09/24(日) 16:19:49
>>174
まてまて、それでJavaScriptの型とJavaの型との違いをうまく
説明できるか?

180 :デフォルトの名無しさん:2006/09/24(日) 18:31:54
166の言ってることは、動的クラスっていうだけだな。
動的クラスを使うためには動的型付が必要になるが、クラスがなくても動的型付けはできる。

動的言語処理(実行時型解決など)ができるかどうかは、言語自体が動的型付か静的型付かには関係ないよ。

181 :デフォルトの名無しさん:2006/09/24(日) 23:39:09
1の趣旨とは全然無関係だが、静的・動的の話は面白いと思った。

182 :デフォルトの名無しさん:2006/09/25(月) 00:37:07
こんなかんじ

typedef struct {
 Class *extends;
 Interface **implements;
 void **methods;
 void **fields;
} Class;




183 :デフォルトの名無しさん:2006/09/25(月) 01:18:31
>>181どのへんが面白いの?

184 :デフォルトの名無しさん:2006/09/25(月) 15:46:03
「動的型付」、という特定の機能を指す言葉(専門用語)は
一般の熟語ではないという合意が得られてないので
「動的」という一般的な形容詞句の話が混じってしまったのが混乱の元。

学会とか専門家ばかりが集まってる場所じゃないから
前提はある程度しっかりしてた方がいいな
まぁ、それくらい分かれよ、と突き放すこともできるが
いろんな人が集まれるこういう場所だ、お互い尊重すればあれることもない

185 :デフォルトの名無しさん:2006/09/25(月) 15:52:37
>>184
もまえ、わかってるようだな。

186 :デフォルトの名無しさん:2006/09/28(木) 15:39:12
>>177
一応できることはできる。未検査キャスト入るし、実際には使い道が無いが

public class Variant {
 private Object value;
 public <T> void set(T value){
  this.value = value;
 }
 public <T> T get() {
  return (T)value;
 }
 public static void main(String[] args){
  Variant v = new Variant();
  v.set("foo");
  String s = v.<String>get();
  System.out.println(s);
 }
}

>>166
クラスにメソッドを追加できるかどうかと、動的型付けかどうかは無関係。
実際、静的型付けで既存のクラスにメソッドを追加できる言語もある。MixJuiceとか

187 :デフォルトの名無しさん:2006/09/28(木) 23:17:36
アスペクト指向言語ライクな言語MixJuiceか

188 :デフォルトの名無しさん:2006/10/06(金) 20:57:19
>>177 ????

<T> T get(){
SomeFactory<T> factory = new Factory<T>();
return factory.getInstance();
}


189 :デフォルトの名無しさん:2006/10/06(金) 22:02:16
Factoryフレームワークか。恐ろしくて使いたくないよw

190 :デフォルトの名無しさん:2006/10/06(金) 22:37:27
factoryは大げさな感じがうざいが、時には有効

191 :デフォルトの名無しさん:2006/10/06(金) 22:42:19
ファクトリ否定したらDIコンテナ使えないな。

192 :デフォルトの名無しさん:2006/10/06(金) 22:52:55
例えば
Validator<EMailAddress> emValidator = ValidatorFactory.get();
みたいなことが出来るならあるいは便利かとも思うが
<T>からClassインスタンスって取れないから使えないな

193 :デフォルトの名無しさん:2006/10/07(土) 16:19:16
Color color = StringConverter.fromString("0, 0, 0");
Point pt = StringConverter.fromString("0, 0");

みたいにしたかったんだけど、Class取れないんで、

Color color = StringConverter.fromString("0, 0, 0", Color.class);
Point pt = StringConverter.fromString("0, 0", Point.class);

で我慢した。Class取れればいいのにね。

194 :デフォルトの名無しさん:2006/10/13(金) 02:42:15
http://www.uploda.org/uporg546208.jar.html

向こうでやるとスレ違いだから
スタティックメソッドとインスタンスメソッドの
呼び出し性能を検証する簡単なコード書いてみた
実行速度見たかったから、俺はヒープサイズ余裕持たせて
実行してみたけど、性能は誤差だね
メモリ消費量はもっとやってみないとわかんないね

195 :デフォルトの名無しさん:2006/10/25(水) 20:21:41
スレ違いって言われたのでココでお聞きしたいのですが、
AWTは1コンポーネント=1ウインドウだからシステムリソースを
食いまくる問題って解決されたのでしょうか?

196 :デフォルトの名無しさん:2006/10/25(水) 21:01:15
>>195
つttp://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/awt/1.3/designspec/lightweights.html

197 :デフォルトの名無しさん:2006/10/26(木) 00:09:36
Lightweightという単語を初めて見たのはSwingについての説明だったと思うが、
こんなに流行るとは思わなかった

198 :デフォルトの名無しさん:2006/10/26(木) 00:14:07
Component ベースだと普通にSwing使ったほうが手軽だし高速になるよな

199 :デフォルトの名無しさん:2006/10/26(木) 01:48:13
>>196 この様子だと、永遠に解決されないみたいですね。

200 :デフォルトの名無しさん:2006/10/26(木) 02:59:30
>>199
それはOSの問題だと思うが

201 :デフォルトの名無しさん:2006/10/26(木) 03:05:05
AWTがリソース食うってのは、要するにMFCのCButtonなんかが
ウィンドウだってのと同じことなんだが、わかってる?

202 :デフォルトの名無しさん:2006/10/26(木) 12:47:03
改善はそれぞれ SWT, Swing, AWT でそれぞれ実験(実装)済みってこと。
Windows9xのときはGDIとかシステムリソース気にしてたけど、
今じゃそんなのどうでもよくて、レスポンスが速いかの方にうつってる。
リソース食いまくるとか過去の話し出し、つまり一番速いAWTつかってOK。

203 :デフォルトの名無しさん:2006/10/26(木) 13:03:36
でも貧弱すぎてつかうやついねーよ

204 :デフォルトの名無しさん:2006/10/26(木) 20:04:32
Swing結構速いけど?

205 :デフォルトの名無しさん:2006/10/26(木) 22:59:45
>>204 Pentium 133 とかだとどうだ?

206 :デフォルトの名無しさん:2006/10/26(木) 23:02:32
それだとWindowsXPどころか2000やNT4もおもいぞ

207 :デフォルトの名無しさん:2006/10/26(木) 23:12:38
あれだ、Pentium133は少し言い過ぎだけど、Swingでプログラム作っても
そのプログラムの処理は低速CPUで事足りるんじゃないか?

Javaってのは最新・現状のパソコンだけをターゲットにした言語じゃないだろ。

208 :デフォルトの名無しさん:2006/10/26(木) 23:22:41
VMは最新に
そしてメモリの速度やキャッシュの速度は速いほうがいい
NetburstアーキよりPenM系列のほうが早い

あとSwingはJava2Dが需要なのでアクセラレーションのレスポンスがいい統合チップセットは意外と早い

Swing使った業務アプリはずっと作ってるけど快適さはやっぱりコードにもよるね
OSがNT4でJRE1.3.1、Pen3/600MHzは快適だった
2000やXPだと5.0にしてPen3/1GHzクラスにならないと快適さはおいつかない感じ

209 :デフォルトの名無しさん:2006/10/27(金) 00:08:33
>>208
それはSwingやJavaが速いとかではなくて、ハードが進化して速くなった事はじゃないか?
業務アプリならなおさらだけど、端末がNTでPentium 200-600とかざらだからね。
それでSwingはないだろ。そしてJavaつかってもらいたいのに、
AWT無視とかどういうことだ?これだったら、UIはWebブラウザの方に流れて当然。

2D, 3DはJavaでなくてC/C++や専用ライブラリ使うから、
Javaはいくらハードが進化しても入り込めない。
今も昔も、何年たってもいまだにJava向けのヒットゲームないでしょ?

210 :デフォルトの名無しさん:2006/10/27(金) 00:12:56
>>209
ハードも大事だし、VMの種類も大事とかいてるだろ
1.2と5.0くらべたら恐ろしいほどの性能さだぞ

それに当時のマシンならブラウザよりSwingのほうがはるかに軽いぞ
ブラウザってかなりメモリは食うし重いものなんだよ
それにインターフェースとして参照系ならともかく入力系はおわっとる
AWTも機能不足

ゲームは今MMORPGとかで海外はJava製ふえてきてる

211 :デフォルトの名無しさん:2006/10/27(金) 00:43:01
性能差は認めるが、その効果が実感できるのは性能(VMの出来)よりも
ハードの進歩が格段に勝っていたってこと。ハード(CPUやGPU)はJavaだけ
じゃなくて他の処理(OSやイベント)をこなして、さらに余った余力でやっても、
VMの性能よりも高速ってどういうこと?

業務アプリはデータベース問い合わせを想定しているが、
大体は業務アプリはその程度じゃないか?AWTやブラウザで十分だろ。
つまりブラウザが重いとか言ってるなら、(winなら)VBとかでUIつくっても
いいけど、そうするとどこにJava(とSwing)の出番があるんだ?

212 :デフォルトの名無しさん:2006/10/27(金) 00:48:54
>>211
DB引いてくるだけて、・・・・どんな業務アプリ・・・
集計ロジックくらいは、入るだろ。

ユーザとのインタラクションはいくらでも入ってくる。

213 :デフォルトの名無しさん:2006/10/27(金) 01:00:09
どうもJavaがデスクトップに入り込めないでいるのは、
「出番なし」だからじゃないか?
C, C++, Perl, Ruby, JavaScript ライバルの方が強すぎて
(PCの)デスクトップには入れないだろ。
ネットワークでも、アプレットでこけたのがいたかったんじゃないか?
今じゃFlashに持ってかれてるし… (デスクトップの話ね)

214 :デフォルトの名無しさん:2006/10/27(金) 06:54:07
ビジネス系だとAppletのが多いけどな。
まあオーサリングツールが無かったのと
ダウンロードの手間がFlashのが少なかったというのが大きい

215 :デフォルトの名無しさん:2006/10/27(金) 08:28:55
>>212
集計ロジックはサーバサイドにやらせて
画面は入力と参照だけの作りが多いと思う。
三階層モデルが普通。DB直で触るような
C/Sモデルは5年前くらいに下火になってる。

それよりも210氏が指摘してるが入力系での優位性が大きい。
ブラウザで入力なんてのは業務系だと無理。
(業務系はえてして入力項目数が多い。)
ここ数年はそれでやってきたプロジェクトが多いけど
結局効率下げるだけで現場では不評。
これからはブラウザベースで作った業務アプリを
作り直す需要が多くなる。(既に増え始めてる。)
リッチクライアントの標準を巡って主導権争いが盛んなのもそれを見越してるから。

Swing は能力的に善戦できると思うんだけど
JRE 入れないと行けないところが難点。
(業務系になると致命的な問題にはならないことが多い。)
FLASH の方がウケが良いのは確かだが、
Swing アプリの方が制約の少ない分、後で盛り返せる余地はあると思う。

アプレットは問題外。これ提案するようなベンダーと付き合うべきでない。

216 :デフォルトの名無しさん:2006/10/27(金) 09:40:09
FLASHで業務アプリって今流行ってんの?

217 :デフォルトの名無しさん:2006/10/27(金) 11:06:46
>>215
>ここ数年はそれでやってきたプロジェクトが多いけど
>結局効率下げるだけで現場では不評。
>これからはブラウザベースで作った業務アプリを
>作り直す需要が多くなる。(既に増え始めてる。)
>リッチクライアントの標準を巡って主導権争いが盛んなのもそれを見越してるから。
でもこのおかげで社員のほとんどは意味も無いのにPCの前に座らせる必要が無いって事に経営層が気づいたのは事実
更に業務はパッケージ買って、経理/人事の社内総務部門をアウトソースして
株主へ利益を還元していく仕組みが出来上がりつつある


218 :デフォルトの名無しさん:2006/10/27(金) 12:12:50
サーバーサイドが普及してきたのはこの5年ほどだし
すべてWEBアプリになってるわけじゃない

クライアントサーバーも開発コストの面で優れるために今でも業務系では多いし
WEBアプリからクラサバや3層式への動きもある
って>>215と重なることばっかりだ
業務系パッケージ/受託とかクラサバ多くてびびるかもよ
ようは流行とか関係なくユーザーの求めるもの作ったところが勝ち

ただアプレットはリッチクライアント用途として問題ないと思うぞ
WEBスタートにしてもいいわけだし、もちろんSwingを使うわけだし

>>216
開発ライセンスの問題とか高コストとかライブラリが整備されていないとかあって
わりと敬遠されてる
3倍金はらってくれるなら作ってもいいとはよく言われる

>>217
総務のアウトソースってはやってるようには見えないし、
パッケージのカスタマイズだけでは無理な場合も多いぞ
無理してカスタマイズされたコードのさらに修正とか死ぬぞ
新規に作ったほうが早くて使いやすい場合も多い

日本はユーザーがパッケージに業務をあわせる文化ないからね

219 :217:2006/10/27(金) 12:37:05
>>218
仕組みが出来つつあるってこと
偽装派遣を合法化した結果はおそらくそこに影響が出る
最終的には金を生み出す仕組みと借金の担保になる会社という資産以外は交換可能な部品にするのが今の経団連のトップ辺りに居る連中の考え方


220 :デフォルトの名無しさん:2006/10/27(金) 13:19:18
偽装請負がいつ合法化されたの?
この数年どんどん手が入ってるでしょ

キヤノンとか偽装請負すべてやめると明言したばかりでしょ

221 :デフォルトの名無しさん:2006/10/27(金) 14:46:03
キャノン・トヨタ・派遣。
密告とかなかなか深いね。
これから噴出する問題だね。
御手洗さんですか・・・
ただ、スレ違い。

222 :デフォルトの名無しさん:2006/10/27(金) 14:51:15
>>215
なかなか良かったんですが…
>Swing アプリの方が制約の少ない分、後で盛り返せる余地はあると思う。
これの根拠はあるんですか?次のJava6でってこと?

>アプレットは問題外。これ提案するようなベンダーと付き合うべきでない。
そうでもないと思うけど、どうしてアプレットは問題外なの?
確か、サーバ・クライアントモデルで、DB集計はサーバーって書いて
るんだから自分の言ってる事と矛盾してるでしょ。

223 :デフォルトの名無しさん:2006/10/27(金) 15:36:43
>>222
昔のしょぼい連中の作ったJavaAppletをみてリッチクライアントじゃねえとか思ってる口だから気にするな

224 :デフォルトの名無しさん:2006/10/27(金) 21:56:24
>>222
>これの根拠は
ローカルリソースにアクセスする為に
署名しろとかいろいろ面倒。
ブラウザから始めるのも一手間無駄になる。
(ブラウザを開くことと仕事とは一切関係がない。)
zip 落として展開して、これを 叩いてください、
次からはショートカット叩きゃOKです、の方が最終的に楽。

だと俺は思ってる。そうは思ってない人も居るだろうし、
それは根拠と言えないだろうと言われればそれまで。
個人の意見なのでご自由にどうぞ。

>どうしてアプレットは問題外なの?
アプリに比べて上段で挙げたことを感じるから。
逆にアプレットの方が優れてるところってどこでしょうか?

225 :デフォルトの名無しさん:2006/10/27(金) 22:22:01
>>224
>個人の意見
そういうことなら了解です。面倒とかそういうのは分かりますです。

>アプレットの方が優れ
サーバー・クライアントモデル、そのままってところでしょうか。

226 :デフォルトの名無しさん:2006/10/27(金) 23:07:19
これってアプレット?

CGoban 3 のダウンロード
http://www.gokgs.com/download.xhtml

227 :デフォルトの名無しさん:2006/10/27(金) 23:17:24
署名って面倒か?
「最初に自動的にインストールしてくれます。更新も自動です。」
ってだけでしょ。

228 :デフォルトの名無しさん:2006/10/28(土) 00:20:59
>>224
そもそも一般人はローカルにZIP落として適当なフォルダに展開というのを嫌がる&出来ない人もいる
というのを認識したほうがいい

わかる人だとZIP版のほうがレジストリいじらないとか変なところやられてないとか安心感はあるけど
普通の人はウィザードインストーラがないとダメみたい

WebStartって最初だけでその後はショートカットがデスクトップに自動的に生成されたり
バージョンチェックとか細かく動かなかったっけ?
アプレットもあるバージョンだった科からはいろいろと細かく動くしね

用途としてローカル資産いじりまくるようなのは確か似合わないけど
WebStartアプレットならJNLPAPI経由でローカル資源はアクセス可能だよ

雇う側からすると今の時代は鯖サイドの技術者のほうが入手せいがいいので
クライアントはあくまでも操作性がいいSwingベース、鯖でロジックという3層式はやりやすい
SpringとかDI使ってさくさく組めるしね

229 :デフォルトの名無しさん:2006/10/28(土) 00:28:44
>>228
>>226がそれ。
起動時にバージョンアップもしてくれるので楽。

230 :デフォルトの名無しさん:2006/10/28(土) 00:29:53
数年で便利になりましたね〜
まだまだ途中ですけどね〜

231 :デフォルトの名無しさん:2006/10/28(土) 00:48:00
さっきJREを_09にアップデートしたんだけど以前のJREも残るんだな。
しかもJDKじゃないからserver vmはふるいまんまだし。
せめて古いバージョンって自動的に削除とかしてくれないの?

232 :デフォルトの名無しさん:2006/10/28(土) 00:52:57
本来あってはならないことだけど
パッチレベルの違いで挙動が異なるプログラムがある以上
勝手に削除するわけには行かないところなのが実情。

233 :デフォルトの名無しさん:2006/10/28(土) 01:32:35
新陳代謝の激しいフリーウェアにはいいかも知れんね。
例えばゲームとかだと頻繁にバグフィクスや難度調整が入るだろうし。

234 :デフォルトの名無しさん:2006/10/28(土) 03:50:26
>>213
「デスクトップ」という言葉が何を指しているのか人によってまちまちなんで
難しいんだけど。

Perl, Ruby, Java Scriptはサーバーサイドでよく使われる技術であって、
PCのデスクトップでの競争にはならないんだと思うけど。

Ruby&Ruby on Railsも、ウェブアプリケーション開発でPHP, Python, Perlを
飛び越してJavaの得意とする業務系でとタイマンでやり合えるかも?という
期待感で注目されているわけで。

デスクトップについてはおれはSwingで作ったらWin標準と同等になるという
ここ最近の状態を今の今まで作らなかったのが最大の敗因だと思う。

あとOSをまたがって汎用性を持たせようとするあまり、あるプラットフォーム
固有の文化というかやり方に合わせようとしないような文化がJavaには
あるような気がする。

例えば、MacユーザーはMacぽくないUIはうけいれないし。

一方でV2Cという2チャンネルビューアがプラットフォームを超えて受け入れられ
ているのは、もしかしたら今後に期待できるということなのかもなーとか思う。

235 :デフォルトの名無しさん:2006/10/28(土) 04:28:57
JavaScriptは思いっきりクライアントサイドですがな。

236 :デフォルトの名無しさん:2006/10/28(土) 05:25:12
JavaScriptはデスクトップでの競争になってるな。

237 :デフォルトの名無しさん:2006/10/28(土) 09:24:55
Web2.0という名称の下で、デスクトップの領域に侵食しようと頑張っているよね。

238 :デフォルトの名無しさん:2006/10/28(土) 09:32:19
Adobeがアポロだったかいう名前で
デスクトップ用のFlash&Ajaxな世界を画策してるな。

239 :デフォルトの名無しさん:2006/10/28(土) 10:59:01
cgiも単なるインターフェースでperlとかもともとクライアント用途メインだったし

240 :デフォルトの名無しさん:2006/10/28(土) 11:03:36
>>234はMacのSwingみたことないのかなぁ

241 :デフォルトの名無しさん:2006/10/28(土) 15:22:46
>>240
ないんだろうなぁ・・・・

242 :デフォルトの名無しさん:2006/10/28(土) 15:38:52
>>234は強烈な電波ってことで・・
言いたい事はわかるが、ずれてる・・

243 :デフォルトの名無しさん:2006/10/28(土) 18:11:23
VM が 0 秒以下で起動するようにならんと
Java 遅いというレッテルはなくならない。
つまり永遠になくならない。

244 :デフォルトの名無しさん:2006/10/28(土) 18:26:45
OS起動時にサービスとして立ち上がり、
そのまま実行環境を10個くらいプーリングし
要求に応じて割り当てる。
メモリをデフォで2GB以上消費する。

そんなJVMサービスプロセス。

245 :デフォルトの名無しさん:2006/10/28(土) 18:45:59
Windowsのプロセス起動の遅さは10年たっても改善されていないけど実用になってるのだが
その辺はどうかね

246 :デフォルトの名無しさん:2006/10/28(土) 18:50:18
ハードが進化してるから

247 :デフォルトの名無しさん:2006/10/28(土) 20:38:33
坊やだからさ


248 :デフォルトの名無しさん:2006/10/29(日) 00:34:40
>>245
どうかねって言われても、この図式だろ。
話をそらしたつもりか?

Java アプリ: プロセス起動時間 + VM 起動時間
ネイティブアプリ: プロセス起動時間

249 :デフォルトの名無しさん:2006/10/29(日) 04:22:05
>>243
JVMのプロセス起動しとけばいいじゃない
MVMが実現したら、解決だな、それじゃ

250 :デフォルトの名無しさん:2006/10/29(日) 15:37:09
>>248
こまかい揚げ足だが、
>Java アプリ: プロセス起動時間 + VM 起動時間
Javaの場合、プロセス=JVMだから、プロセス起動時間 + バイトコード起動時間ね。
昔は.EXEは.COMに比べて起動に時間がかかるとか言われてたけど、いまや誰も気にしてないから、
そのうち、マシンパワーが吸収してくれると思う。WindowsはUNIX系に比べて元々プロセス起動が重いOSだからね。
だからスレッドが発達した訳だし。
でも、regeditとかnotepadのような軽さには到達できんとは思うが。

>>249
やっぱり、.NET Frameworkのような、バイトコード実行インフラが必要になるわけね。
JavaもGlobal Jar Cacheとか作って、共用JarはJITコンパイルされて、キャッシャされるのだろうか。

251 :デフォルトの名無しさん:2006/10/29(日) 16:34:48
ユーザーの作ったクラスは難しいと思う
アプリごとにクラスパスも違うし、バージョンアップ作業もコピーだけでよかったり
クラスパスルートもさまざまだしね

でも標準APIくらいはやってくれてもよさそうなんだけどね

あと設定でクラスをロードしたらすべてコンパイル完成するまで待つというモードもほしいよ
ゲーム用途とかだととくにね

フォアグラウンドコンパイルにしたところでそのメソッドを指定スレッショルド以上つかわないと
コンパイルされねーからな

252 :デフォルトの名無しさん:2006/10/29(日) 17:07:46
>251 -Xcomp

253 :デフォルトの名無しさん:2006/10/29(日) 17:17:15
>>252
だからそれだとだめなんだってば
フォアグラウンドコンパイルになるだけ

254 :デフォルトの名無しさん:2006/10/29(日) 17:34:14
>253 それは-batchでは。

255 :デフォルトの名無しさん:2006/10/29(日) 17:47:59
>>254
だから実行時にコンパイルされるのはメソッド単位なのが問題といってるでしょ
-XX:+PrintCompilationで確認すればわかると思うが-Xcompでは解決しない

メソッドよびだしたときにかたまるようではそれは使い物にならない
まだバックグラウンドコンパイルして最初はインタプリタ動作のほうがかたつきはへる分まし


256 :デフォルトの名無しさん:2006/10/29(日) 22:08:25
Javaじゃなければとっくに解決している問題じゃないのか。
なぜJava使ってる?

257 :デフォルトの名無しさん:2006/10/29(日) 22:27:30
起動時間が遅いって・・・CGI使うわけじゃあるめーしw

258 :デフォルトの名無しさん:2006/10/30(月) 00:25:42
Swing とか SWT って知ってるか?

259 :デフォルトの名無しさん:2006/10/30(月) 00:45:54
>>250
ネイティブコンパイルの結果を再利用できればいいんだが
それと>>249の話は別、単にアプリ起動のフットプリントの話だろうから
JVM起動にかかるコストを無くしたいんだったらJVMは常駐にしとけばいいじゃん、ってこと

260 :デフォルトの名無しさん:2006/10/30(月) 02:24:29
>>259
VM常任しておいて、どうやってプログラム終了するんだよ!

261 :デフォルトの名無しさん:2006/10/30(月) 02:52:40
>>260
その課題も含めてMVMの実現なんだって・・・

262 :デフォルトの名無しさん:2006/10/30(月) 02:54:03
現世代で出来ないならスレ違いだろ。
それをここで愚痴るな。

263 :デフォルトの名無しさん:2006/10/30(月) 10:05:18
次世代のスレは糞みたいなやつが常駐してるので使い物にならん

264 :デフォルトの名無しさん:2006/10/30(月) 17:03:18
>>263 だからここで愚痴るな。おまえは、やっぱりカスだな。

265 :デフォルトの名無しさん:2006/10/30(月) 18:19:14
>>228
> そもそも一般人はローカルにZIP落として適当なフォルダに展開というのを嫌がる&出来ない人もいる
> というのを認識したほうがいい
素朴な質問ですが、今時そんなことやらせてる会社ってあるのでしょうか
私の知っている会社は皆、キッティングなり配布なりでコマンド一発でOKなのですが

266 :デフォルトの名無しさん:2006/10/30(月) 18:46:21
>>264
だからお前はここに来るなと

267 :デフォルトの名無しさん:2006/11/07(火) 22:09:44
>>265
たとえ話として、数人でやるシェア・フリーソフトや会社内部・部署の
みで使うってのもありうるわけで…
ご自分の場合だけで考えるのはいけないですよね。

268 :デフォルトの名無しさん:2006/11/15(水) 10:33:10
些末な例外は何にでもあるからな。

269 :デフォルトの名無しさん:2006/12/01(金) 20:37:55
現世代って言うのか過去なのか一時JythonとかJRubyとかjava実装の言語がはやってたけど
あれは何が目的だったん?

270 :デフォルトの名無しさん:2006/12/01(金) 22:13:55
・Yet Anotherな実装が欲しいが、一からつくんの面倒だしという発想
・一時期以降のJVMは結構速いから、使えば結構嬉しいかもという発想
・セキュリティ機構も活かせると面白いかもという研究ネタ
まあ色々ある。

271 :デフォルトの名無しさん:2006/12/02(土) 00:05:20
現世代と言えば1.5になるのだろうか。

generics の erasure は・・・失敗だったような。

272 :デフォルトの名無しさん:2006/12/02(土) 07:41:35
>>269
JRubyはRuby on Railsも動かしたりしてるし、PHPも動くし「一時」じゃ内希ガス

273 :デフォルトの名無しさん:2006/12/06(水) 01:24:48
Javaって、GPLになったじゃない
だから、Troveみたいな標準より速いとかいうコレクション実装に差し替えちゃう
見たいな話とか出てこないのかな?

274 :デフォルトの名無しさん:2006/12/06(水) 01:59:00
>>273
コレクションってクラスライブラリだよね?
OpenJDKでGPLv2になった部分の範囲外のような気がする。

まだ不勉強なので違ってたらごめん。

275 :デフォルトの名無しさん:2006/12/06(水) 02:12:34
ライブラリはGPLの範囲外ですな

276 :デフォルトの名無しさん:2006/12/11(月) 20:15:34
こんにちは、現世代Javaの仲間入りです。JDK6リリース。

ttp://java.sun.com/javase/ja/6/download.html

277 :デフォルトの名無しさん:2006/12/11(月) 21:22:27
>>276
まだ文残ってる
>ご注意: 現時点で J2SE 5 Itanium ポートは利用できません。ダウンロードバンドルは後日リリースされる予定です。
結局5最後までItanium版出なかったなー

278 :デフォルトの名無しさん:2006/12/16(土) 18:58:57
Summary of changes in Java SE 6u1 build b01
ttp://www.java.net/download/jdk6/6u1/promoted/b01/changes/jdk6u1-b01.html
ttp://download.java.net/jdk6/binaries/

updateリリースに切り替わった。

279 :デフォルトの名無しさん:2007/01/16(火) 21:09:27
Summary of changes in Java SE 6u1 build b02
ttp://download.java.net/jdk6/6u1/promoted/b02/changes/jdk6u1-b02.html
ttp://download.java.net/jdk6/binaries/

年明けなので、Copyright変えましたってのが
変更のほとんどである点がほほえましい

280 :デフォルトの名無しさん:2007/01/18(木) 23:54:26
Java 6ってOpenGLをSwingで使えるんじゃなかったっけ?

281 :デフォルトの名無しさん:2007/01/19(金) 00:26:48
Swingが(というかJava2Dが)OpenGLアクセラレーションできるようになってるが正解
まだバグも多いのでデフォにはできんけどな

5.0のときから一応出来るようにはなってるけどね
5.0でのOpenGLはほんとバグだらけでひどかった


282 :デフォルトの名無しさん:2007/01/21(日) 05:01:11
CompilerAPIがわかんね
ファイル読み込んでクラス生成は出来ても、
文字列からのクラス生成ができね

283 :デフォルトの名無しさん:2007/01/21(日) 05:51:51
仮想ファイルが使えるようになったんだっけ?

284 :デフォルトの名無しさん:2007/01/21(日) 14:27:25
Compiler Tree API を隠しAPI扱いにするのはやめてほしかったなぁ。

バージョン名をパッケージ名前に含めることで下位互換性を保つことは可能だし、
なぜ隠しAPI扱いになったのか理解に苦しむ。

285 :デフォルトの名無しさん:2007/01/21(日) 15:54:17
> Compiler Tree API を隠しAPI扱いにするのはやめてほしかったなぁ。
> なぜ隠しAPI扱いになったのか理解に苦しむ。
どっちなんだ……

286 :デフォルトの名無しさん:2007/01/21(日) 15:59:04
キミはなにを言いたいの?
理解に苦しむ。

287 :デフォルトの名無しさん:2007/01/21(日) 16:21:00
つーかCompiler API使えばクロージャ出来るじゃん・・・
わざわざ言語使用に入れんでも。

288 :デフォルトの名無しさん:2007/01/21(日) 16:26:00
>>284
tree API は doclet API並に公開されてるし、compiler API は java の標準APIでしょ。

javax.lang.model の方で将来のバージョンに対する考慮はしてるみたいだし。

289 :デフォルトの名無しさん:2007/01/21(日) 16:28:27
>>287
今までだってJavaCC 使うとか、自力で字句解析と構文解析すりゃできたよ。

290 :デフォルトの名無しさん:2007/01/21(日) 16:32:30
>>287
サンプル書いてみろよw
口だけやろうがww

291 :デフォルトの名無しさん:2007/01/21(日) 16:38:26
全部機械語で出来るじゃん・・・
わざわざ言語作らんでも。

こんな感じかな。

292 :デフォルトの名無しさん:2007/01/21(日) 17:26:09
>>290
ほらよ
import java.io.File;
import java.io.Writer;
import javax.tools.JavaCompilerTool;
import javax.tools.JavaFileManager;
import javax.tools.JavaFileObject;
import javax.tools.ToolProvider;
public class Main {
public static void main(String[] args) {
JavaCompilerTool javaCompilerTool = ToolProvider.defaultJavaCompiler();
JavaFileManager javaFileManager = javaCompilerTool
.getStandardFileManager();
try {
JavaFileObject javaFileObject = javaFileManager
.getFileForInput("bin/Tutorials.java");
Writer writer = javaFileObject.openWriter();
writer.write("public class Tutorials{"
+ "public static void main(String[] args){"
+ "System.out.println(\"We love JavaLobby :)\");"+ "}" + "}");
writer.close();
javaCompilerTool.setOutputDirectory(new File("bin"));
System.out.println(javaCompilerTool.run(null,new JavaFileObject[]{javaFileObject}).getDiagnostics());
Class.forName("Tutorials").getDeclaredMethod("main",
new Class[] { String[].class }).invoke(null,
new Object[] { null });
} catch (Exception e) {e.printStackTrace();
}}
}

293 :デフォルトの名無しさん:2007/01/21(日) 17:32:04
どこからつっこめばいいのやらw
まずコンパイラぐらい通せよww


294 :デフォルトの名無しさん:2007/02/03(土) 18:43:05
>>287
んなもん、Java6じゃなくてもできるわ。アホかwww
クロージャの意味を、

「よ く 理 解 し て か ら 書 い て ね 。」


295 :デフォルトの名無しさん:2007/02/03(土) 18:44:44
Compiler APIって、APTサポートの目的が強いんだろな。


296 :デフォルトの名無しさん:2007/02/13(火) 14:12:37
JDK6 の日本語ドキュメント完成だってさ。
http://blogs.sun.com/javaev/date/20070213

297 :デフォルトの名無しさん:2007/02/13(火) 16:50:44
今回すごい遅かったな
やっぱり翻訳されたAPIドキュメントがあるのとないのとでは違うからねぇ

298 :デフォルトの名無しさん:2007/02/19(月) 14:49:38
http://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/par-compaction-6.html
並列若い世代コレクタ
( ゚д゚)・・・・・・

何処に突っ込むべきなんだろう

299 :デフォルトの名無しさん:2007/02/19(月) 15:15:38
昔から直訳ってのはよくある
カタカナのままのほうがわかりやすいとかもあるしね

有名どこではシリアライズとかパーシステンスとかだが、まぁこれはまだいいほう
マイナーなAPIだとすごいままだぞ

300 :デフォルトの名無しさん:2007/02/20(火) 00:23:59
永続性っていう日本語は、なんとなくイメージしやすい気がする
直列化はいまだにピンとこない。

301 :デフォルトの名無しさん:2007/02/20(火) 00:26:44
劣等GPLとかすばらしいよな

302 :デフォルトの名無しさん:2007/02/20(火) 08:44:18
劣等パンダ

303 :デフォルトの名無しさん:2007/02/26(月) 15:24:02
Rhino は javax.script.ScriptContext#setWriter で普通の Writer 渡すと
print 時にエラー吐いて死ぬ……

こんぐらいは、フレームワーク側で吸収して欲しいよーな。

80 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)