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

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

[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]

1 :デフォルトの名無しさん:2006/11/20(月) 10:38:16
前スレ

[mustang] 次世代Javaの動向 3 [dolphin]
http://pc8.2ch.net/test/read.cgi/tech/1157227790/

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

【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc8.2ch.net/test/read.cgi/tech/1081698555/

2006年12月にMustang Java SE 6がリリース予定


Mustangの掲げる主な目標は以下の点にある。
* 互換性と安定性および品質の向上
* Easy of Developmentの実現
* WebサービスおよびXMLサポート機能の拡張
* リソース管理や診断機能の強化
* デスクトップ環境の強化


Java SE 6 じゃじゃ馬ならし
http://www.javainthebox.net/laboratory/JavaSE6/

2 :デフォルトの名無しさん:2006/11/20(月) 13:40:07
ふーん、WinFXがあるのにね

3 :デフォルトの名無しさん:2006/11/20(月) 14:11:39
前スレの話題
複素数を扱う前に実数を扱うプリミティブ型がなくちゃ

4 :デフォルトの名無しさん:2006/11/20(月) 16:54:57
>>3
無限精度ってこと?

5 :デフォルトの名無しさん:2006/11/20(月) 17:53:26
>>3
BigDecimalでいいよ。
あれをプリミティブにしてもねえ

6 :デフォルトの名無しさん:2006/11/20(月) 17:55:33
Complexはプリミティブにする必要性を感じない。

conjugate()やabs(),arg(),getReal(),getImaginary(),innerProduct(),

とかいうメソッドがあったとして、これらもいちいち演算子で表現
することになったらどうする気だ。

7 :デフォルトの名無しさん:2006/11/20(月) 18:39:17
Stringみたいに
Complex z = "1+2i";
と宣言できるだけでいいな。

8 :デフォルトの名無しさん:2006/11/20(月) 18:40:34
全くですww
数値演算に特化したサポートはスマンが我慢してもらえると助かります・・・
複素数なんて日常つかわねえっす

9 :デフォルトの名無しさん:2006/11/20(月) 18:41:15
>>7
それくらいなら
Complex z = Complex.valueOf("1+2i");
でいいんじゃないの?

10 : :2006/11/21(火) 00:16:58
mustangのjavaw.exeって60〜70秒に一度くらい規則正しくCPU負荷がすごく高くなりませんか?ワーカースレッドとか負荷の高い計算がない場合でも必ず起こってるようなきがします。

11 :デフォルトの名無しさん:2006/11/21(火) 00:30:08
>>10
つ sun.rmi.dgc.server.gcInterval 、sun.rmi.dgc.client.gcInterval

12 :デフォルトの名無しさん:2006/11/21(火) 00:38:32
>>11
ガベージコレクトしてるんですか。
しかしTigerでは気にならなかったレベルだったような気がします。簡単なアウトラインエディタを作ってるんですが、文字入力や日本語変換とかが1分に一回規則正しく瞬間的に遅くなってしまいます。以前は気にならなかったのに。

13 :12:2006/11/21(火) 00:39:27
自分のパソコンがPenVの733MHZだから遅くて気になるのかな。

14 :デフォルトの名無しさん:2006/11/21(火) 03:05:40
>>7
じゃ、今早速作れ。
構文解析は負担がかかるが。
とりあえずはメソッドを演算子代わりにすることから
始めないことには

15 :デフォルトの名無しさん:2006/11/21(火) 03:07:25
>>9
その程度の簡単なものであればいいが
\int\~\infty_{\infty}\frac{\sin x}[\cos \frac{dx}{dt}]
みたいなものだととんでもなく負担が増大する。

16 :デフォルトの名無しさん:2006/11/21(火) 09:02:49
複素数は虚数単位がIかJかで殺し合いが起きるので却下すます

17 :デフォルトの名無しさん:2006/11/21(火) 09:10:27
Vector v = {1, 2, 3};

Matrix A = {
    {1, 2, 3},
    {4, 5, 6},
    {7, 8, 9},
  };

18 :デフォルトの名無しさん:2006/11/21(火) 12:35:50
>>16
うむ。それもそうだ。
複素数を却下するのではなく、String表記法
について慎重に検討するまでは却下する。

が正しい。@

19 :デフォルトの名無しさん:2006/11/21(火) 12:37:39
>>17
見たからにただの配列と変わらんな。

シンタックスシュガーとして
導入したとでもいうのかね。

だが、行列の演算子はどうする。
行列の積は*でいいのか?
それとも、行列の個々の要素同士の積こそが*であって
行列の積は*で表現すべきではないか?

ベクトルの内積演算子、外積演算子はどうする。

20 :デフォルトの名無しさん:2006/11/21(火) 20:57:09
Java SE 6 っていつ出るの?
11月上旬っていう記事を見たんだが、まだだよねぇ?
http://journal.mycom.co.jp/articles/2006/11/01/java/

21 :デフォルトの名無しさん:2006/11/21(火) 21:25:07
今、RC

22 :デフォルトの名無しさん:2006/11/21(火) 21:34:22
>>20
おまえは>>1すら読めないのか

23 :デフォルトの名無しさん:2006/11/22(水) 08:28:56
>>20
November と December を勘違いでもしたんじゃねーか?
と思わなくも無い。大地タソだし。

そこの記事ちゃんと読むと、記事の日付が 11/1 になってるのに
> Java SE 6のリリースまで1カ月強となった。
とか出てきて変だし。

24 :デフォルトの名無しさん:2006/11/22(水) 18:06:26
いや、当初は11月初頭リリースって予定だったと思ったが・・・。

25 :デフォルトの名無しさん:2006/11/23(木) 02:52:35
>>19
そんなあなたに Fortress


26 :デフォルトの名無しさん:2006/11/23(木) 12:39:02
次のバージョンではGenericsを完全にしてほしい。

27 :デフォルトの名無しさん:2006/11/23(木) 12:43:18
完全てどういうことだ

28 :デフォルトの名無しさん:2006/11/23(木) 13:56:59
C++Template化とかほざいたら>>26をしばきたたこうぜ。

29 :デフォルトの名無しさん:2006/11/23(木) 13:57:16
public class A<E> {
  E[] e = new E[5];
}
ができるように。

30 :デフォルトの名無しさん:2006/11/23(木) 16:07:03
>>29
erasure だけを使ってる限りは無理だろうね。

31 :デフォルトの名無しさん:2006/11/23(木) 18:42:09
erasureによるGenericsは、
全ての型で使える1つのコードを生成するだけでよいという利点
があるんだけど。
キャッシュの当たり率やメモリ消費量的には有利なはず。

C#のGenericsを採用した時点で、JITコンパイラは一部のコードを
C++のテンプレートのように型毎に生成する必要が出てくるからなぁ。

32 :デフォルトの名無しさん:2006/11/24(金) 15:35:44
>>29
そもそも、配列でそんなもんを使う価値が理解できない。
配列自体おかしな仕様なんだから。
List使え。

33 :デフォルトの名無しさん:2006/11/24(金) 15:36:18
>>31
Java GenericsはC#のGenericsとは違うからな。

34 :デフォルトの名無しさん:2006/11/24(金) 16:35:44
> 配列自体おかしな仕様なんだから。
どの辺が?

35 :デフォルトの名無しさん:2006/11/24(金) 16:36:56
ということは、>>29は、利便性とデメリットを検討した上で
排除された記法っぽいな。
俺も>>29が出来てもそんなメリットとも感じないし。

36 :デフォルトの名無しさん:2006/11/24(金) 20:31:36
>>34
まず一つあげてみようか。
配列型を引数にとるとその引数である
配列の要素にまでfinalを指定できないことがあげられるね。
簡単に言うと配列は型安全性が完全に保証されていないこと。
配列の配列を他の配列の配列の型に代入できたりとか。
あと、配列型は継承できないこととか。




37 :デフォルトの名無しさん:2006/11/24(金) 20:49:21
>配列の要素にまでfinalを指定できないことがあげられるね。
コンパイル時、個々の要素毎でなく配列全体一括で不変にできるようにしようって話なら
adding_generics の時にも一旦出てたし、JSR 308 とかでもやろうとしてたりとかしてるね。
http://jcp.org/en/jsr/detail?id=308

> 簡単に言うと配列は型安全性が完全に保証されていないこと。
よくわからんけど、これは List も同じでは?

> あと、配列型は継承できないこととか。
配列を継承したいケースって、どんな時?
toString() 弄りたいとかはわからんでもないが、他の解決法あるし……

38 :デフォルトの名無しさん:2006/11/24(金) 21:01:25
>>37
一番上に関しては List でもコンパイル時にはチェックできないし。
Collections.unmodifiableList() とか使えば実行時にはチェックされるけど。

39 :デフォルトの名無しさん:2006/11/24(金) 21:05:59
>>37
36じゃないが、「配列は型安全性が完全に保証されていない」ってのは
下のコードは実行時例外が出るのにコンパイルが通るって話だろう。
ジェネリックな List だとコンパイルが通らない。

String[] ss = new String[] { "abc" };
Object[] os = ss;
os[0] = new Integer(123);

40 :デフォルトの名無しさん:2006/11/24(金) 21:17:18
>>39
コンパイル時の型安全だけに限ってるのか。
実行時は List の方が緩くなるし、どっちもどっちだと思うけどね。

Collections.checkedList() もあるけど、
Class が必要になるから、必ずしも使えるとは限らんし。

41 :デフォルトの名無しさん:2006/11/24(金) 23:20:57
>>38
それを配列にできないから配列は糞仕様だっていってるんだろ。
いちいりListに変換しないといけないからな

42 :デフォルトの名無しさん:2006/11/24(金) 23:22:40
Developer Worksで配列はCovariantじゃないってのがあったな。

配列をGenericsで扱うと、思い通りにいかないとかってやつ。
今その話が発端になっているのかな?

たしかにあれはキモイ。だから配列は極力つかわないほうが
綺麗になるってことかな。配列とGenericsとの併用は避けるべきだともいえそうだね。


43 :デフォルトの名無しさん:2006/11/24(金) 23:26:37
>>37
> > 簡単に言うと配列は型安全性が完全に保証されていないこと。
> よくわからんけど、これは List も同じでは?

そこでGenericsと、既に出たけれどもCollectionsクラスのアンモディファイアブルを
使う。配列だとListほど思い通りにいくわけでもないな。
配列はListよりパフォーマンスがよくてコード量が短いという
程度のメリットしかないな。


> > あと、配列型は継承できないこととか。
> 配列を継承したいケースって、どんな時?

そんなケースはまれだと思うが、

ある型Aを配列で扱いたいとき、
Aを継承したBも配列で扱いたい。
そんなとき、B[]はA[]を継承できるかっていうと
そうでも無いって奴だな。

そうなったらAArrayやBArrayというクラスを別途
作って対応するしかないって奴だ。



44 :デフォルトの名無しさん:2006/11/24(金) 23:33:52
配列もプリミティブ型同様、
Javaの中で妥協して作られたモノだと見てもいいな。

しかしprintf(String a, Object...)は
実は正体がprintf(String a, Object[] b)というからな

これもいつしか

public <E> PrintStream printf(String a List<E> )

なメソッドがオーバーロードされるんだろうか



45 :デフォルトの名無しさん:2006/11/25(土) 00:03:05
>>42
いや、generics は covariant じゃないから、型安全が保持されてるって書いてあったような。

> 配列とGenericsとの併用は避けるべきだともいえそうだね。
配列と Generics は相性も悪いしね。 >>29 みたいのができないし。

46 :デフォルトの名無しさん:2006/11/25(土) 00:10:13
>>43
> そんなとき、B[]はA[]を継承できるかっていうと
それって、どーゆー時に必要になる?

47 :デフォルトの名無しさん:2006/11/25(土) 00:35:27
例えばSortedSetを継承してTreeSetを作りたい、
みたいなときじゃないかな。

結局配列型を継承せず
配列型を集約するわけだが

48 :デフォルトの名無しさん:2006/11/25(土) 00:42:00
>例えばSortedSetを継承してTreeSetを作りたい
Sorted配列を継承してTree配列作る?
配列に対して、そーゆー発想は無かったなぁ。

49 :デフォルトの名無しさん:2006/11/25(土) 02:25:17
そして配列に失望するのであった。

配列は非オブジェクト指向である。

50 :デフォルトの名無しさん:2006/11/25(土) 02:29:47
構文糖衣を許して、[]=っていうメソッドを定義できるようにするしかない。

51 :デフォルトの名無しさん:2006/11/25(土) 03:09:59
>>48
普通はしない
ってか、Tree配列ってなんだよ

52 :デフォルトの名無しさん:2006/11/25(土) 03:35:37
>>45
でも配列使うAPIも結構多いんだよね。
何しろGenericsができるまでは要素の型を指定できたの配列だけだし。

53 :デフォルトの名無しさん:2006/11/25(土) 09:12:57
Number[] nums = new Double[2];
nums[0] = new Double(1.0); //OK
//nums[1] = new Integer(1000); //ArrayStoreException
Double[] dd = (Double[])nums;//OK

Number[] num2 = new Number[2];
num2[0] = new Double(1.0); //OK
num2[1] = new Integer(1000); //OK
num2[1] = new Double(0.01); //OK
Double[] ddd = (Double[])num2;//ClassCastException

54 :デフォルトの名無しさん:2006/11/25(土) 09:47:30
>>39
それで「型安全が完全に保証されていない」ってんなら、極端な話すれば、

List<String> l = new ArrayList<String>();
Vector<String> v = (Vector<String>)l;
は、コンパイルが通るから、
「参照型の変数は型安全が完全に保証されていない」
とかいう変な話になっちゃうような気もする。

55 :デフォルトの名無しさん:2006/11/25(土) 12:42:16
>>54
それはキャストしてるだけでしょ。
型安全ってのはキャストなしでコンパイルが通ったら
実行時にも型に関する例外が出ないことだよ。

56 :デフォルトの名無しさん:2006/11/25(土) 13:12:16
>>54
それはキャストが型安全じゃない事を示しただけ。

そりゃ、キャストは型安全じゃないわな。

57 :デフォルトの名無しさん:2006/11/25(土) 14:32:17
ArrayListのコードの一部だけど何か奇怪だね。

private transient E[] elementData;(92行)
this.elementData = (E[])new Object[initialCapacity];(113行)

58 :デフォルトの名無しさん:2006/11/25(土) 15:12:10
そりゃ、erasureだからnew E[initialCapacity];はできんでしょ。

59 :デフォルトの名無しさん:2006/11/25(土) 15:23:13
配列は変な仕様だが、
配列がないとCollectionFrameworkもつくれないわけか・・・

60 :デフォルトの名無しさん:2006/11/25(土) 15:28:51
>>59
配列が covariant じゃなかったら 1.4 で Collection#toArray(Object[]) の
使い勝手が滅茶苦茶悪くなるし。極端に変な仕様だとも思わんが。

61 :デフォルトの名無しさん:2006/11/25(土) 19:03:57
>>60
まあその辺はトレードオフだわな
配列がcovariantなおかげで便利な部分があるのも確かだし
一方で型安全では無いとか配列の要素への代入時にチェックが入って遅くなる(可能性がある)
とか、covariantなために発生する問題もある
型安全かつ利便性をそれなりに保つためには、Java Genericsが採用したワイルドカードの
ような機能がJVMレベルであれば良かったんだろうけど、今更言っても後の祭りだしね

62 :デフォルトの名無しさん:2006/11/25(土) 21:01:45
>>59
っJNI

63 :デフォルトの名無しさん:2006/11/25(土) 21:46:16
>59 つcons

64 :デフォルトの名無しさん:2006/11/25(土) 23:09:16
ところで

covariantの意味はなんたるか


統計学用語で
varianseが分散
covarianseが共分散
ってのはわかるんだが


65 :デフォルトの名無しさん:2006/11/25(土) 23:09:49
スペルミスだ

variance
covariance
の間違い

66 :デフォルトの名無しさん:2006/11/25(土) 23:11:35
おっとよく見ると

http://www2.alc.co.jp/ejr/index.php?word_in=covariant&word_in2=%82%A9%82%AB%82%AD%82%AF%82%B1&word_in3=PVawEWi72JXCKoa0Je

# covariant
【形】 《数学》共変{きょうへん}の
# covariant components
共変成分{きょうへん せいぶん}
# covariant derivative
《数学》共変微分{きょうへん びぶん}、共変導関数{きょうへん どうかんすう}
# covariant differential
共変微分{きょうへん びぶん}
# covariant differentiation
《数学》共変微分{きょうへん びぶん}
# covariant equation
共変方程式{きょうへん ほうていしき}
# covariant functor
共変関手{きょうへん かんしゅ}
# covariant gage
共変{きょうへん}ゲージ

67 :デフォルトの名無しさん:2006/11/25(土) 23:13:54
ベクトル解析は三次元までしかしらないので
covariantとかtensor(テンソル)とかいわれても
わからん。

n次元空間とかn次元超平面とかクォータニンとか全然ピンと来ない

68 :デフォルトの名無しさん:2006/11/26(日) 00:58:36
>>64
プログラミング言語関係の用語のcovariance・contravariance
は、共変・反変と訳することが多い。varianceの訳語は
聞いたことが無いので、よくわからない

で、covarianceの意味だがここで言われてる文脈では
ある型AとBとパラメータ型Tについて、
A <: B => T<A> <: T<B> ( A <: B は AがBのサブタイプであるという意味)
が成立するとき、Tはcovariantであると言う。
で、Javaの配列に関して考えてみると
A <: B => A[] <: B[]
がJava言語仕様で決まっているからJavaの配列はcovariantなわけだ
一方、Java Genericsでは上記の命題が成立しないのでJava Genericsの
Generic型はcovriantでは無いというわけ

69 :デフォルトの名無しさん:2006/11/26(日) 03:16:26
お前ら、何でJava使ってるんだ。
もういいから、違う言語使えよ。


70 :64 じゃないが:2006/11/26(日) 03:19:04
>>68
なるほどーすげぇよく分かったよ。サンクスコ


