[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
2006/11/20(月) 10:38:16[mustang] 次世代Javaの動向 3 [dolphin]
http://pc8.2ch.net/test/read.cgi/tech/1157227790/
次世代Javaの動向 ２
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/
0002デフォルトの名無しさん
2006/11/20(月) 13:40:070003デフォルトの名無しさん
2006/11/20(月) 14:11:39複素数を扱う前に実数を扱うプリミティブ型がなくちゃ
0004デフォルトの名無しさん
2006/11/20(月) 16:54:57無限精度ってこと？
0005デフォルトの名無しさん
2006/11/20(月) 17:53:26BigDecimalでいいよ。
あれをプリミティブにしてもねえ
0006デフォルトの名無しさん
2006/11/20(月) 17:55:33conjugate()やabs(),arg(),getReal(),getImaginary(),innerProduct(),
とかいうメソッドがあったとして、これらもいちいち演算子で表現
することになったらどうする気だ。
0007デフォルトの名無しさん
2006/11/20(月) 18:39:17Complex z = "1+2i";
と宣言できるだけでいいな。
0008デフォルトの名無しさん
2006/11/20(月) 18:40:34数値演算に特化したサポートはスマンが我慢してもらえると助かります・・・
複素数なんて日常つかわねえっす
0009デフォルトの名無しさん
2006/11/20(月) 18:41:15それくらいなら
Complex z = Complex.valueOf("1+2i");
でいいんじゃないの？
0011デフォルトの名無しさん
2006/11/21(火) 00:30:08つ sun.rmi.dgc.server.gcInterval 、sun.rmi.dgc.client.gcInterval
0012デフォルトの名無しさん
2006/11/21(火) 00:38:32ガベージコレクトしてるんですか。
しかしTigerでは気にならなかったレベルだったような気がします｡簡単なアウトラインエディタを作ってるんですが、文字入力や日本語変換とかが1分に一回規則正しく瞬間的に遅くなってしまいます｡以前は気にならなかったのに。
001312
2006/11/21(火) 00:39:270014デフォルトの名無しさん
2006/11/21(火) 03:05:40じゃ、今早速作れ。
構文解析は負担がかかるが。
とりあえずはメソッドを演算子代わりにすることから
始めないことには
0015デフォルトの名無しさん
2006/11/21(火) 03:07:25その程度の簡単なものであればいいが
\int\~\infty_{\infty}\frac{\sin x}[\cos \frac{dx}{dt}]
みたいなものだととんでもなく負担が増大する。
0016デフォルトの名無しさん
2006/11/21(火) 09:02:490017デフォルトの名無しさん
2006/11/21(火) 09:10:27Matrix A = {
{1, 2, 3},
{4, 5, 6},
{7, 8, 9},
};
0018デフォルトの名無しさん
2006/11/21(火) 12:35:50うむ。それもそうだ。
複素数を却下するのではなく、String表記法
について慎重に検討するまでは却下する。
が正しい。＠
0019デフォルトの名無しさん
2006/11/21(火) 12:37:39見たからにただの配列と変わらんな。
シンタックスシュガーとして
導入したとでもいうのかね。
だが、行列の演算子はどうする。
行列の積は*でいいのか？
それとも、行列の個々の要素同士の積こそが*であって
行列の積は*で表現すべきではないか？
ベクトルの内積演算子、外積演算子はどうする。
0020デフォルトの名無しさん
2006/11/21(火) 20:57:0911月上旬っていう記事を見たんだが、まだだよねぇ？
http://journal.mycom.co.jp/articles/2006/11/01/java/
0021デフォルトの名無しさん
2006/11/21(火) 21:25:070022デフォルトの名無しさん
2006/11/21(火) 21:34:22おまえは>>1すら読めないのか
0023デフォルトの名無しさん
2006/11/22(水) 08:28:56November と December を勘違いでもしたんじゃねーか？
と思わなくも無い。大地ﾀｿだし。
そこの記事ちゃんと読むと、記事の日付が 11/1 になってるのに
> Java SE 6のリリースまで1カ月強となった。
とか出てきて変だし。
0024デフォルトの名無しさん
2006/11/22(水) 18:06:260025デフォルトの名無しさん
2006/11/23(木) 02:52:35そんなあなたに Fortress
0026デフォルトの名無しさん
2006/11/23(木) 12:39:020027デフォルトの名無しさん
2006/11/23(木) 12:43:180028デフォルトの名無しさん
2006/11/23(木) 13:56:590029デフォルトの名無しさん
2006/11/23(木) 13:57:16E[] e = new E[5];
}
ができるように。
0030デフォルトの名無しさん
2006/11/23(木) 16:07:03erasure だけを使ってる限りは無理だろうね。
0031デフォルトの名無しさん
2006/11/23(木) 18:42:09全ての型で使える１つのコードを生成するだけでよいという利点
があるんだけど。
キャッシュの当たり率やメモリ消費量的には有利なはず。
C#のGenericsを採用した時点で、JITコンパイラは一部のコードを
C++のテンプレートのように型毎に生成する必要が出てくるからなぁ。
0032デフォルトの名無しさん
2006/11/24(金) 15:35:44そもそも、配列でそんなもんを使う価値が理解できない。
配列自体おかしな仕様なんだから。
List使え。
0033デフォルトの名無しさん
2006/11/24(金) 15:36:18Java GenericsはC#のGenericsとは違うからな。
0034デフォルトの名無しさん
2006/11/24(金) 16:35:44どの辺が？
0035デフォルトの名無しさん
2006/11/24(金) 16:36:56排除された記法っぽいな。
俺も>>29が出来てもそんなメリットとも感じないし。
0036デフォルトの名無しさん
2006/11/24(金) 20:31:36まず一つあげてみようか。
配列型を引数にとるとその引数である
配列の要素にまでfinalを指定できないことがあげられるね。
簡単に言うと配列は型安全性が完全に保証されていないこと。
配列の配列を他の配列の配列の型に代入できたりとか。
あと、配列型は継承できないこととか。
0037デフォルトの名無しさん
2006/11/24(金) 20:49:21コンパイル時、個々の要素毎でなく配列全体一括で不変にできるようにしようって話なら
adding_generics の時にも一旦出てたし、JSR 308 とかでもやろうとしてたりとかしてるね。
http://jcp.org/en/jsr/detail?id=308
> 簡単に言うと配列は型安全性が完全に保証されていないこと。
よくわからんけど、これは List も同じでは？
> あと、配列型は継承できないこととか。
配列を継承したいケースって、どんな時？
toString() 弄りたいとかはわからんでもないが、他の解決法あるし……
0038デフォルトの名無しさん
2006/11/24(金) 21:01:25一番上に関しては List でもコンパイル時にはチェックできないし。
Collections.unmodifiableList() とか使えば実行時にはチェックされるけど。
0039デフォルトの名無しさん
2006/11/24(金) 21:05:5936じゃないが、「配列は型安全性が完全に保証されていない」ってのは
下のコードは実行時例外が出るのにコンパイルが通るって話だろう。
ジェネリックな List だとコンパイルが通らない。
String[] ss = new String[] { "abc" };
Object[] os = ss;
os[0] = new Integer(123);
0040デフォルトの名無しさん
2006/11/24(金) 21:17:18コンパイル時の型安全だけに限ってるのか。
実行時は List の方が緩くなるし、どっちもどっちだと思うけどね。
Collections.checkedList() もあるけど、
Class が必要になるから、必ずしも使えるとは限らんし。
0041デフォルトの名無しさん
2006/11/24(金) 23:20:57それを配列にできないから配列は糞仕様だっていってるんだろ。
いちいりListに変換しないといけないからな
0042デフォルトの名無しさん
2006/11/24(金) 23:22:40配列をGenericsで扱うと、思い通りにいかないとかってやつ。
今その話が発端になっているのかな？
たしかにあれはキモイ。だから配列は極力つかわないほうが
綺麗になるってことかな。配列とGenericsとの併用は避けるべきだともいえそうだね。
0043デフォルトの名無しさん
2006/11/24(金) 23:26:37> > 簡単に言うと配列は型安全性が完全に保証されていないこと。
> よくわからんけど、これは List も同じでは？
そこでGenericsと、既に出たけれどもCollectionsクラスのアンモディファイアブルを
使う。配列だとListほど思い通りにいくわけでもないな。
配列はListよりパフォーマンスがよくてコード量が短いという
程度のメリットしかないな。
> > あと、配列型は継承できないこととか。
> 配列を継承したいケースって、どんな時？
そんなケースはまれだと思うが、
ある型Aを配列で扱いたいとき、
Aを継承したBも配列で扱いたい。
そんなとき、B[]はA[]を継承できるかっていうと
そうでも無いって奴だな。
そうなったらAArrayやBArrayというクラスを別途
作って対応するしかないって奴だ。
0044デフォルトの名無しさん
2006/11/24(金) 23:33:52Javaの中で妥協して作られたモノだと見てもいいな。
しかしprintf(String a, Object...)は
実は正体がprintf(String a, Object[] b)というからな
これもいつしか
public <E> PrintStream printf(String a List<E> )
なメソッドがオーバーロードされるんだろうか
0045デフォルトの名無しさん
2006/11/25(土) 00:03:05いや、generics は covariant じゃないから、型安全が保持されてるって書いてあったような。
> 配列とGenericsとの併用は避けるべきだともいえそうだね。
配列と Generics は相性も悪いしね。 >>29 みたいのができないし。
0046デフォルトの名無しさん
2006/11/25(土) 00:10:13> そんなとき、B[]はA[]を継承できるかっていうと
それって、どーゆー時に必要になる？
0047デフォルトの名無しさん
2006/11/25(土) 00:35:27みたいなときじゃないかな。
結局配列型を継承せず
配列型を集約するわけだが
0048デフォルトの名無しさん
2006/11/25(土) 00:42:00Sorted配列を継承してTree配列作る？
配列に対して、そーゆー発想は無かったなぁ。
0049デフォルトの名無しさん
2006/11/25(土) 02:25:17配列は非オブジェクト指向である。
0050デフォルトの名無しさん
2006/11/25(土) 02:29:470051デフォルトの名無しさん
2006/11/25(土) 03:09:59普通はしない
ってか、Tree配列ってなんだよ
0052デフォルトの名無しさん
2006/11/25(土) 03:35:37でも配列使うAPIも結構多いんだよね。
何しろGenericsができるまでは要素の型を指定できたの配列だけだし。
0053デフォルトの名無しさん
2006/11/25(土) 09:12:57nums[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
0054デフォルトの名無しさん
2006/11/25(土) 09:47:30それで「型安全が完全に保証されていない」ってんなら、極端な話すれば、
List<String> l = new ArrayList<String>();
Vector<String> v = (Vector<String>)l;
は、コンパイルが通るから、
「参照型の変数は型安全が完全に保証されていない」
とかいう変な話になっちゃうような気もする。
0055デフォルトの名無しさん
2006/11/25(土) 12:42:16それはキャストしてるだけでしょ。
型安全ってのはキャストなしでコンパイルが通ったら
実行時にも型に関する例外が出ないことだよ。
0056デフォルトの名無しさん
2006/11/25(土) 13:12:16それはキャストが型安全じゃない事を示しただけ。
そりゃ、キャストは型安全じゃないわな。
0057デフォルトの名無しさん
2006/11/25(土) 14:32:17private transient E[] elementData;（92行）
this.elementData = (E[])new Object[initialCapacity];（113行）
0058デフォルトの名無しさん
2006/11/25(土) 15:12:100059デフォルトの名無しさん
2006/11/25(土) 15:23:13配列がないとCollectionFrameworkもつくれないわけか・・・
0060デフォルトの名無しさん
2006/11/25(土) 15:28:51配列が covariant じゃなかったら 1.4 で Collection#toArray（Object[]） の
使い勝手が滅茶苦茶悪くなるし。極端に変な仕様だとも思わんが。
0061デフォルトの名無しさん
2006/11/25(土) 19:03:57まあその辺はトレードオフだわな
配列がcovariantなおかげで便利な部分があるのも確かだし
一方で型安全では無いとか配列の要素への代入時にチェックが入って遅くなる(可能性がある)
とか、covariantなために発生する問題もある
型安全かつ利便性をそれなりに保つためには、Java Genericsが採用したワイルドカードの
ような機能がJVMレベルであれば良かったんだろうけど、今更言っても後の祭りだしね
0062デフォルトの名無しさん
2006/11/25(土) 21:01:45っJNI
0063デフォルトの名無しさん
2006/11/25(土) 21:46:160064デフォルトの名無しさん
2006/11/25(土) 23:09:16covariantの意味はなんたるか
統計学用語で
varianseが分散
covarianseが共分散
ってのはわかるんだが
0065デフォルトの名無しさん
2006/11/25(土) 23:09:49variance
covariance
の間違い
0066デフォルトの名無しさん
2006/11/25(土) 23:11:35http://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
共変｛きょうへん｝ゲージ
0067デフォルトの名無しさん
2006/11/25(土) 23:13:54covariantとかtensor(テンソル)とかいわれても
わからん。
n次元空間とかn次元超平面とかクォータニンとか全然ピンと来ない
0068デフォルトの名無しさん
2006/11/26(日) 00:58:36プログラミング言語関係の用語の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では無いというわけ
0069デフォルトの名無しさん
2006/11/26(日) 03:16:26もういいから、違う言語使えよ。
0071デフォルトの名無しさん
2006/11/26(日) 10:21:31この行を読もうとして変態言語のパーサの気分がよくわかった。
等幅フォントにしたら読みやすくなった。
0072デフォルトの名無しさん
2006/11/26(日) 12:49:03じゃ、オマエのおすすめの言語あげてみそ
0073デフォルトの名無しさん
2006/11/26(日) 13:08:53Javaや.NETと連携できるみたいだね。
面倒な計算はMathematicaのエンジンにやらせて、
結果だけJavaで表示って方法じゃダメか？
Mathematicaしか調べてないけど、他の製品にもこういうのあるんじゃない？
0074デフォルトの名無しさん
2006/11/27(月) 01:52:430075デフォルトの名無しさん
2006/11/27(月) 02:20:17ドトネトとの連携が>>69とどういう繋がりがあるんだかわからないが
数値計算のためにわざわざドトネトを使う価値ってものが
どういうものか説明しないことには意図が伝わらないな
0076デフォルトの名無しさん
2006/11/27(月) 04:31:53いや、>>73の論旨を読めてないでしょう。
JavaOnlyで行わず数値演算は、Mathmatica(あれも一種の言語だよな)
何かに任せ連携を取るということもあるという話。であって
数値演算に、Java、.NET等の汎用言語を「使わない」選択肢について語ってるのが>>73
0077デフォルトの名無しさん
2006/11/27(月) 08:07:07大学の端末には確かに入ってるけど・・
0078デフォルトの名無しさん
2006/11/27(月) 15:36:34つーか他の製品知らない
0079デフォルトの名無しさん
2006/11/27(月) 15:53:39Mathematicaの話をするならドトネトの話は関係ない
0080デフォルトの名無しさん
2006/11/27(月) 15:53:57MATLABのほうが断然使いやすいんだが
0081デフォルトの名無しさん
2006/11/27(月) 20:35:23他の言語とのインターフェースは知らなかったよ。
0082デフォルトの名無しさん
2006/11/27(月) 23:52:44特定の研究室に関わらないと知らないと思うぞ。
あと、高いしな。
FortranやC/C++のほうが知名度が高いだろう。
0083デフォルトの名無しさん
2006/11/29(水) 20:30:400084デフォルトの名無しさん
2006/11/29(水) 22:24:090085デフォルトの名無しさん
2006/11/29(水) 23:26:25CやJavaを使える生徒が減ったという理由でMATLABが必修になりつつある情報科があるんだよなw
まず教授がCやJavaを使えないって話かもしれんがw
0086デフォルトの名無しさん
2006/11/30(木) 01:18:03C#見て小躍りしたんだろうなぁ
>>84
うん。ガッ
0087デフォルトの名無しさん
2006/11/30(木) 01:43:40生徒は中高生のことを指す。
0088デフォルトの名無しさん
2006/11/30(木) 20:26:030089デフォルトの名無しさん
2006/12/01(金) 09:48:410090デフォルトの名無しさん
2006/12/02(土) 07:44:530091デフォルトの名無しさん
2006/12/02(土) 10:42:010092デフォルトの名無しさん
2006/12/02(土) 13:37:010093デフォルトの名無しさん
2006/12/04(月) 12:24:19ttp://download.java.net/jdk7/binaries/
ttp://www.java.net/download/jdk7/changes/jdk7-b03.html
Changelogの多さからして本格稼働した様子。
0094デフォルトの名無しさん
2006/12/10(日) 10:42:440095デフォルトの名無しさん
2006/12/10(日) 14:05:39さすがDelphi作者が作っただけはある。
Java 7からはプロパティやクロージャも検討されるから
2009年には若干C#より柔軟になる。
0096デフォルトの名無しさん
2006/12/10(日) 15:43:400097デフォルトの名無しさん
2006/12/10(日) 19:22:4912月も1/3過ぎちゃうぞ。
0098デフォルトの名無しさん
2006/12/10(日) 23:09:530099デフォルトの名無しさん
2006/12/11(月) 20:13:170100デフォルトの名無しさん
2006/12/11(月) 20:33:55てか5.0のupdate10をちらっとみたけどこっちのがマニアックに凄いな
selectが内部でepollで実装されてるってことはゲーム用途でもいけそう
0101デフォルトの名無しさん
2006/12/11(月) 21:36:15ランゲージパックなんていままでもなかったと思うが。
0102デフォルトの名無しさん
2006/12/11(月) 21:43:470103デフォルトの名無しさん
2006/12/11(月) 21:50:390104デフォルトの名無しさん
2006/12/11(月) 22:31:280105デフォルトの名無しさん
2006/12/11(月) 22:32:50前から、JDKの日本語ダウンロードページなんかは前からあるけど、
ダウンロード方法なんかが訳されてるだけで中身は一緒だったな。
0106デフォルトの名無しさん
2006/12/11(月) 23:17:34早く日本語のAPIリファレンス欲しい人は手伝ってみれば良いかも？
0107デフォルトの名無しさん
2006/12/12(火) 09:59:490108デフォルトの名無しさん
2006/12/12(火) 12:00:47ついにリリースされたか！
気が付くのが遅かった！
早速ダウソ！
0109デフォルトの名無しさん
2006/12/12(火) 17:09:24日本語版NetBeans5.5って正式リリースされてたっけ？
0110デフォルトの名無しさん
2006/12/12(火) 18:04:31JDK6にバンドルされているのは英語版。日本語版は12/14の予定。
いまDLできるJDK6のVMだけど、NetBeansの製品情報で見ると 1.6.0-b105と表示される。
これって本当に正式版なのかな？
0112デフォルトの名無しさん
2006/12/12(火) 18:39:360113デフォルトの名無しさん
2006/12/12(火) 19:13:07起動時の画面の動きが怪しいね。
0114デフォルトの名無しさん
2006/12/12(火) 19:22:250115デフォルトの名無しさん
2006/12/12(火) 19:33:26>>113
どう怪しいのか詳しく。
0116デフォルトの名無しさん
2006/12/12(火) 20:53:04影つきの非矩形でびっくりした。
着実にGUIも進歩しているなぁ
0117デフォルトの名無しさん
2006/12/12(火) 21:23:32これからはJavaアプリ間で使いまわすスクリプトも流行るだろうし研究しなきゃ
0118デフォルトの名無しさん
2006/12/12(火) 21:37:35メインの画面が出る直前に、起動時のプログレスダイアログが左端に動く
0119１１８
2006/12/12(火) 21:38:30○左上
0120デフォルトの名無しさん
2006/12/12(火) 21:55:54ペン３、1GHZじゃ恩恵なし？
0121デフォルトの名無しさん
2006/12/13(水) 00:30:37ような気がする…
0122デフォルトの名無しさん
2006/12/13(水) 01:05:220123デフォルトの名無しさん
2006/12/13(水) 01:30:320124デフォルトの名無しさん
2006/12/13(水) 01:56:28確かに5.0よりやや早いのを確認
VM起動前にスプラッシュ出せるようになったのも重いアンチウイルスソフト使ってる人にはうれしいかもね
0125デフォルトの名無しさん
2006/12/13(水) 08:54:490126デフォルトの名無しさん
2006/12/13(水) 09:08:58java.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"
0127デフォルトの名無しさん
2006/12/13(水) 16:44:550128デフォルトの名無しさん
2006/12/13(水) 16:48:020129デフォルトの名無しさん
2006/12/13(水) 16:58:14MSが真似をして
Javaが起源を主張する
0130デフォルトの名無しさん
2006/12/13(水) 23:13:03どのようにすればごく最近(2003-2004)作成された IronPython を模倣出来るんだろう．．．
最近、歴史を学ばない半島人がオリジナルにパクリを主張することが多くて困る
0131デフォルトの名無しさん
2006/12/14(木) 01:13:19しかも日本人作なんで驚いたもんだ。
0132デフォルトの名無しさん
2006/12/15(金) 04:27:57http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf
なんか BigDecimal で四則演算が使えてるっぽいサンプルとか、
JavaBeansのプロパティが -> で参照できてるっぽいサンプルとかがある。
Closure の構文みるに、8月の段階で提案されてた構文っぽいので
他の言語機能も構文変わったりするのかも。
それと個人的には Java SE 7.0 って機能てんこ盛りすぎに思えるので
いくつかの機能は次のバージョンに持ち越される可能性もあるんじゃないかと心配したり。
ざっとみただけでも、コンパイルエラーになりそうなサンプルが 2つほどあったり……
0133デフォルトの名無しさん
2006/12/15(金) 07:05:51Genericsの略式インスタンスもnew()の方はキモ過ぎる。
インタフェースのデフォルト実装クラスがあるってことだろ。
friend class構文とかと同じキモさ。
0134デフォルトの名無しさん
2006/12/15(金) 07:15:410135デフォルトの名無しさん
2006/12/15(金) 07:46:34> インタフェースのデフォルト実装クラスがあるってことだろ。
そうとも限らないんだけどね。
gosling御大も別のアプローチをブログに書いてたりするし。
その辺の話は、こっちみると良いかも。
http://weblogs.java.net/blog/forax/archive/2006/12/dry_dont_repeat.html
0136デフォルトの名無しさん
2006/12/15(金) 11:15:490137デフォルトの名無しさん
2006/12/15(金) 13:07:39Groovy みたくフィールドアクセスを明示する場合に
foo.@bar なんて構文使うのもアレだし。
0138デフォルトの名無しさん
2006/12/15(金) 20:32:17おお、 := はいいな・・・
0139デフォルトの名無しさん
2006/12/15(金) 22:52:45Javaも拡張しすぎてC++と同じ道を歩みそうな予感…
ところで、みんなの職場では5.0は浸透している？
うちの職場はまだ1.3...orz
0140デフォルトの名無しさん
2006/12/15(金) 23:00:450141デフォルトの名無しさん
2006/12/15(金) 23:09:30去年から1.5だな。さっさと1.6にしたいが流石に時期尚早
0142デフォルトの名無しさん
2006/12/15(金) 23:18:55今回はバグつぶしに金掛けてるし、実用レベルまで叩かれるのも早いかと。
0143デフォルトの名無しさん
2006/12/15(金) 23:43:34どれくらいのものかは肌で感じてるし安心感は強いな
イザとなったら自分で改変もできるし
0144デフォルトの名無しさん
2006/12/15(金) 23:51:49http://download.java.net/jdk7/changes/jdk7-b04.html
そろそろ JDK7 も本格始動？
0145デフォルトの名無しさん
2006/12/16(土) 00:00:480146デフォルトの名無しさん
2006/12/16(土) 00:58:28JDK6を使ってみる。「WindowsVistaに対応してます」の一言で
クライアントのOKが出た。JDK6でなければならない理由はないんだけど、
何より俺が使ってみたいのだ。
0147デフォルトの名無しさん
2006/12/16(土) 01:00:310148デフォルトの名無しさん
2006/12/16(土) 20:31:10同意
0149デフォルトの名無しさん
2006/12/16(土) 22:13:48共用体が欲しいなあとなんとなしに思ってたけど
nioのByteBufferが既にそれっぽいことに今更気づいた。
0150デフォルトの名無しさん
2006/12/16(土) 23:59:17デスクトップアプリで６を使うのはいいと思うけど、EclipseRCPにしてもNetBeansPlatformにしても
へんなのをかますと余計にめんどくさいだけだと思うんだが
重くなりやすいし、バグがあったとしても回避しにくい
普通にSwingベースのほうが開発効率がいい
まぁNetBeansPlatformはSwingベースで開発できる分まだ楽か
0151デフォルトの名無しさん
2006/12/17(日) 00:01:200152デフォルトの名無しさん
2006/12/17(日) 00:23:590153デフォルトの名無しさん
2006/12/17(日) 00:28:010154デフォルトの名無しさん
2006/12/17(日) 00:31:355.0で既に十分なポテンシャル持ってたのに作らなかった。
事実やる気全開のV2Cは今や非Win用2chブラウザの重鎮だし。
0155デフォルトの名無しさん
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まわり改善されるのが面白い
0156デフォルトの名無しさん
2006/12/17(日) 00:38:22V2Cいいんだけど参照のこったままになるの改善してほしいな
ひとつも開いてなくてもあきメモリーがなしってひどす
0157デフォルトの名無しさん
2006/12/17(日) 00:59:46RowSetって使ってるとこあるの？
JDBC4.0は何故かRowSetに肩入れしてるけど
JPAとレイヤーも被ってると思うんだよなぁ
0158デフォルトの名無しさん
2006/12/17(日) 01:08:15あくまで提案か。
実装するにはヤバイのが多いな。
BigDecimalの演算子だが
divide使うとき、MathContextの値はどうするのだろうか。
二つのBigDecimalオブジェクトのMathContextの値が異なれば
誤差が片方のMathContextの制度を基準にして除算を
することになると思うが、そうしたくない場合には
結局BigDecimal#divide(BigDecimal, MathContext)を使うことになるんだろうな。
その辺り、どう解決するのだろうか。
0159デフォルトの名無しさん
2006/12/17(日) 01:18:13だってnewするの面倒だもんと聞いたときには何の冗談かと
あとしらないで1.05とか掛け算したんだけど、なんかコンパイルエラーが出るんですが、doubleにしたらエラー消えたからOKだとおもったとか
こんなのが業務プログラム経験10年とかでベテランですといってごろごろいるんだが
そのたびにぶちきれてる俺はいやなやつと思われてるっぽい
0160デフォルトの名無しさん
2006/12/17(日) 01:20:41正直どうにかして首に追い込めないかとか考えてしまう。
0161デフォルトの名無しさん
2006/12/17(日) 01:23:39C++のテンプレートと同じことが出来なきゃ先は無いだろ。
0162デフォルトの名無しさん
2006/12/17(日) 01:29:11今のところ5.0導入してから半分くらいはついていけないのを確認
5.0ではListに入れる型がわかるので結合時のエラーが減りますね！とかenum便利ですね！とかwktkしてる人もいれば
なんで5.0つかうんだよとうつろなやつもいて、非常に適正がわかりやすい
>>161
目的が違うんだからいいんじゃね？C++と同じだったら逆にぶちきれるだろ
0163デフォルトの名無しさん
2006/12/17(日) 01:31:310164デフォルトの名無しさん
2006/12/17(日) 01:32:220165デフォルトの名無しさん
2006/12/17(日) 01:33:10BigDecimal,BigInteger用のシンタックスシュガーが導入されれば何とかならんかね・・・
しかし・・・・丸めとかの規定ないの？仕様に。
0166デフォルトの名無しさん
2006/12/17(日) 01:40:340167デフォルトの名無しさん
2006/12/17(日) 02:10:27ジェネリクスが今の形になってるのはただ単純に互換性を保つためだけの理由からだよ。
だいたいタイプパラメーターにnew出来ないってありえねーよ。
0168デフォルトの名無しさん
2006/12/17(日) 02:17:310169デフォルトの名無しさん
2006/12/17(日) 02:34:32無制限に型パラメータで new するのは C# でもできないし。
0170デフォルトの名無しさん
2006/12/17(日) 02:37:580171デフォルトの名無しさん
2006/12/17(日) 02:45:01つ「スペルミスなんだけど、気付いた時には既に修正不能だったという逸話が有名な Cloneable」
0172デフォルトの名無しさん
2006/12/17(日) 03:03:58何が遅すぎるのやら。
0173デフォルトの名無しさん
2006/12/17(日) 03:05:23http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=1234712
0174デフォルトの名無しさん
2006/12/17(日) 03:25:14互換性が大事だと一番分かっているのはC++だろｗ
0175デフォルトの名無しさん
2006/12/17(日) 03:39:450176デフォルトの名無しさん
2006/12/17(日) 12:05:100177デフォルトの名無しさん
2006/12/17(日) 12:19:035.0で浸透している。
やはりGenericsとアノテーションは重宝する。
JUnitもアノテーションに対応したことだし。
Generics
>>141
0178デフォルトの名無しさん
2006/12/17(日) 17:28:19うちのV2Cはなったことないな。
ヒープサイズの問題でないなら本スレにバグレポした方がいい。
0179デフォルトの名無しさん
2006/12/17(日) 18:40:37ttp://developers.sun.com/learning/javaoneonline/2006/desktop/TS-3399.pdf
0180デフォルトの名無しさん
2006/12/18(月) 00:30:49> リッチクライアント用途ではすでに普及してると思うが、クライアントサーバのように2層式が
> まだ弱いのが今後大幅に改善されるかもしれない
あれかServlet/JSPとの連携が弱いってやつな。
たしかに俺も思った。弱いって言うか扱いにくい。
RMIでないといけないから。
StrutsやJSFがSwingと合体すれば使いやすいのだが。
0181デフォルトの名無しさん
2006/12/18(月) 00:40:29RMIでもWebServiceでもいいけどそれらのもってきた値とコンポーネントとの関連付けが今は手動になっちまう
＞StrutsやJSFがSwingと合体すれば使いやすいのだが。
これはありえないだろ
前2つよりSwingのほうが圧倒的に使いやすいし
0182デフォルトの名無しさん
2006/12/18(月) 00:46:12てかSwingコンポーネントひとつひとつが<input>タグ化すればいいだけの気もする。
バリデータとコンバータがフレームワーク毎にあることのがメンドイ？
0183デフォルトの名無しさん
2006/12/18(月) 00:52:020184デフォルトの名無しさん
2006/12/18(月) 01:19:56> とはいえ、いまだに大量に要る浮動小数点を金額計算に使うやつらをとめれるのは大きいか
> だってnewするの面倒だもんと聞いたときには何の冗談かと
valueOf()を使えと言っておけ
と思ったが10進2進変換誤差の問題があるから new BigDecimal(String, MathContext)しかないな。
にしてもBigDecimal.valueOf(String) 欲しいモノだ。
0185デフォルトの名無しさん
2006/12/18(月) 01:21:540186デフォルトの名無しさん
2006/12/18(月) 01:23:03> 前2つよりSwingのほうが圧倒的に使いやすいし
Swingだと、
HTMLやXSL + XMLで書かれたページと連携するのが
不便なのだが。
0187デフォルトの名無しさん
2006/12/18(月) 01:24:17これをSwingと連携する方法が・・
0188デフォルトの名無しさん
2006/12/18(月) 01:25:15Webフレームワーク側がXML+XSLTに移行すれば皆幸せ。
0189デフォルトの名無しさん
2006/12/18(月) 01:53:43そういうこと
通信自体はJAXB/JAX-WSが6からクライアントに来たことによってかなりよくなった
後はそのバインドされたコンポーネントだけ
0190デフォルトの名無しさん
2006/12/18(月) 03:07:51Visual Web Packの画面遷移エディタみたいにSwingでも画面遷移管理。
0191デフォルトの名無しさん
2006/12/18(月) 18:16:520192デフォルトの名無しさん
2006/12/18(月) 22:38:49そういやMMOするのも一苦労だったな、あの頃は。
0193デフォルトの名無しさん
2006/12/19(火) 23:55:07このボタンをおしたら２つフレームを出して、ボタンの乗っているカードレイアウトのページを切り替えて・・・とか
そういうのもあるからページベースで考えるというのは無理がある
それに画面遷移の一元管理なんてべつにむずかしくはないだろ
0194デフォルトの名無しさん
2006/12/20(水) 08:39:04JSFのページ遷移でいいんだよ。
画面遷移エディタで俯瞰で見れるのが欲しい。
0195デフォルトの名無しさん
2006/12/20(水) 20:54:04Java EE + ウェブコンテナ + ジャカルタ + オープンソース系の技術
これらの寄せ集めもいいが、この統一感が無い感じこれらの技術よりと
結局は同等のことが出来るMSで統一するのが一番楽に思えてきたんだよ…
若いっていいよな…
0196デフォルトの名無しさん
2006/12/20(水) 20:57:11今はＰＣサーバの能力あがったから大丈夫かもしれんが、ちょいと前まではスケーラビリティの問題がでかかったんだよね
0197デフォルトの名無しさん
2006/12/20(水) 22:34:55Java EEのJSF+EJB3でだいたいいけるよ。
0198デフォルトの名無しさん
2006/12/20(水) 23:31:450199デフォルトの名無しさん
2006/12/21(木) 00:21:31JSCとほぼ同じだが、いい感じで統一感がでてると思うね。
0200デフォルトの名無しさん
2006/12/21(木) 00:34:44俺も昔そう感じていた時期もあったが、
バージョンアップによる互換性のなさに嫌気がして、
その世界から抜け出した。
いまでも.NETで互換性の問題が出ているようだし
判断は間違ってなかったと思ってる。
もちろん、100%PureMSの生み出すパワーは魅力的なのは否定しないがね。
0201デフォルトの名無しさん
2006/12/21(木) 00:37:140202198
2006/12/21(木) 01:07:050203デフォルトの名無しさん
2006/12/21(木) 07:25:51SUNの文章の方が優れていたからじゃないかと思ってる。
Java周辺（SUN/IBM周辺）の技術文章（や本）で統一感があれば
MSのサービスなんか目じゃなくなるんだろうな…
0204デフォルトの名無しさん
2006/12/21(木) 07:29:48足腰が不安定なオープン形の技術よりも、長期間手厚くサポートされ最後まで存続する
技術（ソフト・サービス）はMSの方だと思う。
だけど、現状で融通が利くのは>>195の指摘する限りだ。
0205デフォルトの名無しさん
2006/12/21(木) 09:19:400206デフォルトの名無しさん
2006/12/21(木) 11:26:19そんな奴はJava界にとっても害悪でしかないからなあ。消えてもらって結構。
思う存分Googleでもマンセーしてればいい。
0207デフォルトの名無しさん
2006/12/21(木) 11:34:31そうかなぁ？
MSも技術的には不安定だと思うね。
元VB使いなんだが、2.0から使ってて、バージョンアップの度に、移植に手間がかかったり、
クライアントの環境によっては動かない事があるなど、
いい思い出はない。
0208デフォルトの名無しさん
2006/12/21(木) 11:41:42元々MS嫌いな奴らがいて、
彼らがJavaに飛びついただけ。
単純に言語的な魅力を感じて、Java使いになった人もいるわけで。
今は後者が増えたのだろう。
0209デフォルトの名無しさん
2006/12/21(木) 12:03:45それが統一感がないと感じるのか。
それならJakarta を外してSun純正にすれば？
0210デフォルトの名無しさん
2006/12/21(木) 13:45:21ASP.NETは型にはまれば楽チンだが、ちょっと型から外れることを行うときは、
一から自分でお膳立てしないといけなくて面倒なこともあるよ。
0211デフォルトの名無しさん
2006/12/21(木) 19:23:28そういうことじゃないと思うよ。
0212デフォルトの名無しさん
2006/12/21(木) 19:26:00そういうのところ（ニッチ市場ともいうか）以外は全部MSになってしまうってことなんだね。
Javaの出番は結局大規模上層のところなのかなぁ
0213デフォルトの名無しさん
2006/12/21(木) 20:17:53どうしてそういうレスになるんだ？
日本語理解できてる？
0214デフォルトの名無しさん
2006/12/21(木) 23:07:37フリー版が出てきたよ！ってだけの意味しかないと思うんだが、
何であんなにみんな寄ってたかってあがめたてるのか謎だわ。
まぁ、Rubyの言語的に優れたところを認めるのにはやぶさかではないが。
0215デフォルトの名無しさん
2006/12/21(木) 23:13:360216デフォルトの名無しさん
2006/12/21(木) 23:34:21皆あんまり真面目に書かないんだよな
事前条件の提示とかフェイルファストとかスレッドセーフとか
確かにSunのドキュメントは細かく書かれてて戸惑いが少ない。
驚き最小限の法則に基づけばこの姿勢は大切。
0217デフォルトの名無しさん
2006/12/22(金) 02:31:53そんな未来が、君には見えないのか？
0218デフォルトの名無しさん
2006/12/22(金) 05:17:12Javaは、Macでデスクトップでの可能性が見れたという部分は大有りだがな。
GPL化されたJVMをプレインストールしてPC売り出す勇気のある会社はねえんかね
0219デフォルトの名無しさん
2006/12/22(金) 13:18:360220デフォルトの名無しさん
2006/12/22(金) 15:17:14自分はちゃんとjavadocコメント入れてるよ、というかうちのチームは入れないと深夜に呼ばれて質問されても文句言えないって教わってきたからだけど。
0221デフォルトの名無しさん
2006/12/22(金) 15:19:58いいチームだな
ドキュメントコメントいれておけば補完時に説明出るしね
別途用意したドキュメントとは別次元
publicなメソッド等にはドキュメントコメントがないとコンパイルエラーでてもいいと思うんだ
0222デフォルトの名無しさん
2006/12/22(金) 16:26:51書いてるよ。Eclipseのプラグインを
使わないと真面目に書く気起きないだろうけど
0223デフォルトの名無しさん
2006/12/22(金) 19:35:11書いてるよ。
でも中国人の中国語が文字化けしてるよ。
0224デフォルトの名無しさん
2006/12/22(金) 22:18:32http://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
0225デフォルトの名無しさん
2006/12/23(土) 20:35:14変数のスコープが分かりにくくなる形での推論は特に。
var型とかを用意して必ず有効な参照で
初期化しなければならないくらいのルールは欲しい。
可読性対策に問題が出るくらいなら冗長なGenericsのままのがいいす。
0226デフォルトの名無しさん
2006/12/23(土) 20:45:530227デフォルトの名無しさん
2006/12/23(土) 20:54:26って具体的にどーゆー事かわからん。
0228デフォルトの名無しさん
2006/12/23(土) 21:05:19始めてその名称が使用されたタイミングで
参照型が作られるのはアカンということ。
0229デフォルトの名無しさん
2006/12/23(土) 21:22:49スコープがわかりにくくなるんかな？
0230デフォルトの名無しさん
2006/12/23(土) 21:29:19スタックトレースからコード追うときはイラっとくるかも
0231デフォルトの名無しさん
2006/12/23(土) 21:59:35http://weblogs.java.net/blog/forax/archive/2006/12/call_me_santa.html
の for ループの中で algol構文のシンタックスシュガー使ってる時だけだと思うが。
後は final が付いてたり := があるから変数宣言してんのわかるし。
0232デフォルトの名無しさん
2006/12/25(月) 18:39:390233デフォルトの名無しさん
2006/12/25(月) 23:23:49話題にならないのはすでに2年以上も前の話だからだろ？
0234デフォルトの名無しさん
2006/12/26(火) 16:42:28そしてプログラムで使える人はわかってる人。
というか、次世代じゃなくて現世代だよな。
0235デフォルトの名無しさん
2006/12/26(火) 21:00:240236デフォルトの名無しさん
2006/12/26(火) 21:15:30フレームワーク使う人が使うものじゃないな
0237デフォルトの名無しさん
2006/12/26(火) 22:59:07前世代だろ？
0238デフォルトの名無しさん
2006/12/26(火) 23:33:19こんな、やつがwebアプリ作るからwebアプリって全般的に品質低いんだよ。
たとえば、J2EEは、基本マルチスレッドモデルだからインスタンス変数なんか定義して
リクエストの情報を設定したりなんかすると平気で他人の状態に書き換わったりする。。
strutsみたいなフレームワークを使ってても同様↓
ActionのJavadocより引用
------
リクエストの状態に関連する情報を保持するためにインスタンス変数やスタティック変数を使用してはいけません。
インスタンス変数やスタティック変数は同一のアクションに関してリクエストをまたがってグローバルなリソースを共有したい場合に使用します。
0239238
2006/12/26(火) 23:42:30とにかく、webだからスレッドなんて関係ないぜ。ってのは、よしてくれ。
http://www.atmarkit.co.jp/fjava/rensai2/webopt04/webopt04.html
0240デフォルトの名無しさん
2006/12/27(水) 00:06:25日本語のサンプルすくないじゃん。
サンプルがないとコードがかけないと思う。
0241デフォルトの名無しさん
2006/12/27(水) 01:19:41WEBアプリだと自分で明示的にスレッド作ることは
あまり無いっちゅうことじゃないの？
さすがにそのレベルの間違いをする人はそんなにいない・・・
と言いたいところだが、ちらほら見かけた。
StrutsのActionクラスとかにインスタンス変数書きまくって
「テスト通る時と通らない時があります！
FWのバグじゃないですか？」
とかこいてて、いますぐ死ねってまじで思った。
0242デフォルトの名無しさん
2006/12/27(水) 05:10:020243デフォルトの名無しさん
2006/12/27(水) 05:17:26いやいや、マルチスレッドなのにオブジェクトを使い回すような設計になっているのが悪いんじゃないか。
いまやオブジェクト生成・破棄のコストはそんなに重大ではないんだから、
もっと素直にプログラムできるようなモデルにすべきだった。
0244デフォルトの名無しさん
2006/12/27(水) 08:12:03設定でシングルスレッドモデルって言ってシングルスレッドで動作させる
ようにもできる。
その上でフレームワークを使うって言ったら結構なメモリを使うであろうことが
容易に想像できるわけだが。
0245デフォルトの名無しさん
2006/12/27(水) 12:32:11それにインスタンスも複数使われるかもしれないし、ひとつかもしれないという自由度だったはず
Tomcatはひとつだったはずだけど
スレッドプーリングしてるんだよとか基本を教えないでこのメソッドのみで適当に作っといてとしかいわないのも悪い
0246デフォルトの名無しさん
2006/12/27(水) 14:22:280247デフォルトの名無しさん
2006/12/28(木) 08:29:24interface 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;
として代入も可能。タイプパラメータがあってればいい感じ。
通常の配列もこのインターフェイスを実装済みでいいかも。
0248デフォルトの名無しさん
2006/12/28(木) 08:31:24言語仕様的にはできなくは無いだろうけど、JVMレベルでの互換性を
壊すから、まず入ることは無いだろうな。あと、従来の配列はcovariantだが
genericsはcovariantじゃないというのもある
0249デフォルトの名無しさん
2006/12/28(木) 11:17:30配列じゃないけど indexer っぽいのは >>224 の wish list に入ってたけど。
0250デフォルトの名無しさん
2006/12/28(木) 23:45:13ここのArray Syntax for Collectionsがあればいいんじゃない？
http://blogs.sun.com/ahe/entry/java_se_7_wish_list
0251250
2006/12/28(木) 23:46:000252247
2006/12/29(金) 00:47:46配列を抽象化できるのも魅力かなと。
でもcovariantが・・・なるほどね。。。
BigDecimalの四則演算対応も、できれば何かの特定のインターフェイスを
実装していれば対応できるというのが希望。
それって何て演算子オーバーロード？って言われそうですが・・・
0253デフォルトの名無しさん
2006/12/29(金) 01:36:56みたいな初期化ができれば、配列の抽象化にこだわる必要はまったくなくなると思う。
コレクションのための配列構文も、[]のオーバーロードみたいなもんだし。
0254デフォルトの名無しさん
2006/12/29(金) 01:44:57List<Integer> list = {12,34,56};
は、コンパイルエラー？
0255デフォルトの名無しさん
2006/12/29(金) 03:26:09自分は、それはコンパイルエラーでいいと思う。
0256デフォルトの名無しさん
2006/12/29(金) 03:28:09http://d.hatena.ne.jp/nowokay/20061218
0257デフォルトの名無しさん
2006/12/29(金) 10:02:43final list = ArrayList.of(1, 2, 3);
でよくね？ >>250 に載ってる
・More factory methods for colllection classes
・Shorthand syntax for declaring local variables
のあわせ技で出来ると思うんだけど。
0258デフォルトの名無しさん
2006/12/29(金) 10:23:29問題は Map の factory method だよな、と思う。
0259デフォルトの名無しさん
2006/12/29(金) 10:32:380260235
2006/12/29(金) 12:00:42インスタンス使い回すっていうコンテナの構造上の問題は普通に意識するだろ。
マルチスレッド以前の問題だ。
Webアプリでスレッドを用いる必要があるのはデータのインポート＆エクスポートぐらいだと思う。
重い処理をする間、ユーザーを待たせないっつー意味で。
0261デフォルトの名無しさん
2006/12/30(土) 13:25:270262デフォルトの名無しさん
2006/12/31(日) 02:02:390263デフォルトの名無しさん
2006/12/31(日) 02:41:17Buffered*StreamみたいなのBuffer版アダプタを
標準で用意してくれるだけでも嬉しい
0264デフォルトの名無しさん
2006/12/31(日) 02:52:320265デフォルトの名無しさん
2006/12/31(日) 10:56:51BufferedChannel みたいなものが欲しいって事？
ByteBuffer.wrap(new byte[1]); みたいな小さい ByteBuffer 作って
ちょこまか読み書きしてないなら大して必要とも思わないけど。
ってか、java.ioとの親和性とか関係ないような。
0266デフォルトの名無しさん
2006/12/31(日) 12:14:450267デフォルトの名無しさん
2006/12/31(日) 13:16:45要るか？
0268デフォルトの名無しさん
2006/12/31(日) 13:34:33それが欲しければアプリの中で用意すれば？
ってレベルの需要だろうなぁ
0269デフォルトの名無しさん
2006/12/31(日) 13:34:340270デフォルトの名無しさん
2006/12/31(日) 13:51:220271デフォルトの名無しさん
2006/12/31(日) 14:46:16ダイレクトバッファ使ってても、
InputStream や OutputStream のデコレータだったらアドバンテージないんじゃ？
0272デフォルトの名無しさん
2006/12/31(日) 14:48:28ByteBuffer#get(byte[]) とかあるけど。
0273デフォルトの名無しさん
2006/12/31(日) 14:50:18それを言うなら ByteBuffer#put(byte[]) じゃないかと。
0274デフォルトの名無しさん
2006/12/31(日) 14:52:270275デフォルトの名無しさん
2006/12/31(日) 14:55:19コンポーネント単位で見ればそれもありでは？
nioのが効率はいいんだから、
最適化が必要になった時にnioにあわせていけばいい。
0276デフォルトの名無しさん
2006/12/31(日) 14:56:41NIOUtils.writeTo(WritableByteChannel, ByteBuffer)
みたいなユーティリティメソッドつくっときゃ良いだけのような。
0277デフォルトの名無しさん
2006/12/31(日) 15:01:08いや、単純に無駄だよねって話。
中途半端にやるとクラスが汚くなるだけだし。
最適化が必要になりそうならアプリ側で入出力処理を抽象化しておきゃ良いんだし。
0278デフォルトの名無しさん
2006/12/31(日) 15:06:00内部で Channel 使った ChannelInputStream とか ChannelOutputStream で最適化する時
read(ByteBuffer) とか write(ByteBuffer) があると便利なんだよ！
すげーアホ臭いな。そんだったら最初から Channel 使えば良いし。
0279デフォルトの名無しさん
2006/12/31(日) 15:07:05要るか？
0280デフォルトの名無しさん
2006/12/31(日) 15:07:070281デフォルトの名無しさん
2007/01/05(金) 02:17:08で表示されないのは既出ですか？
0282デフォルトの名無しさん
2007/01/10(水) 21:20:030283デフォルトの名無しさん
2007/01/11(木) 01:52:34http://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コンポーネントとか）書く人の違いなんだろか？
0284デフォルトの名無しさん
2007/01/11(木) 19:27:09object.x = "hoge" を object.setX(String str)
String str = object.x を object.getX()
にmappingする機能でおｋ？
ObjectPascal とかだと直接フィールドを参照するか、メソッドを指定するかとか出来るけど
そーゆー事も考えられてるのかな？
フィールド指定を可能にすることで無駄なsetter,getterの記述が不要になることが
propertyを導入する最大の利点だと考えてるのでそーゆーのが考慮されてないといまいちだなぁ
0285デフォルトの名無しさん
2007/01/11(木) 20:03:56> 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 つけて宣言しないと
シンタックスシュガーでセッターゲッターにアクセスできなかったりする。
0286デフォルトの名無しさん
2007/01/11(木) 20:22:31でも、これって 5文字ぐらい節約できるってだけなんだよねぇ……
0287デフォルトの名無しさん
2007/01/11(木) 22:05:40いやいや違う、漏れが言いたいのは
//フィールドの定義
private int fieldX = 0;
//値をセットするときに必要な特殊処理
public void setX(int x){
this.fieldX=x;
this.logic();
}
//プロパティの定義でgetterはそのまま使って、setterはメソッドを使う
property int x read fieldX write setX;
イメージ的にはこんな感じ。ほぼObjectPascalなんだけどさ。
フィールドの定義は省略して、暗黙的に定義してくれるとなおよさげ。
0288デフォルトの名無しさん
2007/01/11(木) 22:43:37その辺は どー転ぶかわかんない。property 自体却下される可能性もあるし。
とりあえず >>283 のプロトタイプだとできない。
> property int x read fieldX write setX;
この構文だと、Java では フィールド名と同じメソッド名付けられるから
fieldX って名前のフィールドに加えてメソッドまであったらどーすんだろ、とか
setX 以外の名前が指定できると、現在既にあって setX を期待してる
フレームワークが困りそうだなぁ、と思った。
0289デフォルトの名無しさん
2007/01/12(金) 23:43:12Eclipse FoundationがJCPメンバーとして参加することに
なったらしい。ちょっと前にEclipse代表のMike Milinkovichが
JSR277とJSR291の進行に激怒してたからなんかやるだろうなとは思ってたけど。
JSR291に反対票投じたRedhatも先月推進派に転じたみたいだし、さらに今度の
Eclipseの票も加えて1/16～22にあるJSR291の投票をのりきりたいんだろうね。
0290デフォルトの名無しさん
2007/01/16(火) 01:46:34setXxx、getXxxっていうのをプロパティとみなす仕様は変えれないと思うよ。
IDEのプロパティエディタやらJSPのELやら、既存のツールやライブラリが使えなくなる。
0291デフォルトの名無しさん
2007/01/16(火) 05:09:430292デフォルトの名無しさん
2007/01/16(火) 19:56:31現世代Javaの動向 1
http://pc10.2ch.net/test/read.cgi/tech/1150286189/l50
0293デフォルトの名無しさん
2007/01/18(木) 08:02:25これを作るにはJ2SE,J2EE,J2MEの内、どれが相応しいのでしょうか？
次世代Javaに詳しい方教えて下さい。
0294デフォルトの名無しさん
2007/01/18(木) 08:06:11記事を見て jconsole を使おうとしたんだけど、起動後に "JConsole: Output" っていう
ウィンドウが開いて
java.lang.UnsatisfiedLinkError: no attach in java.library.path
というエラーが表示されるし、ローカルプロセスに接続しようとしても
「接続に失敗しました」となってしまいます。
うまく JVM にアタッチするにはどうしたらいいんでしょうか？
Windows XP, JDK 1.6.0 を使っています。
0295デフォルトの名無しさん
2007/01/18(木) 19:15:17構成が今一良く分からない。Webサーバ＋P2PでUIがブラウザなわけかい？
J2EEのServlet（Jettyあたり）を落としてきて、残りはSEでガリガリ書きなさいな。
0296293
2007/01/19(金) 07:57:58P2Pでコミュニティとファイル共有システムを作って、ソフトウェアで提供しようとしているので、
中継ノードでピュアP2P型にするか、中央サーバーでハイブリッドP2P型にするかのどっちかになるのですが、
それぞれJ2SE,J2EE,J2MEのうち、何が相応しいのでしょうか？
教えて下さいませ。
0297デフォルトの名無しさん
2007/01/19(金) 10:32:49まず、J2SE,J2EE,J2MEが何かぐらいは調べて置いたほうがいいだろ。
それとスレ違い。
0298デフォルトの名無しさん
2007/01/19(金) 15:30:45http://download.java.net/jdk7/changes/jdk7-b06.html
http://download.java.net/jdk7/binaries/
個人的にはまだぱっとした新機能ないなぁ
0299デフォルトの名無しさん
2007/01/19(金) 20:33:11Generics環境へのGOサインを導き出してくれることにある。
Java7もXML構文とか登場してまた汚れる（ｗ）から
Java7のデビューはJava8のリリースからとなる。
0300デフォルトの名無しさん
2007/01/19(金) 23:12:57共存させといて問題ないと思うのだが。これのせいで１．４からの移行が進みにくい。
0301デフォルトの名無しさん
2007/01/19(金) 23:15:096は載らなかった機能が一杯あるから枝が付くとなんとなく思ってるが
0302デフォルトの名無しさん
2007/01/20(土) 01:27:400303デフォルトの名無しさん
2007/01/20(土) 01:29:35どういうこと？
0304デフォルトの名無しさん
2007/01/20(土) 01:55:040305デフォルトの名無しさん
2007/01/20(土) 02:22:19非推奨だなんて注釈もdocタグも無いはずなんだが。
0306デフォルトの名無しさん
2007/01/20(土) 02:28:021.5.1 とか 1.6.1 とか出さないって言ってなかったっけ？
0307デフォルトの名無しさん
2007/01/20(土) 03:06:14注: ArrayListDemo.java の操作は、未チェックまたは安全ではありません。
注: 詳細については、-Xlint:unchecked オプションを指定して再コンパイルしてください。
0308デフォルトの名無しさん
2007/01/20(土) 03:17:360309デフォルトの名無しさん
2007/01/20(土) 06:46:59<?>の方がよくねぇ？
0310デフォルトの名無しさん
2007/01/20(土) 13:18:36型パラメータが付いたThrowableのサブクラスを作りたい。
例えば、
class IORuntimeException<IOException> extends RuntimeException{
}
のように定義して、
catch(IORuntimeException e){
throw e.getCause(); //<--IOExceptionをスロー
}
と使えると最高。
0311デフォルトの名無しさん
2007/01/20(土) 15:38:320312デフォルトの名無しさん
2007/01/20(土) 15:49:490313デフォルトの名無しさん
2007/01/20(土) 16:06:04Closure で例外を透過的に使うために、ってんで検討はされてるけど、
>>310 みたいな気持ち悪い奴じゃない。
0314デフォルトの名無しさん
2007/01/20(土) 16:31:14Thoughts about the future of the Java Programming Language.
ttp://gafter.blogspot.com/index.html
0315310
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();
}
}
}
0316デフォルトの名無しさん
2007/01/21(日) 02:15:50> }cathc(ExceptionWrapper<T> e){
……。
ってか、普通に考えて ExceptionWrapper<InvocationTargetException> と
ExceptionWrapper<IllegalAccessException> が実行時に同じクラスに
成り下がりそうで拙いよね……
まぁ、ある意味では「色々面白そう」だけど。
0317デフォルトの名無しさん
2007/01/21(日) 11:26:48問題ないはずだけど
>>308
は旧式のライブラリとの境目で使う
事実上JPAでも必須だけど
>>309
明示的にするなら<Object>のほうがいいとおもう
ただ、これを使ってる時点でGenericsの恩恵ゼロだけどね
従来のライブラリ葉変更せずに使う場合>>308を接合部分につかってラッピングするべし
0318デフォルトの名無しさん
2007/01/23(火) 10:31:36そうすると標準ライブラリだけでXML何でもあり状態で便利なんだが。
EEは需要ありそうだが・・・
ただでさえjdk6は標準ライブラリだけで近代的なブラウザが書ける奇抜な言語だぜｗ
0319デフォルトの名無しさん
2007/01/23(火) 15:43:59Java SE 6へ移行する理由と移行をとどまる5つの理由
http://www.atmarkit.co.jp/fjava/column/andoh/andoh32.html
0320デフォルトの名無しさん
2007/01/23(火) 18:04:30Itanium 1、2がサポートされなくなったのか。
Itanium おしまいだな。
0321デフォルトの名無しさん
2007/01/23(火) 21:53:16なんか、細かいミスというか認識不足が多すぎる気がするよ。
Java SE 7は、もうDolphinとは呼ばれてないはずだし。
0322デフォルトの名無しさん
2007/01/23(火) 21:59:450323デフォルトの名無しさん
2007/01/24(水) 18:06:01正式リリースされている 6系の話題は、現行スレでお願いします。
0324デフォルトの名無しさん
2007/01/24(水) 19:59:040325デフォルトの名無しさん
2007/02/02(金) 17:04:58http://download.java.net/jdk7/changes/jdk7-b07.html
http://download.java.net/jdk7/binaries/
やはりまだnew featureよりバグフィックスが目立つ
0326デフォルトの名無しさん
2007/02/02(金) 18:15:15いまならJava SE
JDKは開発キットだからな(JREに対しての)
0327デフォルトの名無しさん
2007/02/02(金) 18:16:33> 1.3.1以前のバージョンはEnd of Life、サポート終了の扱いです。
なるほど。古いことは気にしなくて良いとは
気が楽だ
法務省のJavaアプリが古いJVMに
しか対応していなかった問題も解決されると願う
0328デフォルトの名無しさん
2007/02/02(金) 19:20:142世代前のものだから当たり前だが
0329デフォルトの名無しさん
2007/02/03(土) 08:40:58MOJ乙
0330デフォルトの名無しさん
2007/02/08(木) 21:18:56ttp://www.javac.info/closures-v05.html
{int,int=>int} plus = {int x, int y => x+y};
うーん、もすこしメソッドと同じような文法にならなかったのかな・・・
0331デフォルトの名無しさん
2007/02/09(金) 02:06:03新しいのは
・nominal version が消えた。
・ユーザ定義のループ定義が草案入り。
ぐらいか。
より良い構文を考え付いたなら、
そっち方面の人のブログにでもコメントしとけば？
0332デフォルトの名無しさん
2007/02/09(金) 02:06:58MOJ?
何それ？
0333デフォルトの名無しさん
2007/02/09(金) 09:01:30そこの担当者
0334デフォルトの名無しさん
2007/02/10(土) 14:59:270335デフォルトの名無しさん
2007/02/11(日) 20:39:310336デフォルトの名無しさん
2007/02/12(月) 01:18:02ってどっかで見たことあるような
0337デフォルトの名無しさん
2007/02/12(月) 03:26:060338デフォルトの名無しさん
2007/02/12(月) 07:48:170339デフォルトの名無しさん
2007/02/12(月) 13:04:01それはもう古いぞ
0340デフォルトの名無しさん
2007/02/12(月) 13:24:020341デフォルトの名無しさん
2007/02/12(月) 13:42:03ﾜﾗﾀ
0342デフォルトの名無しさん
2007/02/12(月) 14:25:37それはjavax.rmiみたいなパッケージとして存在するし
>>338
今はJava 6 の時代だろ
0343デフォルトの名無しさん
2007/02/12(月) 14:33:13JBuilder Xを連想した。
0344デフォルトの名無しさん
2007/02/12(月) 15:56:360345デフォルトの名無しさん
2007/02/12(月) 17:26:370346デフォルトの名無しさん
2007/02/12(月) 17:58:030347デフォルトの名無しさん
2007/02/12(月) 18:33:410348デフォルトの名無しさん
2007/02/12(月) 18:34:340349デフォルトの名無しさん
2007/02/12(月) 18:35:56Java MEみたいだ
0350デフォルトの名無しさん
2007/02/12(月) 20:05:480351デフォルトの名無しさん
2007/02/12(月) 21:06:04(Java Management Extension)
0352デフォルトの名無しさん
2007/02/13(火) 05:36:140353デフォルトの名無しさん
2007/02/13(火) 15:41:53実行はネイティブみたいだし、
あれはどういうテクノロジーなんでしょうか？
0354デフォルトの名無しさん
2007/02/13(火) 23:17:23eclipseもOOoもネイティブな実行ファイルはただのダブルクリッカブルじゃなかった？
0355デフォルトの名無しさん
2007/02/14(水) 01:53:19Swingのように自前でUIコントロールを描画しているのかねぇ？（謎
0356353
2007/02/14(水) 08:42:19ダブルクリッカブルって何ですか？
OOoはクロスGUIを使ってるからモッサリなんじゃないですか？？？
モッサリでも良いからクロスGUI欲しいお。
0357デフォルトの名無しさん
2007/02/14(水) 08:53:48http://api.openoffice.org/docs/DevelopersGuide/ProfUNO/ProfUNO.xhtml
0358デフォルトの名無しさん
2007/02/14(水) 10:40:15（＞＜；） なんにもわかんないんです！＞＜
/つと ﾉ
しー-Ｊ
0359デフォルトの名無しさん
2007/02/14(水) 13:57:37クロスGUIつーかSwingのLnFが何やってるか知ってるか？
0360デフォルトの名無しさん
2007/02/14(水) 14:12:15/つと ﾉ
しー-Ｊ
0361デフォルトの名無しさん
2007/02/14(水) 14:28:01あれはC++だろ。
0362デフォルトの名無しさん
2007/02/14(水) 14:28:44普通に考えて
Double Click + able
ダブルクリック可能って意味になるだろ
0363デフォルトの名無しさん
2007/02/14(水) 14:30:45http://e-words.jp/w/E383ABE38383E382AFEFBC86E38395E382A3E383BCE383AB.html
http://ja.wikipedia.org/wiki/LnF
0364353
2007/02/14(水) 14:47:38今のSwingってXMLのスキンとかいうやつですか？
そのUIから、実行ファイルみたいなのをキック？
それともJNIコール？
0365デフォルトの名無しさん
2007/02/14(水) 15:03:35言ってる意味がわからないが
勝手に言ってることを予測して答えてみる。
今の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は一切関係が無い。
0366353
2007/02/14(水) 15:09:13で、処理部分はC++を使いたいです。
0367デフォルトの名無しさん
2007/02/14(水) 15:10:08そのときの知ってる人はもう少ないな
あの当時とはもはや別物だと思っていい
WebStartは今はデスクトップやプログラムメニューなどのショートカットに対応
つまり2回目からはブラウザの起動すら必要はない
そしてプログラムの追加と削除でもアンインストールができるようになってる
もちろん今までどおりコントロールパネルのJavaキャッシュからの削除なども出来る
0368デフォルトの名無しさん
2007/02/14(水) 15:18:38かったか?
もしかしてMetalでない各プラットフォームで固有LnFにしたいってだけの
話なら、
String sysLnfClassName = UIManager.getSystemLookAndFeelClassName();
UIManager.setLookAndFeel(sysLnfClassName);
0369353
2007/02/14(水) 15:23:15C++のコードがあるのですが、
GUI部分を１つ定義してWin、MAC、Linux全対応したいです。
そのときにC++側からSwing画面を開けるのかなー？、と。
0370デフォルトの名無しさん
2007/02/14(水) 15:26:58GUIをSwingで作って、エントリとなるメソッドをC++から
キックすればOK。
0371デフォルトの名無しさん
2007/02/14(水) 15:39:37Java2以前ってことはSwingというよりJFC?
XMLスキンは、恐らくSynthLookAndFeel
>>353
やりたいのは、NeoOfficeのやってることだな
GUI描画部分を、Javaにやらせるという
0372353
2007/02/14(水) 15:43:180373353
2007/02/14(水) 15:45:00クロスＧＵＩとして使われてるわけじゃないんだ？
0374デフォルトの名無しさん
2007/02/14(水) 16:34:17ある。C++コンパイラはg++。
製品バンドル版OSXなら一緒にg++を含んだ開発環境(Xcode)メディアも付いて
くるし、無料でダウンロードも出来る。Java環境の最新バージョンは1.6.0。
antも入ってる。
0375353
2007/02/14(水) 16:42:45”Java＆C++”の開発効率がちょっぴり不安。
0376デフォルトの名無しさん
2007/02/14(水) 17:04:19Swingの勉強をする。
0377デフォルトの名無しさん
2007/02/14(水) 17:35:14俺はやったけど、両方わかってりゃ大した事は無かった。
つーても、やっぱc++からjavaオブジェクトを返すのにJNIEnvを使う部分があるんで、そこはちょっと効率悪いかな。
あとJNI部分のデバッグが面倒なんで、c++でロジック書いてJNIで薄くラップしてやる感じ。
java側は、ちゃんとMVCに分けて、DAOをしっかり分離してやりゃOK。
テスト用DAOに差し替えて開発して、最終的にJNIを使ったDAOでテストする。
まー規模にもよるだろうが。
0379デフォルトの名無しさん
2007/02/14(水) 17:51:130380デフォルトの名無しさん
2007/02/14(水) 17:53:03ですが、何か？
0381デフォルトの名無しさん
2007/02/14(水) 17:54:42Swingって落ち目な感じ？
0382デフォルトの名無しさん
2007/02/14(水) 18:03:33SWTとかの代替候補の立場が微妙になってるのが現状じゃね?
0383デフォルトの名無しさん
2007/02/14(水) 18:12:19知らないうちに勢力図が変わるんですね。
それと、デファクトだったEclipseがＳ∪∩の開発環境（何だっけ？）に負けたんでしたっけ？
0384デフォルトの名無しさん
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/
0385デフォルトの名無しさん
2007/02/14(水) 18:27:26去年の勝ち組負け組みでEclipseを最初負け組みと書いて後で消したの
一番使われてるのに負け組みはおかしいといわれたそうだが
0386デフォルトの名無しさん
2007/02/14(水) 18:41:27じゃぁ、NetBeansとSwing使っとけば問題無いか。
Windows上だとちょっぴりモタツクだろうけど。
でも、モッサリドトネト（流行ってないくせにWinForms、WPFと２つあって最悪）よりかはましか。
0387デフォルトの名無しさん
2007/02/14(水) 18:42:36NetBeansがEclipseをやっつけたってことは、
JBuilderとかは無用の長物？
0388デフォルトの名無しさん
2007/02/14(水) 18:50:15以前のSwingではレイアウトマネージャのおかげで、
思ったように画面作り難かったのですが、
今のSwingはポトペタしやすいですか？
0389デフォルトの名無しさん
2007/02/14(水) 18:59:48NetBeans(の5以降で導入されたMatisseというデザイナ)を使うと無茶苦茶ポトペタしやすい。
と、漏れは個人的には思っている。
0390デフォルトの名無しさん
2007/02/14(水) 19:11:20JNI なんぞは、1.1 の頃には既にあったわけなんだが……
誘導
★お前らJavaはJNIで組もうぜ★
http://pc10.2ch.net/test/read.cgi/tech/1033795664/
0391デフォルトの名無しさん
2007/02/14(水) 19:14:29個人的には、GUIポトペタ(←(・∀・)ｲｲ!!)は、Netbeans。
ロジック書き書きは、eclipse。
両方使ってるよ。
NetbeansのSubversionプラグインは使いにくいし。
0392デフォルトの名無しさん
2007/02/14(水) 19:24:34CVSはWinCVS（←もしかしてサイアク？）使ってるんで。
JNIもふつーに使われてますか？
0393デフォルトの名無しさん
2007/02/14(水) 19:27:48【Java】NetBeans Part2【Sun】
http://pc10.2ch.net/test/read.cgi/tech/1154582593/
0394デフォルトの名無しさん
2007/02/14(水) 19:57:46public 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");とか、
さらに、オーバーロード可能にすれば他にも使い方ができそうだ。
0395デフォルトの名無しさん
2007/02/14(水) 20:06:55じゃあ標準出力はSystem("%d%d", 100, 200);でOK？
0396デフォルトの名無しさん
2007/02/14(水) 20:18:36@Alias(value = "ltgt" , type = "literal")//自作リテラル（ここでは<>）
@Alias(value = "plus_equal" , type = "operator")//演算子オーバーロード
これで実装するなら>>394は
@Alias("nameless")
ってとこか
んで、呼び出す対象のフィールドの宣言時も@AliasUsingをつける。
まぁ設計がまずいのに無理やり使わされるのもあれだしね。
0397デフォルトの名無しさん
2007/02/14(水) 21:33:06その文字を見たら昔のSunのCMを思い出した。
0398デフォルトの名無しさん
2007/02/14(水) 21:45:16細かい仕様を定義しようとすると複雑になるし、いかに丁寧に仕組みを作っても雑に使われたら困るもんな。
よく使われるやつだけ今のString型みたいにして、アノテーションで限定解除するだけでいいか。
0399デフォルトの名無しさん
2007/02/14(水) 22:40:43>>396
次世代Javaの動向をヲチるスレであって、
勝手な妄想繰り広げるスレじゃないから。
0400デフォルトの名無しさん
2007/02/14(水) 22:48:56C# の Indexerっぽい奴なら、>>249 とか >>250 とかで既に出てるけど。
演算子オーバーロード関連なら、他にも >>283 の一番上のリンクとかもあったし。
0401ﾈｶﾏ由紀恵
2007/02/14(水) 23:05:20入れなくても良いんじゃ・・？
0402デフォルトの名無しさん
2007/02/14(水) 23:23:43特殊なデバイス叩かん限りpureJavaでいける。
実行速度なんて5.0 6.0で激変したしSwingも1.3→1.4以上でまともになったし。
joy pad使うとかしかJNIの存在理由が見当たらん・・・。
ここら辺は成熟してきたからこれ以上はOpenGLドライバの成熟待ちだろ。ATIもnVidiaも最近のドライバはOpenGLが糞。
そのせいで6.0でもsun.java2d.openglプロパティが使い物にならない。
Java側はドライバの対応を待つしかないからベンダと連携とって行くって言ってるし。
俺はあまり言語仕様を動的にするのには興味ないな。
仕様が複雑化してきてるし当初の仕様ポリシーから外れてきてる気がする。
個人的には値渡しの出来る構造体が欲しいかな。
一々データクラス定義してインスタンス化するのがちょっと・・・
0403デフォルトの名無しさん
2007/02/15(木) 00:06:36public type Hoge{
String hoge;
int piyo;
}
見たいな感じかな。でも予約語が・・・
JavaBeanを簡単に生成できるシンタックスシュガーが欲しいね。
0404デフォルトの名無しさん
2007/02/15(木) 00:36:38そこで、エスケープ解析によるオブジェクトのスタック割り付けですよ。
0405デフォルトの名無しさん
2007/02/15(木) 01:23:08NetBeansの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有効にして動いてたような気がするのが気になる
0406デフォルトの名無しさん
2007/02/15(木) 01:34:56その下の奴って構文解析できるのか？
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);
}
}
とかされたら面倒なよーな気がする。
0407デフォルトの名無しさん
2007/02/15(木) 07:18:52昔は希望を書きまくっていた気もするが？
0408デフォルトの名無しさん
2007/02/15(木) 08:40:38遅いからJNIするんじゃなくて、Win用C++コードをMACに移すためにJNI検討中なんです。
CocoaとかいうやつはObjective-Cだったりして困るし。
0409デフォルトの名無しさん
2007/02/15(木) 08:51:30希望なら言語仕様作ってる人達に見える形でで出した方が通りやすいよ。
ksl とかあるんだし。
https://ksl.dev.java.net/
0410デフォルトの名無しさん
2007/02/15(木) 08:56:41int Integer = 1;
System.out.println( (Integer)+10 );
とかと同じ扱いにすりゃ良いんじゃないかと思ったけど……
参照型へのキャストは 単項+ とか 単項- ついたらいかんのか。
つまり Integer って変数が宣言されてないときに
System.out.println( (Integer)+10 );
がコンパイルエラーになるから参考にならんと。むぅ。
0411デフォルトの名無しさん
2007/02/15(木) 17:24:26ヲチりながら、愚痴るんじゃないの？
0412402
2007/02/15(木) 17:43:18リペイントマネージャ乗っ取って全コンポーネントダーティーだと認識させればユーザーの操作に応じて常にスケーラブルでアジャスタブルなウェジェット組めるが流石にまだ重いだろうなｗ
>ベータ時代は・・・
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はそれでカオスってるｗ
0413デフォルトの名無しさん
2007/02/15(木) 18:05:370414デフォルトの名無しさん
2007/02/15(木) 19:04:29Mac→WinだとMacしかないアプリのDLL使ったりして移植ゼロか、
Win→だとGUI周り以外はそうgdgdにならない？
0415デフォルトの名無しさん
2007/02/15(木) 19:11:21MIDP2.1はハードウェアサポートが強化されてるしウェジェットも地味に強化（新たに取り込まれたオプションパッケージが目立つ）してSEのノウハウもフィードバックされて結構良いんだが・・・
0416デフォルトの名無しさん
2007/02/16(金) 17:45:58OpenGLといえばJava3Dを思い出した。
あちらも気が付けば大きな進展があるようだ。
JavaからOpenGLのライブラリを使えるようにするというやつ。
プラットフォーム非依存と呼ばれているJavaも3Dとなると
そうもいかないケースがあるものだが、
今後のJava3Dは古臭い時代遅れなビデオカードでは動かなく
なるか、(AWTのようにOS依存する)劣化表示
or
(Java2Dを使用したSwingのように)超低速表示されることになるんだろうか。
0417デフォルトの名無しさん
2007/02/16(金) 17:48:15> >>391
> NetBeansのSubversionは動作がよくおかしくなる
> というかAntとかもおかしい気がする
> JDKを5.0にすると安定するから6のVMバグかも
EclipseでJava SE 6でAntを使っているがとくに問題ない。
おかしいってどんなエラーがでるのかね。
Subversionは不安なら、TortoiseSVNでコミットしてみるのはどうだろう。
> >>392
> CVSだったらNetBeans標準装備なんでそれ使えば楽
Eclipseと同じだな。しかしSubversion使ったらもうCVSには戻れない。
それだけ使い勝手が良いから。
0418デフォルトの名無しさん
2007/02/16(金) 20:23:44MFCのようにSwingをラップしたGUIフレームワークが標準でJDKに入らないかな
0419デフォルトの名無しさん
2007/02/16(金) 21:14:44http://jcp.org/en/jsr/detail?id=296
これどうなるかねぇ。
0420デフォルトの名無しさん
2007/02/16(金) 21:17:41Javaから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以上にラッピングされてるのだが
0421デフォルトの名無しさん
2007/02/16(金) 21:21:08https://appframework.dev.java.net/
見てみよっと。
0422デフォルトの名無しさん
2007/02/16(金) 21:55:570423デフォルトの名無しさん
2007/02/16(金) 21:58:35http://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 は既に現行世代だと何度言えば……
0424デフォルトの名無しさん
2007/02/16(金) 22:20:15SessionStorage.WindowState って最大化状態サポートせんのか？ と思って
[email protected] に検索かけたら
https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=129
で、最大化状態は保持してるみたい？
最大化した状態で close(exit)した場合、最大化解除した状態のサイズは持ってないって事かな？
0425デフォルトの名無しさん
2007/02/16(金) 22:30:55最大化解除したサイズって、どっかのメソッドで取れたっけか？
常に Frame のサイズ保存しておきながら WindowEvent おっかけて、
Frame#getExtendedState が MAXIMIZED になったら、
直前のサイズを最大化解除したサイズとして保存するとか、
Windows と他の OS で最大化する時の WindowEvent の届き方が違うので
面倒くさくて Windows だけしか対応しないとか、そんな記憶が……
0426デフォルトの名無しさん
2007/02/16(金) 22:44:31いつものことの上、
修正コードが手早く手にはいるようになっただけで
大助かりですよね。
うまく動かなくなるバグなんて、1.4の頃ですが
GC周り突っつけばすぐ出てきましたよ。
バグ報告しても、US SUNまで訴えても直らないバグがあったりしたもんです。
直るにしても、次のリリースまで待たなきゃ駄目だしね。
0427デフォルトの名無しさん
2007/02/16(金) 22:55:570428デフォルトの名無しさん
2007/02/17(土) 00:06:11んなの初めて聞いた。バグ修正もてえへんだろうなあ。
TortoiseSVNは結構良いと思うけどなあ。ファイルの移動を
するときもわざわざ右クリックでめんどいことしないといけないけどさ。
0429デフォルトの名無しさん
2007/02/17(土) 00:10:08直すのかなり難解だと思うが・・・。
Swingが新しくなるということは、SWTやM$のGUIよりも使い勝手がよいAPIを
作れるのだろうか。
0430デフォルトの名無しさん
2007/02/17(土) 00:11:120431デフォルトの名無しさん
2007/02/17(土) 00:18:35コミットする前に最新状態取得しないとだめってあふぉか
CVSクライアントのほうは問題なし
というかSubversionはCVSのように自前で実装してないからなぁ
CVSモジュールに依存してるし
NetBeans3.6だったかあの時代のCVSサポート並のへっぽこさ
だから標準実装されてないのだろうね
0432デフォルトの名無しさん
2007/02/17(土) 01:02:26> で、最大化状態は保持してるみたい？
保持してないんじゃね？単に最大化したbounds持ってるだけで。
ってか、WindowStateだしな。getExtendedState使えるのFrameだし……
0433デフォルトの名無しさん
2007/02/17(土) 02:32:28SVNはCVSにそんなに依存していたっけか。
0434デフォルトの名無しさん
2007/02/17(土) 08:40:54NetBeansのsubversionモジュールはCVSモジュールに依存している
0435デフォルトの名無しさん
2007/02/17(土) 19:04:07６で異常な進化遂げてるし、ないならないでただのコミニュティー潰しにしか見えん。
あの超進化マジックは何？
ヒープの割当・インクリメンタルＧＣのアルゴリズム変更だけであそこまで変わるとは思えん。
＃まあ日本じゃ未だに1.4.2主流だしse7も迷走中だけど。
そろそろstaxとrhinoが使われだしても良いと思うんだ・・・
0436デフォルトの名無しさん
2007/02/17(土) 19:13:41なんだ、そういうことか。
CVS嫌いなSubversion開発者は自分のSVN開発を批判する者に
対してかなり起こっていたからな。
「すでにCVSがあるのに、なんで独自に開発するんだ？」と質問された
ことについてもう反論していた気がする。
0437デフォルトの名無しさん
2007/02/17(土) 20:01:54インクリメンタルGCの変化あったの?
5.0のときにトレインアルゴリズムつかわなくなってコンカレントGCになったけど
またかわったの？
速度は強度の最適化がクライアントVMでかかってるのがわかる。
演算系でサーバーVMとほぼ同じ速度が出たのはわらえた。
だからサーバーVM同梱してないのだなと。
0438デフォルトの名無しさん
2007/02/18(日) 18:07:24とかいうものに変更されたとは聞いているが、そんなに効果があったのかー
Linear Scan Register Allocation
http://www.research.ibm.com/jalapeno/papers/toplas99.pdf
0439デフォルトの名無しさん
2007/02/18(日) 19:25:030440デフォルトの名無しさん
2007/02/19(月) 12:35:310441デフォルトの名無しさん
2007/02/19(月) 12:59:36インクリメンタルGCが、コンカレントGCに置き換えられたのは6からじゃなかったっけ？
5の段階では、Xinc使うなって言われてて・・・・
何か自信ないけど、パフォーマンスアップは、GCだけじゃないってのは賛成。
むしろ、Hotspot系だと思うな。
エスケープ分析効いてないかな？
というか、JDK7で盛り込むJVMの改良ってどっかで話題になってる？
JVMの機能強化ってJCPに乗らないと思うし・・・
0442デフォルトの名無しさん
2007/02/19(月) 13:03:381.4.1だったかあたりからインクリメンタルGCは採用する価値のないものだったからいい変更だと思ったけどね
トレインアルゴリズムを使いたかったらXXオプションで指定すれば5.0でも使えた
GCの性能アップだけじゃパフォーマンスが落ちるのを防ぐだけであって性能は上がらないからGC以外が主なパワーアップだろう
６でのGCチェックはまだしてないけど、5.0でGCが10、20%性能上がってたのは有名かと
0443デフォルトの名無しさん
2007/02/20(火) 19:28:140444デフォルトの名無しさん
2007/02/21(水) 15:02:25フォントならIPAフォントが抱き合わせライセンスじゃなかったら最強だと思うんだけどな。
所でJavaってGCが勝手にメモリガリガリやってるから
メモリの断片化をプログラマで制御出来ないよな？
長期間不眠不休なサーバーとかメモリ空間少ないJ2MEが辛いと思うんだけど、
今後ここら辺の解決策はないの？
緩和でも・・・J2MEのプリベリファイは良い案だったと思うんだ。
＃そういやse6でもプリベリファイ採用してるからそれが実行速度に献上してるかもな。
今思い出したｗ
0445デフォルトの名無しさん
2007/02/21(水) 16:32:00System.GCしか今のところコントロールする方法はない。
あとはVMの実行時パラメータでヒープやアルゴリズムの調整でカバー。
ただ、System.GCはほとんどの実装でFullGC動くので実質使っちゃダメ。
System.newGCとかがあればかなり変わるんだろうけど。
ゲームとかにしろ常にシビアなタイミングがあるわけじゃなくて、今は100μsも遅れるとまずいけど
このタイミングなら10msは大丈夫とかあるからね。
1フレームに1回殿堂入りさせない新世代GCが指定できればそれでおけ。
どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
0446デフォルトの名無しさん
2007/02/21(水) 17:33:20> メモリの断片化をプログラマで制御出来ないよな？
↑出来る処理系ってあるの？
0447デフォルトの名無しさん
2007/02/21(水) 17:47:52C/C++だとメモリ管理は自分でするから確保も解放も
自分のタイミングで出来るって程度の意味だ。
勝手なタイミングでガンガンGCされるより断片化起こらないよねって話な。
0448デフォルトの名無しさん
2007/02/21(水) 18:01:42それはおかしい
断片化と解放とは別の話だろ
それにC++だってアロケートしなおししないと同じだし
JavaのGCはそのタイミングをコントロールできないという点だけが問題
0449デフォルトの名無しさん
2007/02/21(水) 20:44:23-XX:+ExplicitGCInvokesConcurrent
で、Java6なら完全停止は回避できる、のかな？
ttp://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/cms-6.html
0450デフォルトの名無しさん
2007/02/21(水) 23:45:23mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に
placed newでオブジェクト作れば、制御できると思う。
制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。
0451デフォルトの名無しさん
2007/02/21(水) 23:50:06GC でコンパクションが発生するのに断片化って???
0452デフォルトの名無しさん
2007/02/21(水) 23:53:010453デフォルトの名無しさん
2007/02/21(水) 23:57:03いつもの事だ。
0454デフォルトの名無しさん
2007/02/22(木) 00:01:05> >>444
> System.GCしか今のところコントロールする方法はない。
java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。
0455デフォルトの名無しさん
2007/02/22(木) 00:02:05> >>444
> どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、
> 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。
彼らがJavaを作った目的は家電制御なんだけどな。
彼らはサーバを発電所のように使うものを想定している。
0456デフォルトの名無しさん
2007/02/22(木) 00:04:13Bufferインタフェースを使って
巨大な配列を確保すれば
擬似的に管理できないこともないぞｗ
C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。
Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw
0457デフォルトの名無しさん
2007/02/22(木) 00:05:52香具師はいないのね
0458デフォルトの名無しさん
2007/02/22(木) 00:14:10そりゃ、居ないだろ。
あれは到達可能でなくなった事を知るためのもので、
到達可能でなくす事を可能にしてくれるわけじゃない。
0459デフォルトの名無しさん
2007/02/22(木) 01:27:33それ定期的に出てくるけどぜんぜんコントロールできねーよ
0460デフォルトの名無しさん
2007/02/22(木) 13:56:010461デフォルトの名無しさん
2007/02/22(木) 21:22:260462デフォルトの名無しさん
2007/02/23(金) 00:09:490463デフォルトの名無しさん
2007/02/23(金) 00:26:430464デフォルトの名無しさん
2007/02/23(金) 00:27:32あんな仕様では当分Javaには勝てないことがわかった。
D言語やC#のほうが全然魅力的だった。
0465デフォルトの名無しさん
2007/02/23(金) 00:31:080466デフォルトの名無しさん
2007/02/23(金) 01:51:350467デフォルトの名無しさん
2007/02/23(金) 01:57:48チンコの仕様に優れていても、使用に優れてない奴とかいるし。
0468デフォルトの名無しさん
2007/02/23(金) 02:01:08チョンのチンコの仕様は9cmで世界一ミクロ
0469デフォルトの名無しさん
2007/02/23(金) 02:06:380470デフォルトの名無しさん
2007/02/23(金) 04:24:39http://download.java.net/jdk7/changes/jdk7-b08.html
http://download.java.net/jdk7/binaries/
サマリが何も出来ていない
変わってないのかっ
と疑問も持ちつつUpdateする俺でした
0471デフォルトの名無しさん
2007/02/23(金) 05:02:190472デフォルトの名無しさん
2007/02/23(金) 06:35:41最近標準化連中は仕様作り過ぎｗ
C++のexportみたいにry
コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
みたいにさ。
マジレスするとunsignedが欲しい。
static final unsigned byte の範囲の定数が欲しいのにって度々思う
#Java書いてるとshortの存在を忘れてint使っちゃう俺
0473デフォルトの名無しさん
2007/02/23(金) 07:56:31>static final unsigned byte の範囲の定数が欲しいのにって度々思う
short や int じゃだめってこと？
ケータイJavaかなんかかな。
0474デフォルトの名無しさん
2007/02/23(金) 08:57:090475デフォルトの名無しさん
2007/02/23(金) 10:10:27そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
ビット操作中心なんで負数は使えんし、
そもそもMEで使わんディスクスペースとヒープを確保する余裕はない！
そもそもstatic finalなフィールドすら宣言する余裕なんて無いんだよ。
文字列定数の長さを気にする様な世界だ。
ややこしい・・・
0476デフォルトの名無しさん
2007/02/23(金) 11:16:49嫌がらせだなｗ
0477デフォルトの名無しさん
2007/02/23(金) 11:19:44ビット操作でも負数は使えるはずだが
0478デフォルトの名無しさん
2007/02/23(金) 12:33:58どうせ作ってたらサイズでかくなって定数をプリプロセッサやエディタの置換なんかで
マジックナンバーに展開して定数フィールド排除、
クラス名・メソッド名・フィールド名・インターフェイス名何かをAとかBとかにして長さ短くしてそもそもOOP何か無視して設計して
昔はそれでもダメなんでバイナリエディタで無駄なバイトコード手作業で最適化してサイズ落としたよ。
（まあ、今は難読化だけで間に合うが）
そんなんでshortとかintとかlongなんて無駄に使ってられませんｗ
少数も勿論固定少数点数ですｗ
XML1.0とXML in Namespace 仕様フルサポートしたライブラリ書いてjarサイズが50K台じゃでか過ぎるって世界だぜ・・・orz
一般的にはCLDC用のXMLパーサって10K台だよ。
＃つくづく趣味グラマで良かったと思うこの頃。
よくopera mini何て出来たもんだ
0479デフォルトの名無しさん
2007/02/23(金) 13:38:05> CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。
> 最近標準化連中は仕様作り過ぎｗ
> C++のexportみたいにry
> コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！
> みたいにさ。
> マジレスするとunsignedが欲しい。
> static final unsigned byte の範囲の定数が欲しいのにって度々思う
> #Java書いてるとshortの存在を忘れてint使っちゃう俺
ラッパークラス作れ
0480デフォルトの名無しさん
2007/02/23(金) 13:54:21> >>473
> そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。
今はJ2MEではなくJava ME。
つうか、もうそろそろ、スペック問題解決してもいいのでは。
昔と比べ、容量は10倍以上になったんじゃないのか？
S!アプリももう何年か前から1MBアプリを作れるようになったし
iアプリも903iからDoja5.0になって1MBにもなったし、今やダウンロード、スクラッチパッドの境界が
無くなって外部メモリも使えるようになって1MB以上のアプリも作れるようになったろ。
昔の10kB時代と比べたら全然気にしなくても良いようになってきたんではないのか？
0481デフォルトの名無しさん
2007/02/23(金) 13:55:320-127に加えて-1か128を128替わり使えばいいのではと
0482デフォルトの名無しさん
2007/02/23(金) 13:56:13とりあえず新たにデータ型作るってのはどうよ
0483デフォルトの名無しさん
2007/02/23(金) 13:57:12jarsで圧縮率を上げればjarサイズが半分になるぜ
0484デフォルトの名無しさん
2007/02/23(金) 21:57:02言語仕様で決まってなかったっけ。
0485デフォルトの名無しさん
2007/02/23(金) 22:04:07使えるのか？
0486デフォルトの名無しさん
2007/02/23(金) 22:05:35決まってない。final で修飾されて、確実に定数式で初期化される変数だけ。
それに、ME とかの場合は static final な変数自体も節約したいんでしょ。
0487デフォルトの名無しさん
2007/02/24(土) 03:48:32使えない。VM仕様がJITがオプション扱いでブートストラップクラスローダしかない1.4か1.3時代程度だったとオモ。
けどジェネリックスなんて使うケースないと思う。
MEじゃあるべき処理を平気でとっぱらうからアルゴリズムの使い回しとか不要。
他にも汎用データクラス作るんじゃなくて一つのクラスに全てのデータと処理をぶち込むからジェネリックスの立場がない・・・。
インターフェイスすら排除する世界だぜｗ
ところでこんなリスト見つけた。VM仕様関連の情報らしい。
ttp://www.ingrid.org/java/vm/
0488デフォルトの名無しさん
2007/02/24(土) 12:23:48ジェネリクスはコレクションを手軽に扱うためだけとおもっても十分な効果が出るよ
0489デフォルトの名無しさん
2007/02/24(土) 12:59:51まだ搭載できないでいるのか・・・
しかもまたまた1.3レベルとは。assertも使えぬのか。
アノテーションくらいはつかえたほうがいいとは思うのだが。
コンパイル時には無視できるタイプのアノテーションはとくにあったほうが便利だろう？
それに、いくつかクラスやメソッドが増えているし。
制約上全部は使えないとは思うけど、利便性を考えると、1.3レベルってつらそう。
0490デフォルトの名無しさん
2007/02/24(土) 13:32:37> ttp://www.ingrid.org/java/vm/
古いね。デッドリンク多いし。
0491デフォルトの名無しさん
2007/02/24(土) 15:42:08高速化したのはSunのJava SE 5の実装で、Javaっていう規格じゃないだろ。
ケータイって、SunのJVMが主流なの？
0492デフォルトの名無しさん
2007/02/24(土) 17:23:16コレクションFWないよ？レガシーしか。
java.util.*はDataとCalenderが端末依存でGMTすら禄に扱えない。
端末毎に返ってくる値が違う事があるし端末の時計とは
別にＶＭが時計持ってて端末と時間違うし時計アプリなんて信頼できんよ？
UTCなんてない。
これでもちゃんとした仕様の範囲だから困りもんだ。
>>491
主流はアプレックスのJBlend。
一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。
KDDIとかSBM専用のオプションパッケージの実体はcom.jblend.*パッケージが主でリンク用のスタブクラスとJavaDocをCPに公開してるだけ。
最近のSEの仕様の恩恵が受けられないのが保守性が悪い悪い・・・
ドコモキャリア仕様の端末以外例外投げると問答無用でVM落とすしエラー出力ないから酷い酷い・・・
クラスローダーがブートストラップのしかないんで動的リンクできんしJarサイズがデカクなるって言うんで汎用のFWは作れんから
再開発部分が多いだろうねぇ。
プリベリファイがSEに取り込まれたんだからMEに何かくれよｗ
0493デフォルトの名無しさん
2007/02/24(土) 17:52:22CLDC 1.1 なら java.util.TimeZone が GMT をサポートするのは義務じゃなかったっけ？
TimeZone は GMT をサポートするけど、それを使っても
GMT な時間が返ってくるとは限らないってオチはあるかもなー、とか思った。
そーいや、JSR-310 で Date and Time API ってのがあったような。
あれって、JDK7 の contents だっけか？
0494デフォルトの名無しさん
2007/02/24(土) 18:28:20System.currentTimeMills()の値を引数にして
DateやCalenderを作っても正確にならない？
0495デフォルトの名無しさん
2007/02/24(土) 18:31:30> >>491
> 主流はアプレックスのJBlend。
> 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。
遅いとかではなく、かれらがハードウェアリソースをケチっているだけだと
いってみたかったりする。
携帯電話をもう少し大型化して、JVMの部分を物理的に大きく専有するようにして、電池も
巨大化させれば携帯電話でも十分早くなるはずだ、と言ってみる。
ハードディスク搭載、とバッテリ寿命さえ延びれば、さらにその理屈もとおるはずだ、と言ってみる。
そして、連中は、独自実装で市場を独占したいだけに過ぎないのだ、
かつてのSonyがやってたような、独自製品で覆い尽くし、ライバル製品との
互換性をわざと奪うために標準Java実装から逃げているだけなのだ、と言ってみせる。
0496デフォルトの名無しさん
2007/02/24(土) 19:48:51いやVectorとかでいいんだよ
それでも十分使い勝手がいい
中に何を格納するべきなのかをドキュメントに書かないとわからないってのは面倒だったりする
そういやJavaME用HotspotVMを開発したとかどっかのニュースみたな
携帯の用途だとhotspotよりはアーカイブ単位での丸ごとコンパイルのほうがよさそうだが
0497デフォルトの名無しさん
2007/02/24(土) 20:10:36IBMの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のときこの部分ごっそり削除してくれるし。
0498497
2007/02/24(土) 20:36:05>static final boolean DEBUG = false;
>public void assert(boolean flag, ...){
> if(DEBUG){
> if(!flag){
> ...
> }
> }
>}
みたいな感じか。細かいことだけど。
0499デフォルトの名無しさん
2007/02/24(土) 20:52:52今ならAspectJでもっと効率よくできるかな？
0500デフォルトの名無しさん
2007/02/24(土) 22:31:51確か仕様上は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騒動であれだけカオスったのに。
0501497
2007/02/24(土) 22:46:46IBMがつくったコンパイラは例えば
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とは別物だよ。
0502デフォルトの名無しさん
2007/02/24(土) 23:54:51もうさ、メガアプリ限定にしてしまえばいいよ。
俺たちが作りたいソフトはこういうものだから、
ハードウェアをもっと強化しろ！
とハード屋に圧力をかけてさ。
マイクロソフトみたいに力がないと
Vistaみたいな激重Windowsを開発してハードウェア屋が
それに追従するってこと難しいかな。
今はハード基準で携帯電話開発を強いられているみたいだけど、
ソフト屋からハード屋になんとかして圧力かけられないかねえ。
「お前らハード屋がだらしないから携帯電話開発がしづらいんだ！
ハードのスペックを高めることを要求する！」
みたいにさ
0503デフォルトの名無しさん
2007/02/24(土) 23:58:12> >>496
> いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。
java.nio.Bufferを実装したクラスを配列代わりに扱えば高速化するのでは？
と思ったら、あれJ2SE1.4からのものだった。
> >>497
> 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。
SoftBankもまともじゃないし、KDDIもまともじゃないし、Docomoもどいつもこいつも
独占欲だけは高いからねえ。
ハードウェア重視でソフトウェアをなめてかかっているところが、だらしないよ。
日本の有名な大手家電メーカーがインターネット産業ろくに力を注がず、Web2.0に
乗り遅れたことをも証明しているし。
0504デフォルトの名無しさん
2007/02/25(日) 00:04:27とは言え、行き過ぎると Vista や PS3 の二の舞になると思うよ。
0505デフォルトの名無しさん
2007/02/25(日) 00:42:46どちらにしてもオープン標準のJava仕様がないがしろにされてるな。
まあ、ソフト屋ですら飼いならされてる現状じゃ仕方ないか。
仕様の地位をもっとこうW3C勧告の仕様並みに出来んかねぇ？（IEの糞実装さえなくなれば平和だからなアッチは）
ハードの方は十分にパワフルだと思うけどな・・・
翌々考えたら昔はメモリ以外今の携帯以下のハードと糞ＯＳでJavaが動いてたんだから。
win95よりce5のが安定してるしｗ
国内携帯は無駄な機能に溢れ返ってるからそれにシステムリソースとコストと
開発期間が圧迫されて一ソフトウェアどころじゃないだろうな。
またしても仕様の地位不足か・・・
SUNの苦労体質全部をJavaが担ってる気がするｗ
0506デフォルトの名無しさん
2007/02/25(日) 01:02:42パワフルな割には容量が足りないってどういう事なんだろうなあと思うよ。
メモリもっと増やすべき。でないととてもパワフルじゃないな。
現実問題として電力消費が激しいと言う問題があるそうだ。
しかし省エネ型DRAMのようなメモリがもっと普及すれば解決できるんだとか。
つうか、携帯電話会社は、余計な機能にエネルギーを無駄に費やさず
Javaの部分にエネルギーを費やして欲しいな。
あらゆる機能をJavaを中心に動かせるようにすれば水平ポータビリティを
維持できるし、どの携帯電話でも同じように動くアプリを簡単に作れるようになる。
0507デフォルトの名無しさん
2007/02/25(日) 01:23:02建前上JBlend on BREW（サービス名オープンアプリ/どこがオープン何だと小一時間・・・）のっけましたが？
Javaで水平ポータビリティ実現すればsunの当初の目的が実現するな。
その為にはベンダーに協力してもらわんとダメだが。
その前に日本の携帯ビジネスモデルを破壊しないと受け入れられないだろう。
4G携帯なんて出したらドコモが死守してソフトバンクが
嘘ばら蒔いてイーモバとウィルが歓迎するんだろうな。
KDDIはBREW動いて音楽と動画DL出来れば何でも良さそうだが。
ネイティブ開発は個人には不可能か敷居高いだろうしJava（MIDP）流行らんもんかね
0508デフォルトの名無しさん
2007/02/25(日) 01:38:36審査に金かかるわ時間もかかるわ。
0509デフォルトの名無しさん
2007/02/25(日) 06:56:240510デフォルトの名無しさん
2007/02/25(日) 07:12:430511デフォルトの名無しさん
2007/02/25(日) 10:59:44今の技術では、携帯に望みすぎ。
0512デフォルトの名無しさん
2007/02/25(日) 12:55:29燃料電池またはＨＤＤが搭載されるもしくは
PDAなどもっと大型の携帯端末なら、
Javaをやる価値は少しはあるのではないかと言ってみる。
携帯キャリアメーカーもJavaに自分たちの収入源を
奪われるのを恐れて、わざとJavaの機能を制限して
Write Once, Run Anywhereの妨害をしているとおもうけどな。
彼らの、Javaの普及を妨害するやり方はつくづく陰湿だと思う。
0513デフォルトの名無しさん
2007/02/25(日) 13:37:18CPUのクロックだけで比べても意味がないぞ
0514デフォルトの名無しさん
2007/02/25(日) 21:46:090515デフォルトの名無しさん
2007/02/25(日) 22:17:51すごく間違いだと思うなあ。Java熱に浮かされてただけじゃないかな。
0516デフォルトの名無しさん
2007/02/26(月) 03:24:52今に間違いじゃない日が来るって
おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
５年前に予想してたか？
>>512
わざとっていうか、自由はセキュリティリスクを持っているからな。
徐々に拡大してけばいいだろう
何でも出来る穴だらけの何かがデファクトになるのが怖いよ
0517デフォルトの名無しさん
2007/02/26(月) 04:23:39>今に間違いじゃない日が来るって
それって、今は間違いってことじゃん。
間違いじゃない日がきてから実用化すればいいのに。
なんでJava以外の選択肢を考えないのかね。
Collectionも使えないなんて、そんなんJavaじゃねーよ。
道具は適材適所。そこまでしてJavaにこだわるのが分からん。
0518デフォルトの名無しさん
2007/02/26(月) 06:53:19それどころかボロクソに言われてた
昔はAWTすら使いもんにならなかった気がする。もっとスリムだったし。
0519デフォルトの名無しさん
2007/02/26(月) 08:18:20新型レンダラまだー？
0520デフォルトの名無しさん
2007/02/26(月) 09:07:330521デフォルトの名無しさん
2007/02/26(月) 10:50:29ただ、フルスクリーン時にGLCanvasが描画されないプラットフォームがあるとかが気になる
GLJPanelは遅くてゲームなどでは実用にならないし
あと日本語ドキュメントが皆無なのがきついな
OpenGL部分はどうでもなるがそこ以外が追うのがきつい
JOGLがコアAPIになればJOGL自体の機能も充実してくると思われ
0522デフォルトの名無しさん
2007/02/26(月) 16:20:42あるとしたら現行Java2Dのハードウェア支援コードとの統合くらいじゃない？
どちらにせよいつの時代もOpenGLはデスクトップ向けVGAのドライバ対応が中途半端だからな。
ワークステーション向けは知らんが。
0523デフォルトの名無しさん
2007/02/26(月) 16:59:41> >>510
> 今に間違いじゃない日が来るって
> おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を
> ５年前に予想してたか？
> >>512
> わざとっていうか、自由はセキュリティリスクを持っているからな。
> 徐々に拡大してけばいいだろう
> 何でも出来る穴だらけの何かがデファクトになるのが怖いよ
多重継承も演算子オーバーロードも何でもできますよとPRする
C++言語仕様じゃあるまいし。それはちょっと違うだろう。
Javaでできることはいっぱいあるのに、あえて彼らがそれをやらないのは
彼らが己の既得権益が破壊されるのを恐れているから。
日本企業はハードウェアに強い企業は多いけどソフトウェアには弱い
企業ばかりだからね。ソフト屋にハード屋をつぶされるのを恐れている。
その構図は、テレビ局などのメディアがインターネットを嫌っている理由に非常に良く似ている。
彼らがインターネットやGoogle、Web2.0を嫌っているのは、
彼らが苦労して長い時間をかけて培ってきたノウハウを破壊されるのを恐れているから。
彼らは小泉純一郎のような「痛みを伴う改革」や「格差社会」に自分たちが巻き込まれる
ことをひどく嫌い、ひどく恐れている。
0524デフォルトの名無しさん
2007/02/26(月) 17:06:04Javaでもこういうことができるよってことで、
とりあえず宣伝だけしておいただけだと思うがな。
いや「だけ」ってことはないな。
Sunが目指していることを実現するための
前準備としての実験でもあったわけだし
一般人にも、Javaというものがどういうものか、
これで理解してもらえたかもしれないね。
最近じゃauの勢力が拡大してどうなるかわからないけど、
一応、BREWの上でJavaも動かせると言われているし。
それに携帯Javaアプリは使えるものはいくつもある。
SuicaのアプリだってＦｅｌｉＣａチップと入出力するところを除き、
アプリケーションはJavaでできている。
なんだかんだいって、燃料電池のような大容量電池を携帯電話に搭載し、
チップが小型化すれば携帯電話Javaもますます良い方向に進んでゆくと
思うけどね。
そこで、Java以外の選択肢を出すと、結局ベンダ依存になってしまう。
今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
基本的なAPIはベンダ依存していない。Java以外の選択肢で、
複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。
BREW開発なんてCPに検査してもらうコストも時間もかかるし、メモリリークの
心配ばかりしないといけないし、容量は相変わらずS!アプリやiアプリの半分くらいでとっても地獄じゃないか。
そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
0525デフォルトの名無しさん
2007/02/26(月) 17:21:02マ板行け。
0526デフォルトの名無しさん
2007/02/26(月) 17:30:02要望も含まれているから、ここでもいいのではないかと
0527デフォルトの名無しさん
2007/02/26(月) 17:35:53要望なら要望聞いてくれるところで言わんと意味無かろうが。
動機からして現状を変えたいというものではなく、
単なる現状の愚痴なわけだし、完全にマ板ネタだろ。
>>523-524 は技術的な話ですらないし。
0528デフォルトの名無しさん
2007/02/26(月) 22:03:340529デフォルトの名無しさん
2007/02/26(月) 23:23:01要望ねえ。JCPか？
0530デフォルトの名無しさん
2007/02/26(月) 23:26:20含まれてないよ。マ板池。
0531デフォルトの名無しさん
2007/02/26(月) 23:29:54営業やってる連中とか、プログラマ卒業した連中とかだと
>>523-524 が技術的に見えるのかもしらん。
0532デフォルトの名無しさん
2007/02/27(火) 03:14:34というか、そろそろ携帯でJavaSE動かすことできそうなんだけど・・・
Mysaifuの取り組みには期待している
0533デフォルトの名無しさん
2007/02/27(火) 06:00:49>今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、
>基本的なAPIはベンダ依存していない。Java以外の選択肢で、
>複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。
ダウト。Write once Run anywhere はケータイでは全然できていない。
APIも仕様も違うのに、簡単とかいうな。お前、じつは作ったことないだろ。
＃何だよ、scratch padって。
#if #else #endif が使えるC++のほうがまだケータイ向き。
でもauの審査がクソ遅いのはなんとかしてほしい。マジで。
> そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
つうかPalmOSが載ってくれれば一番よかったんだよ。なんでJavaなんだ？
0534デフォルトの名無しさん
2007/02/27(火) 07:00:15phoneME Advancedのどこが不満なんだ！ｗ
Mysaifu JVMは俺も入れてるけど・・・。
だって～かんきょうなくてびるど出来なかったんだも～んｗｗ
まあ、冗談は置いといてphoneME AdvancedならRIだし全部入りだしHotoSpotあるし、phoneMEベースのプロジェクトを見かけた事ないのが不思議だ。
てかBREW自体流行ってないし国内じゃあうのせいでBREWの印象悪いし、正直実装さえしてくれたらKJNIの方が良いな。
もうちょっとJBlendがRI通りに実装してくれたら・・・
MIDPにMMAPIのprotocolパッケージ入れてくれたら・・・
WavPlyer実装してくれたら・・・
後はデコードくらい自分でするのに・・・
ところでMEにnioパッケージ実装しても端末の物理メモリが足りませんって落ちになるんだろうか？
0535デフォルトの名無しさん
2007/02/27(火) 07:09:12M1000ってPalmじゃなかったけ？
MIDPが使えるからkjavaじゃなくてMIDP for Palm OSなんだろうか。
0536デフォルトの名無しさん
2007/02/27(火) 12:07:15キミら、次世代と関係ない話題は他所でやってくれんかね？
次世代っても、勝手な妄想とか勝手な要望とかは愚痴と変わらんのよ。
便所に「税金安くしてくれ」って書いて要望とか言わんでしょ。
0537デフォルトの名無しさん
2007/02/27(火) 19:04:270538デフォルトの名無しさん
2007/02/27(火) 20:21:12http://journal.mycom.co.jp/articles/2007/02/26/jsr296/
0539デフォルトの名無しさん
2007/02/27(火) 21:17:25フレームワークがはやったから作っただけというのが近い
struts以上に薄いラッパだし、SwingWorerとダブるところも多いし
これほどメリットがないフレームワークってのも珍しい
0540デフォルトの名無しさん
2007/02/27(火) 21:33:510541デフォルトの名無しさん
2007/02/28(水) 09:38:38> >>524
> #if #else #endif が使えるC++のほうがまだケータイ向き。
> でもauの審査がクソ遅いのはなんとかしてほしい。マジで。
プリ糞セッサに依存している時点で設計が全然駄目じゃん。
> > そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。
> それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。
Python載せられることのどこがいいの理解できない。
0542デフォルトの名無しさん
2007/02/28(水) 22:01:150543デフォルトの名無しさん
2007/02/28(水) 22:22:37んー、まえもimodeスレかMIDPスレで書いたけど、#ifdefのような条件
コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だよね。C/C++の後追いだからちゃんと考えられてる。仕様書よんでごらん。
そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。まあ
マクロはないから文法ひっくりかえすような表記でコードは書けないけど、
それはC/C++でも行儀良くないからな。
0544543
2007/02/28(水) 22:31:04http://techon.nikkeibp.co.jp/article/HONSHI/20070220/127928/
↑
OSGi(JSR232)はJavaMEの分野では静かに着々と浸透しているのに
SEへの導入(JSR291)は及び腰なんだよな、Sun。自分で旗振って
OSGi始めたのにいまさら梯子外すのはないよなあ。
0545デフォルトの名無しさん
2007/03/01(木) 09:21:12>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
だからそれはJ2SEのような環境が統一されている場合の話であって、
機種依存が激しい携帯ではなりたたないって。
VMですら機能やバージョンが違うのに。
>そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ
>併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。
インライン展開があればプリプロセッサは必要ないという根拠が分からん。説明よろしく。
0546デフォルトの名無しさん
2007/03/01(木) 10:02:45>#ifdefのような条件
>コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん
MEで一つのソースの中に複数ターゲット向けのコード混ぜたら絶望的なソースになるよ？
最低プロファイル・機種毎にソース分けんと確実に死ねる。
jadも分けんとたまにハマるから油断できん！
0547デフォルトの名無しさん
2007/03/01(木) 10:13:36システムが勝手に走らせる特定のスレッドの実行が一定時間以内に終わらないと強制終了とか。
実行時例外catchしてcatch節でコード実行すると問答無用で落とすとか（catchしても何もしなければ良かったり、ときにはcatchすら許してくれない）
あと実機じゃ機嫌悪いと動くコードもマジで動かん。
MEでプリプロセッサ使ったソースなんて保守以前の問題。
0548デフォルトの名無しさん
2007/03/01(木) 10:58:01>だからそれはJ2SEのような環境が統一されている場合の話であって、
>機種依存が激しい携帯ではなりたたないって。
>VMですら機能やバージョンが違うのに。
つーか、J2SEでも、Sun/IBM VM間のクセの違いの吸収や、
Sun VMでもSwingの1.4, 5, 6での差を吸収させるのに、#ifdefは欲しい。
0549デフォルトの名無しさん
2007/03/01(木) 11:39:58MEやれ
0550デフォルトの名無しさん
2007/03/02(金) 00:07:56SEで、ifdefは勘弁して欲しい。
それなら、せめて其処のコードは別クラスに分けて設計してくれよ・・・
0551デフォルトの名無しさん
2007/03/02(金) 20:50:21http://download.java.net/jdk7/changes/jdk7-b09.html
http://download.java.net/jdk7/binaries/
何だろう？2回続けてサマリがないビルドだ・・・
まあ今回もupdateするけど～
0552デフォルトの名無しさん
2007/03/02(金) 21:32:24>>470 のリンク先見たら前回のは出てる。
ビルド方法でトラブってて changes が自動生成できてないから、
後から手動で生成してるとか？ それとも単に怠慢で遅れてるだけ？
0553デフォルトの名無しさん
2007/03/03(土) 07:27:48例：List<Integer> listのInteger
0554デフォルトの名無しさん
2007/03/03(土) 08:19:37べつに無理にJava標準に含めることを早めなくても問題なかろ。
早めることよりもむしろ、理にかなってこそ導入すべきだが。
Javaを駄目にするおそれがあるとしてJavaに導入することをまだ認めていないだけだと思うぞ。
JCPは少なくとも、Java SE 1.3以降からの上位互換性をもの凄く気にしているようだから
下手にほいほいと導入するわけにはいかんでしょうや。
そう考えると、enum型の導入が遅くなった理由もなんとなくわかる。
OSGiはなぜかEclipse Communityががんばっているようだし。
Eclipseのプラグインフレームワークに導入されているが、
SunとIBMだもんね。そういうところでは決して仲がよいとはいえないしねえ。
SWTを巡る技術的な問題もあるし。Swingは遅いからSWTを作ったと主張してきたIBM
に不信感を抱いているのではないかな？
0555デフォルトの名無しさん
2007/03/03(土) 08:22:53駄目だお前。
ソフトウェア工学をなめとる。
修行が足りんぞ。
0556デフォルトの名無しさん
2007/03/03(土) 08:24:07get(i)
0557デフォルトの名無しさん
2007/03/03(土) 08:28:45http://download.java.net/jdk/jdk-api-localizations/jdk-api-ja/builds/latest/html/ja/api/java/lang/reflect/ParameterizedType.html
0558デフォルトの名無しさん
2007/03/03(土) 08:50:51$ cat Test.java
import java.util.List;
import java.util.ArrayList;
import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
public class Test {
public static void main(String[] args) {
ArrayList<Integer> l = new ArrayList<Integer>();
Type type = l.getClass().getGenericSuperclass();
ParameterizedType pt = (ParameterizedType)type;
for (Type t: pt.getActualTypeArguments()) {
System.out.println(t);
}
}
}
$ java Test
E
ありゃ。
0559デフォルトの名無しさん
2007/03/03(土) 09:02:20public class Test {
public static void main(String[] args) {
Type type = IntegerList.class.getGenericSuperclass();
for (Type t: ((ParameterizedType)type).getActualTypeArguments()) {
System.out.println(t);
}
}
}
とすると
class java.lang.Integer
となるな。
0560デフォルトの名無しさん
2007/03/03(土) 11:03:18List<Integer> の Integer はコンパイル時に情報消えるよ。
>>559 みたいなのは特殊な例。
0561デフォルトの名無しさん
2007/03/03(土) 11:15:54public class test {
public List<Integer> sample;
public static void main(String[] args) throws Exception {
for (Type t: ((ParameterizedType)test.class.getField("sample").getGenericType()).getActualTypeArguments()) {
System.out.println(t);
}
}
}
>java test
class java.lang.Integer
0562デフォルトの名無しさん
2007/03/03(土) 11:21:520563デフォルトの名無しさん
2007/03/03(土) 14:24:41初心者質問スレ行けよ。
0564デフォルトの名無しさん
2007/03/03(土) 15:28:47㌧
0565デフォルトの名無しさん
2007/03/04(日) 09:29:05追記：
見た目で大きく変わるところ発見。
Javaのウィンドウのデフォルトアイコンがデュークのアイコンになってる！！
可愛いです。
デュークのライセンス変更で、こういう事になったのね
わかりにくいカップよりコレはいいな
0566デフォルトの名無しさん
2007/03/05(月) 16:02:110567デフォルトの名無しさん
2007/03/05(月) 16:44:34実行時に動的でも静的でも良いから invokedynamic 使ったクラス読み込んで、
エラー出たら使えないんじゃね？
そーいや、invokedynamic って今どーなってんだろ？
invokedynamic のオペランドとかの詳細あったっけか？
0568デフォルトの名無しさん
2007/03/11(日) 15:34:36> クロージャよりは揉めずに入りそうな気がしてる。
ウソはいかん。javac の人なんかはイラネって言ってるし。
http://blogs.sun.com/ahe/entry/java_se_7_wish_list
要は、プロパティに dot でアクセスしようとすると、
既存のフィールドアクセスと区別つかなくなるので、後付の面倒なルールを加える必要があるから嫌だそうで。
例えばフィールド宣言したコンパイル単位ではフィールドアクセスで それ以外ではプロパティアクセスとか、
プロパティと同名のフィールド持てないとか、そんな感じのルール。
どんなルールで対処するにせよ、完全な互換性維持は無理だろうし。
もしくは "->" とかでプロパティにアクセスする とかだけど、これはこれでキモイから嫌なんだそうで。
http://weblogs.java.net/blog/forax/archive/2007/01/property_reload.html
ksl でプロパティの試験実装してた人とかも、
Access to property は setter getter で、って意見変えてるし。
0569デフォルトの名無しさん
2007/03/11(日) 17:20:57そうか、キモイか・・・うん、キモイなぁ
dotを使うのは、駄目と言う点は全く賛成だが
表記方法さえ、決まればOKだと思ってるんだけどなぁ
俺は、個人的な好みは->はキモイけど、 : ならOKです。
0570デフォルトの名無しさん
2007/03/11(日) 17:41:54.
.*
->
->*
いろんな言語のaccessor。あと何があったっけ？
0571デフォルトの名無しさん
2007/03/11(日) 17:48:11オレ自身は "->" でもいいじゃん、とか思ってたりする。
他の人が "->" がキモイって言うのも理解できるんだけど。
http://jroller.com/page/scolebourne?entry=property_access_is_it_an
${classInstance.propertyName} みたいに ${} で括った部分では
式言語使えるようにすりゃええやん、ってのも出てるけど……
そこまでして dot に拘らんでも、と思わなくもない。
0572デフォルトの名無しさん
2007/03/11(日) 18:14:36:: じゃなくて : なの？
class A { property Object b; }
class B { property Object c; }
class Hoge {
A a; B b; Object c;
boolean flag;
Object method(){
return flag ? a : b : c;
}
}
とかされると分かりにくくなるよーな気もする。
構文解析自体は結合順位とかがあるから出来ると思うけど。
0573デフォルトの名無しさん
2007/03/11(日) 18:15:17フィールドアクセスとプロパティのインターフェースを別のものにしたら、
単なるgetter/setterの省略表記になってしまってあまりうまみがないと
思うのは俺だけかな？
0574デフォルトの名無しさん
2007/03/11(日) 18:42:44皆が納得できる上手いルールが作れれば dot でも良いと思うけど。
人気がないって言うよりも、>>568 のような追加ルールを決める部分を
誰もやりたがらないような気もする。
簡単なルールで互換性壊したりすれば既存のソース使えなくなった人から嫌われるだろうし、
なるべく互換性維持しようとすると、ルールが複雑になって
今度はコンパイラの作者とかから嫌われるだろうし。
>>132 のリンク先が紹介された後、"->" はキモい、dot が良いって言ってた連中の
blog 見た感じだと、>>568 みたいな問題を小さく考えてるか、
もしくは問題自体を理解してないような。
C# みたく最初から言語機能としてプロパティを持ってる言語ならともかく、
Javaの場合は既存のJavaBeansのプロパティがあって後付けしようとしてるんだから
getter/setter の省略表記と割り切った方が現実的じゃないかな？
0575デフォルトの名無しさん
2007/03/11(日) 22:38:47あ、いや、: ←コロンを使うという意味だった。
Perl、Pnutsなんかで親しんでいる例からいくと、 :: で使うのを想定してた。
一つだと、 hogehoge==null？a : b;
とか、switchが混乱するから。
>>573
いや、むしろそれがいい。
見たら裏で何をしているかがよく分かる。
別に、dotではなくて :: でも可読性は落ちないと思う。
-> は、演算記号と紛らわしくて、嫌。
0576デフォルトの名無しさん
2007/03/11(日) 23:03:00どうせ使えるようにするならマイクロソフト系の言語と同じ記法でいいと思うんだがなあ。
0577デフォルトの名無しさん
2007/03/11(日) 23:08:52具体的には？
0578デフォルトの名無しさん
2007/03/12(月) 03:22:060579デフォルトの名無しさん
2007/03/12(月) 04:10:14VBだとdotじゃなかったっけ？
0580デフォルトの名無しさん
2007/03/12(月) 08:32:28VB,C#ともどっとだね。
仕様策定してる連中がドットを嫌う理由がよくわかんない。
どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
新しくプロパティの意味を持たせても別にいいと思うんだが。
0581デフォルトの名無しさん
2007/03/12(月) 08:50:48C# だと、同名のプロパティとフィールドは同時に宣言できないんだっけか？
まぁ、そーゆー後付けのルール追加すりゃ出来るかもしれんけどさ。
Javaに、そんなルール後付けしたら互換性無くなるし。
なんでこんな簡単な事が理解できないのかわかんない。
0582デフォルトの名無しさん
2007/03/12(月) 08:55:00プロパティ自体後付けじゃん…て思ったんだけど、
setter/getterペアにアクセスする演算子のことなのか。
プロパティ定義の構文も新しく作るのかと思ったよ。
C#の Property Hoge { ～ } みたいにさ。
だったら「そんなもんｲﾗﾈ」に一票だなあ
0583デフォルトの名無しさん
2007/03/12(月) 09:19:05> プロパティ自体後付けじゃん…て思ったんだけど、
JavaBeans のプロパティ自体はあって、その構文糖を追加しなければならない。
だから、完全に後付けってわけでもない。
JavaBeansのプロパティや、それを使ってる既存のフレームワーク捨てるなら別だけど。
あとプロパティ定義の構文を新しく作っても、プロパティアクセスに dot 使えば問題は出る。
例えば、
class MyComponent implements java.beans.DesignMode {
private boolean designTime;
public boolean isDesignTime(){ return designTime; }
public void setDesignTime(boolean f){ designTime = f; }
}
みたいな既存のコードがあるとする。
プロパティが追加されて java.beans.DesignMode が
interface DesignMode {
public static final String PROPERTYNAME = "designTime";
public abstract property designTime;
}
みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。
0584デフォルトの名無しさん
2007/03/12(月) 09:57:09> 仕様策定してる連中がドットを嫌う理由がよくわかんない。
dot 使ったらフィールドアクセスとプロパティアクセスの区別がつかなくなると何度言えば……
0585デフォルトの名無しさん
2007/03/12(月) 10:02:47> どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから
ひょっとして、現存するソースコードに Beans のプロパティ持ってるものが
大量にあるって事がわかってない？
0586デフォルトの名無しさん
2007/03/12(月) 11:37:56それとは別に新しい概念を持ち込むのかと思ってたって>>582に書いたでしょう。
何嬉しそうにツッコミいれてんだよ。
0587デフォルトの名無しさん
2007/03/12(月) 11:41:08いや、無知だなぁ、と思って。
0588デフォルトの名無しさん
2007/03/12(月) 11:51:08どの辺が無知だったか教えてちょ。勉強するから。
0589デフォルトの名無しさん
2007/03/12(月) 11:56:57このスレに出てるのだけでも、プロパティに関するリンク先読んでれば
beans と関係のない新しいプロパティを導入するとか思わんでしょ。普通。
0590デフォルトの名無しさん
2007/03/12(月) 13:21:21そうだな。すまんかった。
0591デフォルトの名無しさん
2007/03/12(月) 20:35:44>みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。
ここがよくわかんないんだけど、誰か解説して。
アクセッサがあればそちらを優先的に使う（あるいは逆にフィールドアクセスを優先する）というルールを決めればすむ話じゃないの？
で、583みたいな状況になったらコンパイラが警告を出してくれればそれでいいと思うんだけど。
0592デフォルトの名無しさん
2007/03/12(月) 20:47:38> アクセッサがあればそちらを優先的に使う
それやったらコンパイルが通らん。
> フィールドアクセスを優先する
フィールドでプロパティを上書きできるようになるけど、それで良いんか？
0593デフォルトの名無しさん
2007/03/12(月) 20:56:24○ フィールドでプロパティを覆い隠し
0594デフォルトの名無しさん
2007/03/12(月) 21:00:25> > アクセッサがあればそちらを優先的に使う
> それやったらコンパイルが通らん。
いや、コンパイルは通るかもしれんが……
例えば
> public boolean isDesignTime(){ return designTime; }
は public boolean isDesignTime(){ return isDesignTime(); }
に展開されるから実行時に StackOverflowError 吐いて死ぬ。
0595デフォルトの名無しさん
2007/03/12(月) 21:20:38区別させないのがプロパティだろうに。
0596デフォルトの名無しさん
2007/03/12(月) 21:24:32コンパイラが区別できないって意味なんだけど。
人間が区別しないとか、区別を意識させるべきでないってのとは別の話だよ。
0597デフォルトの名無しさん
2007/03/12(月) 22:11:17まぁ互換性を維持してのプロパティの導入には実装上の困難を
解決できていないというのはいいんだが、だからといって
「できる方法で実装しちゃおう」となるとしたら賛成できないなぁ。
互換性の面から考えた場合、方法は大きく3種類に分類できて、
1.JavaBeansと相互に互換性のある方法
2.JavaBeansとは互換性がないが、バイトコードレベルでの
仕様変更を伴わない方法
3.バイトコードレベルで拡張する方法
このうち、3.を採用すると何でもありだから議論から除外するとして、
個人的には1.には拘らないから2.でうまいことやってくれないかなと
思うんだが。
0598デフォルトの名無しさん
2007/03/12(月) 23:05:531 の場合はともかく、2 や 3 の場合は コンパイラ実装するとか言語仕様追加する、
とかってのは一番楽な部分だからね。
JavaBeans を切り捨てるってのは、技術的というより政治的な問題だから、
ハッカー気質が強い人ほど、自分でコード書いたりする時間がなくなって
政治的な問題に時間を取られる、って予感があるので手を引きたがる。
2 の場合は機能を欲しがる人は居るかもしれんけど、
（2 をやれるだけの政治的立場とか確保してる人の中で）
やりたがる人は居ないと俺は思うから、たぶん実現できないと思う。
0599デフォルトの名無しさん
2007/03/12(月) 23:18:49切り捨てるわけじゃないか……
でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか
標準API とかの setter/getter を新プロパティで置き換えるとかってなれば
厄介な政治的問題だってのは予想できるでしょ。
言語として 2 のプロパティ持ってても、
標準API は 2 のプロパティをサポートしませんとかなったら間抜けだし。
0600デフォルトの名無しさん
2007/03/12(月) 23:26:45こんな決定したら 袋叩きにあうような気もする。
メンテ面倒くさいし。
enum でも、似たような事やってたけどさ。
enum だと、自前の enum を定義するクラスが比較的少ないから
メンテが面倒って不満がそれほど大きくならんかっただけだと思うし。
0601デフォルトの名無しさん
2007/03/12(月) 23:30:420602デフォルトの名無しさん
2007/03/12(月) 23:34:54http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5015403
0603デフォルトの名無しさん
2007/03/13(火) 08:40:52>それやったらコンパイルが通らん。
だから具体的に説明してくれって。頭の悪い俺でも分かるように。
>フィールドでプロパティを上書きできるようになるけど、それで良いんか？
これが問題になるのって、フィールドがnon privateのときだけだよね。
フィールドもアクセッサもpublicというのはちょっと考えにくいから、これでも別にいいと思うけど。
>>594
>例えば
>> public boolean isDesignTime(){ return designTime; }
>は public boolean isDesignTime(){ return isDesignTime(); }
>に展開されるから実行時に StackOverflowError 吐いて死ぬ。
これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。
展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
これなら大丈夫じゃない？
0604デフォルトの名無しさん
2007/03/13(火) 09:35:33> これが問題になるのって、フィールドがnon privateのときだけだよね。
違う。例えば
class A{ public int field = 0; }
class B extends A{ private int field = 1; }
class C { public static void main(String[] args){
System.out.println( new B().field );
} }
とかだと A の field にアクセスできんでしょ？
つまり、private なフィールドでも public なプロパティを覆い隠せる。
ってか、言語仕様読んでも、なんで Ａ の field にアクセスできないのか
俺には良くわからんのだが…… 覆い隠しって単純名だけに作用するんじゃないんかな？
> これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。
そうだよ。だから無理だって言ってるじゃん。
> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。
0605デフォルトの名無しさん
2007/03/13(火) 09:38:13> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
> これなら大丈夫じゃない？
package-private もしくは protected な フィールドと、
public なプロパティで問題起こるから解決になってない。
0606デフォルトの名無しさん
2007/03/13(火) 10:13:00> 覆い隠しって単純名だけに作用するんじゃないんかな？
違うか。覆い隠しじゃなくて、隠蔽されたフィールドは継承されないから、
B のインスタンスからは A の field にはアクセスできないのか。
名前の章ばっかし見てたら理解できんかった。
0607デフォルトの名無しさん
2007/03/13(火) 10:17:350608デフォルトの名無しさん
2007/03/13(火) 12:25:260609デフォルトの名無しさん
2007/03/13(火) 13:47:17> 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。
これだと、他にも穴があるか。
class A implements Compareble<A>{
private int field; public long getField(){ return field; }
public int compareTo(A another){ return this.field - another.field; }
}
とかがコンパイルエラーになる、と。
0610デフォルトの名無しさん
2007/03/13(火) 15:00:26(this).bar とかだと どうすんだろ？
0611デフォルトの名無しさん
2007/03/13(火) 16:53:37・フィールドが可視ならフィールドアクセス
・そうでなければ、プロパティがあるならプロパティアクセス
とかの方が良いような気もする。
それでも static なプロパティを許したりすると、同名のメンバークラスと衝突するし。
ってか、同名のフィールドが可視なら shorthand syntax for accessing properties
を使えないのって、本当に使いやすいかも結構問題のような？
0612デフォルトの名無しさん
2007/03/13(火) 19:42:20ttp://download.java.net/jdk7/binaries/
0613デフォルトの名無しさん
2007/03/13(火) 19:42:27>違う
というのは勘違いということでいいのかな？
>そうだよ。だから無理だって言ってるじゃん。
だから『 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく』といっているんだけど。
>そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。
なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
0614デフォルトの名無しさん
2007/03/13(火) 19:48:30＞なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。
汚い設計。
わかりにくいです。
あとマルチスレッド周りで問題がでそうだな。
0615デフォルトの名無しさん
2007/03/13(火) 20:05:41> というのは勘違いということでいいのかな？
いや、覆い隠しは勘違いだったけど、
private フィールドで public なプロパティを隠蔽できるから問題になるのは変わらない。
> 区別してないなら区別すればいいじゃん。
区別しても、 >>605、>>609、>>610 みたいな穴があるから、やるだけ無駄。
0616デフォルトの名無しさん
2007/03/13(火) 20:44:57どっちかっつーと dot でプロパティアクセス許す場合、
フィールドと同名のプロパティを作れるってのが混乱の元だとか認識されてんのかも？
0617デフォルトの名無しさん
2007/03/13(火) 20:51:03問題でるかな？
0618デフォルトの名無しさん
2007/03/13(火) 20:53:23> なんで無茶なの？
根本に近い方のルールを書き直すってのは、
既存のコンパイラを改変する時に多くの労力がかかりそうだってのは分かるでしょ？
だから無茶なの。
0619デフォルトの名無しさん
2007/03/13(火) 21:20:36> ${classInstance.propertyName} みたいに ${} で括った部分では
> 式言語使えるようにすりゃええやん、ってのも出てるけど……
ksl の 課題追跡にあった
https://ksl.dev.java.net/issues/show_bug.cgi?id=2
に似てるっちゃ似てるかも。
でも、ecmascript みたいに Java と同じく } でブロック終了する言語だと
対応とるの大変そうだなとか思った。その辺は EL だと楽だけど。
0620デフォルトの名無しさん
2007/03/13(火) 21:34:43Velocityが標準になるみたいな感じだが。
0621デフォルトの名無しさん
2007/03/13(火) 22:29:53要は、今の仕様で
private int xxx;
というフィールドと
public int getXxx()
というメソッドが混在できる以上、フィールドの延長上のプロパティと
getter/setterの延長上のプロパティとは相容れないわけだ。
いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
関係もないことにすりゃ、それで解決すると思うんだけどね。
0622デフォルトの名無しさん
2007/03/13(火) 22:49:49> いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
> 関係もないことにすりゃ、それで解決すると思うんだけどね。
仮に、それをやっても「解決する」のは言語仕様の問題だけで、
ライブラリ＆フレームワーク＆ユーザーコードの方に問題を押し付けてるのような。
それなら、ぶっちゃけ新しい言語作っちゃった方が速いと思う。
0623デフォルトの名無しさん
2007/03/13(火) 23:18:12上の方でだれか言ってたけど、フレームワークのプロパティとは無関係な「Java言語プロパティ」
を作ってもいいんじゃないか。紛らわしいなら名前は変えてもいいけど。
そもそもなんでプロパティ構文が欲しいんだ。ドットネットが羨ましいんだろうか。
0624デフォルトの名無しさん
2007/03/13(火) 23:24:53「問題」って、どんな問題かな？
別に既存コードの変更が迫られるわけじゃないっしょ？
0625デフォルトの名無しさん
2007/03/14(水) 00:09:08むしろstructが羨ましいんじゃないか？
0626デフォルトの名無しさん
2007/03/14(水) 02:48:40互換性を確保しつつ新プロパティを使おうと思ったら、
既存のプロパティと、新プロパティの両方管理しなきゃいけなくなる。
二重のコストを払う必要が出るんだから、普通は問題になる。
おまけに、フレームワークやライブラリが二重のコストに耐えかねて
既存のプロパティを捨てたら、やっぱり既存のコードを書き換える必要が出る。
直接コードの変更を迫ってないだけで、間接的にコードの変更を迫ってる。
0627デフォルトの名無しさん
2007/03/14(水) 07:18:35プロパティが導入されたからといって、既存のコードを無理に
対応させることはないでしょ？別物なんだから。
それに例えば、ジェネリクスが導入されたとき、それに対応して
書き換えられたフレームワークはあったし、もちろんそれを利用
しているユーザーコードも書き換えられることがあったけど、
それは別に変更を余儀なくされて行ったわけじゃないよね？
0628デフォルトの名無しさん
2007/03/14(水) 07:52:01> それに例えば、ジェネリクスが導入されたとき、それに対応して
Generics の場合は「JavaBeans とは無関係なプロパティ」導入と違って、
例えば Collection フレームワークを Generics対応に書き換えたら、
互換性が完全に無くなるってわけではなかったけど、
「JavaBeans とは無関係なプロパティ」の場合は、
「JavaBeansのプロパティ」のサポートをうちきれば互換性が無くなるし。
例えるなら enum の方が近いな。int enum と typesafe enum の両方を提供してるAPIがあって。
それにはコストがかかる。int enum だけ、typesafe enum だけを提供してるAPIもあるけど、
プロパティの場合は影響範囲も、統一的に扱う必要性も enum の時より大きいから
両方の提供がより大規模に起こるのは容易に想像できる。
「JavaBeansのプロパティ」と「JavaBeans とは無関係なプロパティ」は共存可能って話なんだろう？
互換性維持のためには「JavaBeansのプロパティ」が必要で、
新機能対応のためには「JavaBeans とは無関係なプロパティ」が必要で、
それを両方管理しようとすりゃコストはかかる。問題になるだろ、普通は。
0629デフォルトの名無しさん
2007/03/14(水) 08:10:26例えば、p=a.getXxx()をp=a.xxx、a.setXxx(p)を a.xxx=pとか。
0630デフォルトの名無しさん
2007/03/14(水) 08:37:50それだと dot でやるのが面倒。
既存の getter/setter に使われてる「プロパティの名前」と
同名のフィールドが存在可能だから。
0631デフォルトの名無しさん
2007/03/14(水) 08:39:25そのコストってのもフレームワークの作者とかはともかく開発者は関係ないね
0632デフォルトの名無しさん
2007/03/14(水) 08:44:16何より、無駄にバグのリスクが増えるし、
標準APIとかでドキュメントの翻訳に時間がかかるようになるとも考えられるね。
0633デフォルトの名無しさん
2007/03/14(水) 08:45:07開発者というより、末端ユーザだな
0634デフォルトの名無しさん
2007/03/14(水) 09:10:34a.xxx と同名のフィールド a.xxx があった場合、扱いが面倒。
互換性を考えるなら >>611 あたりのルールが落としどころかとも思うけど、
public な同名のフィールド使えば、プロパティに触れなくする事ができたりするし、
完璧とはいいがたい。
言語仕様に書く文言も相当慎重に選ばないと、
デフォルトパッケージのクラスが import 出来なくなったみたいに、
言語仕様の文言から副作用がでる可能性も……
もっとも、import の方は意図しない副作用なのか意図的なものか、
ちゃんと知らんのだけど。
0635デフォルトの名無しさん
2007/03/14(水) 12:24:270636デフォルトの名無しさん
2007/03/14(水) 12:37:32Genericsは、既存の一般コードに関しては意味の変更なく使えたぞ
>>632
さすがにそのコストを考えるのは臆病すぎｗｗｗ
>>635
マルチコア対応って一体何なのか分からない。
なぁ、何でみんなdotにこだわるの？
別の記号にして、定義も全く別にすればスッキリ導入なんだけど？
バイトコードは拡張しないと駄目だろうけど。
0637デフォルトの名無しさん
2007/03/14(水) 12:48:08> 別の記号にして、
dot 以外の記号はキモイから嫌らしい。
> 定義も全く別にすれば
既存の資産と協調して使えないので、導入しても嬉しさ半減。
> バイトコードは拡張しないと駄目だろうけど。
バイトコード拡張は必要ないでしょ。
クラスファイル仕様は弄るかもしらんけど。
0638デフォルトの名無しさん
2007/03/14(水) 12:50:02マルチCPU対応のVMだったら、マルチコアも そのまま使えるんじゃない？
ってか、マルチコア対応を言語にのっけるってどーやるんだ……
0639デフォルトの名無しさん
2007/03/14(水) 13:13:07JavaBeans使ってたんだろうか？
結局JavaScriptObjectのプロパティからアクセスしようとした時JavaObject側にxxxってフィールドがあると衝突して使い物にならないから
LiveConnectには元々ない後付けされた機能なんて不完全だって言われてたな・・・。
オライリーのサイ本にも指摘されてたような。
0640デフォルトの名無しさん
2007/03/14(水) 13:39:56阿呆だな。もっと簡単な問題があるよ。
>>624
JavaBenas のプロパティと別のプロパティなわけでしょ？
標準API とかの既存の interface に abstract な property を追加したら
既存のコードの中で、そのinterface を実装してて JavaBeans とは別のプロパティを
実装してないクラスがあれば、互換性に問題が出る。
互換性に配慮したら interface に迂闊にプロパティ追加できない。
それだと、たぶん使い物にならない。
0641デフォルトの名無しさん
2007/03/14(水) 13:48:02具体的に言えば java.beans.DesignMode にプロパティ追加して
interface DesignMode {
public static final String PROPERTYNAME = "designTime";
boolean isDesignTime(); void setDesignTime(boolean f);
public abstract property designTime;
}
とかすると、既存の
class MyComponent implements java.beans.DesignMode {
private boolean designTime;
public boolean isDesignTime(){ return designTime; }
public void setDesignTime(boolean f){ designTime = f; }
}
みたいなコードを書き直す必要がある。
DesignTime とかだけならともかく、他の interface も property の追加に関しては慎重にならざるをえない。
よって interface で property にアクセスできない事が多くなる。
JavaBeans のプロパティと別の新プロパティを導入しても、
あんまし使い勝手がよくないだろうね。
0642デフォルトの名無しさん
2007/03/14(水) 14:10:45結局 ->案が一番妥当だろう。
プロパティを定義する側はこれまでどおりgetXXX/setXXXを使用する。
プロパティを使用する側はgetXXX/setXXXと->XXXの両方が使える。
フィールドにXXXがあっても問題なし。
しかし、この程度のものならいらないな。
0643デフォルトの名無しさん
2007/03/14(水) 15:29:22だよな。
いらないと思うよな。
0644デフォルトの名無しさん
2007/03/14(水) 15:41:270645デフォルトの名無しさん
2007/03/14(水) 15:47:49今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入するのだったらその書き換えはいらないよね？
0646デフォルトの名無しさん
2007/03/14(水) 16:03:21だから、>>641 は
> 今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入
した場合に発生する問題だってば。
今Beansで「プロパティ」と呼んでいるもの、
要するに setter/getter呼び出す syntax sugar として
accessing properties な構文を入れるなら、>>641 の問題は発生しない。
0647デフォルトの名無しさん
2007/03/14(水) 16:36:28なんで書き換えようとするの？そのままにしとけばいいじゃん。
0648デフォルトの名無しさん
2007/03/14(水) 16:56:32>>641 をちゃんと読め。
0649デフォルトの名無しさん
2007/03/14(水) 17:45:12ちゃんと読んでもわからないです。
何故 interface DesignMode に property designTime を追加してるの？
ひょっとして俺ｽｹﾞｰアホなこと訊いてる？
0650デフォルトの名無しさん
2007/03/14(水) 18:38:36うん。
0651デフォルトの名無しさん
2007/03/14(水) 22:27:50あきれる。
isXXX()/getXXX()をgetterのインターフェースに用いたままプロパティを
実現しようとすることに問題があるから別のインターフェースを採用
しようという話なんだから、その例でinterfaceの方にisDesignTime()を
追加するという仮定自体がそもそもありえないし、仮に追加しても
何の影響もない。
0652デフォルトの名無しさん
2007/03/14(水) 22:35:240653デフォルトの名無しさん
2007/03/14(水) 23:25:14孔明あらわる
0654デフォルトの名無しさん
2007/03/14(水) 23:56:34俺もそんな気がしたんだけど、>>650 だそうです。
0655デフォルトの名無しさん
2007/03/14(水) 23:57:200656デフォルトの名無しさん
2007/03/15(木) 00:00:240657デフォルトの名無しさん
2007/03/15(木) 00:45:46↑これらも
つか==なしとか縛りきつくね？
0658デフォルトの名無しさん
2007/03/15(木) 00:47:52FlashのActionScript(ECMAScript派生)もread onlyプロパティがあったが、dotだね。
dot以外を選択するのは、正直コンパイラ屋の都合でしかないと感じる。
メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。
0659デフォルトの名無しさん
2007/03/15(木) 01:30:430660デフォルトの名無しさん
2007/03/15(木) 01:32:162chらしい模範解答だなｗ
0661デフォルトの名無しさん
2007/03/15(木) 01:52:21そんな構文糖は要らないってのも意見として尊重してほすぃ。
0662デフォルトの名無しさん
2007/03/15(木) 02:15:35どうなんだろ、セマンティクスがハッキリするから
getter,setterが分かりやすくなるという点ではIDEも歓迎なのでは？
実現方法はともかく。
0663デフォルトの名無しさん
2007/03/15(木) 04:06:26コードの読みやすさが上がるのであれば、新しい構文糖の導入も大いに結構じゃないかい？
0664デフォルトの名無しさん
2007/03/15(木) 07:43:28あきれる。
> 仮に追加しても何の影響もない。
そんなは事ない。
0665デフォルトの名無しさん
2007/03/15(木) 07:47:20>仮に追加しても何の影響もない。
追加したら、java.beans.DesignTime を実装している既存のクラスを書き換えなきゃいけなくなるだろう。
影響がないって、馬鹿じゃないのか？
0666デフォルトの名無しさん
2007/03/15(木) 07:48:08× java.beans.DesignTime
○ java.beans.DesignMode
0667デフォルトの名無しさん
2007/03/15(木) 08:18:45http://java.net/pub/pq/142 とか見ると、
property構文は、XML構文に次いで人気がないんだよね。
http://java.net/pub/pq/141 とかだと、
very important と、somewhat important をあわせても 1/4 ぐらいだったりする。
まぁ、この手の投票がちゃんと機能してるかはわからんし、
構文糖なら要らないってのと、重要度が低いってのは同じ意見じゃないんだけど。
0668デフォルトの名無しさん
2007/03/15(木) 08:34:05> VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。
もし問題がないなら dot を使うのに反対の人はあんまし居ないと思うんだが。
同じクラスでフィールドと同名のプロパティが持てる言語を出してきて
わかりにくくないって言うんならともかく。
> メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。
それって、何か改善する？
0669デフォルトの名無しさん
2007/03/15(木) 09:09:07> 同じクラスでフィールドと同名のプロパティが持てる言語を出してきて
> わかりにくくないって言うんならともかく。
それなら、同名のフィールドとプロパティが共存できて、
さらにフィールドもプロパティも dot でアクセスする言語がわかりにくくないって言わないと。
（dotじゃなくても良いけど同じ記号でアクセスする言語）
0670デフォルトの名無しさん
2007/03/15(木) 09:17:17> その例でinterfaceの方にisDesignTime()を
> 追加するという仮定自体がそもそもありえないし
……。 isDesignTime() は元からあるメソッドですが。
0672デフォルトの名無しさん
2007/03/15(木) 10:26:26質問になってない。
0674デフォルトの名無しさん
2007/03/15(木) 10:36:21それだけじゃ解決しないね。
新プロパティ(dotでアクセス)と同名のフィールドが作れるなら
setter/getterのプロパティと同じ問題が起こるし、
C#みたく新プロパティと同名のフィールドが作れなくするなら、
標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。
これ以降は >>640 >>641 と同じ路線だな。
上記の書き換えを最小限に抑えようとすれば、
標準APIは極力 新プロパティを追加しない方向になるだろうから、
新プロパティの構文は言語仕様に定義されたが、
標準APIで 新プロパティが使えない、という本末転倒な事態が予測される。
つまり、使い勝手が悪い。
0675デフォルトの名無しさん
2007/03/15(木) 10:39:07標準APIが新プロパティを追加したら、
そのclass/interfaceを継承/実装して同名のフィールドを使っていたユーザコードの書き換えが必要になる。
0676649
2007/03/15(木) 10:42:440677デフォルトの名無しさん
2007/03/15(木) 11:02:59まぁ、interface に「新プロパティ」を追加したら、
どっちみち そのinterface を実装しているクラスの書き換えが必要になる。
既存のコードは setter/getter は実装してても、
「新プロパティ」まで実装してて書き換えの必要がないってのは考えにくいから。
この書き換えを最小限に抑えようとすれば、
標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから
以下、>>674 と同文、と。
0678デフォルトの名無しさん
2007/03/15(木) 11:15:13標準API は、既存の setter/getter を置き換えるものも含めて、
極力 abstract な新プロパティを追加しない方向になるだろうから
うーむ。既存の setter/getter は互換性のために残す事を想定してるから
置き換える、じゃないんな。まぁ、setter/getter を残しても残さなくても、
標準API に abstract な新プロパティを追加すれば同じだけど。
0679デフォルトの名無しさん
2007/03/15(木) 20:13:04OSを選ばないUDIライブラリとか、BGM周りはネイティブにディスパッチとかね。
標準であるかどうかってのがここらへんは大きい。
0680デフォルトの名無しさん
2007/03/15(木) 22:34:050681デフォルトの名無しさん
2007/03/15(木) 23:05:33って10年前からいわれてるが
あとはJOGLも標準ではいってくれるといいのだが
今はプラットフォームごとに用意してあげないといかんからWindows以外はめんどくさい
本当は新世代専用GCコールもほしい
タイミングコントロールできて殿堂入りしないやつならアクション系もバリバリ使える
0682デフォルトの名無しさん
2007/03/16(金) 00:05:01interfaceに追加したらそれを実装するクラスに影響があるのは、
「プロパティ」に限らず抽象メソッドでも同じだわな。
既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
↓
だから標準APIに「抽象メソッド」は追加できない
↓
「抽象メソッド」は標準APIに使えないから無意味
あほか。
0683デフォルトの名無しさん
2007/03/16(金) 00:22:54> 既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る
普通は、既存の interface に抽象メソッド追加するのは慎重にする。
逆に、 今までにない interface を作る時は自由に抽象メソッドを定義できる。
> 「抽象メソッド」は標準APIに使えないから無意味
安易に追加できないが、「使えない」とか「無意味」とはならない。
abstract な新プロパティも、抽象メソッドと同じで、
今までにない interface を作る場合は自由に定義できるだろうけど、
既存の interface に追加する場合は慎重にならざるを得ないだろう。
既存の interface 経由で使えない事が予想される新プロパティは
「使えない」とか「使い勝手が悪い」と言える。
0684デフォルトの名無しさん
2007/03/16(金) 00:26:00△既存の interface -> ○標準APIの既存の interface
0685デフォルトの名無しさん
2007/03/16(金) 01:10:18古い実装のを呼ぼうとするとErrorでも出るかな
0686デフォルトの名無しさん
2007/03/16(金) 01:11:37既存のinterfaceを安易に拡張できないってのは当然だね。
>既存の interface 経由で使えない事が予想される新プロパティは
なんで新プロパティに限って既存のinterface経由で使われることを
期待されなければならないんだろう？
0687デフォルトの名無しさん
2007/03/16(金) 01:16:08> だから標準APIに「抽象メソッド」は追加できない
> ↓
> 「抽象メソッド」は標準APIに使えないから無意味
ここで飛躍してる。基本的には「追加できない」==「使えない」とはならない。
で、setter/getter とは無関係な新プロパティシステムを導入したとして、
その新プロパティを、標準APIの既存の interface で使いたいと言う場合は
・新プロパティを追加すれば、その interface を実装していたコードを変更する必要が出る。
・逆に新プロパティを追加しなければ、標準APIの既存の interface では新プロパティは使えない
で、俺は標準APIの管理者は後者を選択すると予想するので、
その場合は新プロパティは「標準APIの既存の interface経由では使えない」ので
使えないとか、使い勝手が悪いと言えるだろう。
仮に前者を選んだとしても、コードの変更を迫られるので無問題とはならない。
0688デフォルトの名無しさん
2007/03/16(金) 01:23:35> なんで新プロパティに限って既存のinterface経由で使われることを
> 期待されなければならないんだろう？
限って？ 他では期待されてないんだっけか？
0689デフォルトの名無しさん
2007/03/16(金) 01:27:18限ってないよな。Closure だって、Closure Conversion とかで
abstract なメソッドが一つだけの既存の interface に変換する事を考えてたりするし。
0690デフォルトの名無しさん
2007/03/16(金) 01:48:55たいてい inteface と関係ないか、既存の interface との協調にも配慮してあるよーな。
0691デフォルトの名無しさん
2007/03/16(金) 05:18:23新世代・・・・ああああNewGeneration用のGCってことか。
いや、殿堂入りが無いというより、tenureの32をいじれるようになった方がいいかな。
ある程度、コア数が増えて並行処理が速くなると、OldGenerationを少なくして
Newgenerationのtenureを32回より多くして、NewGenerationで運用したほうが
効率いいと思うんよねぇ。
昔、24CPUのマシン使った時、10GB程度のNewGenerationをParNewGCかけてたけど
確か0.5s程、ホンの一瞬だった。
0692デフォルトの名無しさん
2007/03/16(金) 07:42:00class定義に影響する新機能としては例えばfunction-typeなんかがあるけど、
じゃあこれは既存のinterfaceに追加されて使われることを期待されてるの？
0693デフォルトの名無しさん
2007/03/16(金) 08:53:05対抗馬である setter/getter の syntax sugar なプロパティなら
既存の interface経由で使えるしな。
それと比較しても 「使い勝手が悪い」といえるだろうね。
0694デフォルトの名無しさん
2007/03/16(金) 08:53:44具体的に、どんな問題が出るんだ？
0695デフォルトの名無しさん
2007/03/16(金) 12:35:00並列GCはデフォの状態よりスループットはいいけどレスポンスが大幅に悪化するぞ
あとGC稼動のタイミングをコントロールできる10msのGCとコントロールできない0.1msのGCだと前者のほうがいいわけで
0696デフォルトの名無しさん
2007/03/16(金) 13:50:53今のマシンスペックならGCに0.1msもかからんよ。
ゲームならヒープサイズとスタックサイズの調整で2Dまでならストレスなく遊べる。
やっぱメモリ食いは収まらないけど。
取り合えずただのデスクトップツールとしては実用的じゃない？
ジョイパッド拾えるようになると同じ方向性で障害者用の入力補助装置の入力拾えそうでアクセシビリティ周りが格段に良くなって良いと思うけどな。
0697デフォルトの名無しさん
2007/03/16(金) 14:15:04GCの時間はヒープサイズに綺麗に比例するのでなんともいえないよ
最近のマシン持っているけど0.5msきることは実際にゲームつくっていてまずない
新世代領域を少なくしてやっと0.2mくらいか
インクリメンタルGC（現在の実装は並列GC）だとレスポンス悪化してるし、
デフォのGCだとFullGCがいつかは必ず起きるし、おきたら使い物にならない
そもそもJava2DやJOGLなどライブラリによるGCはコントロールできなから
自分のコードでの調整は何も意味がない
0.1mが0.05mであっても同じこと
リアルタイム性ってのは早いかどうかじゃなく、コントロールできること、把握できることだから
0698デフォルトの名無しさん
2007/03/16(金) 15:41:40まるでApache Antの記法だな
0699デフォルトの名無しさん
2007/03/16(金) 15:42:31四項演算子か。
Checkstyleプラグインが警告しそうだな
0700デフォルトの名無しさん
2007/03/16(金) 19:54:46既存のinterfaceに public int getHoge(); なんて追加したら
おんなじように「問題」は発生するが？
>>694
何の問題も出ないだろう。既存のinterfaceに追加したりしなけりゃ。
0701デフォルトの名無しさん
2007/03/16(金) 20:14:48setter/getter の syntax sugar なプロパティであれば、
既存の interface で、既に宣言されている setter/getter で
プロパティにアクセスする分には問題は発生しない。
setter/getter と関係のない新プロパティシステムを導入した場合、
既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。
で、標準API みたいに変更すると影響範囲が大きい既存の interface は安易に変更できないから
新プロパティを追加したくても既存の interface には追加できず、
既存の interface からは、この新プロパティは使用できない可能性が高い。
故に setter/getter の syntax sugar よりも 「使い勝手が悪い」といえる。
0702デフォルトの名無しさん
2007/03/16(金) 21:11:410703デフォルトの名無しさん
2007/03/16(金) 21:19:010704デフォルトの名無しさん
2007/03/16(金) 22:07:53>既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。
既存の「getter/setter」と関係ないプロパティが前提なら、当然既存のinterfaceにも
存在しているわけがないだろう。ここでアクセスしようとしている「プロパティ」ってのは
何のことを言っているんだ？
もし「getter/setter」のことならば、それはプロパティとは関係のない単なるメソッドだから、
普通にメソッドとしてアクセスすればよい。
もし新たにプロパティを追加することを想定しているのならば、それはインターフェースの
拡張に他ならないから、他に影響が出るのは当然。それは別にプロパティに限らない。
0705デフォルトの名無しさん
2007/03/16(金) 22:18:48> ここでアクセスしようとしている「プロパティ」ってのは
当然、setter/getter と関係ない新プロパティシステムのプロパティ。
で、プロパティの持つものは、既存の setter/getter で表わされるのと同じもの。
プロパティ導入の大きな動機の一つに、setter/getter を宣言するのも、
呼び出すのも冗長だという不満を解消するというものがある。
setter/gettter とは別の新プロパティシステムを使えば、
既存の interface にある、既存の JavaBeans のプロパティに対して、
setter/getter を呼び出すのが冗長だという不満を解消できない。
仮に Tiger で追加された Generics が、もし仮に既存の Collection API と協調できず、
List でも Map でもパラメタ型を取れなければ、使い勝手が悪いと評価されるだろう。
それと同じ。
0706デフォルトの名無しさん
2007/03/16(金) 23:00:03foo.getBar()がfoo->barになっただけでどんな不満が解消するんだよ。
0707デフォルトの名無しさん
2007/03/16(金) 23:07:260708デフォルトの名無しさん
2007/03/16(金) 23:08:42なら、なんでプロパティが必要なんだ？
それに、最初出てきた案は setter/getter の syntax sugar なんだぜ？
0709デフォルトの名無しさん
2007/03/16(金) 23:18:32わかってもらえない場合は、別の角度からの説明を試みるべきだと思う。
>>706
だよな。いらねーよな、こんなプロパティもどき。初心者が混乱するだけ。
0710デフォルトの名無しさん
2007/03/16(金) 23:22:40普通は説明されなくてもわかるだろ。あんなの。
気づかない方が頭がおかしいんだよ。
0711デフォルトの名無しさん
2007/03/16(金) 23:35:01「普通」とか言うけど、「使い勝手が悪い」っていう結論は主観が入り込んでるだろ？
0712デフォルトの名無しさん
2007/03/17(土) 00:10:420713デフォルトの名無しさん
2007/03/17(土) 00:25:29>>621 で
> いまのキモいJavaBeansのgetter/setterはプロパティとはなんの
> 関係もないことにすりゃ、それで解決する
という意見が出た。
新プロパティシステムを作れば、フィールドと同名のプロパティを禁止できるからって話なんだろうけど、
>>674 のような問題も予想されるため、完全な解決とはならない。
結局、限定名のルールとかフィールドアクセスのルールが
ぎちぎちに詰め込まれているので dot でフィールドにアクセスする事と、
dot でプロパティにアクセスする事が相容れないと考えた方が良いみたい。
それとは別に、>>640、>>641 で言ったように setter/getter とは別の新プロパティシステムを導入する場合、
setter/getter の syntax sugar ならプロパティとしてアクセスできた情報の一部に
プロパティシステムを使ってアクセスできない事が予想される。
結局、「setter/getter とは別の新プロパティシステム」を導入しても
setter/getter のsyntax sugar で問題とされた事を解決できず、
さらに setter/getter の syntax sugar では出なかった問題も発生する。
まぁ、「setter/getter とは別の新プロパティシステム」の詳細を見ての評価じゃないけど
現在の情報からなら setter/getter の syntax sugar より「使い勝手が悪い」と言える。
0714デフォルトの名無しさん
2007/03/17(土) 00:28:20どうでもいーけど長文ウザイ
0715デフォルトの名無しさん
2007/03/17(土) 10:20:140716デフォルトの名無しさん
2007/03/17(土) 10:22:41どんな影響が出るかを予見できないってのは技術者として拙いだろ。
0717デフォルトの名無しさん
2007/03/17(土) 10:30:57なんで一生懸命説明してんの？
0718デフォルトの名無しさん
2007/03/17(土) 10:33:03次世代Javaと関係ない話題だな。 続きは他所行ってやれ。
0719デフォルトの名無しさん
2007/03/17(土) 12:59:19たった2レス程度で…気が短いな
0720デフォルトの名無しさん
2007/03/17(土) 16:16:28結局、getHoge()/setHoge()を使わない新プロパティシステムを導入しても、
既存のgetHoge()/setHoge()を使えないから使い勝手が悪いということかw
0721デフォルトの名無しさん
2007/03/19(月) 00:14:19プロパティは既存の言語機能と干渉するから、導入の必要はないというもの。
それ、ほんとなのかなあ（ｒｙ
0722デフォルトの名無しさん
2007/03/19(月) 00:44:26当然のことだよね
0723デフォルトの名無しさん
2007/03/19(月) 00:51:13既存の言語機能と干渉とかいう以前に、そもそも「そんなに必要な物なのか」って
ことがまずあるんじゃないか？
プロパティの仕組み導入の話が出てるのは、
「定義するのも使うのも既存のgetter/setterの仕組みだとめんどくさい」
という要望から来てるんだろうけど、
「めんどくさい」っていう理由だけで言語仕様変えてったらとんでもないことになる気がする。
相当面倒、ってのが、すごく簡単ってなるならまだ納得できなくもないけど、
IDE使ってる人の中にはgetter/setterがそこまで面倒とは思わない人もいるんじゃないかとも思う
ちなみに個人的にはgetter/setterの使用側は今のままで十分。
ただ、定義するのが面倒だから、アノテーションとかで自動でデフォルトのgetter/setterが
作成される仕組みができるぐらいでも満足だよ。
0724デフォルトの名無しさん
2007/03/19(月) 02:14:53obj set foo = 1;
0725デフォルトの名無しさん
2007/03/19(月) 08:54:34>>667 の結果を見るに、
プロパティ要らないって意見の方が サイレントマジョリティで、
プロパティ欲しいと言ってる方が、声の大きい少数派。
0726デフォルトの名無しさん
2007/03/19(月) 11:47:220727デフォルトの名無しさん
2007/03/19(月) 12:23:090729デフォルトの名無しさん
2007/03/19(月) 23:15:19うむ。
プロパティ自体は特にそんなに欲しいものでもないが、自分で開発していて
コードの半分以上が意味のないgetter/setterで占められているクラスが
山のようにあるのを見ると、何かが間違ってる気がしてならない.。
0730デフォルトの名無しさん
2007/03/19(月) 23:21:52同様にBigDecimalの演算もきっつい
0731デフォルトの名無しさん
2007/03/20(火) 00:51:51プロパティに足し算して格納とかってそんなに使う？
俺、WEB開発系がメインだけど、プロパティに対して加算とかって
ほとんどしたことないし、BigDecimalも使ったことない。
きっとプロパティが必要な分野と、たいして必要とされない分野があるんだろうな。
0732デフォルトの名無しさん
2007/03/20(火) 01:17:10やっぱりadd()がめんどくさいから演算子オーバーロード使わせろ
とか言うのかな。
0733デフォルトの名無しさん
2007/03/20(火) 02:00:33BigDecimalだけはStringのようにシンタックスシュガーとしてaddとかやってほしいな
プロパティの足し算引き算ってのは普通にあるっしょ
金額とか在庫とかいくらでも
特にO/RマッパやBeanBinding関係使うと頻発
0734しろうと
2007/03/20(火) 09:36:43public int bar;
}
じゃだめなん？
0735デフォルトの名無しさん
2007/03/20(火) 10:15:22それに定義のほうはどうにでもなるためたぶん問題になってない
0736デフォルトの名無しさん
2007/03/20(火) 22:24:230737デフォルトの名無しさん
2007/03/20(火) 22:34:180738デフォルトの名無しさん
2007/03/20(火) 22:38:44グリッドとかは、アプリケーションの下で何らかのグリッド制御部が
動いていて、JVMのリソースとしてグリッドが見えるって前提だろうから
MVMが実現して、アプリケーションの起動とJVMの起動が分離するまでは
あんまり興味がないね。
0739デフォルトの名無しさん
2007/03/20(火) 23:23:42BEAだかが仮想化技術として構想を発表してたはず
0740デフォルトの名無しさん
2007/03/20(火) 23:27:12グリッドが見えるのを前提にする必要はないでしょう。
HotSpotが全自動で動的最適化を行うように
グリッド制御部が全自動でスレッド分散を行うのが
あるべき姿だと思います。
0741デフォルトの名無しさん
2007/03/24(土) 22:20:18http://download.java.net/jdk7/changes/jdk7-b10.html
http://download.java.net/jdk7/binaries/
NewFeatureは地味なパフォーマンス向上と
getAsText,setAsTextか。これはちょっと嬉しいな。
0742デフォルトの名無しさん
2007/03/25(日) 05:37:51を生成することになることが重要。
PGがthreadを手書きしてでしか対応できないというのではコストがかかりすぎる。
0743デフォルトの名無しさん
2007/03/26(月) 13:15:00やっぱ、何か明示的にプロパティを示す構文がほしい。
と思ったのは、eclipseでリファクタリングするとき。
getter側をリネームしたら、setter側も変わってほしいし、名前の定数も変わってほしい。
public static final string PROPNAME_XXX = "XXX";
public Object getXXX() { ... }
public void setXXX() { ... }
の三者の一貫性を、自動的に保ちたい。
なんか、アノテーションつけとくと、eclipseが、それをヒントに一括リネームしてくれる
だけでもいいんだけど。
0744デフォルトの名無しさん
2007/03/26(月) 14:16:160745デフォルトの名無しさん
2007/03/26(月) 14:25:33getter/setter はまだしも、
> public static final string PROPNAME_XXX = "XXX";
の必要性が良く分からん。
0746デフォルトの名無しさん
2007/03/26(月) 14:42:25名前だけで型がないし、そもそも型が要らないならenumでいいし
まさか、文字列の中身がクラス名とか
0747デフォルトの名無しさん
2007/03/26(月) 15:40:52>>746
プロパティ名を変えるときに、プロパティ名の文字列リテラルがソース中に散らばってると、
修正がめんどくさいから。
IDEの完全一致文字列リテラルの置換でできなくはないけど、"item"、"count"なんてプロパティ名
だと、無関係な文字列に誤爆するかもしれん。
0748デフォルトの名無しさん
2007/03/26(月) 17:01:43＞修正がめんどくさいから。
得てしてこういう理由で出てくるワークアラウンドは
引きずらない方がいい悪習慣である可能性が高い
0749デフォルトの名無しさん
2007/03/26(月) 18:19:33いや、一つの識別子をソース中に書くのは1回で、あとは参照に置き換えるってのは、
コードのメンテナンス性を保つ上で、ものすごく基本的なことだと思うが。
getXXX, setXXXというメソッド名は、XXXというプロパティ名に従属する識別子なんだから、
ソース中の1箇所の変更で、全てが整合性を保った状態で変更されるのが理想。
C#では、それを文法で強制している。javaでは、整合性の保持はプログラマ任せ。
プロパティ名変更する度に、getXXX、setXXX、firePropertyChangeの引数、全て変更って、
バカバカし過ぎる。せめて、IDEに面倒みてもらいたい。
YYYListener、addYYYListener、removeYYYListenerも、相互に関連する名前なんだから、
ソース1箇所の変更で全てが修正される方が望ましい。
これも、C#ではeventで実現できるが、javaはプログラマ任せ。
javaは保たれるべき一貫性の保持を、文法で強制するんじゃなくて、守るべき
ルールとして与えてるだけなんで、そのルールが守られることのチェックを、アノテーションでできてほしい。
addYYYListenerにしても、
@AddListenerMethodFor(YYYListener.class)
void addYYYListener(YYYListener listener) {}
みたいにして、名前の整合性がなかったら、コンパイラで検出できるようにすべきだと思う。
IDEではYYYListenerをリファクタリングでリネームしたら、addもremoveもリネームできて、ほしい。
javaは、識別子の命名ルール関係で、コンパイラでは検出できないけど、
守られていないと正しく動作しない決め事が結構ある。
そのあたり、アノテーションでバンバン検出できるようになると良いんだけど。
0750デフォルトの名無しさん
2007/03/26(月) 19:16:31そのプロパティを実際に使用している箇所の変更は不要なの？
0751デフォルトの名無しさん
2007/03/26(月) 19:26:01public int MyProperty {
get { return myVar; }
set { myVar = value; }
}
0752デフォルトの名無しさん
2007/03/26(月) 21:00:03> getXXX, setXXXというメソッド名は、XXXというプロパティ名に従属する識別子なんだから、
これも別の概念なんだよね。BeanInfo や PropertyDescriptor を自分で書いてる人は
hoge って名前のプロパティで、void hoge(Object) を setter に、Object hoge() を getter に指定する事も出来るし。
もっとも、真面目に BeanInfo 見てないフレームワークだとプロパティと認識してくれないかもしれんけど。
> バカバカし過ぎる。せめて、IDEに面倒みてもらいたい。
ここは同意なんだけど、IDEで吸収するのか、言語/コンパイラで吸収するのかってのもあるし。
とりあえず、現状だと言語/コンパイラのレベルで BeanInfo 扱うのは面倒っぽい。
例えば、今コンパイルしようとしてる Hoge.java の BeanInfo を扱うのが面倒。
PropertyDescriptor の getWriteMethod とか getReadMethod とかで、
まだコンパイルされてない Hoge.class の java.lang.reflect.Method 取るっても取れないだろうし。
これがないと、プロパティ名を getter/setter に変換できないし。
0753デフォルトの名無しさん
2007/03/26(月) 23:03:02それはわかるが>>743のコードはカス
>>751のようにすべきかと
0754デフォルトの名無しさん
2007/03/26(月) 23:15:07PROPNAME_XXX って firePropertyChange 関連以外で使う？
0755デフォルトの名無しさん
2007/03/26(月) 23:48:38C#構文をそのまま持ち込んだらこうなるな。
欲を言えば、myVarとMyPropertyの関係(というか変数実体についての記述)を
何らかの形で示すことができて、省略時はデフォルトsetter/getterが呼ばれる
ようにできたらとC#より便利になると思うんだけどね。
つまり、アクセスをフックしたり禁止したりする場合だけ明示的に記述する。
＃C#の場合はgetter/setterを省略した場合はアクセス不可
0756デフォルトの名無しさん
2007/03/27(火) 00:42:520757デフォルトの名無しさん
2007/03/27(火) 01:14:48フィールドを指定すること*も*できるってんならいいんじゃない？
0758デフォルトの名無しさん
2007/03/27(火) 08:18:580759デフォルトの名無しさん
2007/03/27(火) 12:29:55getとsetのメソッドやら先頭を大文字推奨、プロパティとしては小文字扱いとか
現状のほうがややこしいだろ
getとsetがばらばらにおかれることによって見通しが悪くなる場合もあるし
リファクタリングの問題もある
プロパティ名としてマルチバイトキャラ埋め込んだ場合の話とかもあるし
現状のままが最悪だよ
0760デフォルトの名無しさん
2007/03/27(火) 13:44:08そっから .NET に倣って、 set_プロパティ名 get_プロパティ名 ってメソッドに展開される、と？
0761デフォルトの名無しさん
2007/03/30(金) 02:49:13public get int myProperty() {return myVar;}
public set void myProperty(int value) {myVar = value;}
JavaScriptライクにこれでおｋ。
0762デフォルトの名無しさん
2007/03/30(金) 05:11:320763デフォルトの名無しさん
2007/03/30(金) 05:31:480764デフォルトの名無しさん
2007/03/30(金) 05:45:230765デフォルトの名無しさん
2007/03/30(金) 05:49:20むしろIDEに機能として組み込めよ
0766デフォルトの名無しさん
2007/03/30(金) 07:07:495.0になったときも非互換変更あったじゃん
そのためにコンパイラの文法バージョンを指定するオプションがあるんでしょ
0767デフォルトの名無しさん
2007/03/30(金) 07:33:32private String str;
で
XX.setStr("A");
XX.getStr();
がコンパイルとおる、でなにがいかんのかと（ry
0768デフォルトの名無しさん
2007/03/30(金) 09:52:12@Set、@Getにすればいいよ。
0769デフォルトの名無しさん
2007/03/30(金) 11:45:380770デフォルトの名無しさん
2007/03/30(金) 11:54:29@setter("setValue");
private String value;
これでいーよ。
0771デフォルトの名無しさん
2007/03/30(金) 11:56:080772デフォルトの名無しさん
2007/03/30(金) 12:12:16@setter("__value") @getter("__value") public String value;
private String __value;
0773デフォルトの名無しさん
2007/03/30(金) 14:36:20に一票。
assertだって使ってた奴いたんだから構わんよ。
というか、get、setっていう変数はなさそうだし、あとに何も付かないset,getメソッドも
そんなに無いだろうからいいよ、それで。
0774デフォルトの名無しさん
2007/03/30(金) 14:55:04予約語にしたら set get が変数名、フィールド名、メソッド名、クラス名等々に使えなくなる。
>>773
java.util.List#get(int) java.util.List#set(int, E)
java.util.Map#get(Object)
これだけあれば影響力十分だよなぁ……
いくら互換性を軽視したって言っても、流石にシャレにならんと思うぞ。
俺なら >>761 の文法なら予約語にしない方を選ぶけど。
ってか、そもそも >>761 って set get つける必要あるのか？
0775デフォルトの名無しさん
2007/03/30(金) 19:29:56のほうがまとまってていいな
0776デフォルトの名無しさん
2007/03/30(金) 19:35:36説明の下手なおじさんが上の方で散々教えてくれてるのに。
0777デフォルトの名無しさん
2007/03/30(金) 21:55:010778デフォルトの名無しさん
2007/03/30(金) 22:12:44C# みたいな文脈依存の予約語なら、value が使えないのは set {} 内だけだし。
0779デフォルトの名無しさん
2007/03/30(金) 22:32:27private int myVar;
public int MyProperty(value) {
get { return myVar; }
set { myVar = value; }
}
とか
0780デフォルトの名無しさん
2007/03/30(金) 22:45:47……。そっちに付けるか
0781デフォルトの名無しさん
2007/03/30(金) 23:50:18今のアノテーション仕様にとらわれる必要はないよ。
http://journal.mycom.co.jp/articles/2006/11/01/jsr308/
0782デフォルトの名無しさん
2007/03/31(土) 00:02:40ディレクティブは邪道だから駄目か
0783デフォルトの名無しさん
2007/03/31(土) 00:50:04説明だけが下手なんだったら良かったが、論理展開も
おそらく頭の中も下手だったからな。
0784デフォルトの名無しさん
2007/03/31(土) 06:33:250785デフォルトの名無しさん
2007/03/31(土) 10:08:46これ今の文法だとgetの後に;が無いって怒られるじゃない
普通のメソッドの中でも {} でスコープを制限する記法があるから
やっぱ普通のメソッドじゃないという何らかの記述は必要。
>>751 に加えてsetの後に引数記述付けたらいいんじゃないか？
で、この書き方の場合はアノテーションじゃなくて
propertyとかいう新しい予約語使うのがいいな。
メソッドは文法が違うんだから。
アノテーションは、あくまで付加的な情報であって
文法の指定であって欲しくはない。
0786デフォルトの名無しさん
2007/03/31(土) 11:32:15コンパイル制御させたら地獄のIFDEFの復活になりそうなんだが…。
0787デフォルトの名無しさん
2007/03/31(土) 12:43:15でも C# には ConditionalAttribute あるよ
0788デフォルトの名無しさん
2007/03/31(土) 13:54:10プロパティ構文実装しようとしてる時点で
現行の文法でとおらないというのは意味のないことだな
propertyの予約語に関しては影響範囲はたぶんenumよりは少ないと思う
enumはつかわれまくってたからなぁ
0789デフォルトの名無しさん
2007/03/31(土) 16:09:44過去の言語を十分に研究して作成した言語でも言語設計の失敗はある。
0790デフォルトの名無しさん
2007/03/31(土) 16:13:510791デフォルトの名無しさん
2007/03/31(土) 16:55:34ちっとは勉強した方が……
http://blogs.sun.com/ahe/entry/java_se_7_wish_list
の Shorthand syntax for declaring properties のところに、
この構文なら property はキーワードにする必要が無いって書いてある。
http://weblogs.java.net/blog/forax/archive/2007/01/a_property_prop_1.html
の prototype-1.7-b05.jar 試してみれば分かるけど
property を言語全体に影響する予約語にする事無く、property でプロパティの定義させてる。
常に予約語にする必要がないってわけじゃないけど、
導入する構文によっては予約語にする必要はない。
もしくは、予約語にしないように導入する構文を慎重に決める必要がある。
0792デフォルトの名無しさん
2007/03/31(土) 17:00:14単純にはいえんよ
0793デフォルトの名無しさん
2007/03/31(土) 17:17:48なんか一言で失敗作呼ばわりされてしまったなぁｗ
0794デフォルトの名無しさん
2007/03/31(土) 17:40:08「property を予約語にしない」ってのを選択肢として持ってないのは不勉強。
0795デフォルトの名無しさん
2007/03/31(土) 17:58:51上のほうのget setも構文解析からだけ考えれば予約語にする必要はないべ
gotoだって使わないが予約語だし、newだって予約語にしなくても本当は使えることは使える
0796デフォルトの名無しさん
2007/03/31(土) 18:01:38既出。
0797デフォルトの名無しさん
2007/03/31(土) 20:18:57「既出。」だけのレスは2ch不勉強
0798デフォルトの名無しさん
2007/03/31(土) 23:32:260799デフォルトの名無しさん
2007/04/01(日) 11:57:31紛らわしさって？
property を予約語にしない場合の紛らわしさって言っても
せいぜい property property が出来るぐらいだと思うが。
0800デフォルトの名無しさん
2007/04/01(日) 12:05:25○class property がある時に property property property が出来る
もっとも、>>785 も >>788 も具体的な構文規則も例も書いてないから、
>>785 >>788 の脳内構文で出来るのかは知らんけど。
0801デフォルトの名無しさん
2007/04/01(日) 15:41:45前にGenerics使うと長くなるからtypedefいるだろとか言ってたC++信者がいたが
これはほんとに可読性に問題起こしそうだな……
どうにかならんもんか
0802デフォルトの名無しさん
2007/04/01(日) 15:52:49http://blogs.sun.com/ahe/entry/java_se_7_wish_list
Type aliasing
Shorthand syntax for declaring local variables
0803デフォルトの名無しさん
2007/04/01(日) 16:57:04結局は、独自定義があるとそれによって可読性が落ちるかもしれないから
適用範囲に十分注意ってとこだな
0804デフォルトの名無しさん
2007/04/01(日) 18:00:26新しい型の有効範囲外だとエラー投げてほしい。
typedef month byte 1...12;
aliasでも良いね。...は->でも良いかも。
alias day byte 1->31;
typedef leapsecond byte 1->60;
キャストは値の範囲が大きい方から小さい方の場合は代入されている値が小さい方で表せる範囲の場合のみ、または小さい方から大きい方。
0805デフォルトの名無しさん
2007/04/01(日) 18:12:17それこそアノテーションでいいんじゃないか？
0806デフォルトの名無しさん
2007/04/01(日) 18:34:49飽和演算もほしくなるな
0807デフォルトの名無しさん
2007/04/01(日) 18:52:21範囲外がきたとき例外出すのか、飽和させるのか、値を変えないのかの判断もいれればグッド
ついでに一番面倒なプロパティリスナのfireも自動でやってほしい
0808デフォルトの名無しさん
2007/04/01(日) 21:53:14その情報を元にWebアプリ側で自動でバリデートやエラーメッセージ出してくれたら最高に楽だな。
0809デフォルトの名無しさん
2007/04/01(日) 22:05:41なんかライブラリとNetBeansでプラグイン作りたくなってきた
GUIとのバインディングでもかなり効率よさそうだしな
0810デフォルトの名無しさん
2007/04/01(日) 22:41:26構文糖・即・悪こそが我々Java厨の共有する唯一の正義ではなかったのか！
それを捨てるというならば、まずtypedefを導入しやがれ
0811デフォルトの名無しさん
2007/04/01(日) 23:14:33生成されるバイトコードはキャスト使いまくりのものと同じだろ
0812デフォルトの名無しさん
2007/04/01(日) 23:28:04そんなもん、EoD とか言って autoboxing みたいな構文糖が入った時点で捨てとるような。
0813デフォルトの名無しさん
2007/04/02(月) 00:10:56乙
0814デフォルトの名無しさん
2007/04/03(火) 11:11:13何かいまいち語呂が悪いな
というかtyprdefはねえよwww
0815デフォルトの名無しさん
2007/04/03(火) 19:05:07ある程度どのように実装しているか表現できればコードチェックのときに便利だと思う。
copy(Cloneable obj)とかif(obj instanceof Cloneable){/*処理*/}とかそういうことは出来なくなるけど……
0816デフォルトの名無しさん
2007/04/03(火) 19:40:24Javaで導入されていないのは、sourceが読みにくくなるという理由だろうけど。
0817デフォルトの名無しさん
2007/04/03(火) 21:04:57みたいなのは同じ型の別名を作るだけだから有害だが、
typedef Map<String, List<MyClass<Integer, String>>> MyType;
みたいなのは特別な組み合わせに特別な名前をつけているから有用だと思う。
だから、Genericsありの場合のみtypedefを許すというのはどうだろうか。
0818デフォルトの名無しさん
2007/04/03(火) 21:12:110819デフォルトの名無しさん
2007/04/03(火) 21:31:09実態が変わるのならきっついのでは？
Javaはすべてダイナミックリンクなわけで
Stringからchar[]への変更とかIntegerからLongへの変更とか現実的ではないし
0820デフォルトの名無しさん
2007/04/03(火) 21:38:01typedef String MyString;
MyString abc = "sample";
これ、OK にするん？ NG にするん？
0821デフォルトの名無しさん
2007/04/03(火) 21:44:12それでいけるかー
typedefのためだけにファイルいっこつくるのが許容できるかどうかだな
0822デフォルトの名無しさん
2007/04/03(火) 21:51:09逆にファイル一個作らない場合、どのソースファイルに記述するか迷わないか？
ひとつのクラス内でのみ使用するというならいいが。
0823デフォルトの名無しさん
2007/04/03(火) 21:53:30擬似Typedefアンチパターン
http://www-06.ibm.com/jp/developerworks/java/060310/j_j-jtp02216.shtml
0824デフォルトの名無しさん
2007/04/03(火) 22:27:37公開APIで使うべきではないけど、内部処理で使うには問題はなかろう。
「大規模では・・・」というのも、モジュール境界で使わなければいいだろう。
0825デフォルトの名無しさん
2007/04/03(火) 22:33:36OKだろ。
0826デフォルトの名無しさん
2007/04/03(火) 22:59:03当を得る、的を射ると書こうと思ったが
"的を得る"もあながち間違いとはいえないらしい
0827デフォルトの名無しさん
2007/04/03(火) 23:09:14そんなん言語仕様作ってる連中が居るところで聞かなきゃ意味がない。
どーせやるなら generics のパラメタ型だけじゃなくて
JSR 308 の型へのアノテーションも含めて欲しいけど。
0828デフォルトの名無しさん
2007/04/03(火) 23:35:42所詮dolphinなんか、property派のお祭に過ぎない！
我々typedef派にとってdolphinほど馬鹿馬鹿しいものはない！
多数決で決めれば、property派が勝つに決まってるじゃないか！
0829デフォルトの名無しさん
2007/04/04(水) 00:16:01MVMさえ実現されれば、デスクトップJavaもサーバJavaもかなりの勢いで道が開ける。
0830デフォルトの名無しさん
2007/04/04(水) 00:44:350831デフォルトの名無しさん
2007/04/04(水) 01:12:55俺はビビらない
もうちょっと上手くやってください
>>830
俺がずっとヲチしてるとこは年単位で動きナス
ttp://research.sun.com/projects/barcelona/
ttp://java.sun.com/developer/technicalArticles/Programming/mvm/
唯一怪しげな情報として引っかかってきたのが
ttps://jvmcomm.stage.dev.java.net/
ここによると、MVMは作られた、とのこと。
もしかして、通常権限だとアクセスできない
ttps://mvm.dev.java.net/
に何らかの情報が？誰か触った事のある奴居ないっすか？
0832デフォルトの名無しさん
2007/04/04(水) 08:41:27いい記事を知った
㌧
0833デフォルトの名無しさん
2007/04/04(水) 09:33:04クロージャー祭りなワケですが。
0834デフォルトの名無しさん
2007/04/04(水) 11:59:58プログラミングだとかコンピュータだとか、
私はそんなことには一切興味がない！
あれこれ改変して問題が解決するような、
もはやそんな甘っちょろい段階にはない！
こんな言語はもう見捨てるしかないんだ、
こんな言語はもう滅ぼせ！
私には、建設的な提案なんか一つもない！
今はただ、スクラッチ＆スクラッチ、0から書き直すことだ！
0835デフォルトの名無しさん
2007/04/04(水) 13:45:510836デフォルトの名無しさん
2007/04/04(水) 20:03:090837デフォルトの名無しさん
2007/04/05(木) 01:17:46うん、MSは儲かるよ
0838デフォルトの名無しさん
2007/04/05(木) 07:55:410839デフォルトの名無しさん
2007/04/12(木) 20:20:00http://download.java.net/jdk7/changes/jdk7-b11.html
http://download.java.net/jdk7/binaries/
何か地味なビルド。
OpenJDKでのビルド修正に関するFixばかり。
0840デフォルトの名無しさん
2007/04/13(金) 15:01:43http://d.hatena.ne.jp/kazama/20070413 より。
0841デフォルトの名無しさん
2007/04/13(金) 21:03:32日本語版が用意されているという趣向が
ちょっと見てみようかという気になる
0842デフォルトの名無しさん
2007/04/18(水) 12:27:47http://journal.mycom.co.jp/articles/2007/04/11/openterracotta/index.html
0843デフォルトの名無しさん
2007/04/18(水) 20:17:380844デフォルトの名無しさん
2007/04/18(水) 20:53:590845デフォルトの名無しさん
2007/04/18(水) 21:06:02次世代関係ないな。初心者質問スレいけ。
0846デフォルトの名無しさん
2007/04/19(木) 08:13:460847デフォルトの名無しさん
2007/04/19(木) 21:58:33Uniform Driver Interface対応がされれば
Javaクライアントの未来もあるんだが、
今だサーバ関係ばっかサポートしてるな。
0848デフォルトの名無しさん
2007/04/19(木) 22:03:55今のバージョンでOpenGLレンダリングでGLJPanel使うとよくおちる
5.0はまともにレンダリングされなかったけどな
なんかリペイントマネージャがおかしかった模様
JOGL＋GLCanvas自体は安定してるのでゲームでは問題ないけど、
GLJPanelが動くようにならないと復権無理だな
あとは入力インターフェースとして2軸2ボタンでいいのでジョイパッドの正式サポートを
0849デフォルトの名無しさん
2007/04/19(木) 23:13:540850デフォルトの名無しさん
2007/04/19(木) 23:31:50NIO2は別名なんだろ？
統合か名前が変わるかするだろう
0851デフォルトの名無しさん
2007/04/20(金) 10:36:48サントリー New Old
0852デフォルトの名無しさん
2007/04/20(金) 12:39:51あれはわざとやったらしいよ
0853デフォルトの名無しさん
2007/04/20(金) 23:37:330854デフォルトの名無しさん
2007/04/21(土) 00:43:10仁王？
0855デフォルトの名無しさん
2007/04/28(土) 06:15:280856デフォルトの名無しさん
2007/04/28(土) 09:15:37そうなのか。Sunってなんか変なところでマーケティングが変なこと言い出す気がする。
1.1→1.2→1.3→1.4→5.0→6.0
なバージョニングといい
J2SE→Java SE
といい。
0857デフォルトの名無しさん
2007/04/28(土) 09:42:56sunの文化として0.1がメジャーバージョンアップなんだよ
でもマイナーバージョンアップにしか見えない
だから製品名と内部バージョンとをわけるという他の会社と同じものにあわせた
あと6.0はない、6だ
Java2登場前はただのJavaがあったし、SDKはJDKという名前でまたJDKに戻った
Java2という名前を入れるときに製品名としては2.0にすべきだったのさ
ただそれだけのこと
0858デフォルトの名無しさん
2007/04/28(土) 11:14:04ブランド名はずっとJavaの4文字だし。
JDKに戻ったのもsun内部ではずっとJDKと呼ばれ続け、開発者側もJDKで十分慣れ親しんだため。
そして何より、今はゲイツの相手せずに済むから・・・
J/Directなんて禁句だぜ？
アゝ、なつかしの*7・・・
0859デフォルトの名無しさん
2007/04/28(土) 16:05:42♪ア・ソ～レ
ア・チョン！ ア・チョン！
ア・チョン！ チョン！ チョン！ バカ！
0860デフォルトの名無しさん
2007/04/29(日) 00:11:38String sql = <<END_OF_SQL
update USER_TBL
set name = ?,
age = ?
where id = ?
END_OF_SQL
0861デフォルトの名無しさん
2007/04/29(日) 00:14:260862デフォルトの名無しさん
2007/04/29(日) 00:34:43commonsにライブラリあるからそれで十分。
0863デフォルトの名無しさん
2007/04/29(日) 08:52:50ヒアドキュメントは確かに欲しい
あと、ヒアドキュメント中にJavaの式を埋め込むこともできたらいいな
0864デフォルトの名無しさん
2007/04/29(日) 09:17:280865デフォルトの名無しさん
2007/04/29(日) 09:57:060866デフォルトの名無しさん
2007/04/29(日) 10:20:46ほとんどの場合Excel準拠でいいのだろうが
H2のライブラリを使うという手もある
だが、まずはファイルのコピー等を実装するのが先じゃね？
0867デフォルトの名無しさん
2007/04/29(日) 10:47:04カンマで区切る以外はメチャクチャだろ。
0868デフォルトの名無しさん
2007/04/29(日) 11:05:130869デフォルトの名無しさん
2007/04/29(日) 11:53:46ときには全く意味ないよね。
0870デフォルトの名無しさん
2007/04/29(日) 12:37:17どうせやるなら文字コードやどのソフトで出力したかなどメタ情報がほしいね
そのへんつっこんでいくとXMLになるから意味がないのだけれども
0871デフォルトの名無しさん
2007/04/29(日) 12:55:08RFC準拠の標準ライブラリとかならともかく、
自分とこの独自規格に合ったのが欲しいなら
自前の CSVライブラリ作った方が楽だし簡単。
0872デフォルトの名無しさん
2007/04/29(日) 13:07:50これ使ってる。別に困った事はない。というか、ＣＳＶ使うのは止めて欲しい。
問題が解決するわけじゃないが、タブ区切りの方が好み。
カンマより、タブの方が文章中で出てくる頻度が少ない。
というか、明確に項目を区切るための制御文字があってそれを入力できる方がいいなぁ
0873デフォルトの名無しさん
2007/04/29(日) 13:08:18MIMEにあるかIANAに見に行って、RFCも日本語訳参考にしてるから
たぶん仕様的には正確だと思う。
RFC4180についてだけど、セル内改行を LF にすればExcel CSVに対応できる。
しかしAccess CSVは CRLF で、RFC4180と仕様が同じという困ったちゃん。
読み込みは柔軟に、書き出しは目的に合わせて厳密にという対応が必要だね。
0874デフォルトの名無しさん
2007/04/29(日) 13:28:53相変わらずMSはオープン標準に従う気はないし。
テキストフォーマットの読み書きといえばODFなんかの文書フォーマット読み書きライブラリが標準拡張くらいであっても良いのにね。
やるとしたらテキストコンポーネントのプラグイン扱いかな。
変なところで妙に充実してるのがjavaのクラスライブラリなんだし。
0875デフォルトの名無しさん
2007/04/29(日) 13:29:04おれもそのAccessとの対応を対数ヶ月前やった
ダブルクォーテーションの中はあらゆる改行タイプをゆるせばいいだけだったっぽい
動きとしてはAccessのほうが納得しやすい
0876デフォルトの名無しさん
2007/04/29(日) 13:35:53javaってinterface作るのは好きだけど
SPIを作るのは嫌いって人が多すぎるんだよね。
MP3とかOGGとかSound APIにちょこっとしか準拠してないしｗ
0877デフォルトの名無しさん
2007/04/29(日) 13:54:41インターフェース作る＝自分でAPI定義
SPIの実装＝定義にあわせて作る
だからまったく別の話じゃね？
0878デフォルトの名無しさん
2007/04/29(日) 14:00:48ルールに従うくらいなら俺仕様でって奴が多いってこと。
0879デフォルトの名無しさん
2007/04/29(日) 21:31:55うわ、激烈耳が痛てぇ。 orz
0880デフォルトの名無しさん
2007/04/29(日) 23:46:40それじゃMSがやってることと同じじゃんか。
0881デフォルトの名無しさん
2007/04/30(月) 00:08:540882デフォルトの名無しさん
2007/04/30(月) 00:36:26例えば標準のプラグインがヘボいので上書きしたい場合みたいに
他のプラグインと衝突する場合のガイドラインがなかったりするし。
いざ作ろうとすると、SPIまわりはドキュメントが不足してる。
他にも、Sun の標準プラグインに必要なインターフェイスだけしかないとか
java.net.URLStreamHandlerFactory はなんで SPIになってねーんだとか
SPI自体がテキトーに作られてる感が無きにしも非ず。
0883デフォルトの名無しさん
2007/04/30(月) 10:26:19コンパイラに実装するのは難しくないだろ。
いろんなComplexクラスとか見ると、また車輪の最発明なのかと思って悲しくなる。
0884デフォルトの名無しさん
2007/04/30(月) 10:55:57C99なんて仕様だけだろﾌﾟｷﾞｬｰm9
って言えばいいのか？
マジレスもしとくか、複素数を普通の演算子で扱いたいって事なんだろうけど
Javaの流れとしてはXMLリテラルの方が先じゃない？
俺としてはどっちも要らんが。
0885デフォルトの名無しさん
2007/04/30(月) 11:42:39確かに人それぞれの複素数クラスがあるよね。
0886デフォルトの名無しさん
2007/04/30(月) 12:50:02複素数型がライブラリ毎に違うのが面倒くさいとか
そーゆーケースでもない限り標準APIに拘る必要も無いような。
複素数型入れても今更感が強いし、
下手すると独自規格乱立したCSVに後付標準規格(?)ができたのと同じで
それほど意味がないものになるような気もする。
0887デフォルトの名無しさん
2007/04/30(月) 12:55:54gccのC99じゃだめなのか？
Javaも無料のコンパイラ使ってるくせに…
0888デフォルトの名無しさん
2007/04/30(月) 15:30:340889デフォルトの名無しさん
2007/04/30(月) 15:56:36Complexクラスが標準になればいいだけの話か。
0890デフォルトの名無しさん
2007/04/30(月) 16:45:230891デフォルトの名無しさん
2007/04/30(月) 17:05:27同時にWikipedia以外のWikiも盛り上げよう！
0892デフォルトの名無しさん
2007/04/30(月) 17:17:46携帯するものなんて電話以外にもいくらでもあるのに
携帯電話を携帯って略すのもやめよう
0893デフォルトの名無しさん
2007/04/30(月) 17:29:32リテラルは知らんけど、BigInteger BigDecimal の演算子オーバーロードは
dolphin で追加されそうな気配はある。>>132 のスライドに入ってるし。
もっとも、目玉は closure と erase erasure だろうけど。
closure というか、function type の実装には
java.lang.function パッケージに引数型+戻り値型を名前にした interface を使うみたいだけど
（ {int=>int} なら java.lang.function.II みたいな名前で int invoke(int) だけを持つ interface）
これ、実行時に生成するなら同じ仕組みで List<String> とかも生成するんじゃないかな。
と妄想中。VM（厳密には ClassLoader？）に手を入れる事になるけど。
で、そっちに時間取られると演算子オーバーロードとかは漏れる可能性もあるもしんない。
0894デフォルトの名無しさん
2007/04/30(月) 17:57:08seasarスレにカエレ(・∀・)
ま、どうせこのスレとあっちのスレ、中の人は同じだがな。
0895デフォルトの名無しさん
2007/04/30(月) 18:23:11スレッドはネイティブ対応しないのか？
あーらんに負けるぞ。
0896デフォルトの名無しさん
2007/04/30(月) 18:28:56？？？
0897デフォルトの名無しさん
2007/04/30(月) 19:25:000898デフォルトの名無しさん
2007/04/30(月) 19:34:540899デフォルトの名無しさん
2007/04/30(月) 19:46:22ﾉｼ おれもれも。
ところでRuby処理系のネイティヴスレッド化って完了したの？
YARV Ruby でぐぐってみたけど、ささだ先生のところは0.4.1くらいで更新が
止まってるみたいで、最新の状況がよくわからん。
あ、スレちがいか。すまん。
0900デフォルトの名無しさん
2007/04/30(月) 20:17:55目玉はBigIntegerとBigDecimalだと思うよ
業務アプリだとこの辺頻繁に使うし
0901デフォルトの名無しさん
2007/04/30(月) 20:19:27そういうときはJRubyに関連付けするのだ
0.9.9がでたのでもうすぐ正式版が登場
つまりJavaVM上でRubyは動かすのが正解
VM起動時間なんてJavaSE6なら2回目以降は0.5秒だから問題ないし
0902デフォルトの名無しさん
2007/04/30(月) 20:46:47っても、closureの話は聞こえてくるけどBigDecimalの話はあんまし聞こえてこないんだよね。
0903デフォルトの名無しさん
2007/04/30(月) 20:53:57仕事に絡まないプログラムならそうかもしれんが
仕事では使わないという場面はほとんどないからなぁ。
そして仕事で組んでる場合、次の技術というのに目が行く人は少ない。
目をつけていても発言する場が日本語でできないのなら誰もしないだろうさ。
0904デフォルトの名無しさん
2007/04/30(月) 21:24:54いや、Sunがどーゆー実装にするとか、JCPでどーゆー提案が出たとか
そーゆー話が聞こえてこないって事なんだけど。
0905デフォルトの名無しさん
2007/04/30(月) 21:37:140906デフォルトの名無しさん
2007/04/30(月) 21:42:30>目をつけていても発言する場が日本語でできないのなら誰もしないだろうさ。
技術者として終わってるな
0907デフォルトの名無しさん
2007/04/30(月) 21:51:54じゃぁ始まってるアンタが変えてよ
0908デフォルトの名無しさん
2007/04/30(月) 21:56:07愚痴たれるんならマ板に行ってやれ。
0909デフォルトの名無しさん
2007/04/30(月) 22:04:35たとえ真実でも、言ってはいけない事ってのがあってだな……
0910デフォルトの名無しさん
2007/04/30(月) 22:28:02PGが絶対口にしてはいけない一言
http://pc11.2ch.net/test/read.cgi/tech/1176001986/l50
0911デフォルトの名無しさん
2007/05/01(火) 01:55:23ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか
よりも、プリミティブな複素数型を言語に追加してくれってこと。
複素数は機種依存するもんじゃないし、
たとえばFFTや平面座標上の点の計算に活躍する。
0912デフォルトの名無しさん
2007/05/01(火) 02:00:430913デフォルトの名無しさん
2007/05/01(火) 07:17:37現実的に国内で業務システムに絡んでる奴は
頭弱すぎて割り込めないだけ。
0914デフォルトの名無しさん
2007/05/01(火) 07:49:23> たとえばFFTや平面座標上の点の計算に活躍する。
の用途のために、何故
> プリミティブな複素数型を言語に追加してくれってこと。
が必要なのかわからん。クラスじゃ何でダメなんだ？
あと「プリミティブな」ってVM変更（バイトコードインストラクションを拡張）しろって話？
たぶん、そんな要求してもマトモに相手にされないと思うけど。
0915デフォルトの名無しさん
2007/05/01(火) 08:19:29言葉が不自由なので、自分の要求を正しく伝えられないのでは？
0916デフォルトの名無しさん
2007/05/01(火) 08:35:19言語仕様の追加みたいだけど、どこからVM仕様追加の話になるんだ？
C99のようにゴニョゴニョっとまねして、チャチャッ実装しちゃってくれってことじゃないのか。
まあ、あれば便利だし、有難く使わせてもらうけど。
0917デフォルトの名無しさん
2007/05/01(火) 08:42:260918デフォルトの名無しさん
2007/05/01(火) 08:54:090919デフォルトの名無しさん
2007/05/01(火) 08:56:26いちいち、引数をとらないといけないし、Fortranなどマシン語レベルの
ライブラリ充実している言語と比べると、スピードが出ないだろうけど、
だからといって、VM仕様から変更は影響が大きすぎるだろ。
0920デフォルトの名無しさん
2007/05/01(火) 09:06:24だからどうしてVM仕様変更の話になるんだと小一時間（ｒｙ
0921デフォルトの名無しさん
2007/05/01(火) 09:14:02http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19511
0922デフォルトの名無しさん
2007/05/01(火) 09:36:30strictfpで宣言しない限り結局はFPUに計算させてない？
0923デフォルトの名無しさん
2007/05/01(火) 10:37:21>>911 の
> ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか
> よりも、プリミティブな複素数型を言語に追加してくれってこと。
から。
クラスもダメで、演算子オーバーロードもダメで（たぶんリテラルもダメ）、
プリミティブな型を追加と言われたらバイトコード拡張なのか？ ってのは至極当然。
0924デフォルトの名無しさん
2007/05/01(火) 11:13:540925デフォルトの名無しさん
2007/05/02(水) 04:33:33>>921
>>923
それがどうやって実装されるかということを君達がアレコレ妄想する必要はない。
それがあればどう世界が変わるかだけを考えろ！
0926デフォルトの名無しさん
2007/05/02(水) 07:43:02以上
0927デフォルトの名無しさん
2007/05/02(水) 08:46:01複素数リテラルって何？
3.1i
1 + 2i
"3 + 4i"
とかのことか
それと演算子オーバーロードは、
Complex,Matrixクラスの話題とよくセットで出てくるが、
その程度で演算子オーバーロードを実装するのはコストが
高いなどの論点とは今回は関係ないようだ。
おまえは思い込みが激しいようだな。
0928デフォルトの名無しさん
2007/05/02(水) 08:57:250929デフォルトの名無しさん
2007/05/02(水) 09:03:14>>928
おまえ誰だよ。早く消えちまいな。
0930デフォルトの名無しさん
2007/05/02(水) 09:35:380931デフォルトの名無しさん
2007/05/02(水) 11:39:25ｦﾀとDQNが抜けてるぞ
0932デフォルトの名無しさん
2007/05/03(木) 06:00:15どう実装されるかはしらんが、プリミティブ型を追加するという時点でVMに手をいれないといけないのは決定だろ。
0933デフォルトの名無しさん
2007/05/03(木) 09:20:31struct complex {double real, imag;}
struct complex {double z[2];}
とかで実装されてるんじゃないか。
だからコンパイラの拡張のみでマシーン（VM)の方に手を入れることはない。
というか、一般人が実装のことを考える事自体が意味ないじゃん。
0934デフォルトの名無しさん
2007/05/03(木) 09:32:360935デフォルトの名無しさん
2007/05/03(木) 09:58:40えーと。
結局、プリミティブな複素数型は特に必要がなくてクラスでやってもOKって話かな？
本当に複素数型欲しいなら
現時点でGPLで配布されてる javac に複素数型導入して公開したり、
そのパッチを ksl に投稿してみるとか、
BugDatabaseに行って、RFE出すとか既存のRFEに投票するとか、
その bugID 晒して、皆に投票呼びかけたりとか、
もちっと前向きな行動した方が良いと思うよ。
ここで複素数追加みたいなネタ振られたって、
皆でどーゆー実装するのか妄想して遊ぶぐらいしかできないでしょ。
0936デフォルトの名無しさん
2007/05/03(木) 10:09:09複素数クラスがあってもnewしまくるから遠慮してたけど、
言語に追加されるなら便利そうだけどな。
今のトレンドは言語に複素数を追加することなんじゃないか。
C,D,Pythonは既に言語レベルでサポートしてるし。
0937デフォルトの名無しさん
2007/05/03(木) 10:25:590938デフォルトの名無しさん
2007/05/03(木) 10:37:45頭悪そう
C99を使ってろ
0939デフォルトの名無しさん
2007/05/03(木) 10:53:07ちなみに、何を作りたくて複素数型が必要なんだ？
0940デフォルトの名無しさん
2007/05/03(木) 10:57:23C#の値型は、クラスと比べてどんなメリットがあるの？
コンパイル時に最適化されて
ランタイム負荷が小さいとか？
0941デフォルトの名無しさん
2007/05/03(木) 12:34:41クラスのオブジェクトに比べ生成と削除のコストが低い。
値型は参照を介せずにスタックに直接値が格納されたり、
配列やクラスのメンバーとして直接その領域に値が格納されるので
ボクシングが発生しない限りGCの必要な実体が作られることがない。
このためプリミティブ型に近いパフォーマンスを発揮する。
0942デフォルトの名無しさん
2007/05/03(木) 12:45:20必要ないんでしょ。
ってか、実際に複素数型が必要な分野のプログラム組んでる人間が
「演算子オーバーロードよりもプリミティブな複素数型」なんて言うとは考えられないし。
0943デフォルトの名無しさん
2007/05/03(木) 14:50:30値型ってのが広い範囲を表すからいいたいことがあいまいだぞ
0944デフォルトの名無しさん
2007/05/03(木) 15:00:41ByteBufferで我慢が出来ないなら諦めてくれって方針で十分。
0945デフォルトの名無しさん
2007/05/03(木) 19:32:28だから、それはプリミティブ型じゃないだろ。
0946デフォルトの名無しさん
2007/05/03(木) 20:49:44って言いたかっただけなんじゃないか、と。
0947デフォルトの名無しさん
2007/05/03(木) 21:32:14Java に C# の値型みたいなの導入すると
コンパイラ弄るだけじゃすまなくて、それこそ VMの変更が必要なりそうだし。
メソッドの戻り値で値型を使う場合とか。
それに、C# は最初から値型があったから良いけど、
Java の場合は generics 導入しちゃった後だからねぇ。
今から C# の値型みたいなものを追加したとしても
現時点でのプリミティブ型みたいに generics で使えなさそうだし。
0948デフォルトの名無しさん
2007/05/03(木) 21:52:460949デフォルトの名無しさん
2007/05/03(木) 22:05:05おいおい……
バイトコードインストラクションの話ならJSR-292のinvokedynamic追加の検討中。
後は>>893がfunction type関連でVM拡張とか言ってる。
0950デフォルトの名無しさん
2007/05/03(木) 22:13:31さんくす。複素数の議論でVM拡張は避けるべき的な話が出てたので確認してみた。
別にVM拡張前提で話をしてもかまわないわけだよね。
0951デフォルトの名無しさん
2007/05/03(木) 22:21:32ここは「次世代Javaの動向」をヲチるスレだから、
新機能追加の要望とか、単なる妄想オナニーなら他所でやってくれ。
0952デフォルトの名無しさん
2007/05/03(木) 22:24:400953デフォルトの名無しさん
2007/05/03(木) 22:28:41ヲチするだけとはどこにも書いてないわけで。
しかも、最初から要望とか妄想オナニーばかりのスレで、950も過ぎてから言ったところで説得力ない。
0954デフォルトの名無しさん
2007/05/03(木) 22:32:05今回ので言えば、既に >>935 で他所行けって出てるし。
他の話題でも他所行けってのは散々出てるし。
0955デフォルトの名無しさん
2007/05/03(木) 22:38:340956デフォルトの名無しさん
2007/05/03(木) 22:41:32便所に落書きしても要望だとは思われないよな。普通は。
0957デフォルトの名無しさん
2007/05/04(金) 01:17:58言語仕様に含めるのはやり過ぎです。
ところで値型って、VBのByValを指しているの？
0958デフォルトの名無しさん
2007/05/04(金) 01:45:44ここは予想や感想を述べる場所じゃないとのことなので、
そういう動向は今のところ無いということでおしまいらしい。
値型はVB.NET以降では、ユーザー定義型（Structure）、Enum、クラスを除くVBの基本データ型をさす。
VBのデータ型と.NET(CLR)のプリミティブ型は若干違うから注意。
ここではユーザー定義型（Structure）の意味で使ってる。
.NET(CLR)ではValueType C#ではstruct。
Javaだと参照型以外の型＝プリミティブ型＝値型という理解でいいのかな？（自信は無いが）
あとは質問か雑談スレへとかいわれそうだ。
0959デフォルトの名無しさん
2007/05/04(金) 03:50:43「普通は。」ってなんだよ 9m(^x^
0960デフォルトの名無しさん
2007/05/04(金) 09:51:42Java：エスケープ分析で自動的にスタックに置くｳﾏｰ
0961デフォルトの名無しさん
2007/05/04(金) 12:14:58typedef double complex[2];
でいいじゃん。どう実装されるかなんかはベンダ任せなんだけどね。
0962デフォルトの名無しさん
2007/05/04(金) 19:07:540963デフォルトの名無しさん
2007/05/04(金) 20:59:250964デフォルトの名無しさん
2007/05/05(土) 21:03:270965デフォルトの名無しさん
2007/05/06(日) 18:45:02VMに組み込むべきだ。
0966デフォルトの名無しさん
2007/05/07(月) 17:29:02http://download.java.net/jdk7/changes/jdk7-b12.html
http://download.java.net/jdk7/binaries/
IO関連とOpenJDK関連の修正が多いみたい。
0967デフォルトの名無しさん
2007/05/09(水) 01:30:29一波乱ありそうだな。ネットスケープにJavaの商標貸さなかったら
JavaScriptになってたんだろうな。
0968デフォルトの名無しさん
2007/05/09(水) 01:52:50もうちょっとカッコ良い名前を考えてくれー
0969デフォルトの名無しさん
2007/05/09(水) 10:37:10そして、Pnutsとの絡みも・・・
0970デフォルトの名無しさん
2007/05/10(木) 12:25:51個人的にはXMLより見やすくて良さそう。
0971デフォルトの名無しさん
2007/05/10(木) 13:47:390972デフォルトの名無しさん
2007/05/10(木) 14:03:32FXは新規におこしたもの、というよりは>>970のいうようにXAML対抗に見える
Javascriptは標準APIにきたことや、JRubyの力の入れ具合もすごいことで
Groovyがどんどん存在価値がなくなってるのは確かに悲しいかも
0973デフォルトの名無しさん
2007/05/10(木) 21:14:22全然簡単じゃないし。速くもないし・・・・
0974デフォルトの名無しさん
2007/05/10(木) 22:10:22Pythonは世界では結構使われてるが日本ではドマイナーという部分を引いても。
けど、サーバーサイドでrubyが祭り起こしたし
最近JRubyも1.0へ向けてラストスパートって所だから熱いよね。
JavaEEサーバと相性良いかも。
Groovyは更新遅いし、スクリプト言語らしい手抜きが出来ないし・・・
う～んRhinoでLiveConnect使うよりJavaとの親和性高いんだけどね。
ただ、jdk6のRhinoはただの劣化品。
0975デフォルトの名無しさん
2007/05/10(木) 22:12:55標準APIなんてそんなものだ
Pythonは各種IDEのサポート具合考えると日本以外でも注目されてないんじゃないの？
Googleでもそれほどマンセーじゃなかったのが意外だったけど
0976デフォルトの名無しさん
2007/05/10(木) 23:22:20これは本家の実装がしょぼいってこと？
0977デフォルトの名無しさん
2007/05/10(木) 23:33:07JVMの性能向上がポイントじゃないか？
同じ意味で、Jyphonも注目あびてんじゃないかと思う。
0978デフォルトの名無しさん
2007/05/10(木) 23:34:170979デフォルトの名無しさん
2007/05/11(金) 00:05:04Flash Player並にさくっとインストールされるようになると最高なんだけど。
0980デフォルトの名無しさん
2007/05/11(金) 00:09:221.2、1.4とか1.5の大きさにそれぞれ驚いたものだ
>>976
JavaScriptingAPI上のスクリプトはコンパイルして実行できるから速くても驚かん
つーか、実際速いので運用はJavaVMでというのが現実的
0981デフォルトの名無しさん
2007/05/11(金) 00:24:41動的・静的共にバイトコードへコンパイル可能なRhinoが
すべてとっぱらわれてインタプリタモードのみになったんだぞ？
だから実装次第。
コンパイルモードのRhino早かったのに・・・。
0982デフォルトの名無しさん
2007/05/11(金) 00:26:430983デフォルトの名無しさん
2007/05/11(金) 01:22:080984デフォルトの名無しさん
2007/05/11(金) 01:25:36ん？オプションであるというのは>>980の書き方でわかるはずだが
0985デフォルトの名無しさん
2007/05/11(金) 01:26:52http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html
0986デフォルトの名無しさん
2007/05/11(金) 15:15:11わかんねーよ
0987デフォルトの名無しさん
2007/05/11(金) 16:22:110988デフォルトの名無しさん
2007/05/11(金) 17:58:20FlashみたいにWebページの中に埋め込めないのかな・・・？
0989デフォルトの名無しさん
2007/05/11(金) 18:37:120990デフォルトの名無しさん
2007/05/11(金) 20:01:04JavaFX起動するFlash書けばいいんじゃね？
0991デフォルトの名無しさん
2007/05/11(金) 20:14:01アプレットにFX組み込めるんじゃない？
けど、今時アプレットなんて日本人しか使わないからあんま利点ないよ。
0992デフォルトの名無しさん
2007/05/11(金) 20:40:440993デフォルトの名無しさん
2007/05/11(金) 21:46:54FXは実行環境はアプレットでしょ？
直接バイトコード生成して渡すほうがメインとかいっとるけど、Swing理解してないやつにしかメリットがないなぁ。
0994デフォルトの名無しさん
2007/05/11(金) 22:10:140995デフォルトの名無しさん
2007/05/11(金) 22:16:470996デフォルトの名無しさん
2007/05/12(土) 00:18:48組み込めるのかもしれないけど、アプレットを読み込んだ時のあのブラウザの動きが止まるのが、いやなんだよね。
0997デフォルトの名無しさん
2007/05/12(土) 00:40:18PDFも処理遅いだろ。JWSならインスコはネトワーク超しでも実行はローカルディスクだから止まらないんじゃない？
0998デフォルトの名無しさん
2007/05/12(土) 00:42:23SilverlightやFlashに勝てるか少なくとも並べなければ競争のスタートラインにすら立てまい
0999デフォルトの名無しさん
2007/05/12(土) 00:42:23現在のプレビュー版では、動作環境となるJavaFXフレームワークに含まれるインタープリタで実行されるが、
将来はコンパイラを提供し、JavaFX Scriptから直接バイトコードを生成し、これをJVM上で実行することが計画されているという。
そのため、現在はJavaFX Scirptで記述したWebサイトにアクセスした際に、クライアントにはインタープリタがダウンロードされることになるが、
将来はバイトコードが Java Appletとしてクライアントに送られてくるだけで、インタープリタのダウンロードは不要になるという。
だって。
1000デフォルトの名無しさん
2007/05/12(土) 01:15:431001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。