71 :デフォルトの名無しさん:2006/11/26(日) 10:21:31
A <: B => T<A> <: T<B> ( A <: B は AがBのサブタイプであるという意味)
この行を読もうとして変態言語のパーサの気分がよくわかった。
等幅フォントにしたら読みやすくなった。


72 :デフォルトの名無しさん:2006/11/26(日) 12:49:03
>>69
じゃ、オマエのおすすめの言語あげてみそ

73 :デフォルトの名無しさん:2006/11/26(日) 13:08:53
>>69じゃないけど、MathematicaだとJ/Linkや.NET/Linkで
Javaや.NETと連携できるみたいだね。
面倒な計算はMathematicaのエンジンにやらせて、
結果だけJavaで表示って方法じゃダメか?
Mathematicaしか調べてないけど、他の製品にもこういうのあるんじゃない?

74 :デフォルトの名無しさん:2006/11/27(月) 01:52:43
それが普通の人の発想だと思おうよ

75 :デフォルトの名無しさん:2006/11/27(月) 02:20:17
>>73
ドトネトとの連携が>>69とどういう繋がりがあるんだかわからないが
数値計算のためにわざわざドトネトを使う価値ってものが
どういうものか説明しないことには意図が伝わらないな

76 :デフォルトの名無しさん:2006/11/27(月) 04:31:53
>>75
いや、>>73の論旨を読めてないでしょう。
JavaOnlyで行わず数値演算は、Mathmatica(あれも一種の言語だよな)
何かに任せ連携を取るということもあるという話。であって
数値演算に、Java、.NET等の汎用言語を「使わない」選択肢について語ってるのが>>73

77 :デフォルトの名無しさん:2006/11/27(月) 08:07:07
Mathmaticaってそんな一般的?
大学の端末には確かに入ってるけど・・

78 :デフォルトの名無しさん:2006/11/27(月) 15:36:34
本気で数値計算やるなら大抵持ってる希ガス
つーか他の製品知らない

79 :デフォルトの名無しさん:2006/11/27(月) 15:53:39
>>76
Mathematicaの話をするならドトネトの話は関係ない

80 :デフォルトの名無しさん:2006/11/27(月) 15:53:57
>>78
MATLABのほうが断然使いやすいんだが

81 :デフォルトの名無しさん:2006/11/27(月) 20:35:23
MATLAB,Mathematicaは、理系で大学生以上なら一般的に知ってると思う
他の言語とのインターフェースは知らなかったよ。

82 :デフォルトの名無しさん:2006/11/27(月) 23:52:44
MATLABは大学でも
特定の研究室に関わらないと知らないと思うぞ。

あと、高いしな。

FortranやC/C++のほうが知名度が高いだろう。


83 :デフォルトの名無しさん:2006/11/29(水) 20:30:40
昔、Javaにポインタを導入しろとか言ってたやつがいたなw

84 :デフォルトの名無しさん:2006/11/29(水) 22:24:09
ぬるぽ

85 :デフォルトの名無しさん:2006/11/29(水) 23:26:25
>>82
CやJavaを使える生徒が減ったという理由でMATLABが必修になりつつある情報科があるんだよなw
まず教授がCやJavaを使えないって話かもしれんがw

86 :デフォルトの名無しさん:2006/11/30(木) 01:18:03
>>83
C#見て小躍りしたんだろうなぁ
>>84
うん。ガッ

87 :デフォルトの名無しさん:2006/11/30(木) 01:43:40
大学生は生徒とは呼ばない。学生と呼ぶ。
生徒は中高生のことを指す。

88 :デフォルトの名無しさん:2006/11/30(木) 20:26:03
++java

89 :デフォルトの名無しさん:2006/12/01(金) 09:48:41
Java#

90 :デフォルトの名無しさん:2006/12/02(土) 07:44:53
#java++

91 :デフォルトの名無しさん:2006/12/02(土) 10:42:01
Java SE 6 まだ〜?

92 :デフォルトの名無しさん:2006/12/02(土) 13:37:01
#import <java.lang.System>

93 :デフォルトの名無しさん:2006/12/04(月) 12:24:19
JDK7 build03
ttp://download.java.net/jdk7/binaries/
ttp://www.java.net/download/jdk7/changes/jdk7-b03.html

Changelogの多さからして本格稼働した様子。

94 :デフォルトの名無しさん:2006/12/10(日) 10:42:44
次世代Java == C#

95 :デフォルトの名無しさん:2006/12/10(日) 14:05:39
流石に言語機能としてはまだC#のほうが上かな。
さすがDelphi作者が作っただけはある。
Java 7からはプロパティやクロージャも検討されるから
2009年には若干C#より柔軟になる。

96 :デフォルトの名無しさん:2006/12/10(日) 15:43:40
そーいや、クロージャの話はいろいろ出てきたけどプロパティの話はあんましみないね。

97 :デフォルトの名無しさん:2006/12/10(日) 19:22:49
リリースまだかよ。
12月も1/3過ぎちゃうぞ。

98 :デフォルトの名無しさん:2006/12/10(日) 23:09:53
なんか、最近ようやく継続の存在意義を知った


99 :デフォルトの名無しさん:2006/12/11(月) 20:13:17
リリースされたよ。JDK6。

100 :デフォルトの名無しさん:2006/12/11(月) 20:33:55
ランゲージパックは無し?
てか5.0のupdate10をちらっとみたけどこっちのがマニアックに凄いな
selectが内部でepollで実装されてるってことはゲーム用途でもいけそう

101 :デフォルトの名無しさん:2006/12/11(月) 21:36:15
>>100
ランゲージパックなんていままでもなかったと思うが。


102 :デフォルトの名無しさん:2006/12/11(月) 21:43:47
そうだっけか。ドキュメントやらNBやらと違ってそのまま使えばいいのか。

103 :デフォルトの名無しさん:2006/12/11(月) 21:50:39
静かなリリース

104 :デフォルトの名無しさん:2006/12/11(月) 22:31:28
まだりりきゃんでしょ。

105 :デフォルトの名無しさん:2006/12/11(月) 22:32:50
>>102
前から、JDKの日本語ダウンロードページなんかは前からあるけど、
ダウンロード方法なんかが訳されてるだけで中身は一緒だったな。



106 :デフォルトの名無しさん:2006/12/11(月) 23:17:34
翻訳は https://jdk-api-ja.dev.java.net/ja/index.html でやってるよん。
早く日本語のAPIリファレンス欲しい人は手伝ってみれば良いかも?

107 :デフォルトの名無しさん:2006/12/12(火) 09:59:49
静かなリリースsage

108 :デフォルトの名無しさん:2006/12/12(火) 12:00:47
おおおおおおおおおおおおおおおおおおおおおおおおおおおおおおおお!!

ついにリリースされたか!

気が付くのが遅かった!



早速ダウソ!

109 :デフォルトの名無しさん:2006/12/12(火) 17:09:24
ダウンロードにNetBeans5.5バンドルのがあるけど、
日本語版NetBeans5.5って正式リリースされてたっけ?

110 :デフォルトの名無しさん:2006/12/12(火) 18:04:31
>>109
JDK6にバンドルされているのは英語版。日本語版は12/14の予定。

いまDLできるJDK6のVMだけど、NetBeansの製品情報で見ると 1.6.0-b105と表示される。
これって本当に正式版なのかな?


111 :109:2006/12/12(火) 18:26:18
>>110
thx
JDK5のときも1.5.0_0*-b0*みたいに表示されてたから、たぶん正式版だと思う。

112 :デフォルトの名無しさん:2006/12/12(火) 18:39:36
build 番号 105 なのか(w

113 :デフォルトの名無しさん:2006/12/12(火) 19:13:07
JDK6入れてJava2Dのデモプログラム動かしてみたけど、
起動時の画面の動きが怪しいね。

114 :デフォルトの名無しさん:2006/12/12(火) 19:22:25
さいしょはみんな bはベータのbだと思うよな。


115 :デフォルトの名無しさん:2006/12/12(火) 19:33:26
weeklyビルドを追っていたら混乱するはずがないです。

>>113
どう怪しいのか詳しく。

116 :デフォルトの名無しさん:2006/12/12(火) 20:53:04
SwingSet2のスプラッシュスクリーンのウィンドウの形が、
影つきの非矩形でびっくりした。

着実にGUIも進歩しているなぁ

117 :デフォルトの名無しさん:2006/12/12(火) 21:23:32
あら、RhinoはMapをプロパティ風に使えないのか?
これからはJavaアプリ間で使いまわすスクリプトも流行るだろうし研究しなきゃ

118 :デフォルトの名無しさん:2006/12/12(火) 21:37:35
>>115
メインの画面が出る直前に、起動時のプログレスダイアログが左端に動く

119 :118:2006/12/12(火) 21:38:30
×左端
○左上

120 :デフォルトの名無しさん:2006/12/12(火) 21:55:54
パフォーマンスが改善したって聞いたけど、ほとんど感じない…
ペン3、1GHZじゃ恩恵なし?

121 :デフォルトの名無しさん:2006/12/13(水) 00:30:37
VMの起動が早くなった
ような気がする…

122 :デフォルトの名無しさん:2006/12/13(水) 01:05:22
nbの検索が糞遅くなった気が・・・5.0だからか?

123 :デフォルトの名無しさん:2006/12/13(水) 01:30:32
結局、SystemTrayから開けるメニューはAWTのPopupだけか。


124 :デフォルトの名無しさん:2006/12/13(水) 01:56:28
>>121
確かに5.0よりやや早いのを確認
VM起動前にスプラッシュ出せるようになったのも重いアンチウイルスソフト使ってる人にはうれしいかもね

125 :デフォルトの名無しさん:2006/12/13(水) 08:54:49
jarファイルのアイコンが変わったね

126 :デフォルトの名無しさん:2006/12/13(水) 09:08:58
>>117
java.util.Mapの要素をプロパティ風に参照したいってこと?
それなら少なくともそのままやるのは無理っぽい

js> importPackage(java.util)
js> var m = new HashMap()
js> m
{}
js> m.foo = "foo"
js: "<stdin>", line 5: Java class "java.util.HashMap" has no public instance fie
ld or method named "foo".
js: "<stdin>", line 5: org.mozilla.javascript.EvaluatorException: Java class "ja
va.util.HashMap" has no public instance field or method named "foo". (<stdin>#5)

Pnuts使うのがいいんじゃないかなあ

> import java.util.*
null
> m = new HashMap()
{}
> m.foo = "foo"
"foo"
> m.foo
"foo"

127 :デフォルトの名無しさん:2006/12/13(水) 16:44:55
何このIronPythonのパクリ(嘲笑

128 :デフォルトの名無しさん:2006/12/13(水) 16:48:02
何を指しているのだろう。


129 :デフォルトの名無しさん:2006/12/13(水) 16:58:14
Borlandが作り
MSが真似をして
Javaが起源を主張する

130 :デフォルトの名無しさん:2006/12/13(水) 23:13:03
古い歴史を持つ Rhino や Pnuts が、
どのようにすればごく最近(2003-2004)作成された IronPython を模倣出来るんだろう...

最近、歴史を学ばない半島人がオリジナルにパクリを主張することが多くて困る

131 :デフォルトの名無しさん:2006/12/14(木) 01:13:19
PnutsなんてJavaのごく初期から数少ないJava製スクリプト言語だったよな。
しかも日本人作なんで驚いたもんだ。


132 :デフォルトの名無しさん:2006/12/15(金) 04:27:57
Java SE 7.0 のスライド、らしい。
http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf

なんか BigDecimal で四則演算が使えてるっぽいサンプルとか、
JavaBeansのプロパティが -> で参照できてるっぽいサンプルとかがある。

Closure の構文みるに、8月の段階で提案されてた構文っぽいので
他の言語機能も構文変わったりするのかも。
それと個人的には Java SE 7.0 って機能てんこ盛りすぎに思えるので
いくつかの機能は次のバージョンに持ち越される可能性もあるんじゃないかと心配したり。
ざっとみただけでも、コンパイルエラーになりそうなサンプルが 2つほどあったり……

133 :デフォルトの名無しさん:2006/12/15(金) 07:05:51
プロパティはいらん。機能そのものじゃなくて構文がダメ。
Genericsの略式インスタンスもnew()の方はキモ過ぎる。
インタフェースのデフォルト実装クラスがあるってことだろ。
friend class構文とかと同じキモさ。

134 :デフォルトの名無しさん:2006/12/15(金) 07:15:41
要はC# 3.0のパクリなんだろ。(ゲラ

135 :デフォルトの名無しさん:2006/12/15(金) 07:46:34
>>133
> インタフェースのデフォルト実装クラスがあるってことだろ。
そうとも限らないんだけどね。
gosling御大も別のアプローチをブログに書いてたりするし。

その辺の話は、こっちみると良いかも。
http://weblogs.java.net/blog/forax/archive/2006/12/dry_dont_repeat.html

136 :デフォルトの名無しさん:2006/12/15(金) 11:15:49
つーか、 -> はやめて欲しい。純粋にキモい。ふつーにドットにしろよ。

137 :デフォルトの名無しさん:2006/12/15(金) 13:07:39
ドットは止めて欲しい。フィールドアクセスと区別つかんし
Groovy みたくフィールドアクセスを明示する場合に
foo.@bar なんて構文使うのもアレだし。

138 :デフォルトの名無しさん:2006/12/15(金) 20:32:17
>>135
おお、 :=  はいいな・・・

139 :デフォルトの名無しさん:2006/12/15(金) 22:52:45
>>132
Javaも拡張しすぎてC++と同じ道を歩みそうな予感…
ところで、みんなの職場では5.0は浸透している?
うちの職場はまだ1.3...orz

140 :デフォルトの名無しさん:2006/12/15(金) 23:00:45
うちは今年度からようやく1.4

141 :デフォルトの名無しさん:2006/12/15(金) 23:09:30
ちょ・・・1.3てwww
去年から1.5だな。さっさと1.6にしたいが流石に時期尚早

142 :デフォルトの名無しさん:2006/12/15(金) 23:18:55
OutOfMemoryとかJMXとかの強化だけでも6に移行する価値がある。
今回はバグつぶしに金掛けてるし、実用レベルまで叩かれるのも早いかと。

143 :デフォルトの名無しさん:2006/12/15(金) 23:43:34
ある程度バグはあるが、weeklyに追いかけてきたから
どれくらいのものかは肌で感じてるし安心感は強いな
イザとなったら自分で改変もできるし

144 :デフォルトの名無しさん:2006/12/15(金) 23:51:49
たまたま覗いたら JDK7 b04 が出てた。
http://download.java.net/jdk7/changes/jdk7-b04.html

そろそろ JDK7 も本格始動?

145 :デフォルトの名無しさん:2006/12/16(土) 00:00:48
XML構文より先にヒアドキュメントを実装して欲しい。

146 :デフォルトの名無しさん:2006/12/16(土) 00:58:28
1月から開発するNetBeans Platformベースのデスクトップアプリで
JDK6を使ってみる。「WindowsVistaに対応してます」の一言で
クライアントのOKが出た。JDK6でなければならない理由はないんだけど、
何より俺が使ってみたいのだ。

147 :デフォルトの名無しさん:2006/12/16(土) 01:00:31
おめでとうw

148 :デフォルトの名無しさん:2006/12/16(土) 20:31:10
>145

同意

149 :デフォルトの名無しさん:2006/12/16(土) 22:13:48
別にここでするレスじゃないかも知れんが
共用体が欲しいなあとなんとなしに思ってたけど
nioのByteBufferが既にそれっぽいことに今更気づいた。

150 :デフォルトの名無しさん:2006/12/16(土) 23:59:17
>>146
デスクトップアプリで6を使うのはいいと思うけど、EclipseRCPにしてもNetBeansPlatformにしても
へんなのをかますと余計にめんどくさいだけだと思うんだが
重くなりやすいし、バグがあったとしても回避しにくい

普通にSwingベースのほうが開発効率がいい
まぁNetBeansPlatformはSwingベースで開発できる分まだ楽か

151 :デフォルトの名無しさん:2006/12/17(日) 00:01:20
150が何いってんのか誰か教えて。

152 :デフォルトの名無しさん:2006/12/17(日) 00:23:59
君にはまだ早い

153 :デフォルトの名無しさん:2006/12/17(日) 00:28:01
今度こそ本当にJavaでデスクトップアプリ開発が流行るんですかね?

154 :デフォルトの名無しさん:2006/12/17(日) 00:31:35
流行るってかモチベーションの問題だろ
5.0で既に十分なポテンシャル持ってたのに作らなかった。
事実やる気全開のV2Cは今や非Win用2chブラウザの重鎮だし。

155 :デフォルトの名無しさん:2006/12/17(日) 00:35:59
・グループレイアウトが標準実装された
 これによってGUIコンポーネント配置が容易に(絶対座標系のレイアウトやVBなどより楽になった)

・VMの起動速度大幅アップ&VM起動前にスプラッシュ表示可能
 クライアント用途ではVM立ち上げ直しが多いから有効

リッチクライアント用途ではすでに普及してると思うが、クライアントサーバのように2層式が
まだ弱いのが今後大幅に改善されるかもしれない

たしかNetBeansでGUIコンポーネントとDBをつなげるやつ開発してたよね
JPA,JDBC4、RowSetなどでこの辺実装できるはずだけどどれ使うんだろ

postgreSQLだけRowSet動かないのもなぁ
postgreSQLはJDBCドライバすててるのかな
Oracleのように実装してもらわないと改善されない予感
OracleはOracleで基本がなってないのだが、JDBC4で強制的にLOBまわり改善されるのが面白い

156 :デフォルトの名無しさん:2006/12/17(日) 00:38:22
>>154
V2Cいいんだけど参照のこったままになるの改善してほしいな
ひとつも開いてなくてもあきメモリーがなしってひどす

157 :デフォルトの名無しさん:2006/12/17(日) 00:59:46
>>155
RowSetって使ってるとこあるの?
JDBC4.0は何故かRowSetに肩入れしてるけど
JPAとレイヤーも被ってると思うんだよなぁ

158 :デフォルトの名無しさん:2006/12/17(日) 01:08:15
>>132
あくまで提案か。
実装するにはヤバイのが多いな。
BigDecimalの演算子だが
divide使うとき、MathContextの値はどうするのだろうか。
二つのBigDecimalオブジェクトのMathContextの値が異なれば
誤差が片方のMathContextの制度を基準にして除算を
することになると思うが、そうしたくない場合には
結局BigDecimal#divide(BigDecimal, MathContext)を使うことになるんだろうな。

その辺り、どう解決するのだろうか。


159 :デフォルトの名無しさん:2006/12/17(日) 01:18:13
とはいえ、いまだに大量に要る浮動小数点を金額計算に使うやつらをとめれるのは大きいか

だってnewするの面倒だもんと聞いたときには何の冗談かと

あとしらないで1.05とか掛け算したんだけど、なんかコンパイルエラーが出るんですが、doubleにしたらエラー消えたからOKだとおもったとか

こんなのが業務プログラム経験10年とかでベテランですといってごろごろいるんだが
そのたびにぶちきれてる俺はいやなやつと思われてるっぽい

160 :デフォルトの名無しさん:2006/12/17(日) 01:20:41
その手の奴はダメ出ししまくって修正させると「さすが大先生」とか卑屈になるんだよな
正直どうにかして首に追い込めないかとか考えてしまう。

161 :デフォルトの名無しさん:2006/12/17(日) 01:23:39
javaのジェネリクスのしょぼさがなぁ。
C++のテンプレートと同じことが出来なきゃ先は無いだろ。

162 :デフォルトの名無しさん:2006/12/17(日) 01:29:11
>>160
今のところ5.0導入してから半分くらいはついていけないのを確認

5.0ではListに入れる型がわかるので結合時のエラーが減りますね!とかenum便利ですね!とかwktkしてる人もいれば
なんで5.0つかうんだよとうつろなやつもいて、非常に適正がわかりやすい

>>161
目的が違うんだからいいんじゃね?C++と同じだったら逆にぶちきれるだろ

163 :デフォルトの名無しさん:2006/12/17(日) 01:31:31
Javaにboostみたいなのが出てくるのも考えモノだな。


164 :デフォルトの名無しさん:2006/12/17(日) 01:32:22
templateが害悪だからGenericsになったわけだが。

165 :デフォルトの名無しさん:2006/12/17(日) 01:33:10
>>159
BigDecimal,BigInteger用のシンタックスシュガーが導入されれば何とかならんかね・・・
しかし・・・・丸めとかの規定ないの?仕様に。

166 :デフォルトの名無しさん:2006/12/17(日) 01:40:34
123.45B とか 999999B で型推論?精度が違う場合は警告とし、左のほうに合わせる。

167 :デフォルトの名無しさん:2006/12/17(日) 02:10:27
>>164
ジェネリクスが今の形になってるのはただ単純に互換性を保つためだけの理由からだよ。
だいたいタイプパラメーターにnew出来ないってありえねーよ。

168 :デフォルトの名無しさん:2006/12/17(日) 02:17:31
ありえるからJavaは普通に普及してるんだけど。

169 :デフォルトの名無しさん:2006/12/17(日) 02:34:32
>>167
無制限に型パラメータで new するのは C# でもできないし。

170 :デフォルトの名無しさん:2006/12/17(日) 02:37:58
防御的コピーしたい場合を考えるとコピーコンストラクタくらいは使えてもよかったかな。

171 :デフォルトの名無しさん:2006/12/17(日) 02:45:01
>>170
つ「スペルミスなんだけど、気付いた時には既に修正不能だったという逸話が有名な Cloneable」

172 :デフォルトの名無しさん:2006/12/17(日) 03:03:58
でもスペルミスが指摘されたのはβ時代。
何が遅すぎるのやら。


173 :デフォルトの名無しさん:2006/12/17(日) 03:05:23
あ、これのことね。
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=1234712




174 :デフォルトの名無しさん:2006/12/17(日) 03:25:14
>>167
互換性が大事だと一番分かっているのはC++だろw

175 :デフォルトの名無しさん:2006/12/17(日) 03:39:45
creat・・・・

176 :デフォルトの名無しさん:2006/12/17(日) 12:05:10
近い未来・・・、JavaがJavaでなくなる日が訪れる。

177 :デフォルトの名無しさん:2006/12/17(日) 12:19:03
>>139
5.0で浸透している。
やはりGenericsとアノテーションは重宝する。
JUnitもアノテーションに対応したことだし。
Generics
>>141


178 :デフォルトの名無しさん:2006/12/17(日) 17:28:19
>>156
うちのV2Cはなったことないな。
ヒープサイズの問題でないなら本スレにバグレポした方がいい。

179 :デフォルトの名無しさん:2006/12/17(日) 18:40:37
DolphinといえばSwing Application Frameworkが気になる。
ttp://developers.sun.com/learning/javaoneonline/2006/desktop/TS-3399.pdf

180 :デフォルトの名無しさん:2006/12/18(月) 00:30:49
>>155
> リッチクライアント用途ではすでに普及してると思うが、クライアントサーバのように2層式が
> まだ弱いのが今後大幅に改善されるかもしれない

あれかServlet/JSPとの連携が弱いってやつな。
たしかに俺も思った。弱いって言うか扱いにくい。
RMIでないといけないから。

StrutsやJSFがSwingと合体すれば使いやすいのだが。


181 :デフォルトの名無しさん:2006/12/18(月) 00:40:29
いや、ふつうに2層式だからクライアントとDBとの接続
RMIでもWebServiceでもいいけどそれらのもってきた値とコンポーネントとの関連付けが今は手動になっちまう

>StrutsやJSFがSwingと合体すれば使いやすいのだが。
これはありえないだろ
前2つよりSwingのほうが圧倒的に使いやすいし

182 :デフォルトの名無しさん:2006/12/18(月) 00:46:12
JSFのSwing化はJSF登場時からすでに検討課題だから。
てかSwingコンポーネントひとつひとつが<input>タグ化すればいいだけの気もする。
バリデータとコンバータがフレームワーク毎にあることのがメンドイ?

183 :デフォルトの名無しさん:2006/12/18(月) 00:52:02
各種イベントがどうしようもねぇな、WEBページベースだと

184 :デフォルトの名無しさん:2006/12/18(月) 01:19:56
>>159
> とはいえ、いまだに大量に要る浮動小数点を金額計算に使うやつらをとめれるのは大きいか
> だってnewするの面倒だもんと聞いたときには何の冗談かと

valueOf()を使えと言っておけ
と思ったが10進2進変換誤差の問題があるから new BigDecimal(String, MathContext)しかないな。

にしてもBigDecimal.valueOf(String) 欲しいモノだ。


185 :デフォルトの名無しさん:2006/12/18(月) 01:21:54
ValueOfableの出番だな

186 :デフォルトの名無しさん:2006/12/18(月) 01:23:03
>>181
> 前2つよりSwingのほうが圧倒的に使いやすいし

Swingだと、
HTMLやXSL + XMLで書かれたページと連携するのが
不便なのだが。


187 :デフォルトの名無しさん:2006/12/18(月) 01:24:17
JSF, Struts, tapestry, Seasar2 + Ajax

これをSwingと連携する方法が・・

188 :デフォルトの名無しさん:2006/12/18(月) 01:25:15
レスポンスで必要なのはXMLだけだろ。
Webフレームワーク側がXML+XSLTに移行すれば皆幸せ。

189 :デフォルトの名無しさん:2006/12/18(月) 01:53:43
>>188
そういうこと
通信自体はJAXB/JAX-WSが6からクライアントに来たことによってかなりよくなった
後はそのバインドされたコンポーネントだけ


190 :デフォルトの名無しさん:2006/12/18(月) 03:07:51
Strutsはどうでもいいけど、JSFみたいに画面遷移を管理する仕組みがSwingにも欲しい。
Visual Web Packの画面遷移エディタみたいにSwingでも画面遷移管理。

191 :デフォルトの名無しさん:2006/12/18(月) 18:16:52
さすがのJavaも98/Me非対応になったかw

192 :デフォルトの名無しさん:2006/12/18(月) 22:38:49
VRAMとかもついてけないんだろうか。
そういやMMOするのも一苦労だったな、あの頃は。

193 :デフォルトの名無しさん:2006/12/19(火) 23:55:07
>>190
このボタンをおしたら2つフレームを出して、ボタンの乗っているカードレイアウトのページを切り替えて・・・とか
そういうのもあるからページベースで考えるというのは無理がある

それに画面遷移の一元管理なんてべつにむずかしくはないだろ

194 :デフォルトの名無しさん:2006/12/20(水) 08:39:04
>>193
JSFのページ遷移でいいんだよ。
画面遷移エディタで俯瞰で見れるのが欲しい。

195 :デフォルトの名無しさん:2006/12/20(水) 20:54:04
最近思うんだがMSの.Netでいいんじゃないかと。
Java EE + ウェブコンテナ + ジャカルタ + オープンソース系の技術
これらの寄せ集めもいいが、この統一感が無い感じこれらの技術よりと
結局は同等のことが出来るMSで統一するのが一番楽に思えてきたんだよ…

若いっていいよな…

196 :デフォルトの名無しさん:2006/12/20(水) 20:57:11
>>195
今はPCサーバの能力あがったから大丈夫かもしれんが、ちょいと前まではスケーラビリティの問題がでかかったんだよね


197 :デフォルトの名無しさん:2006/12/20(水) 22:34:55
>>195
Java EEのJSF+EJB3でだいたいいけるよ。

198 :デフォルトの名無しさん:2006/12/20(水) 23:31:45
>>195氏のためにNetBeans Visual Web Packを試してみるか。

199 :デフォルトの名無しさん:2006/12/21(木) 00:21:31
>>199
JSCとほぼ同じだが、いい感じで統一感がでてると思うね。

200 :デフォルトの名無しさん:2006/12/21(木) 00:34:44
>>195
俺も昔そう感じていた時期もあったが、
バージョンアップによる互換性のなさに嫌気がして、
その世界から抜け出した。
いまでも.NETで互換性の問題が出ているようだし
判断は間違ってなかったと思ってる。
もちろん、100%PureMSの生み出すパワーは魅力的なのは否定しないがね。

201 :デフォルトの名無しさん:2006/12/21(木) 00:37:14
仕事で使うのが未だに1.4だらけな件…

202 :198:2006/12/21(木) 01:07:05
うん、画面遷移も楽そうだった。SessionBean1とか作られてるんだがTomcatだけで動いてるのが何か不安w

203 :デフォルトの名無しさん:2006/12/21(木) 07:25:51
Javaが良いのは、MSの(API解説)文章よりも
SUNの文章の方が優れていたからじゃないかと思ってる。
Java周辺(SUN/IBM周辺)の技術文章(や本)で統一感があれば
MSのサービスなんか目じゃなくなるんだろうな…

204 :デフォルトの名無しさん:2006/12/21(木) 07:29:48
技術の相互互換性の問題とバージョンアップの後方互換性の問題のようだね。
足腰が不安定なオープン形の技術よりも、長期間手厚くサポートされ最後まで存続する
技術(ソフト・サービス)はMSの方だと思う。
だけど、現状で融通が利くのは>>195の指摘する限りだ。

205 :デフォルトの名無しさん:2006/12/21(木) 09:19:40
昔は「MS」という名前を見ただけで発狂するJava使いが多かったが、冷静に語れる時代になったんだなあ。

206 :デフォルトの名無しさん:2006/12/21(木) 11:26:19
>>205
そんな奴はJava界にとっても害悪でしかないからなあ。消えてもらって結構。
思う存分Googleでもマンセーしてればいい。

207 :デフォルトの名無しさん:2006/12/21(木) 11:34:31
>>204
そうかなぁ?
MSも技術的には不安定だと思うね。
元VB使いなんだが、2.0から使ってて、バージョンアップの度に、移植に手間がかかったり、
クライアントの環境によっては動かない事があるなど、
いい思い出はない。

208 :デフォルトの名無しさん:2006/12/21(木) 11:41:42
>>205
元々MS嫌いな奴らがいて、
彼らがJavaに飛びついただけ。
単純に言語的な魅力を感じて、Java使いになった人もいるわけで。
今は後者が増えたのだろう。


209 :デフォルトの名無しさん:2006/12/21(木) 12:03:45
>>195
それが統一感がないと感じるのか。

それならJakarta を外してSun純正にすれば?

210 :デフォルトの名無しさん:2006/12/21(木) 13:45:21
色々な開発方法が利用できることが良いとみるか悪いとみるかだな。

ASP.NETは型にはまれば楽チンだが、ちょっと型から外れることを行うときは、
一から自分でお膳立てしないといけなくて面倒なこともあるよ。

211 :デフォルトの名無しさん:2006/12/21(木) 19:23:28
>>209
そういうことじゃないと思うよ。

212 :デフォルトの名無しさん:2006/12/21(木) 19:26:00
>>210
そういうのところ(ニッチ市場ともいうか)以外は全部MSになってしまうってことなんだね。
Javaの出番は結局大規模上層のところなのかなぁ

213 :デフォルトの名無しさん:2006/12/21(木) 20:17:53
>>212
どうしてそういうレスになるんだ?
日本語理解できてる?

214 :デフォルトの名無しさん:2006/12/21(木) 23:07:37
Railsの興隆とかも、結局MSが作ってきたオールインワンなプロダクトの
フリー版が出てきたよ!ってだけの意味しかないと思うんだが、
何であんなにみんな寄ってたかってあがめたてるのか謎だわ。

まぁ、Rubyの言語的に優れたところを認めるのにはやぶさかではないが。

215 :デフォルトの名無しさん:2006/12/21(木) 23:13:36
Railsの場合は宣伝パワーかねぇ。


216 :デフォルトの名無しさん:2006/12/21(木) 23:34:21
JavaDocは中々優れたツールなんだけど
皆あんまり真面目に書かないんだよな

事前条件の提示とかフェイルファストとかスレッドセーフとか
確かにSunのドキュメントは細かく書かれてて戸惑いが少ない。
驚き最小限の法則に基づけばこの姿勢は大切。

217 :デフォルトの名無しさん:2006/12/22(金) 02:31:53
Macが売れ出してWindowsあぼーんでJavaが大活躍。
そんな未来が、君には見えないのか?

218 :デフォルトの名無しさん:2006/12/22(金) 05:17:12
それをいったらRubyにも同じ未来が!
Javaは、Macでデスクトップでの可能性が見れたという部分は大有りだがな。

GPL化されたJVMをプレインストールしてPC売り出す勇気のある会社はねえんかね

219 :デフォルトの名無しさん:2006/12/22(金) 13:18:36
GPL化されてなくてもプリインストールされてるけど、なんか問題あるか?

220 :デフォルトの名無しさん:2006/12/22(金) 15:17:14
>>216
自分はちゃんとjavadocコメント入れてるよ、というかうちのチームは入れないと深夜に呼ばれて質問されても文句言えないって教わってきたからだけど。


221 :デフォルトの名無しさん:2006/12/22(金) 15:19:58
>>220
いいチームだな
ドキュメントコメントいれておけば補完時に説明出るしね
別途用意したドキュメントとは別次元

publicなメソッド等にはドキュメントコメントがないとコンパイルエラーでてもいいと思うんだ

222 :デフォルトの名無しさん:2006/12/22(金) 16:26:51
>>216
書いてるよ。Eclipseのプラグインを
使わないと真面目に書く気起きないだろうけど

223 :デフォルトの名無しさん:2006/12/22(金) 19:35:11
>>216
書いてるよ。
でも中国人の中国語が文字化けしてるよ。

224 :デフォルトの名無しさん:2006/12/22(金) 22:18:32
Sun の中の人のブログ
http://blogs.sun.com/ahe/entry/java_se_7_wish_list
で、言語拡張のリストっぽいのが出てる。
closure のリンク先見るに、>>132 よりはこっちのが新しいっぽい?

>>132 と比べると BigDecimal の四則演算が見当たらない。
代わりに C# のインデクサっぽいのが入ってたりする。

ついでに、closure の最新っぽい草案
http://www.javac.info/closures-v04.html

もひとつ ついでに、>>135 で触れてる gosling案とかを実装してみたらしい。
http://weblogs.java.net/blog/forax/archive/2006/12/call_me_santa.html

225 :デフォルトの名無しさん:2006/12/23(土) 20:35:14
型推論は個人的にちょっとまった!だな。
変数のスコープが分かりにくくなる形での推論は特に。

var型とかを用意して必ず有効な参照で
初期化しなければならないくらいのルールは欲しい。
可読性対策に問題が出るくらいなら冗長なGenericsのままのがいいす。

226 :デフォルトの名無しさん:2006/12/23(土) 20:45:53
IDEが自動補完してくれたほうがいいな。

227 :デフォルトの名無しさん:2006/12/23(土) 20:54:26
> 変数のスコープが分かりにくくなる形での推論は特に
って具体的にどーゆー事かわからん。

228 :デフォルトの名無しさん:2006/12/23(土) 21:05:19
スクリプト言語みたいに
始めてその名称が使用されたタイミングで
参照型が作られるのはアカンということ。

229 :デフォルトの名無しさん:2006/12/23(土) 21:22:49
>>224 にある奴とかは、単に変数宣言のシンタックスシュガーなだけでしょ。
スコープがわかりにくくなるんかな?

230 :デフォルトの名無しさん:2006/12/23(土) 21:29:19
メソッドの頭から眺めるなら大したことじゃないが
スタックトレースからコード追うときはイラっとくるかも

231 :デフォルトの名無しさん:2006/12/23(土) 21:59:35
スコープが混乱するのって
http://weblogs.java.net/blog/forax/archive/2006/12/call_me_santa.html
の for ループの中で algol構文のシンタックスシュガー使ってる時だけだと思うが。
後は final が付いてたり := があるから変数宣言してんのわかるし。

232 :デフォルトの名無しさん:2006/12/25(月) 18:39:39
Concurrent API便利なのに使ってる人少なすぎ

233 :デフォルトの名無しさん:2006/12/25(月) 23:23:49
>>232
話題にならないのはすでに2年以上も前の話だからだろ?

234 :デフォルトの名無しさん:2006/12/26(火) 16:42:28
マルチスレッドでプログラムしてる人が少ないんだろうな
そしてプログラムで使える人はわかってる人。

というか、次世代じゃなくて現世代だよな。

235 :デフォルトの名無しさん:2006/12/26(火) 21:00:24
Webアプリだとコンテナとフレームワークの上でガシガシ組むから基本スレッドは意識しないな。

236 :デフォルトの名無しさん:2006/12/26(火) 21:15:30
Concurrent APIとかフレームワーク作る人が使うもので
フレームワーク使う人が使うものじゃないな

237 :デフォルトの名無しさん:2006/12/26(火) 22:59:07
>>234
前世代だろ?

238 :デフォルトの名無しさん:2006/12/26(火) 23:33:19
>>235
こんな、やつがwebアプリ作るからwebアプリって全般的に品質低いんだよ。

たとえば、J2EEは、基本マルチスレッドモデルだからインスタンス変数なんか定義して
リクエストの情報を設定したりなんかすると平気で他人の状態に書き換わったりする。。

strutsみたいなフレームワークを使ってても同様↓

ActionのJavadocより引用
------
リクエストの状態に関連する情報を保持するためにインスタンス変数やスタティック変数を使用してはいけません。
インスタンス変数やスタティック変数は同一のアクションに関してリクエストをまたがってグローバルなリソースを共有したい場合に使用します。


239 :238:2006/12/26(火) 23:42:30
もっと詳しい解説があった。
とにかく、webだからスレッドなんて関係ないぜ。ってのは、よしてくれ。

http://www.atmarkit.co.jp/fjava/rensai2/webopt04/webopt04.html

240 :デフォルトの名無しさん:2006/12/27(水) 00:06:25
>>232
日本語のサンプルすくないじゃん。
サンプルがないとコードがかけないと思う。

241 :デフォルトの名無しさん:2006/12/27(水) 01:19:41
>>238
WEBアプリだと自分で明示的にスレッド作ることは
あまり無いっちゅうことじゃないの?

さすがにそのレベルの間違いをする人はそんなにいない・・・
と言いたいところだが、ちらほら見かけた。
StrutsのActionクラスとかにインスタンス変数書きまくって
「テスト通る時と通らない時があります!
 FWのバグじゃないですか?」
とかこいてて、いますぐ死ねってまじで思った。

242 :デフォルトの名無しさん:2006/12/27(水) 05:10:02
何のためにセッションやらリクエストパラメータがあるのかと小一時間>>Webアプリのへたれプログラマ


243 :デフォルトの名無しさん:2006/12/27(水) 05:17:26
>>241
いやいや、マルチスレッドなのにオブジェクトを使い回すような設計になっているのが悪いんじゃないか。
いまやオブジェクト生成・破棄のコストはそんなに重大ではないんだから、
もっと素直にプログラムできるようなモデルにすべきだった。

244 :デフォルトの名無しさん:2006/12/27(水) 08:12:03
>>243
設定でシングルスレッドモデルって言ってシングルスレッドで動作させる
ようにもできる。
その上でフレームワークを使うって言ったら結構なメモリを使うであろうことが
容易に想像できるわけだが。

245 :デフォルトの名無しさん:2006/12/27(水) 12:32:11
もうシングルスレッドモデルはねーぞ
それにインスタンスも複数使われるかもしれないし、ひとつかもしれないという自由度だったはず
Tomcatはひとつだったはずだけど

スレッドプーリングしてるんだよとか基本を教えないでこのメソッドのみで適当に作っといてとしかいわないのも悪い

246 :デフォルトの名無しさん:2006/12/27(水) 14:22:28
結構なメモリってどんな処理だ?

247 :デフォルトの名無しさん:2006/12/28(木) 08:29:24
配列のインターフェイスが欲しいな。例えばjava.lang.Array見たいな感じ。

interface Array<T>{
T get(int idx);
void set(T value, int idx);
int getLength();
Array<T> clone();
Class<? extends T> getComponentType();
}

見たいな感じ。で、

String[] hoge = new MyArray<String>();
みたいに配列として使える感じ。逆もありで、
Array<String> array = hoge;
として代入も可能。タイプパラメータがあってればいい感じ。
通常の配列もこのインターフェイスを実装済みでいいかも。



248 :デフォルトの名無しさん:2006/12/28(木) 08:31:24
>>247
言語仕様的にはできなくは無いだろうけど、JVMレベルでの互換性を
壊すから、まず入ることは無いだろうな。あと、従来の配列はcovariantだが
genericsはcovariantじゃないというのもある

249 :デフォルトの名無しさん:2006/12/28(木) 11:17:30
>>247
配列じゃないけど indexer っぽいのは >>224 の wish list に入ってたけど。

250 :デフォルトの名無しさん:2006/12/28(木) 23:45:13
>>247
ここのArray Syntax for Collectionsがあればいいんじゃない?
http://blogs.sun.com/ahe/entry/java_se_7_wish_list

251 :250:2006/12/28(木) 23:46:00
あ、249が言ってるのと同じだった。

252 :247:2006/12/29(金) 00:47:46
構文のサポートも欲しいところなんですが、
配列を抽象化できるのも魅力かなと。
でもcovariantが・・・なるほどね。。。

BigDecimalの四則演算対応も、できれば何かの特定のインターフェイスを
実装していれば対応できるというのが希望。
それって何て演算子オーバーロード?って言われそうですが・・・

253 :デフォルトの名無しさん:2006/12/29(金) 01:36:56
ArrayList<Integer> list = {12, 34, 56};
みたいな初期化ができれば、配列の抽象化にこだわる必要はまったくなくなると思う。
コレクションのための配列構文も、[]のオーバーロードみたいなもんだし。

254 :デフォルトの名無しさん:2006/12/29(金) 01:44:57
型推論っていうんだっけ?

List<Integer> list = {12,34,56};
は、コンパイルエラー?

255 :デフォルトの名無しさん:2006/12/29(金) 03:26:09
デフォルトをつけるかどうかだよね。
自分は、それはコンパイルエラーでいいと思う。

256 :デフォルトの名無しさん:2006/12/29(金) 03:28:09
要するにこんな感じのが欲しい。
http://d.hatena.ne.jp/nowokay/20061218

257 :デフォルトの名無しさん:2006/12/29(金) 10:02:43
>>253
final list = ArrayList.of(1, 2, 3);

でよくね? >>250 に載ってる
・More factory methods for colllection classes
・Shorthand syntax for declaring local variables
のあわせ技で出来ると思うんだけど。

258 :デフォルトの名無しさん:2006/12/29(金) 10:23:29
> More factory methods for colllection classes
問題は Map の factory method だよな、と思う。

259 :デフォルトの名無しさん:2006/12/29(金) 10:32:38
List<Integer> list = Arrays.asList(1, 2, 3);

260 :235:2006/12/29(金) 12:00:42
>>238
インスタンス使い回すっていうコンテナの構造上の問題は普通に意識するだろ。
マルチスレッド以前の問題だ。

Webアプリでスレッドを用いる必要があるのはデータのインポート&エクスポートぐらいだと思う。
重い処理をする間、ユーザーを待たせないっつー意味で。

261 :デフォルトの名無しさん:2006/12/30(土) 13:25:27
java.ioとnioの親和性をもうちょっと頑張って欲しいな

262 :デフォルトの名無しさん:2006/12/31(日) 02:02:39
親和性って具体的には?

263 :デフォルトの名無しさん:2006/12/31(日) 02:41:17
Channelはデコレートパターン向きじゃないからね
Buffered*StreamみたいなのBuffer版アダプタを
標準で用意してくれるだけでも嬉しい

264 :デフォルトの名無しさん:2006/12/31(日) 02:52:32
ああ、しかし、BufferedとByteBufferだと名前が似すぎて間違えるか

265 :デフォルトの名無しさん:2006/12/31(日) 10:56:51
>>263
BufferedChannel みたいなものが欲しいって事?
ByteBuffer.wrap(new byte[1]); みたいな小さい ByteBuffer 作って
ちょこまか読み書きしてないなら大して必要とも思わないけど。

ってか、java.ioとの親和性とか関係ないような。

266 :デフォルトの名無しさん:2006/12/31(日) 12:14:45
ByteBufferInputStreamとかStream側にあわせるアダプタだろ

267 :デフォルトの名無しさん:2006/12/31(日) 13:16:45
> ByteBufferInputStream
要るか?

268 :デフォルトの名無しさん:2006/12/31(日) 13:34:33
>>267
それが欲しければアプリの中で用意すれば?
ってレベルの需要だろうなぁ

269 :デフォルトの名無しさん:2006/12/31(日) 13:34:34
場面によりけり。ダイレクトバッファ使ってる場合なら欲しい。

270 :デフォルトの名無しさん:2006/12/31(日) 13:51:22
writeToメソッドみたいなのがBufferに欲しい

271 :デフォルトの名無しさん:2006/12/31(日) 14:46:16
>>269
ダイレクトバッファ使ってても、
InputStream や OutputStream のデコレータだったらアドバンテージないんじゃ?

272 :デフォルトの名無しさん:2006/12/31(日) 14:48:28
>>270
ByteBuffer#get(byte[]) とかあるけど。

273 :デフォルトの名無しさん:2006/12/31(日) 14:50:18
>>272
それを言うなら ByteBuffer#put(byte[]) じゃないかと。

274 :デフォルトの名無しさん:2006/12/31(日) 14:52:27
マップファイルを外部にゲロるのに便利そう writeTo

275 :デフォルトの名無しさん:2006/12/31(日) 14:55:19
>>271
コンポーネント単位で見ればそれもありでは?
nioのが効率はいいんだから、
最適化が必要になった時にnioにあわせていけばいい。

276 :デフォルトの名無しさん:2006/12/31(日) 14:56:41
便利に使いたいだけなら
NIOUtils.writeTo(WritableByteChannel, ByteBuffer)
みたいなユーティリティメソッドつくっときゃ良いだけのような。

277 :デフォルトの名無しさん:2006/12/31(日) 15:01:08
>>275
いや、単純に無駄だよねって話。

中途半端にやるとクラスが汚くなるだけだし。
最適化が必要になりそうならアプリ側で入出力処理を抽象化しておきゃ良いんだし。

278 :デフォルトの名無しさん:2006/12/31(日) 15:06:00
>>277
内部で Channel 使った ChannelInputStream とか ChannelOutputStream で最適化する時
read(ByteBuffer) とか write(ByteBuffer) があると便利なんだよ!

すげーアホ臭いな。そんだったら最初から Channel 使えば良いし。

279 :デフォルトの名無しさん:2006/12/31(日) 15:07:05
> NIOUtils.writeTo(WritableByteChannel, ByteBuffer)
要るか?

280 :デフォルトの名無しさん:2006/12/31(日) 15:07:07
ん?Servletにnioを適用するための記事とか普通に出回ってるが

281 :デフォルトの名無しさん:2007/01/05(金) 02:17:08
6.0でCommons Modelerを使用してPOJOを登録したんだがjconsoleのmbeanタグ
で表示されないのは既出ですか?

282 :デフォルトの名無しさん:2007/01/10(水) 21:20:03
DOMとコレクションフレームワークの親和性をあげてほしいなぁ。

283 :デフォルトの名無しさん:2007/01/11(木) 01:52:34
Closure の人(?) が面白いアイデアを書いてる。
http://gafter.blogspot.com/2007/01/methodnamesinpieces.html

なんか、javac弄って遊ぶプロジェクトらしい?
https://ksl.dev.java.net/
http://blogs.sun.com/ahe/entry/ksl_answers

>>224 の一番最後の人が property を試しに実装してみたらしい。
http://weblogs.java.net/blog/forax/archive/2007/01/a_property_prop_1.html

protperty 慎重派の人も居るらしい。
http://weblogs.java.net/blog/hansmuller/archive/2007/01/property_syntax.html

アプリ書く人と、ライブラリ(Swingコンポーネントとか)書く人の違いなんだろか?

284 :デフォルトの名無しさん:2007/01/11(木) 19:27:09
propertyってどんな機能を指してるのかよくわかんないんだけど

object.x = "hoge" を object.setX(String str)
String str = object.x を object.getX()

にmappingする機能でおk?

ObjectPascal とかだと直接フィールドを参照するか、メソッドを指定するかとか出来るけど
そーゆー事も考えられてるのかな?

フィールド指定を可能にすることで無駄なsetter,getterの記述が不要になることが
propertyを導入する最大の利点だと考えてるのでそーゆーのが考慮されてないといまいちだなぁ

285 :デフォルトの名無しさん:2007/01/11(木) 20:03:56
>>284
> propertyってどんな機能を指してるのかよくわかんないんだけど
それ自体も議論の対象っぽい。
getterやsetterの呼び出しのシンタックスシュガーだけじゃなくて
暗黙的なフィールドやgetterやsetterの宣言のシンタックスシュガーまで含んでたり。
例えば、public property int hoge; って書くと、暗黙のうちに
private int hoge;
public void setHoge(int h){ hoge = h; }
public int getHoge(){ return hoge; }
が自動生成されるとか。
java.lang.Class に getProperty みたいなメソッドを追加したいって人も居るし。
JavaBeans の場合は firePropertyChange よんだりも!ってのもあるかもしんないし。
他にも色々あるんじゃない?

>>283 で紹介されてる実装だと、property つけて宣言しないと
シンタックスシュガーでセッターゲッターにアクセスできなかったりする。

286 :デフォルトの名無しさん:2007/01/11(木) 20:22:31
> フィールド指定を可能にすることで無駄なsetter,getterの記述が不要になることが
でも、これって 5文字ぐらい節約できるってだけなんだよねぇ……

287 :デフォルトの名無しさん:2007/01/11(木) 22:05:40
>>286
いやいや違う、漏れが言いたいのは

//フィールドの定義
private int fieldX = 0;

//値をセットするときに必要な特殊処理
public void setX(int x){
 this.fieldX=x;
 this.logic();
}

//プロパティの定義でgetterはそのまま使って、setterはメソッドを使う
property int x read fieldX write setX;

イメージ的にはこんな感じ。ほぼObjectPascalなんだけどさ。
フィールドの定義は省略して、暗黙的に定義してくれるとなおよさげ。

288 :デフォルトの名無しさん:2007/01/11(木) 22:43:37
>>287
その辺は どー転ぶかわかんない。property 自体却下される可能性もあるし。
とりあえず >>283 のプロトタイプだとできない。

> property int x read fieldX write setX;
この構文だと、Java では フィールド名と同じメソッド名付けられるから
fieldX って名前のフィールドに加えてメソッドまであったらどーすんだろ、とか
setX 以外の名前が指定できると、現在既にあって setX を期待してる
フレームワークが困りそうだなぁ、と思った。

289 :デフォルトの名無しさん:2007/01/12(金) 23:43:12
http://jcp.org/en/participation/members/E
Eclipse FoundationがJCPメンバーとして参加することに
なったらしい。ちょっと前にEclipse代表のMike Milinkovichが
JSR277とJSR291の進行に激怒してたからなんかやるだろうなとは思ってたけど。
JSR291に反対票投じたRedhatも先月推進派に転じたみたいだし、さらに今度の
Eclipseの票も加えて1/16〜22にあるJSR291の投票をのりきりたいんだろうね。

290 :デフォルトの名無しさん:2007/01/16(火) 01:46:34
>>287
setXxx、getXxxっていうのをプロパティとみなす仕様は変えれないと思うよ。
IDEのプロパティエディタやらJSPのELやら、既存のツールやライブラリが使えなくなる。

291 :デフォルトの名無しさん:2007/01/16(火) 05:09:43
Java6の話はどこですればいいのかな?

292 :デフォルトの名無しさん:2007/01/16(火) 19:56:31
>>291
現世代Javaの動向 1
http://pc10.2ch.net/test/read.cgi/tech/1150286189/l50

293 :デフォルトの名無しさん:2007/01/18(木) 08:02:25
AjaxでハイブリッドP2P型を作成しようと思っているのですが、
これを作るにはJ2SE,J2EE,J2MEの内、どれが相応しいのでしょうか?
次世代Javaに詳しい方教えて下さい。

294 :デフォルトの名無しさん:2007/01/18(木) 08:06:11
mustang で普通に起動した JVM に jconsole からアタッチできるようになったという
記事を見て jconsole を使おうとしたんだけど、起動後に "JConsole: Output" っていう
ウィンドウが開いて

java.lang.UnsatisfiedLinkError: no attach in java.library.path

というエラーが表示されるし、ローカルプロセスに接続しようとしても
「接続に失敗しました」となってしまいます。

うまく JVM にアタッチするにはどうしたらいいんでしょうか?
Windows XP, JDK 1.6.0 を使っています。

295 :デフォルトの名無しさん:2007/01/18(木) 19:15:17
>>293
構成が今一良く分からない。Webサーバ+P2PでUIがブラウザなわけかい?
J2EEのServlet(Jettyあたり)を落としてきて、残りはSEでガリガリ書きなさいな。

296 :293:2007/01/19(金) 07:57:58
>>295
P2Pでコミュニティとファイル共有システムを作って、ソフトウェアで提供しようとしているので、
中継ノードでピュアP2P型にするか、中央サーバーでハイブリッドP2P型にするかのどっちかになるのですが、
それぞれJ2SE,J2EE,J2MEのうち、何が相応しいのでしょうか?
教えて下さいませ。

297 :デフォルトの名無しさん:2007/01/19(金) 10:32:49
>>296
まず、J2SE,J2EE,J2MEが何かぐらいは調べて置いたほうがいいだろ。
それとスレ違い。

298 :デフォルトの名無しさん:2007/01/19(金) 15:30:45
JDK7 build06
http://download.java.net/jdk7/changes/jdk7-b06.html
http://download.java.net/jdk7/binaries/

個人的にはまだぱっとした新機能ないなぁ

299 :デフォルトの名無しさん:2007/01/19(金) 20:33:11
Java6の役目はその機能ではなく、1.4.2を古いものとし、
Generics環境へのGOサインを導き出してくれることにある。
Java7もXML構文とか登場してまた汚れる(w)から
Java7のデビューはJava8のリリースからとなる。

300 :デフォルトの名無しさん:2007/01/19(金) 23:12:57
Genericは結構なんだけど旧形式のコレクションも@deprecatedにしないで
共存させといて問題ないと思うのだが。これのせいで1.4からの移行が進みにくい。

301 :デフォルトの名無しさん:2007/01/19(金) 23:15:09
5.1が出ないってことは、最近のJREはアーキの急遽対応がないんだな。
6は載らなかった機能が一杯あるから枝が付くとなんとなく思ってるが

302 :デフォルトの名無しさん:2007/01/20(土) 01:27:40
6はおまけっぽいのがてんこもりだからね。

303 :デフォルトの名無しさん:2007/01/20(土) 01:29:35
>>300
どういうこと?

304 :デフォルトの名無しさん:2007/01/20(土) 01:55:04
普通に「互換性あれば簡単に乗り換えれるのに」って意味じゃないの?

305 :デフォルトの名無しさん:2007/01/20(土) 02:22:19
コレクションは互換性のために残されたレガシーコレクションとはあるが
非推奨だなんて注釈もdocタグも無いはずなんだが。

306 :デフォルトの名無しさん:2007/01/20(土) 02:28:02
> 6は載らなかった機能が一杯あるから枝が付くとなんとなく思ってるが
1.5.1 とか 1.6.1 とか出さないって言ってなかったっけ?

307 :デフォルトの名無しさん:2007/01/20(土) 03:06:14
ああこれのことね。無視すればいいけど、うちは何も考えずに<Object>つけてるぞイミねぇ

注: ArrayListDemo.java の操作は、未チェックまたは安全ではありません。
注: 詳細については、-Xlint:unchecked オプションを指定して再コンパイルしてください。

308 :デフォルトの名無しさん:2007/01/20(土) 03:17:36
無視したいなら@SuppressWarnings("unchecked")でいいじゃん

309 :デフォルトの名無しさん:2007/01/20(土) 06:46:59
>>307
<?>の方がよくねぇ?

310 :デフォルトの名無しさん:2007/01/20(土) 13:18:36
例外にもジェネリクス対応して欲しいな。
型パラメータが付いたThrowableのサブクラスを作りたい。

例えば、
class IORuntimeException<IOException> extends RuntimeException{
}
のように定義して、
catch(IORuntimeException e){
throw e.getCause(); //<--IOExceptionをスロー
}
と使えると最高。

311 :デフォルトの名無しさん:2007/01/20(土) 15:38:32
RuntimeExceptionが何故IOExceptionを投げるんだ・・・

312 :デフォルトの名無しさん:2007/01/20(土) 15:49:49
IOExceptionをRuntimeExceptionでラップしたいんだろ。

313 :デフォルトの名無しさん:2007/01/20(土) 16:06:04
>>310
Closure で例外を透過的に使うために、ってんで検討はされてるけど、
>>310 みたいな気持ち悪い奴じゃない。

314 :デフォルトの名無しさん:2007/01/20(土) 16:31:14
Neal Gafter's blog
Thoughts about the future of the Java Programming Language.

ttp://gafter.blogspot.com/index.html


315 :310:2007/01/21(日) 01:49:23
キモくてスマン。
単純にチェック例外を実行時例外でラップしたいだけ。

例外にジェネリクスが使えると、色々面白そうだけど。

class Hoge<T>{
  void piyo() throws WrapperException<T>{
    ...//色々
  }

  void fuga() throws T{
    try{
      piyo();
    }cathc(ExceptionWrapper<T> e){
      throw e.getCause();
    }
  }
}

316 :デフォルトの名無しさん:2007/01/21(日) 02:15:50
> void piyo() throws WrapperException<T>
> }cathc(ExceptionWrapper<T> e){
……。

ってか、普通に考えて ExceptionWrapper<InvocationTargetException> と
ExceptionWrapper<IllegalAccessException> が実行時に同じクラスに
成り下がりそうで拙いよね……

まぁ、ある意味では「色々面白そう」だけど。

317 :デフォルトの名無しさん:2007/01/21(日) 11:26:48
>>300
問題ないはずだけど

>>308
は旧式のライブラリとの境目で使う
事実上JPAでも必須だけど

>>309
明示的にするなら<Object>のほうがいいとおもう
ただ、これを使ってる時点でGenericsの恩恵ゼロだけどね
従来のライブラリ葉変更せずに使う場合>>308を接合部分につかってラッピングするべし

318 :デフォルトの名無しさん:2007/01/23(火) 10:31:36
突然だけど将来的にSEとEEにApache FOPも追加してくれんかな?

そうすると標準ライブラリだけでXML何でもあり状態で便利なんだが。

EEは需要ありそうだが・・・

ただでさえjdk6は標準ライブラリだけで近代的なブラウザが書ける奇抜な言語だぜw


319 :デフォルトの名無しさん:2007/01/23(火) 15:43:59
安藤幸央のランダウン[32]
Java SE 6へ移行する理由と移行をとどまる5つの理由
http://www.atmarkit.co.jp/fjava/column/andoh/andoh32.html


320 :デフォルトの名無しさん:2007/01/23(火) 18:04:30
>>319
Itanium 1、2がサポートされなくなったのか。
Itanium おしまいだな。

321 :デフォルトの名無しさん:2007/01/23(火) 21:53:16
>>319
なんか、細かいミスというか認識不足が多すぎる気がするよ。
Java SE 7は、もうDolphinとは呼ばれてないはずだし。

322 :デフォルトの名無しさん:2007/01/23(火) 21:59:45
というか、JDKとJava2SE/JavaSEが混同されすぎ。

323 :デフォルトの名無しさん:2007/01/24(水) 18:06:01
>>319
正式リリースされている 6系の話題は、現行スレでお願いします。

324 :デフォルトの名無しさん:2007/01/24(水) 19:59:04
java.comがjre6を頒布するのはいつごろの予定なの?

325 :デフォルトの名無しさん:2007/02/02(金) 17:04:58
JDK7 build07
http://download.java.net/jdk7/changes/jdk7-b07.html
http://download.java.net/jdk7/binaries/

やはりまだnew featureよりバグフィックスが目立つ

326 :デフォルトの名無しさん:2007/02/02(金) 18:15:15
>>322
いまならJava SE


JDKは開発キットだからな(JREに対しての)


327 :デフォルトの名無しさん:2007/02/02(金) 18:16:33
>>319
> 1.3.1以前のバージョンはEnd of Life、サポート終了の扱いです。

なるほど。古いことは気にしなくて良いとは
気が楽だ

法務省のJavaアプリが古いJVMに
しか対応していなかった問題も解決されると願う


328 :デフォルトの名無しさん:2007/02/02(金) 19:20:14
1.4も1.4.2までいったから多少長かったけど、今からだとサポート期間短いよね
2世代前のものだから当たり前だが

329 :デフォルトの名無しさん:2007/02/03(土) 08:40:58
>>327
MOJ乙

330 :デフォルトの名無しさん:2007/02/08(木) 21:18:56
Closures for the Java Programming Language (v0.5)
ttp://www.javac.info/closures-v05.html

{int,int=>int} plus = {int x, int y => x+y};

うーん、もすこしメソッドと同じような文法にならなかったのかな・・・

331 :デフォルトの名無しさん:2007/02/09(金) 02:06:03
>>330
新しいのは
・nominal version が消えた。
・ユーザ定義のループ定義が草案入り。
ぐらいか。

より良い構文を考え付いたなら、
そっち方面の人のブログにでもコメントしとけば?

332 :デフォルトの名無しさん:2007/02/09(金) 02:06:58
>>329
MOJ?

何それ?

333 :デフォルトの名無しさん:2007/02/09(金) 09:01:30
ぐぐると一番最初にくる省庁の英語略称
そこの担当者

334 :デフォルトの名無しさん:2007/02/10(土) 14:59:27
Java++

335 :デフォルトの名無しさん:2007/02/11(日) 20:39:31
Java#

336 :デフォルトの名無しさん:2007/02/12(月) 01:18:02
=>
ってどっかで見たことあるような

337 :デフォルトの名無しさん:2007/02/12(月) 03:26:06
PerlやPHPのハッシュに使う演算子だろ。

338 :デフォルトの名無しさん:2007/02/12(月) 07:48:17
Java2.0

339 :デフォルトの名無しさん:2007/02/12(月) 13:04:01
>>338
それはもう古いぞ

340 :デフォルトの名無しさん:2007/02/12(月) 13:24:02
JavaX

341 :デフォルトの名無しさん:2007/02/12(月) 13:42:03
>>338-339
ワラタ


342 :デフォルトの名無しさん:2007/02/12(月) 14:25:37
>>340
それはjavax.rmiみたいなパッケージとして存在するし

>>338
今はJava 6 の時代だろ

343 :デフォルトの名無しさん:2007/02/12(月) 14:33:13
>>340
JBuilder Xを連想した。

344 :デフォルトの名無しさん:2007/02/12(月) 15:56:36
JavaOSX?

345 :デフォルトの名無しさん:2007/02/12(月) 17:26:37
Java Vista

346 :デフォルトの名無しさん:2007/02/12(月) 17:58:03
JavaMillenniumEdition

347 :デフォルトの名無しさん:2007/02/12(月) 18:33:41
Javaって、いつからOSになったんだ?

348 :デフォルトの名無しさん:2007/02/12(月) 18:34:34
JNodeから

349 :デフォルトの名無しさん:2007/02/12(月) 18:35:56
Japan Vistaと
Java MEみたいだ



350 :デフォルトの名無しさん:2007/02/12(月) 20:05:48
JavaMX

351 :デフォルトの名無しさん:2007/02/12(月) 21:06:04
JMXみてえじゃねえか
(Java Management Extension)

352 :デフォルトの名無しさん:2007/02/13(火) 05:36:14
Java侍

353 :デフォルトの名無しさん:2007/02/13(火) 15:41:53
ooの画面ってJavaみたいに見えるし、
実行はネイティブみたいだし、
あれはどういうテクノロジーなんでしょうか?

354 :デフォルトの名無しさん:2007/02/13(火) 23:17:23
oo?OOoか?
eclipseもOOoもネイティブな実行ファイルはただのダブルクリッカブルじゃなかった?

355 :デフォルトの名無しさん:2007/02/14(水) 01:53:19
>>353
Swingのように自前でUIコントロールを描画しているのかねぇ?(謎

356 :353:2007/02/14(水) 08:42:19
>ネイティブな実行ファイルはただのダブルクリッカブル

ダブルクリッカブルって何ですか?



OOoはクロスGUIを使ってるからモッサリなんじゃないですか???
モッサリでも良いからクロスGUI欲しいお。

357 :デフォルトの名無しさん:2007/02/14(水) 08:53:48
ググレカス

http://api.openoffice.org/docs/DevelopersGuide/ProfUNO/ProfUNO.xhtml

358 :デフォルトの名無しさん:2007/02/14(水) 10:40:15
>>357

 (><;) なんにもわかんないんです!><
 /つと ノ  
 しー-J


359 :デフォルトの名無しさん:2007/02/14(水) 13:57:37
>>356
クロスGUIつーかSwingのLnFが何やってるか知ってるか?

360 :デフォルトの名無しさん:2007/02/14(水) 14:12:15
 (><;) Swingを使った事はありますがLnFわかんないんです!
 /つと ノ  
 しー-J



361 :デフォルトの名無しさん:2007/02/14(水) 14:28:01
>>353
あれはC++だろ。



362 :デフォルトの名無しさん:2007/02/14(水) 14:28:44
>>356
普通に考えて

Double Click + able

ダブルクリック可能って意味になるだろ

363 :デフォルトの名無しさん:2007/02/14(水) 14:30:45
>>360
http://e-words.jp/w/E383ABE38383E382AFEFBC86E38395E382A3E383BCE383AB.html
http://ja.wikipedia.org/wiki/LnF

364 :353:2007/02/14(水) 14:47:38
Java2より前のSwingしか使った事無いのですが、
今のSwingってXMLのスキンとかいうやつですか?

そのUIから、実行ファイルみたいなのをキック?
それともJNIコール?

365 :デフォルトの名無しさん:2007/02/14(水) 15:03:35
>>364
言ってる意味がわからないが
勝手に言ってることを予測して答えてみる。

今のSwingは性能が良い。
スキン変更はJavaプログラムで可能。
そのためWinXPのルナスキンを利用可能。ただしこれはWin
意外のOSで使うと著作権侵害になるのでWinのとき専用。
MacのときはMacのスキンも使える。
よって見た目は綺麗。XAMLやCAMLやXULみたいな、
XMLでスキンを変えられるかどうかということについてはよく知らない。

キック? については、これも推測すると。
恐らく、Java Web Startの事を言っているのかと推測。
SwingアプリをJava Web Startに対応させるには、拡張子がjnlpという
XMLファイルを作って、そこの決められたフォーマットでSwingアプリの
main()メソッドがあるクラスへのリンクや
バージョン情報、必要なJREのバージョンなどを記述する。
すると、ブラウザ上で拡張子jnlpファイルを見つけると、まさにキックされ、
MIMEタイプを確認し、JREが入っているかどうかを確認し、バージョンチェックされ、
Java Web Startが起動し、Swingアプリのバージョンをチェックされ
Swingアプリが起動し実行される。

Java Web Startは、JNIは一切関係が無い。





366 :353:2007/02/14(水) 15:09:13
OOoのような画面をクロス環境(Win、MAC、Linux)で使いたかったらどうすれば良いのでしょうか?
で、処理部分はC++を使いたいです。

367 :デフォルトの名無しさん:2007/02/14(水) 15:10:08
Java2より前ってことはオプショナルパッケージのころか
そのときの知ってる人はもう少ないな

あの当時とはもはや別物だと思っていい

WebStartは今はデスクトップやプログラムメニューなどのショートカットに対応
つまり2回目からはブラウザの起動すら必要はない

そしてプログラムの追加と削除でもアンインストールができるようになってる
もちろん今までどおりコントロールパネルのJavaキャッシュからの削除なども出来る

368 :デフォルトの名無しさん:2007/02/14(水) 15:18:38
OooでJavaを使うのは、文書にJavaアプレットを埋めたりするくらいじゃな
かったか?

もしかしてMetalでない各プラットフォームで固有LnFにしたいってだけの
話なら、
String sysLnfClassName = UIManager.getSystemLookAndFeelClassName();
UIManager.setLookAndFeel(sysLnfClassName);


369 :353:2007/02/14(水) 15:23:15
いや、Java側から考えるのでなくて、
C++のコードがあるのですが、
GUI部分を1つ定義してWin、MAC、Linux全対応したいです。

そのときにC++側からSwing画面を開けるのかなー?、と。

370 :デフォルトの名無しさん:2007/02/14(水) 15:26:58
JNIはC++ APIもあって、データのやりとりも出来るので、
GUIをSwingで作って、エントリとなるメソッドをC++から
キックすればOK。


371 :デフォルトの名無しさん:2007/02/14(水) 15:39:37
>>364
Java2以前ってことはSwingというよりJFC?
XMLスキンは、恐らくSynthLookAndFeel
>>353
やりたいのは、NeoOfficeのやってることだな
GUI描画部分を、Javaにやらせるという

372 :353:2007/02/14(水) 15:43:18
MACでもJNIを簡単に作れますか?

373 :353:2007/02/14(水) 15:45:00
NeoOffice見ましたが、MACのみ。

クロスGUIとして使われてるわけじゃないんだ?

374 :デフォルトの名無しさん:2007/02/14(水) 16:34:17
MacOSXにおいてJavaは標準サポートされてるし、JNI関係のヘッダもツールも
ある。C++コンパイラはg++。

製品バンドル版OSXなら一緒にg++を含んだ開発環境(Xcode)メディアも付いて
くるし、無料でダウンロードも出来る。Java環境の最新バージョンは1.6.0。
antも入ってる。


375 :353:2007/02/14(水) 16:42:45
じゃ、Javaで画面作って、C++コードはg++でコンパイルすれば宵ってことかぁ。

”Java&C++”の開発効率がちょっぴり不安。

376 :デフォルトの名無しさん:2007/02/14(水) 17:04:19
>>366
Swingの勉強をする。

377 :デフォルトの名無しさん:2007/02/14(水) 17:35:14
>>375
俺はやったけど、両方わかってりゃ大した事は無かった。
つーても、やっぱc++からjavaオブジェクトを返すのにJNIEnvを使う部分があるんで、そこはちょっと効率悪いかな。
あとJNI部分のデバッグが面倒なんで、c++でロジック書いてJNIで薄くラップしてやる感じ。

java側は、ちゃんとMVCに分けて、DAOをしっかり分離してやりゃOK。
テスト用DAOに差し替えて開発して、最終的にJNIを使ったDAOでテストする。
まー規模にもよるだろうが。

378 :353:2007/02/14(水) 17:38:49
サンクツ>>377

DLLコールと比べて、さらに効率悪いのかなぁ?

出来上がったアプリはやっぱりモッサリ?

379 :デフォルトの名無しさん:2007/02/14(水) 17:51:13
次世代Javaの動向と関係ない話題は他所いってやれ。

380 :デフォルトの名無しさん:2007/02/14(水) 17:53:03
次世代Java=C++と連携

ですが、何か?

381 :デフォルトの名無しさん:2007/02/14(水) 17:54:42
ところで、次世代Javaというか有力候補のウィンドウライブラリって何?

Swingって落ち目な感じ?

382 :デフォルトの名無しさん:2007/02/14(水) 18:03:33
Swingは1.4以降実用レベルになってしまったから、
SWTとかの代替候補の立場が微妙になってるのが現状じゃね?


383 :デフォルトの名無しさん:2007/02/14(水) 18:12:19
あ、SWTが落ち目なんだ知らなかった。
知らないうちに勢力図が変わるんですね。

それと、デファクトだったEclipseがS∪∩の開発環境(何だっけ?)に負けたんでしたっけ?


384 :デフォルトの名無しさん:2007/02/14(水) 18:20:25
其処までは行ってない。
むしろ、SWTの活躍の場は、eclipseしかない、という感じ。
Netbeansは、Jackpotがどうなるか、か?

誘導
Java 高速GUI SWT 3
http://pc10.2ch.net/test/read.cgi/tech/1164877399/
Java低速GUI Swing 5
http://pc10.2ch.net/test/read.cgi/tech/1161139809/
【Java】NetBeans Part2【Sun】
http://pc10.2ch.net/test/read.cgi/tech/1154582593/

385 :デフォルトの名無しさん:2007/02/14(水) 18:27:26
オライリーだっけ
去年の勝ち組負け組みでEclipseを最初負け組みと書いて後で消したの
一番使われてるのに負け組みはおかしいといわれたそうだが

386 :デフォルトの名無しさん:2007/02/14(水) 18:41:27
ふ〜ん

じゃぁ、NetBeansとSwing使っとけば問題無いか。

Windows上だとちょっぴりモタツクだろうけど。
でも、モッサリドトネト(流行ってないくせにWinForms、WPFと2つあって最悪)よりかはましか。

387 :デフォルトの名無しさん:2007/02/14(水) 18:42:36
ごめん、もう一つ教えて。

NetBeansがEclipseをやっつけたってことは、
JBuilderとかは無用の長物?

388 :デフォルトの名無しさん:2007/02/14(水) 18:50:15
ごめん、さらにもう一つだけ教えて下さい。

以前のSwingではレイアウトマネージャのおかげで、
思ったように画面作り難かったのですが、
今のSwingはポトペタしやすいですか?

389 :デフォルトの名無しさん:2007/02/14(水) 18:59:48
>>388
NetBeans(の5以降で導入されたMatisseというデザイナ)を使うと無茶苦茶ポトペタしやすい。
と、漏れは個人的には思っている。

390 :デフォルトの名無しさん:2007/02/14(水) 19:11:20
>>380
JNI なんぞは、1.1 の頃には既にあったわけなんだが……

誘導
★お前らJavaはJNIで組もうぜ★
http://pc10.2ch.net/test/read.cgi/tech/1033795664/

391 :デフォルトの名無しさん:2007/02/14(水) 19:14:29
>>388
個人的には、GUIポトペタ(←(・∀・)イイ!!)は、Netbeans。
ロジック書き書きは、eclipse。
両方使ってるよ。
NetbeansのSubversionプラグインは使いにくいし。

392 :デフォルトの名無しさん:2007/02/14(水) 19:24:34
じゃ、Netbeans使います。
CVSはWinCVS(←もしかしてサイアク?)使ってるんで。

JNIもふつーに使われてますか?

393 :デフォルトの名無しさん:2007/02/14(水) 19:27:48
誘導
【Java】NetBeans Part2【Sun】
http://pc10.2ch.net/test/read.cgi/tech/1154582593/

394 :デフォルトの名無しさん:2007/02/14(水) 19:57:46
名前のないメソッドつくろうぜ。例えば、
public class ArrayList<E> {
  public nameless E (int index) { return get(i); }
  //その他省略
}
のように書いて
String s = list(2); //listはArrayListのインスタンス
みたいにインスタンス名(引数)の形で呼び出す。
他にも、Mapなら
public nameless E (K key);と書いて
String s = map("key0");とか、
さらに、オーバーロード可能にすれば他にも使い方ができそうだ。

395 :デフォルトの名無しさん:2007/02/14(水) 20:06:55
>>394
じゃあ標準出力はSystem("%d%d", 100, 200);でOK?

396 :デフォルトの名無しさん:2007/02/14(水) 20:18:36
関数呼び出しのときの表現を変えるのをアノテーションで定義するのはどうだろう
@Alias(value = "ltgt" , type = "literal")//自作リテラル(ここでは<>)
@Alias(value = "plus_equal" , type = "operator")//演算子オーバーロード
これで実装するなら>>394
@Alias("nameless")
ってとこか

んで、呼び出す対象のフィールドの宣言時も@AliasUsingをつける。
まぁ設計がまずいのに無理やり使わされるのもあれだしね。

397 :デフォルトの名無しさん:2007/02/14(水) 21:33:06
> それと、デファクトだったEclipseがS∪∩の開発環境(何だっけ?)に負けたんでしたっけ?


その文字を見たら昔のSunのCMを思い出した。

398 :デフォルトの名無しさん:2007/02/14(水) 21:45:16
396だけど、だめだな。
細かい仕様を定義しようとすると複雑になるし、いかに丁寧に仕組みを作っても雑に使われたら困るもんな。
よく使われるやつだけ今のString型みたいにして、アノテーションで限定解除するだけでいいか。

399 :デフォルトの名無しさん:2007/02/14(水) 22:40:43
>>394
>>396
次世代Javaの動向をヲチるスレであって、
勝手な妄想繰り広げるスレじゃないから。

400 :デフォルトの名無しさん:2007/02/14(水) 22:48:56
>>394
C# の Indexerっぽい奴なら、>>249 とか >>250 とかで既に出てるけど。

演算子オーバーロード関連なら、他にも >>283 の一番上のリンクとかもあったし。

401 :ネカマ由紀恵:2007/02/14(水) 23:05:20
Groovy でやっていることは
入れなくても良いんじゃ・・?

402 :デフォルトの名無しさん:2007/02/14(水) 23:23:43
ていうか今時中身の処理が遅いからJNIなんてのは無いな。

特殊なデバイス叩かん限りpureJavaでいける。
実行速度なんて5.0 6.0で激変したしSwingも1.3→1.4以上でまともになったし。

joy pad使うとかしかJNIの存在理由が見当たらん・・・。

ここら辺は成熟してきたからこれ以上はOpenGLドライバの成熟待ちだろ。ATIもnVidiaも最近のドライバはOpenGLが糞。

そのせいで6.0でもsun.java2d.openglプロパティが使い物にならない。

Java側はドライバの対応を待つしかないからベンダと連携とって行くって言ってるし。

俺はあまり言語仕様を動的にするのには興味ないな。
仕様が複雑化してきてるし当初の仕様ポリシーから外れてきてる気がする。

個人的には値渡しの出来る構造体が欲しいかな。
一々データクラス定義してインスタンス化するのがちょっと・・・

403 :デフォルトの名無しさん:2007/02/15(木) 00:06:36
>>402
public type Hoge{

String hoge;

int piyo;
}
見たいな感じかな。でも予約語が・・・
JavaBeanを簡単に生成できるシンタックスシュガーが欲しいね。

404 :デフォルトの名無しさん:2007/02/15(木) 00:36:38
>>402
そこで、エスケープ解析によるオブジェクトのスタック割り付けですよ。

405 :デフォルトの名無しさん:2007/02/15(木) 01:23:08
>>391
NetBeansのSubversionは動作がよくおかしくなる
というかAntとかもおかしい気がする
JDKを5.0にすると安定するから6のVMバグかも

>>392
CVSだったらNetBeans標準装備なんでそれ使えば楽

>>402
Swingは速度が目立つけど、実際は1.3で実用になるようなAPIが多数追加されて
5.0で目立つようなのが追加されていたりする

6も5.0と同じくsun.java2d.opengl使い物にならないね
JOGL自体は安定してるんだがGLJPanelのほうがイマイチなのもなおらねぇ
というかベータ時代はOpenGL有効にして動いてたような気がするのが気になる

406 :デフォルトの名無しさん:2007/02/15(木) 01:34:56
>>400
その下の奴って構文解析できるのか?
class hoge{}
class A {
 public static Object method(int arg){ return null; }
 public static int (int lh)method(int rh){ return lh + rh; }
 public static void main(String[] args){
  int hoge = 0;
  (hoge)method(10);
 }
}

とかされたら面倒なよーな気がする。

407 :デフォルトの名無しさん:2007/02/15(木) 07:18:52
>>399
昔は希望を書きまくっていた気もするが?

408 :デフォルトの名無しさん:2007/02/15(木) 08:40:38
>>402
遅いからJNIするんじゃなくて、Win用C++コードをMACに移すためにJNI検討中なんです。

CocoaとかいうやつはObjective-Cだったりして困るし。

409 :デフォルトの名無しさん:2007/02/15(木) 08:51:30
>>407
希望なら言語仕様作ってる人達に見える形でで出した方が通りやすいよ。

ksl とかあるんだし。
https://ksl.dev.java.net/

410 :デフォルトの名無しさん:2007/02/15(木) 08:56:41
>>406
int Integer = 1;
System.out.println( (Integer)+10 );

とかと同じ扱いにすりゃ良いんじゃないかと思ったけど……
参照型へのキャストは 単項+ とか 単項- ついたらいかんのか。
つまり Integer って変数が宣言されてないときに

System.out.println( (Integer)+10 );

がコンパイルエラーになるから参考にならんと。むぅ。

411 :デフォルトの名無しさん:2007/02/15(木) 17:24:26
>>399
ヲチりながら、愚痴るんじゃないの?

412 :402:2007/02/15(木) 17:43:18
>>405
リペイントマネージャ乗っ取って全コンポーネントダーティーだと認識させればユーザーの操作に応じて常にスケーラブルでアジャスタブルなウェジェット組めるが流石にまだ重いだろうなw

>ベータ時代は・・・
ttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6458746
これの応急処置だと思う。
JDialogに限らずOpenGL使ったコンポーネントが破壊される。

描画領域の破壊は-Dsun.java2d.opengl.fbobject=falseを指定すれば回避できるが・・・

FBO周り以外もバグがあるみたいでどうも-Dsun.java2d.opengl.fbobjectに関係なく-Dsun.java2d.opengl使った処理自体まずいみたい。
nVidiaのリグレッションバグなんだがOpenGL有効にしたらグラボ自体が不安定になって最悪システムクラッシュする。

グラボのドライバって既存アプリの描画に影響を与えるしな。リグレッションバグならそうそう戻す訳にはいかんだろうし。

>>408
結局JNI噛ます共有ライブラリ部分はネイティブなんだからリビルドするだろ?
てかwinのライブラリをmacで使おうって発想もな。
JNIにしたってネイティブ部分はプラットフォーム毎に用意するんだし。

J2MEはそれでカオスってるw


413 :デフォルトの名無しさん:2007/02/15(木) 18:05:37
C++のコードをJavaに移植するほうが早そうだな

414 :デフォルトの名無しさん:2007/02/15(木) 19:04:29
>>413ロジックのみならね。
Mac→WinだとMacしかないアプリのDLL使ったりして移植ゼロか、
Win→だとGUI周り以外はそうgdgdにならない?

415 :デフォルトの名無しさん:2007/02/15(木) 19:11:21
あーJ2MEはJSR118-MR2からOpenGL実装したので専用チップ要求して更にカオスw

MIDP2.1はハードウェアサポートが強化されてるしウェジェットも地味に強化(新たに取り込まれたオプションパッケージが目立つ)してSEのノウハウもフィードバックされて結構良いんだが・・・

416 :デフォルトの名無しさん:2007/02/16(金) 17:45:58
>>402
OpenGLといえばJava3Dを思い出した。
あちらも気が付けば大きな進展があるようだ。
JavaからOpenGLのライブラリを使えるようにするというやつ。
プラットフォーム非依存と呼ばれているJavaも3Dとなると
そうもいかないケースがあるものだが、
今後のJava3Dは古臭い時代遅れなビデオカードでは動かなく
なるか、(AWTのようにOS依存する)劣化表示
or
(Java2Dを使用したSwingのように)超低速表示されることになるんだろうか。


417 :デフォルトの名無しさん:2007/02/16(金) 17:48:15
>>405
> >>391
> NetBeansのSubversionは動作がよくおかしくなる
> というかAntとかもおかしい気がする
> JDKを5.0にすると安定するから6のVMバグかも

EclipseでJava SE 6でAntを使っているがとくに問題ない。
おかしいってどんなエラーがでるのかね。
Subversionは不安なら、TortoiseSVNでコミットしてみるのはどうだろう。

> >>392
> CVSだったらNetBeans標準装備なんでそれ使えば楽
Eclipseと同じだな。しかしSubversion使ったらもうCVSには戻れない。
それだけ使い勝手が良いから。


418 :デフォルトの名無しさん:2007/02/16(金) 20:23:44
そろそろ
MFCのようにSwingをラップしたGUIフレームワークが標準でJDKに入らないかな

419 :デフォルトの名無しさん:2007/02/16(金) 21:14:44
JSR 296: Swing Application Framework
http://jcp.org/en/jsr/detail?id=296

これどうなるかねぇ。


420 :デフォルトの名無しさん:2007/02/16(金) 21:17:41
>>416
JavaからOpenGL使うのはJOGL
去年1.0でたばっかりなのでこれからだと思うがOpenGL2.0がそのままラッピングされている
結果SWTのように汚いけど、これはCのコードのラップだからこれはこれでいいだろう
結果staticImportと相性がいい
まぁJOGLはSwingとは直接関係ないけど

>>417
Java6はVMがバグってるので演算結果がたまにおかしくなるというひどいバグがある
次のupdateでなおってるはずだけど最適化のバグっぽい
まぁ5.0とは別次元の速度になってるんでこんなにVMに手を入れていいのだろうかと思ったけど
予想通りVMのコアにバグいれるとは
はじめてオープンソースになった成果がこれってひどすぎ

つまりsubversionだけじゃなくてNetBeans自体が不安定になる>JDK6
それにトータスは使い物にならないよ
バージョン管理ツーつってのはIDEと統合されてナンボだから

>>418
Swingの時点でMFC以上にラッピングされてるのだが

421 :デフォルトの名無しさん:2007/02/16(金) 21:21:08
Swing Application Frameworkのプロトタイプ実装らしい。
https://appframework.dev.java.net/

見てみよっと。


422 :デフォルトの名無しさん:2007/02/16(金) 21:55:57
SwingのラッパーはGroovyやRhinoから使うの便利そうだな

423 :デフォルトの名無しさん:2007/02/16(金) 21:58:35
>>420
http://d.hatena.ne.jp/nowokay/20070113 で話題になってた
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512534 か?

J2SE 1.4.0 のときも、コードによっては 1.3.1 より遅くなって処理完了まで
2倍時間かかったり、とかあったしなぁ。個人的にはいつもの事だと思うんだけど。
ってか、JDK6 は既に現行世代だと何度言えば……

424 :デフォルトの名無しさん:2007/02/16(金) 22:20:15
>>421
SessionStorage.WindowState って最大化状態サポートせんのか? と思って
users@appframework.dev.java.net に検索かけたら
https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=129
で、最大化状態は保持してるみたい?

最大化した状態で close(exit)した場合、最大化解除した状態のサイズは持ってないって事かな?

425 :デフォルトの名無しさん:2007/02/16(金) 22:30:55
>>424
最大化解除したサイズって、どっかのメソッドで取れたっけか?

常に Frame のサイズ保存しておきながら WindowEvent おっかけて、
Frame#getExtendedState が MAXIMIZED になったら、
直前のサイズを最大化解除したサイズとして保存するとか、
Windows と他の OS で最大化する時の WindowEvent の届き方が違うので
面倒くさくて Windows だけしか対応しないとか、そんな記憶が……

426 :デフォルトの名無しさん:2007/02/16(金) 22:44:31
>>423
いつものことの上、
修正コードが手早く手にはいるようになっただけで
大助かりですよね。

うまく動かなくなるバグなんて、1.4の頃ですが
GC周り突っつけばすぐ出てきましたよ。
バグ報告しても、US SUNまで訴えても直らないバグがあったりしたもんです。
直るにしても、次のリリースまで待たなきゃ駄目だしね。

427 :デフォルトの名無しさん:2007/02/16(金) 22:55:57
とはいえ今はJDK7で自分で治せて配布できるようになったのは大きいかも

428 :デフォルトの名無しさん:2007/02/17(土) 00:06:11
>>420
んなの初めて聞いた。バグ修正もてえへんだろうなあ。

TortoiseSVNは結構良いと思うけどなあ。ファイルの移動を
するときもわざわざ右クリックでめんどいことしないといけないけどさ。

429 :デフォルトの名無しさん:2007/02/17(土) 00:10:08
>>427
直すのかなり難解だと思うが・・・。


Swingが新しくなるということは、SWTやM$のGUIよりも使い勝手がよいAPIを
作れるのだろうか。

430 :デフォルトの名無しさん:2007/02/17(土) 00:11:12
そもそも新しくなるの?


431 :デフォルトの名無しさん:2007/02/17(土) 00:18:35
NetBeansのSubversionは修正がされているかどうかがわざわざ再表示押さないと反映されないのがカス
コミットする前に最新状態取得しないとだめってあふぉか

CVSクライアントのほうは問題なし

というかSubversionはCVSのように自前で実装してないからなぁ
CVSモジュールに依存してるし

NetBeans3.6だったかあの時代のCVSサポート並のへっぽこさ
だから標準実装されてないのだろうね

432 :デフォルトの名無しさん:2007/02/17(土) 01:02:26
>>424
> で、最大化状態は保持してるみたい?
保持してないんじゃね?単に最大化したbounds持ってるだけで。

ってか、WindowStateだしな。getExtendedState使えるのFrameだし……

433 :デフォルトの名無しさん:2007/02/17(土) 02:32:28
>>431
SVNはCVSにそんなに依存していたっけか。



434 :デフォルトの名無しさん:2007/02/17(土) 08:40:54
>>433
NetBeansのsubversionモジュールはCVSモジュールに依存している

435 :デフォルトの名無しさん:2007/02/17(土) 19:04:07
SE 6てOSSにしてからコードの提供あったの?
6で異常な進化遂げてるし、ないならないでただのコミニュティー潰しにしか見えん。

あの超進化マジックは何?
ヒープの割当・インクリメンタルGCのアルゴリズム変更だけであそこまで変わるとは思えん。

#まあ日本じゃ未だに1.4.2主流だしse7も迷走中だけど。
そろそろstaxとrhinoが使われだしても良いと思うんだ・・・

436 :デフォルトの名無しさん:2007/02/17(土) 19:13:41
>>434
なんだ、そういうことか。
CVS嫌いなSubversion開発者は自分のSVN開発を批判する者に
対してかなり起こっていたからな。
「すでにCVSがあるのに、なんで独自に開発するんだ?」と質問された
ことについてもう反論していた気がする。

437 :デフォルトの名無しさん:2007/02/17(土) 20:01:54
>>435
インクリメンタルGCの変化あったの?
5.0のときにトレインアルゴリズムつかわなくなってコンカレントGCになったけど
またかわったの?

速度は強度の最適化がクライアントVMでかかってるのがわかる。
演算系でサーバーVMとほぼ同じ速度が出たのはわらえた。
だからサーバーVM同梱してないのだなと。

438 :デフォルトの名無しさん:2007/02/18(日) 18:07:24
レジスタ割付アルゴリズムが Linear Scan Register Allocation
とかいうものに変更されたとは聞いているが、そんなに効果があったのかー

Linear Scan Register Allocation
http://www.research.ibm.com/jalapeno/papers/toplas99.pdf

439 :デフォルトの名無しさん:2007/02/18(日) 19:25:03
従来のバイナリをいじらずおおむね2、30%速度向上してるんだよね

440 :デフォルトの名無しさん:2007/02/19(月) 12:35:31
そろそろABAPみたいにSQLをネイティブに書けるようになると思うんだ。

441 :デフォルトの名無しさん:2007/02/19(月) 12:59:36
>>437
インクリメンタルGCが、コンカレントGCに置き換えられたのは6からじゃなかったっけ?
5の段階では、Xinc使うなって言われてて・・・・
何か自信ないけど、パフォーマンスアップは、GCだけじゃないってのは賛成。

むしろ、Hotspot系だと思うな。
エスケープ分析効いてないかな?

というか、JDK7で盛り込むJVMの改良ってどっかで話題になってる?
JVMの機能強化ってJCPに乗らないと思うし・・・

442 :デフォルトの名無しさん:2007/02/19(月) 13:03:38
5.0からだよ、コンカレントGCにかわったのは

1.4.1だったかあたりからインクリメンタルGCは採用する価値のないものだったからいい変更だと思ったけどね
トレインアルゴリズムを使いたかったらXXオプションで指定すれば5.0でも使えた

GCの性能アップだけじゃパフォーマンスが落ちるのを防ぐだけであって性能は上がらないからGC以外が主なパワーアップだろう
6でのGCチェックはまだしてないけど、5.0でGCが10、20%性能上がってたのは有名かと

443 :デフォルトの名無しさん:2007/02/20(火) 19:28:14
Lucidaフォントに日本語を追加する事ってできるの

444 :デフォルトの名無しさん:2007/02/21(水) 15:02:25
可能だけど莫大な金と人材と時間と日本語を熟知したフォントデザイナが必要だからsunだけじゃ不可能。

フォントならIPAフォントが抱き合わせライセンスじゃなかったら最強だと思うんだけどな。

所でJavaってGCが勝手にメモリガリガリやってるから
メモリの断片化をプログラマで制御出来ないよな?

長期間不眠不休なサーバーとかメモリ空間少ないJ2MEが辛いと思うんだけど、
今後ここら辺の解決策はないの?
緩和でも・・・J2MEのプリベリファイは良い案だったと思うんだ。

#そういやse6でもプリベリファイ採用してるからそれが実行速度に献上してるかもな。
今思い出したw

445 :デフォルトの名無しさん:2007/02/21(水) 16:32:00
>>444
System.GCしか今のところコントロールする方法はない。
あとはVMの実行時パラメータでヒープやアルゴリズムの調整でカバー。

ただ、System.GCはほとんどの実装でFullGC動くので実質使っちゃダメ。
System.newGCとかがあればかなり変わるんだろうけど。

ゲームとかにしろ常にシビアなタイミングがあるわけじゃなくて、今は100μsも遅れるとまずいけど
このタイミングなら10msは大丈夫とかあるからね。
1フレームに1回殿堂入りさせない新世代GCが指定できればそれでおけ。

どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。

446 :デフォルトの名無しさん:2007/02/21(水) 17:33:20
> 所でJavaってGCが勝手にメモリガリガリやってるから
> メモリの断片化をプログラマで制御出来ないよな?
↑出来る処理系ってあるの?

447 :デフォルトの名無しさん:2007/02/21(水) 17:47:52
>>446
C/C++だとメモリ管理は自分でするから確保も解放も
自分のタイミングで出来るって程度の意味だ。

勝手なタイミングでガンガンGCされるより断片化起こらないよねって話な。


448 :デフォルトの名無しさん:2007/02/21(水) 18:01:42
>>447
それはおかしい
断片化と解放とは別の話だろ
それにC++だってアロケートしなおししないと同じだし

JavaのGCはそのタイミングをコントロールできないという点だけが問題

449 :デフォルトの名無しさん:2007/02/21(水) 20:44:23
>>445
-XX:+ExplicitGCInvokesConcurrent
で、Java6なら完全停止は回避できる、のかな?
ttp://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/cms-6.html

450 :デフォルトの名無しさん:2007/02/21(水) 23:45:23
>>448
mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に
placed newでオブジェクト作れば、制御できると思う。
制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。


451 :デフォルトの名無しさん:2007/02/21(水) 23:50:06
>>444
GC でコンパクションが発生するのに断片化って???

452 :デフォルトの名無しさん:2007/02/21(水) 23:53:01
なんか、全然次世代じゃない話で盛り上がってるな。

453 :デフォルトの名無しさん:2007/02/21(水) 23:57:03
>>452
いつもの事だ。

454 :デフォルトの名無しさん:2007/02/22(木) 00:01:05
>>445
> >>444
> System.GCしか今のところコントロールする方法はない。

java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。


455 :デフォルトの名無しさん:2007/02/22(木) 00:02:05
>>445
> >>444
> どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
> 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。

彼らがJavaを作った目的は家電制御なんだけどな。
彼らはサーバを発電所のように使うものを想定している。


456 :デフォルトの名無しさん:2007/02/22(木) 00:04:13
>>446
Bufferインタフェースを使って
巨大な配列を確保すれば
擬似的に管理できないこともないぞw

C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。
Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw

457 :デフォルトの名無しさん:2007/02/22(木) 00:05:52
java.lang.refでオブジェクトの「到達可能性」をコントロールできる
香具師はいないのね

458 :デフォルトの名無しさん:2007/02/22(木) 00:14:10
>>457
そりゃ、居ないだろ。

あれは到達可能でなくなった事を知るためのもので、
到達可能でなくす事を可能にしてくれるわけじゃない。

459 :デフォルトの名無しさん:2007/02/22(木) 01:27:33
>>454
それ定期的に出てくるけどぜんぜんコントロールできねーよ

460 :デフォルトの名無しさん:2007/02/22(木) 13:56:01
いつの世代でもGCは永遠の謎なのだ。

461 :デフォルトの名無しさん:2007/02/22(木) 21:22:26
GCなしの方がよかったかもな〜

462 :デフォルトの名無しさん:2007/02/23(金) 00:09:49
GCなしなんていまさらありえんだろ

463 :デフォルトの名無しさん:2007/02/23(金) 00:26:43
C++に逆戻りか?

464 :デフォルトの名無しさん:2007/02/23(金) 00:27:32
C++0xの使用をみたが、期待はずれだった。

あんな仕様では当分Javaには勝てないことがわかった。

D言語やC#のほうが全然魅力的だった。




465 :デフォルトの名無しさん:2007/02/23(金) 00:31:08
もう使用されているとは

466 :デフォルトの名無しさん:2007/02/23(金) 01:51:35
なんで、C++はそんなに使用を拡張していくんだろうねぇ…。今でも十分じゃん。

467 :デフォルトの名無しさん:2007/02/23(金) 01:57:48
そうだよな。

チンコの仕様に優れていても、使用に優れてない奴とかいるし。

468 :デフォルトの名無しさん:2007/02/23(金) 02:01:08
チョンの仕様かと思ったw

チョンのチンコの仕様は9cmで世界一ミクロ

469 :デフォルトの名無しさん:2007/02/23(金) 02:06:38
仕様も使用もダメな例だな

470 :デフォルトの名無しさん:2007/02/23(金) 04:24:39
JDK7 build08
http://download.java.net/jdk7/changes/jdk7-b08.html
http://download.java.net/jdk7/binaries/

サマリが何も出来ていない
変わってないのかっ
と疑問も持ちつつUpdateする俺でした

471 :デフォルトの名無しさん:2007/02/23(金) 05:02:19
マネージド○○って完全にわすry

472 :デフォルトの名無しさん:2007/02/23(金) 06:35:41
CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
最近標準化連中は仕様作り過ぎw
C++のexportみたいにry

コンパイル→テスト→ビルドの流れが全てプログラミング出来ます!
みたいにさ。

マジレスするとunsignedが欲しい。

static final unsigned byte の範囲の定数が欲しいのにって度々思う

#Java書いてるとshortの存在を忘れてint使っちゃう俺

473 :デフォルトの名無しさん:2007/02/23(金) 07:56:31
>>472
>static final unsigned byte の範囲の定数が欲しいのにって度々思う
short や int じゃだめってこと?
ケータイJavaかなんかかな。

474 :デフォルトの名無しさん:2007/02/23(金) 08:57:09
マイナス、負の値を使えばいい。

475 :デフォルトの名無しさん:2007/02/23(金) 10:10:27
>>473
そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
ビット操作中心なんで負数は使えんし、
そもそもMEで使わんディスクスペースとヒープを確保する余裕はない!

そもそもstatic finalなフィールドすら宣言する余裕なんて無いんだよ。

文字列定数の長さを気にする様な世界だ。
ややこしい・・・

476 :デフォルトの名無しさん:2007/02/23(金) 11:16:49
>丁度0-128を使う

嫌がらせだなw

477 :デフォルトの名無しさん:2007/02/23(金) 11:19:44
>>475
ビット操作でも負数は使えるはずだが

478 :デフォルトの名無しさん:2007/02/23(金) 12:33:58
まあ、負数使いたくないのは個人的理由でもあるw

どうせ作ってたらサイズでかくなって定数をプリプロセッサやエディタの置換なんかで
マジックナンバーに展開して定数フィールド排除、
クラス名・メソッド名・フィールド名・インターフェイス名何かをAとかBとかにして長さ短くしてそもそもOOP何か無視して設計して
昔はそれでもダメなんでバイナリエディタで無駄なバイトコード手作業で最適化してサイズ落としたよ。
(まあ、今は難読化だけで間に合うが)

そんなんでshortとかintとかlongなんて無駄に使ってられませんw
少数も勿論固定少数点数ですw

XML1.0とXML in Namespace 仕様フルサポートしたライブラリ書いてjarサイズが50K台じゃでか過ぎるって世界だぜ・・・orz
一般的にはCLDC用のXMLパーサって10K台だよ。

#つくづく趣味グラマで良かったと思うこの頃。
よくopera mini何て出来たもんだ


479 :デフォルトの名無しさん:2007/02/23(金) 13:38:05
>>472
> CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
> 最近標準化連中は仕様作り過ぎw
> C++のexportみたいにry
> コンパイル→テスト→ビルドの流れが全てプログラミング出来ます!
> みたいにさ。
> マジレスするとunsignedが欲しい。
> static final unsigned byte の範囲の定数が欲しいのにって度々思う
> #Java書いてるとshortの存在を忘れてint使っちゃう俺

ラッパークラス作れ

480 :デフォルトの名無しさん:2007/02/23(金) 13:54:21
>>475
> >>473
> そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。

今はJ2MEではなくJava ME。


つうか、もうそろそろ、スペック問題解決してもいいのでは。

昔と比べ、容量は10倍以上になったんじゃないのか?

S!アプリももう何年か前から1MBアプリを作れるようになったし
iアプリも903iからDoja5.0になって1MBにもなったし、今やダウンロード、スクラッチパッドの境界が
無くなって外部メモリも使えるようになって1MB以上のアプリも作れるようになったろ。


昔の10kB時代と比べたら全然気にしなくても良いようになってきたんではないのか?

481 :デフォルトの名無しさん:2007/02/23(金) 13:55:32
>>476
0-127に加えて-1か128を128替わり使えばいいのではと

482 :デフォルトの名無しさん:2007/02/23(金) 13:56:13
>>478
とりあえず新たにデータ型作るってのはどうよ

483 :デフォルトの名無しさん:2007/02/23(金) 13:57:12
>>478
jarsで圧縮率を上げればjarサイズが半分になるぜ

484 :デフォルトの名無しさん:2007/02/23(金) 21:57:02
static final は普通に、コンパイラでインライン展開することが
言語仕様で決まってなかったっけ。

485 :デフォルトの名無しさん:2007/02/23(金) 22:04:07
今のJava MEではGenericsやアノテーションは
使えるのか?

486 :デフォルトの名無しさん:2007/02/23(金) 22:05:35
>>484
決まってない。final で修飾されて、確実に定数式で初期化される変数だけ。

それに、ME とかの場合は static final な変数自体も節約したいんでしょ。

487 :デフォルトの名無しさん:2007/02/24(土) 03:48:32
>>845
使えない。VM仕様がJITがオプション扱いでブートストラップクラスローダしかない1.4か1.3時代程度だったとオモ。

けどジェネリックスなんて使うケースないと思う。
MEじゃあるべき処理を平気でとっぱらうからアルゴリズムの使い回しとか不要。
他にも汎用データクラス作るんじゃなくて一つのクラスに全てのデータと処理をぶち込むからジェネリックスの立場がない・・・。

インターフェイスすら排除する世界だぜw


ところでこんなリスト見つけた。VM仕様関連の情報らしい。
ttp://www.ingrid.org/java/vm/

488 :デフォルトの名無しさん:2007/02/24(土) 12:23:48
>>487
ジェネリクスはコレクションを手軽に扱うためだけとおもっても十分な効果が出るよ

489 :デフォルトの名無しさん:2007/02/24(土) 12:59:51
Java SE 5になってから大分高速化したのに携帯電話には
まだ搭載できないでいるのか・・・

しかもまたまた1.3レベルとは。assertも使えぬのか。

アノテーションくらいはつかえたほうがいいとは思うのだが。
コンパイル時には無視できるタイプのアノテーションはとくにあったほうが便利だろう?

それに、いくつかクラスやメソッドが増えているし。
制約上全部は使えないとは思うけど、利便性を考えると、1.3レベルってつらそう。



490 :デフォルトの名無しさん:2007/02/24(土) 13:32:37
>>487
> ttp://www.ingrid.org/java/vm/
古いね。デッドリンク多いし。

491 :デフォルトの名無しさん:2007/02/24(土) 15:42:08
>>489
高速化したのはSunのJava SE 5の実装で、Javaっていう規格じゃないだろ。
ケータイって、SunのJVMが主流なの?

492 :デフォルトの名無しさん:2007/02/24(土) 17:23:16
>>488
コレクションFWないよ?レガシーしか。
java.util.*はDataとCalenderが端末依存でGMTすら禄に扱えない。
端末毎に返ってくる値が違う事があるし端末の時計とは
別にVMが時計持ってて端末と時間違うし時計アプリなんて信頼できんよ?
UTCなんてない。

これでもちゃんとした仕様の範囲だから困りもんだ。

>>491
主流はアプレックスのJBlend。
一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装+JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。

KDDIとかSBM専用のオプションパッケージの実体はcom.jblend.*パッケージが主でリンク用のスタブクラスとJavaDocをCPに公開してるだけ。

最近のSEの仕様の恩恵が受けられないのが保守性が悪い悪い・・・
ドコモキャリア仕様の端末以外例外投げると問答無用でVM落とすしエラー出力ないから酷い酷い・・・

クラスローダーがブートストラップのしかないんで動的リンクできんしJarサイズがデカクなるって言うんで汎用のFWは作れんから
再開発部分が多いだろうねぇ。

プリベリファイがSEに取り込まれたんだからMEに何かくれよw

493 :デフォルトの名無しさん:2007/02/24(土) 17:52:22
>>492
CLDC 1.1 なら java.util.TimeZone が GMT をサポートするのは義務じゃなかったっけ?
TimeZone は GMT をサポートするけど、それを使っても
GMT な時間が返ってくるとは限らないってオチはあるかもなー、とか思った。

そーいや、JSR-310 で Date and Time API ってのがあったような。
あれって、JDK7 の contents だっけか?

494 :デフォルトの名無しさん:2007/02/24(土) 18:28:20
>>492
System.currentTimeMills()の値を引数にして
DateやCalenderを作っても正確にならない?

495 :デフォルトの名無しさん:2007/02/24(土) 18:31:30
>>492
> >>491
> 主流はアプレックスのJBlend。
> 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装+JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。

遅いとかではなく、かれらがハードウェアリソースをケチっているだけだと
いってみたかったりする。
携帯電話をもう少し大型化して、JVMの部分を物理的に大きく専有するようにして、電池も
巨大化させれば携帯電話でも十分早くなるはずだ、と言ってみる。

ハードディスク搭載、とバッテリ寿命さえ延びれば、さらにその理屈もとおるはずだ、と言ってみる。

そして、連中は、独自実装で市場を独占したいだけに過ぎないのだ、
かつてのSonyがやってたような、独自製品で覆い尽くし、ライバル製品との
互換性をわざと奪うために標準Java実装から逃げているだけなのだ、と言ってみせる。


496 :デフォルトの名無しさん:2007/02/24(土) 19:48:51
>>492
いやVectorとかでいいんだよ
それでも十分使い勝手がいい

中に何を格納するべきなのかをドキュメントに書かないとわからないってのは面倒だったりする

そういやJavaME用HotspotVMを開発したとかどっかのニュースみたな
携帯の用途だとhotspotよりはアーカイブ単位での丸ごとコンパイルのほうがよさそうだが

497 :デフォルトの名無しさん:2007/02/24(土) 20:10:36
>>489
IBMのJavaME向けコンパイラ/オプティマイザみたいな商用系使ってると
かなりのレベルまでstaticメソッドのインライン展開するし、
アサーションってMEの言語仕様で定めなくてもいいかなって気がするんだよね。
それよりも言語仕様のほうはシンプルにしてアプリケーションプログラマ
のほうで適切にアサーションのutilクラスを書いた方が全体としてシンプルで融通効くと思う。

というかコンパイル時にstaticメソッドのインライン展開なくても
>static final boolean DEBUG = false;
>public void assert(...){
> if(DEBUG){
> System.err.println(...);
> ...
> }
>}
みたいなコードが書けるように1.3でも言語仕様上ifブロックでの到達不能性チェックに
例外が設けられていて、かつ実装系の方でもSunとかIBMとか大体のコンパイラは
DEBUG=falseのときこの部分ごっそり削除してくれるし。

498 :497:2007/02/24(土) 20:36:05
アサーションだから
>static final boolean DEBUG = false;
>public void assert(boolean flag, ...){
> if(DEBUG){
> if(!flag){
> ...
> }
> }
>}
みたいな感じか。細かいことだけど。

499 :デフォルトの名無しさん:2007/02/24(土) 20:52:52
なるほどー。
今ならAspectJでもっと効率よくできるかな?

500 :デフォルトの名無しさん:2007/02/24(土) 22:31:51
>>493
確か仕様上はGMTサポートしろゴルァだけどオチは

>GMT な時間が返ってくるとは限らないってオチはあるかもなー
だったかと・・・

>>495
仕様上は130K程度の不揮発性メモリ(KVM用)と30K程度の揮発性メモリ(コンフィグレーションライブラリロード用)
と16/32bit CPU及び何らかの方法でのネットワーク接続方法。

結局はプロファイルとオプションのライブラリロードが居るんでSUNは160~500K程度のメモリ(揮発・不揮発問わず)を想定してるんだけど。

が仕様上の要求だけどねぇ。携帯電話はそれでもリソースケチるからな・・・。

>>496
いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。

ホットスポットVMなら仕様上はCDC HIとCLDC Hotspotて感じのが一応ある。
CDC用はネフロのVMが実装してたな。

>>497
良いねそれ。eclipseのjavacで試してみよう。


まあ、MEも仕様上はEcmaScript並みに互換性あるけどベンダーの実装が変な事やってんだよね。
MS VMとネスケVMとSUN VMで互換性が無かった時代のように
(厳密にはMS VMがネスケVMとSUN VMに互換性なかったんだけど。ライブラリのサポートも屑だったし)

学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。

501 :497:2007/02/24(土) 22:46:46
>>500
IBMがつくったコンパイラは例えば

1. VisualAge for Java
2. j9c(後期型は4と同等) + jxelink
3. IBM JDKのjavac
4. Eclipse/JDT(ecj.jar)
5. jikes

が挙げられる。497でstaticメソッドの展開が...って言ったのは
1のjxelink。厳密にはポストプロセッサ。

>良いねそれ。eclipseのjavacで試してみよう。

これが4のことを言っているのなら、1のjxelinkとは別物だよ。

502 :デフォルトの名無しさん:2007/02/24(土) 23:54:51
>>500
もうさ、メガアプリ限定にしてしまえばいいよ。
俺たちが作りたいソフトはこういうものだから、
ハードウェアをもっと強化しろ!

とハード屋に圧力をかけてさ。

マイクロソフトみたいに力がないと
Vistaみたいな激重Windowsを開発してハードウェア屋が
それに追従するってこと難しいかな。

今はハード基準で携帯電話開発を強いられているみたいだけど、
ソフト屋からハード屋になんとかして圧力かけられないかねえ。

「お前らハード屋がだらしないから携帯電話開発がしづらいんだ!
ハードのスペックを高めることを要求する!」
みたいにさ



503 :デフォルトの名無しさん:2007/02/24(土) 23:58:12
>>500
> >>496
> いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。

java.nio.Bufferを実装したクラスを配列代わりに扱えば高速化するのでは?
と思ったら、あれJ2SE1.4からのものだった。


> >>497
> 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。

SoftBankもまともじゃないし、KDDIもまともじゃないし、Docomoもどいつもこいつも
独占欲だけは高いからねえ。

ハードウェア重視でソフトウェアをなめてかかっているところが、だらしないよ。
日本の有名な大手家電メーカーがインターネット産業ろくに力を注がず、Web2.0に
乗り遅れたことをも証明しているし。



504 :デフォルトの名無しさん:2007/02/25(日) 00:04:27
>>502
とは言え、行き過ぎると Vista や PS3 の二の舞になると思うよ。

505 :デフォルトの名無しさん:2007/02/25(日) 00:42:46
国内だとキャリア(←こいつが一番無関係w)、世界的にはハード屋が頂点か。
どちらにしてもオープン標準のJava仕様がないがしろにされてるな。

まあ、ソフト屋ですら飼いならされてる現状じゃ仕方ないか。
仕様の地位をもっとこうW3C勧告の仕様並みに出来んかねぇ?(IEの糞実装さえなくなれば平和だからなアッチは)

ハードの方は十分にパワフルだと思うけどな・・・
翌々考えたら昔はメモリ以外今の携帯以下のハードと糞OSでJavaが動いてたんだから。
win95よりce5のが安定してるしw
国内携帯は無駄な機能に溢れ返ってるからそれにシステムリソースとコストと
開発期間が圧迫されて一ソフトウェアどころじゃないだろうな。
またしても仕様の地位不足か・・・

SUNの苦労体質全部をJavaが担ってる気がするw


506 :デフォルトの名無しさん:2007/02/25(日) 01:02:42
>>505
パワフルな割には容量が足りないってどういう事なんだろうなあと思うよ。
メモリもっと増やすべき。でないととてもパワフルじゃないな。

現実問題として電力消費が激しいと言う問題があるそうだ。

しかし省エネ型DRAMのようなメモリがもっと普及すれば解決できるんだとか。

つうか、携帯電話会社は、余計な機能にエネルギーを無駄に費やさず
Javaの部分にエネルギーを費やして欲しいな。
あらゆる機能をJavaを中心に動かせるようにすれば水平ポータビリティを
維持できるし、どの携帯電話でも同じように動くアプリを簡単に作れるようになる。



507 :デフォルトの名無しさん:2007/02/25(日) 01:23:02
KDDIがBREWで水平ポータビリィティやろうとしてソフト屋・消費者から大ブーイング受けた結果
建前上JBlend on BREW(サービス名オープンアプリ/どこがオープン何だと小一時間・・・)のっけましたが?

Javaで水平ポータビリティ実現すればsunの当初の目的が実現するな。
その為にはベンダーに協力してもらわんとダメだが。

その前に日本の携帯ビジネスモデルを破壊しないと受け入れられないだろう。
4G携帯なんて出したらドコモが死守してソフトバンクが
嘘ばら蒔いてイーモバとウィルが歓迎するんだろうな。
KDDIはBREW動いて音楽と動画DL出来れば何でも良さそうだが。

ネイティブ開発は個人には不可能か敷居高いだろうしJava(MIDP)流行らんもんかね


508 :デフォルトの名無しさん:2007/02/25(日) 01:38:36
つかネイティブ開発はCPの審査がウザイよ。
審査に金かかるわ時間もかかるわ。


509 :デフォルトの名無しさん:2007/02/25(日) 06:56:24
今のケータイでJavaをやろうとすること自体が間違いなことに気づけ。

510 :デフォルトの名無しさん:2007/02/25(日) 07:12:43
て事は昔の、今の携帯以下のスペックで動かしてたJava自体間違いだったって事か

511 :デフォルトの名無しさん:2007/02/25(日) 10:59:44
Javaで何をするかが問題。
今の技術では、携帯に望みすぎ。


512 :デフォルトの名無しさん:2007/02/25(日) 12:55:29
>>509
燃料電池またはHDDが搭載されるもしくは
PDAなどもっと大型の携帯端末なら、
Javaをやる価値は少しはあるのではないかと言ってみる。


携帯キャリアメーカーもJavaに自分たちの収入源を
奪われるのを恐れて、わざとJavaの機能を制限して
Write Once, Run Anywhereの妨害をしているとおもうけどな。
彼らの、Javaの普及を妨害するやり方はつくづく陰湿だと思う。


513 :デフォルトの名無しさん:2007/02/25(日) 13:37:18
>>510
CPUのクロックだけで比べても意味がないぞ

514 :デフォルトの名無しさん:2007/02/25(日) 21:46:09
まあ、VMはハードウェアとOSを仮想化してるから下にパワーが無いとVMも非力になるな。



515 :デフォルトの名無しさん:2007/02/25(日) 22:17:51
>>510
すごく間違いだと思うなあ。Java熱に浮かされてただけじゃないかな。

516 :デフォルトの名無しさん:2007/02/26(月) 03:24:52
>>510
今に間違いじゃない日が来るって
おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
5年前に予想してたか?
>>512
わざとっていうか、自由はセキュリティリスクを持っているからな。
徐々に拡大してけばいいだろう
何でも出来る穴だらけの何かがデファクトになるのが怖いよ

517 :デフォルトの名無しさん:2007/02/26(月) 04:23:39
>>516
>今に間違いじゃない日が来るって
それって、今は間違いってことじゃん。
間違いじゃない日がきてから実用化すればいいのに。
なんでJava以外の選択肢を考えないのかね。
Collectionも使えないなんて、そんなんJavaじゃねーよ。
道具は適材適所。そこまでしてJavaにこだわるのが分からん。


518 :デフォルトの名無しさん:2007/02/26(月) 06:53:19
*7の頃から追っかけてるがあの頃の方が見向きもされなかったぞ。
それどころかボロクソに言われてた

昔はAWTすら使いもんにならなかった気がする。もっとスリムだったし。

519 :デフォルトの名無しさん:2007/02/26(月) 08:18:20
Avalon・Quartz・Cairoて出そろったのになんでJavaだけJava2Dなんだよ。

新型レンダラまだー?

520 :デフォルトの名無しさん:2007/02/26(月) 09:07:33
JOGLがあるよ。

521 :デフォルトの名無しさん:2007/02/26(月) 10:50:29
3DはJOGLが1.0になったので使い物になった
ただ、フルスクリーン時にGLCanvasが描画されないプラットフォームがあるとかが気になる
GLJPanelは遅くてゲームなどでは実用にならないし

あと日本語ドキュメントが皆無なのがきついな
OpenGL部分はどうでもなるがそこ以外が追うのがきつい

JOGLがコアAPIになればJOGL自体の機能も充実してくると思われ

522 :デフォルトの名無しさん:2007/02/26(月) 16:20:42
JOGLのコア化ってありえるか?
あるとしたら現行Java2Dのハードウェア支援コードとの統合くらいじゃない?

どちらにせよいつの時代もOpenGLはデスクトップ向けVGAのドライバ対応が中途半端だからな。
ワークステーション向けは知らんが。


523 :デフォルトの名無しさん:2007/02/26(月) 16:59:41
>>516
> >>510
> 今に間違いじゃない日が来るって
> おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
> 5年前に予想してたか?
> >>512
> わざとっていうか、自由はセキュリティリスクを持っているからな。
> 徐々に拡大してけばいいだろう
> 何でも出来る穴だらけの何かがデファクトになるのが怖いよ

多重継承も演算子オーバーロードも何でもできますよとPRする
C++言語仕様じゃあるまいし。それはちょっと違うだろう。

Javaでできることはいっぱいあるのに、あえて彼らがそれをやらないのは
彼らが己の既得権益が破壊されるのを恐れているから。
日本企業はハードウェアに強い企業は多いけどソフトウェアには弱い
企業ばかりだからね。ソフト屋にハード屋をつぶされるのを恐れている。

その構図は、テレビ局などのメディアがインターネットを嫌っている理由に非常に良く似ている。
彼らがインターネットやGoogle、Web2.0を嫌っているのは、
彼らが苦労して長い時間をかけて培ってきたノウハウを破壊されるのを恐れているから。
彼らは小泉純一郎のような「痛みを伴う改革」や「格差社会」に自分たちが巻き込まれる
ことをひどく嫌い、ひどく恐れている。




524 :デフォルトの名無しさん:2007/02/26(月) 17:06:04
>>517
Javaでもこういうことができるよってことで、
とりあえず宣伝だけしておいただけだと思うがな。

いや「だけ」ってことはないな。
Sunが目指していることを実現するための
前準備としての実験でもあったわけだし
一般人にも、Javaというものがどういうものか、
これで理解してもらえたかもしれないね。
最近じゃauの勢力が拡大してどうなるかわからないけど、
一応、BREWの上でJavaも動かせると言われているし。

それに携帯Javaアプリは使えるものはいくつもある。
SuicaのアプリだってFeliCaチップと入出力するところを除き、
アプリケーションはJavaでできている。

なんだかんだいって、燃料電池のような大容量電池を携帯電話に搭載し、
チップが小型化すれば携帯電話Javaもますます良い方向に進んでゆくと
思うけどね。

そこで、Java以外の選択肢を出すと、結局ベンダ依存になってしまう。
今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
基本的なAPIはベンダ依存していない。Java以外の選択肢で、
複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。

BREW開発なんてCPに検査してもらうコストも時間もかかるし、メモリリークの
心配ばかりしないといけないし、容量は相変わらずS!アプリやiアプリの半分くらいでとっても地獄じゃないか。

そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。


525 :デフォルトの名無しさん:2007/02/26(月) 17:21:02
>>523-524
マ板行け。

526 :デフォルトの名無しさん:2007/02/26(月) 17:30:02
マ板ネタも含まれているかもしれないけどJava MEの将来に対する
要望も含まれているから、ここでもいいのではないかと

527 :デフォルトの名無しさん:2007/02/26(月) 17:35:53
>>526
要望なら要望聞いてくれるところで言わんと意味無かろうが。

動機からして現状を変えたいというものではなく、
単なる現状の愚痴なわけだし、完全にマ板ネタだろ。
>>523-524 は技術的な話ですらないし。

528 :デフォルトの名無しさん:2007/02/26(月) 22:03:34
表題みるかぎりSE専門かと

529 :デフォルトの名無しさん:2007/02/26(月) 23:23:01
技術的な話も含まれているがのう。

要望ねえ。JCPか?

530 :デフォルトの名無しさん:2007/02/26(月) 23:26:20
>>529
含まれてないよ。マ板池。

531 :デフォルトの名無しさん:2007/02/26(月) 23:29:54
>>530
営業やってる連中とか、プログラマ卒業した連中とかだと
>>523-524 が技術的に見えるのかもしらん。

532 :デフォルトの名無しさん:2007/02/27(火) 03:14:34
むしろBREW上のJAVAで話を広げて欲しかった。
というか、そろそろ携帯でJavaSE動かすことできそうなんだけど・・・
Mysaifuの取り組みには期待している

533 :デフォルトの名無しさん:2007/02/27(火) 06:00:49
>>524
>今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
>基本的なAPIはベンダ依存していない。Java以外の選択肢で、
>複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。

ダウト。Write once Run anywhere はケータイでは全然できていない。
APIも仕様も違うのに、簡単とかいうな。お前、じつは作ったことないだろ。
#何だよ、scratch padって。

#if #else #endif が使えるC++のほうがまだケータイ向き。
でもauの審査がクソ遅いのはなんとかしてほしい。マジで。

> そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。

それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
つうかPalmOSが載ってくれれば一番よかったんだよ。なんでJavaなんだ?

534 :デフォルトの名無しさん:2007/02/27(火) 07:00:15
>>532
phoneME Advancedのどこが不満なんだ!w

Mysaifu JVMは俺も入れてるけど・・・。
だって〜かんきょうなくてびるど出来なかったんだも〜んww

まあ、冗談は置いといてphoneME AdvancedならRIだし全部入りだしHotoSpotあるし、phoneMEベースのプロジェクトを見かけた事ないのが不思議だ。

てかBREW自体流行ってないし国内じゃあうのせいでBREWの印象悪いし、正直実装さえしてくれたらKJNIの方が良いな。

もうちょっとJBlendがRI通りに実装してくれたら・・・
MIDPにMMAPIのprotocolパッケージ入れてくれたら・・・
WavPlyer実装してくれたら・・・
後はデコードくらい自分でするのに・・・

ところでMEにnioパッケージ実装しても端末の物理メモリが足りませんって落ちになるんだろうか?


535 :デフォルトの名無しさん:2007/02/27(火) 07:09:12
>>533
M1000ってPalmじゃなかったけ?
MIDPが使えるからkjavaじゃなくてMIDP for Palm OSなんだろうか。

536 :デフォルトの名無しさん:2007/02/27(火) 12:07:15
>>532-535
キミら、次世代と関係ない話題は他所でやってくれんかね?

次世代っても、勝手な妄想とか勝手な要望とかは愚痴と変わらんのよ。
便所に「税金安くしてくれ」って書いて要望とか言わんでしょ。

537 :デフォルトの名無しさん:2007/02/27(火) 19:04:27
て言ってもSE7って情報少ないな

538 :デフォルトの名無しさん:2007/02/27(火) 20:21:12
これがSDKに内包されてjavaguiが広まないかなぁ

http://journal.mycom.co.jp/articles/2007/02/26/jsr296/

539 :デフォルトの名無しさん:2007/02/27(火) 21:17:25
それSwing普通に使える人にとってメリットがほとんどないぞ

フレームワークがはやったから作っただけというのが近い
struts以上に薄いラッパだし、SwingWorerとダブるところも多いし
これほどメリットがないフレームワークってのも珍しい

540 :デフォルトの名無しさん:2007/02/27(火) 21:33:51
ポトペタツールが対応するか次第のよーな。

541 :デフォルトの名無しさん:2007/02/28(水) 09:38:38
>>533
> >>524
> #if #else #endif が使えるC++のほうがまだケータイ向き。
> でもauの審査がクソ遅いのはなんとかしてほしい。マジで。

プリ糞セッサに依存している時点で設計が全然駄目じゃん。


> > そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
> それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。

Python載せられることのどこがいいの理解できない。



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

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

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