06/07/17 21:36:03
＞JDK6にむけてRhinoの勉強をしているんですが
なんかRhinoがJava6から脱落したみたいなレスがどっかにあったような…。
522:デフォルトの名無しさん
06/07/17 21:40:01
>>519
夏帆クラスの女の子の手作りケーキは付くのか付かないのか、
それが問題だと（ry
523:デフォルトの名無しさん
06/07/17 21:45:18
>>521
>>487 ただし、b90ｲﾝｽｺに失敗するので試せてない
524:デフォルトの名無しさん
06/07/17 22:04:31
b91 だと Rhino あるよ。rt.jar の中っぽいけど。
525:デフォルトの名無しさん
06/07/17 22:41:51
>>520
JavaScript側で設定した変数の値を、Java側にとってこようとしています。
そのため、JavaScript側でintを設定したつもりなのに、Java側に渡るとDoubleになっているのは困る訳です。
526:デフォルトの名無しさん
06/07/17 22:54:10
scriptでは常にDouble
精度速度保障のために値が変更されなければintのまま扱ってるだけだろうな
定数だけという感じで
だからJavaではDoubleをすべてvalueofで拾うのが正しそうだが
527:デフォルトの名無しさん
06/07/18 18:12:28
>>525
ウチで試したら、代入したときからDoubleみたい。
というか、何か呼び出し方が違うなぁ・・・・Binding使ってるから変換されてる？
この挙動から推察すると、JavaとのインターフェースではDoubleになるのが仕様なのでは？
/*ソースはインデントの為、半角→全角変換しています*/
package script;
import javax.script.*;
public class TypeTest {
public static void main(String[] args) {
try {
ScriptEngine se = new ScriptEngineManager().getEngineByName("js");
Bindings bdg = se.createBindings();
bdg.put("x", null);
se.setBindings(bdg, ScriptContext.ENGINE_SCOPE);
Object res;
res = se.eval("var x = 1;");
System.out.println("JS Binding:"
+ bdg.get("x").getClass().getName() + ":"
+ bdg.get("x"));
} catch (ScriptException e) {
e.printStackTrace();
}
}
}
結果：
JS Binding:java.lang.Double:1.0
528:デフォルトの名無しさん
06/07/21 17:58:47
b90以降インストール出来ない件は
やはりバグでした。b94でfix予定。
URLﾘﾝｸ(bugs.sun.com)
回避策は、
jdk*.exe /lang=1033
としてインストーラを起動。
英語版として起動させるという手段らしいです。
529:デフォルトの名無しさん
06/07/22 23:13:33
Java5のGenericsなクラス、Genericsによって
型指定されたクラス(たとえばList<String>とか)を
クラス図で記述できるUMLモデリングツールがほしい。
Jude3.0では対応していなかった。
530:デフォルトの名無しさん
06/07/23 12:58:22
Judeはいまだに5.0未対応か
1.4系のSystemLAFはぜんぜん似てないからちとな
531:デフォルトの名無しさん
06/08/08 09:03:43
>>528
b94の変更点一覧によると、インストーラの不具合は予定通り修正されたようだな。
532:デフォルトの名無しさん
06/08/09 02:17:11
>>531
いっぺん、アンインストールのときにエラーがでるかもしれんけど
気にせず２回目実行すれば大丈夫だな
533:デフォルトの名無しさん
06/08/09 19:38:40
そーいや、7月に Dolphin プロジェクト始まるとか言ってなかったっけ？
534:デフォルトの名無しさん
06/08/16 16:38:37
>>533
チェックしたら7/21にビルド始まってた
URLﾘﾝｸ(download.java.net)
ビルドサイクルは、まだ確立されてなさげだけど
535:デフォルトの名無しさん
06/08/16 16:47:24
>>534
追記：
ベースになってるのがb90-b93らしいので
>>528 の回避策を使わないとインストールできませんので。
536:デフォルトの名無しさん
06/08/20 17:29:10
Javaは引数の参照渡しができない
とんでもない駄作
537:デフォルトの名無しさん
06/08/20 17:35:07
536は引数の参照渡しができないとスワップもできない駄プログラマ
538:デフォルトの名無しさん
06/08/20 17:49:09
Javaは参照の値渡しをしているだけだ。
参照そのものは渡せない。だからライブラリが作りやすいのに。
539:デフォルトの名無しさん
06/08/20 19:12:00
> 536
問題なし。
void hoge(int[] a){
a[0]=a[0] * 2;
}
void main(){
int[] lap = {2}
hoge(lap);
int v = lap[0];
System.out.println(v);
}
540:デフォルトの名無しさん
06/08/21 14:08:50
C言語風だな。
541:デフォルトの名無しさん
06/08/21 14:59:40
>>539
Arrayでラップか、でもその場合つづりはwrapじゃないか？
542:デフォルトの名無しさん
06/08/21 15:06:53
>>522
STARDUST OFFICIAL SITE
URLﾘﾝｸ(www.stardust.co.jp)
こんな子がでたらそりゃどきどきするわな。
ただし時給1000円だと、こんなかわいい女の子と仲良くなった途端
仕事辞めちゃうもんだなw
543:デフォルトの名無しさん
06/08/21 18:51:32
>>542
こんなかわいい女の子がプログラミングに興味持つのだろうか？
周りを見回すと、数少ない女はみんな…ｒｙ
誰かかわいい女の子がいる職場知ってる？
544:デフォルトの名無しさん
06/08/21 19:04:01
可愛いってのはそれだけで才能だからな。それを活かせるのは
プログラムするところじゃないだろう。本人が好きなら分らんけど、
そうなる可能性は奇跡のように小さいだろうね。
545:デフォルトの名無しさん
06/08/21 22:03:24
peter ahe のブログみてたら クロージャの文法っぽいpdf が落ちてた。
URLﾘﾝｸ(blogs.sun.com)
クロージャ変換というのが提案されてて、
java.lang.Runnable みたいに 1つしかメソッドを持たない interface と
同じシグニチャを持つ クロージャは変換可能になるみたい。
（void() 型のクロージャは Runnable にも変換できるらしい？）
ただこれ、java.uril.concurrent.Executor executor = ...;
execurot.execute( (){ System.out.println("test"); } ); は
コンパイラが暗黙に Runnable の匿名クラス作ればOKっぽいけど
例えば Runnable と似たようなインターフェイス
interface MyInterface{ void method(); } があったときに
void() closure = (){ System.out.println("test");
Runnable r = closure;
MyInterface m = closure;
とかされた時どーすんのかな？ とか思った。
あと、null が正式に型に昇格する事も検討されてるらしい。
null.class とかできるようになるとか？
546:デフォルトの名無しさん
06/08/21 22:30:15
nullがクラスになったらどういう事が出来るようになるの？
547:デフォルトの名無しさん
06/08/21 22:47:37
reflection とか型推論とか通常は値を返さない関数のように動くクロージャに必要って書いてあるけど、
よくわからん。
548:デフォルトの名無しさん
06/08/21 23:04:29
あ、判った。匿名クロージャは引数型は必要だけど戻り値型を書かなくていいらしい。
で匿名クロージャで return 文を書かずに、その匿名クロージャが中途完了する場合
（必ず例外投げる場合とか？）は戻り値型が null になるって事らしい。
正常完了する場合とか、引数無しの return がある場合は戻り値型 が void になるって書いてあった。
549:デフォルトの名無しさん
06/08/21 23:08:15
それって、戻り値が「必ず」nullになるんなら、nullじゃなくてvoidにしたらなんで駄目なんだろうか。
550:デフォルトの名無しさん
06/08/21 23:14:42
戻り値が必ず null になる場合に void にしたら拙いじゃん。
Object closure() ってのがあって、
そのつもりで (){ return null; } って匿名クロージャ書いて
戻り値型を void にされたら適わん。
551:デフォルトの名無しさん
06/08/21 23:16:05
あれ？
nullが型になるってことは、そういう場合は
Null closure()
って書かないといけないってことなのかと思ったんだけど。
552:デフォルトの名無しさん
06/08/21 23:20:07
よーするに、中途完了する匿名クロージャは、
値を返すクロージャと型の互換性が無いと拙いって事では無いかと。
値を返すメソッドを持った interface を書いて、
実際には必ず例外投げる匿名クラスを作りたいとする。
匿名クラスの場合は戻り値型があるから良いけど、
匿名クロージャは明示的に戻り値型を書けないっぽいので。
戻り値型を null にしておけば、どんな戻り値型のクロージャとも
互換性ができるのでは無いかと思う。たぶん。
仮にそーだとすると、null は void の上位クラスって感じになるのかな？
553:デフォルトの名無しさん
06/08/21 23:25:47
void の上位クラスっつーか、null は void と Object の上位クラスって感じか……
554:デフォルトの名無しさん
06/08/21 23:38:53
>>545には、そんな難しい事書いてない。
値nullが存在する限り、値nullには型が必要ってだけ。
closureの文法では陽に書く場合があるので、これを機会に導入。
もともと型推論的には必要だったもの。
555:デフォルトの名無しさん
06/08/22 03:54:04
>>553
その辺はSubtypingのところに書いてあるな。
> A function type T is a subtype of function type U iff all of the following hold:
> ・Either
> ・The return type of T is either the same as the return type of U or
> ・Both return types are reference types and the return type of T is a subtype of the return type of
U, or
> ・the return type of U is void.
（以下、引数型や例外に関しての条件が続く）
以下の条件の全てをみたすなら関数型Tは関数型Uの下位型である。
・以下の何れか
・Tの戻り型がUの戻り型と同じ
・二つの戻り型が共に参照型であり、Tの戻り型がUの戻り型の下位型である
・Uの戻り型がvoidである
（以下、引数型や例外に関しての条件が続く）
556:デフォルトの名無しさん
06/08/22 04:20:12
Referencing names from the enclosing scope のところ見ると、
匿名クラスの時みたいに final 付けろって書いてあるね。
557:デフォルトの名無しさん
06/08/22 12:30:17
>>556
逆、逆。
匿名クラスのように、finalを*付けなくていい*と書いてある
テキトーに訳してみると
>> We do not propose a rule that requires referenced variables be final,
>> as is currently required for anonymous class instances.
現在、匿名クラスのインスタンスに対して要求されているような、参照される
変数がfinalでなければならないという制約は提案しない
>> The constraint on anonymous class instances is also relaxed to allow
>> them to reference any local variable in scope.
また、匿名クラスに対する制約も緩和され、スコープ内のどんなローカル変数も
参照できるようになる
558:デフォルトの名無しさん
06/08/22 12:35:56
>>545
> 例えば Runnable と似たようなインターフェイス
> interface MyInterface{ void method(); } があったときに
> void() closure = (){ System.out.println("test");
> Runnable r = closure;
> MyInterface m = closure;
> とかされた時どーすんのかな？ とか思った。
closureをラップするクラスをそれぞれの代入に対して、自動生成すればいいんでない？
Runnable r = new Runnable_closure_bridge(closure);
MyInterface m = new MyInterface_closure_bridge(closure);
みたいな感じで
559:デフォルトの名無しさん
06/08/22 19:35:52
>>557
あ、本当だ。嘘ついてすまん。
このスレの >>12 とかでも話題になってる変数の扱いとか、
どーなるんだろね？ 後は VM に変更なしで実装できるんか？とか。
560:デフォルトの名無しさん
06/08/22 21:36:40
>>559
基本的には、ほとんどの機能はVMに変更なしで、コンパイラのみで
実装できると思う(ただし、クラスファイルフォーマットの変更は必要か？)
ただ、クロージャの中からそれを囲む関数をreturnする機能
(Non-local transferの部分)はVM変更なしでやるのはつらそう
簡単に実装するには、例外を使えばいいだろうけど、それだと性能出ないだろうし
561:デフォルトの名無しさん
06/08/22 21:38:12
>>560
自己レス
> クロージャの中からそれを囲む関数をreturnする機能
クロージャの中からそれを囲む関数の外側へreturnする機能、の間違いだ
562:デフォルトの名無しさん
06/08/22 22:11:08
Non-local transferは、p.5-6に記述がある。
その中でも>>560が心配しているケースはUnmatchedNonlocalTranser例外になる。
563:デフォルトの名無しさん
06/08/23 17:50:22
URLﾘﾝｸ(journal.mycom.co.jp)
Javaにクロージャだって。
564:デフォルトの名無しさん
06/08/23 17:57:58
上を見てみろ
565:デフォルトの名無しさん
06/08/23 18:05:27
('A`)
566:デフォルトの名無しさん
06/08/23 18:49:28
苦労じゃ
567:デフォルトの名無しさん
06/08/23 19:07:55
くだらん
568:デフォルトの名無しさん
06/08/23 19:49:51
で、結局このクロージャ内からローカル変数は参照できるの？
それとも引数渡し？
569:デフォルトの名無しさん
06/08/23 22:18:36
馬も出てないのになぜjdk7の仕様を気にするのか・・
570:569
06/08/23 22:23:10
あ、ごめんここ次世代スレだった
スレ間違った
571:デフォルトの名無しさん
06/08/23 22:29:11
ん？なんでスレ違い？Java6はもうすぐ出るしここでもいいような・・・
572:デフォルトの名無しさん
06/08/24 00:48:51
Java6は、メンテナンスリリース色が高いからな。
今後も、偶数バージョンは小変更、奇数バージョンは大変更という感じになるみたい
573:デフォルトの名無しさん
06/08/24 01:01:50
だが、あいかわらず5.0update8でエンバグとかやらかしてるからなんとも・・・
Java2DのOpenGLがWin環境でもちゃんと動作するようになってるかが見もの
574:デフォルトの名無しさん
06/08/24 17:32:21
Java7でクロージャの導入か。
いまいちクロージャって理解できていないのだが、
「外側のメソッドのローカル変数にfinal がついていなくてもアクセス可能な匿名クラス」
が仮に認められたら、これはクロージャ？
575:デフォルトの名無しさん
06/08/24 20:48:36
>>574
ちょっと違うとおもう。
それよりもマルチスレッド下でローカル変数束縛するとスタック上の実体をコピーで解決するつもりだったらアウトだし
ローカル環境を生かしておくとGCでメモリ断片化激しくなりそうとか厭な考えがよぎっちゃうんだけど、どういう風にするつもりなんだろう？
HotSpotがSelf由来だと考えればなにか考慮されているのだろうけど、関連論文とか乗っかっている書き込みとか見かけた人いる？
576:デフォルトの名無しさん
06/08/24 21:00:11
スコープを変数化するのがクロージャって感じかな。
ECMAScript触ってると特にそう思う。
577:デフォルトの名無しさん
06/08/24 21:03:03
クロージャからのローカル変数のアクセスは暗黙的に排他すんじゃないの？
それよりスレッドにクロージャを渡すような使い方は俺はしたくねーな
578:デフォルトの名無しさん
06/08/24 21:19:25
スタックを保存してヒープにもってくとかそんな感じ？よーわからんなぁ。
スクリプトだとthisの扱いがいつでもmixinって感じで使いにくいから
クロージャ使わないとデリゲートにならないんだよな
579:デフォルトの名無しさん
06/08/24 21:52:28
文書読んでみたが、並行性については特に何もやる気ないみたいだね
必要なら今まで同様プログラマが対処しろって感じ
580:デフォルトの名無しさん
06/08/24 22:47:06
Java in the BoxさんとこにJava 6では
「Server VM と Client VM の動的な変更」がサポートされるとあるんだけど
これってSwingとかで文字列置換メソッドは
Server VMでJITコンパイルできるとかそんなん？
581:デフォルトの名無しさん
06/08/24 23:46:44
クロージャはifやforの{}が引数と戻り値持った感じだと思う
>>577
Rubyやってると割と普通な気がするんだが、どの辺がいやなの？
582:デフォルトの名無しさん
06/08/25 00:13:18
匿名クラスでコンストラクタ定義できればそれだけでいいんだけどな。
583:デフォルトの名無しさん
06/08/25 00:23:38
そんなことより、Genericsの仕様、
さらなる変化は無いのか？
パラメタライズドクラスを作るのが大変なんだが。
タイプセーフなため、配列と違って、List<Integer>はList<Number>のサブクラスにはできんし。
<>の中にさらに<>を入れ子に書いてとクラス設計が難しい。
パラメタライズされたクラスの継承でのパラメータの扱いといい、
慣れるのが大変。
584:デフォルトの名無しさん
06/08/25 01:32:15
解ってないんだけど、ローカル変数ってもともとスレッド毎でしょ？
マルチスレッドで、何の問題があるの？
スコープ抜けたときにスタックからヒープにコピーすればいいだけじゃん？
585:デフォルトの名無しさん
06/08/25 03:48:23
クロージャってC++にも追加されるんでしょ？
流行ってるね
586:デフォルトの名無しさん
06/08/25 06:38:13
>>584
そのスレッドで、Runnableなオブジェクトを作って
クロージャを引き渡したらどうなると思う？
そういうこと。
また、今のListener系のような使い方をした場合、
マルチスレッドになるのは目に見えてる。
ただ、先の文書ではそこらへんは保証しないみたい。
主張を読むと、そういう場合は、今まで通り匿名クラスを使うか、
Javaで既に用意されてる並行性の仕組みを使えってこと。
なぜなら、そんなのを必要としない大多数の開発者には
パフォーマンスが落ちるだけで有り難迷惑だから。
587:デフォルトの名無しさん
06/08/25 06:47:06
>>583
つワイルドカード
List<Integer> ints = new ArrayList<Integer>();
...
List<? extends Number> nums = ints; //OK
588:デフォルトの名無しさん
06/08/25 10:19:17
>>587
List<T extends Number> nums = ints;
はだめなのか
589:デフォルトの名無しさん
06/08/25 10:25:11
>>588
public <T> void aMethod() {
List<T extends Number> nums;
//
}
とかならTが型パラメータと分かるので可能だが、そうでなく唐突に
Tが出ても未定義シンボルになる。
590:デフォルトの名無しさん
06/08/25 10:26:20
と思ったら出来なかったorz
591:デフォルトの名無しさん
06/08/25 10:45:45
>>582
いや、普通にできるが。
592:デフォルトの名無しさん
06/08/25 21:40:02
インスタンスイニシャライザではダメなんですたぶん
593:デフォルトの名無しさん
06/08/25 21:52:34
>>589
うーむ。Tの定義ってメソッドの頭かクラス宣言の後だったんだね。
継承使うとき、どうりで変だと思った
class A<T> implements SuperA {}
という表記はうまくいっても
class A implements SuperA<T> {}
はうまくいかず未定義といわれる。
当然、
class A implements SuperA<T extends Number> {
は怒られる
class A implements SuperA<?> {
も怒られる。
594:デフォルトの名無しさん
06/08/25 23:08:22
変なのはおまいの頭だと思うよ…
595:デフォルトの名無しさん
06/08/25 23:21:55
いきなりむかつくこといいやがったなおめえ。
確かにgenericsにはまだまだ慣れていないが、
情報が少なすぎていつもGenericsで悪戦苦闘して
こっちは大変なんだよ。
しかし、Genericsでパラメタライズされたクラスを
作ってる奴は少ないんだな。
2chでも稀なほうか。
C++Templateとは似てるようで違うためか、
使いこなせない奴も多いもんだな。
596:デフォルトの名無しさん
06/08/25 23:34:05
>>595
情報とか言う以前に仕様書を読めよ。
あと
class A implements SuperA<T> {}
なんか A を使うときにどうやって T が型パラメタか
普通のクラスか見分けるんだよ。少なくとも
class A<T> implements SuperA<T> {}
とやらないとパラメタ指定できないだろ。
597:しろうと
06/08/25 23:59:55
ちょっと質問なんですが、クロージャが実現できると、何がウレシイのでしょうか？
実行時評価するわけじゃなくて匿名インナークラスのSyntaxSugar＋α程度のもの
でしかないのなら、別にどっちでもいいんじゃねえのとおもうんだが。
ここのところ、大々的に言語仕様かえるといっといて、結局やってることは
プリコンパイラにどっちでもいいだろという機能を追加してる程度のケース
が多いようなのだけど、どういう圧力からそういう結論になるのでしょうか。
後方互換を保つために妙な妥協して、あるべき論と掛け離れた中途半端な仕様
を差し込むくらいなら、何もしないほうがいいと思うのは私だけデスカ？
598:しろうと
06/08/26 00:09:24
>>595
別に無理に使わなくても、ちょっと頑張れば同じことができてたから
じゃないの。
おいらの場合、コードがコンパイラ依存になるのが嫌なので、当分セ
コセコデリゲートクラスとか自作して頑張ってくつもりです。
599:デフォルトの名無しさん
06/08/26 00:15:01
関数型のメリットは多いよ
・delegateの実装が楽（クロージャ）
・スクリプトフレームワークの拡張がしやすくなる
・継承では補いきれない差分プログラミングが可能（保守性向上）
600:デフォルトの名無しさん
06/08/26 00:17:08
>>597
> どういう圧力からそういう結論になるのでしょうか
VMにでかい機能を追加すると遅くなるだろ。
しかしGenericsの仕様はいくらなんでもあれだが。
601:デフォルトの名無しさん
06/08/26 00:20:42
>>598
Javaは私企業のプロダクトだから結局C#対抗な訳よ
マイクロソフトに負けたくないっていうSunの言語ｵﾀの意地とｵﾅﾆｰ
602:デフォルトの名無しさん
06/08/26 00:22:15
.classみたいな感じで.methodってできるようになったら良くない？
ってとっくに議論され、破棄されたんだろうが。。。
いまでもリフレクションでできるけど面倒なんだよね。
メソッドにアノテーションつけた時に参照するのも
obj.getClass().getMethod("method1").getAnnotation(anno);
とかだぜ。タイプセーフの意味がない。
これが
method1.method.getAnnotation(anno);
となりすっきり。。。
603:しろうと
06/08/26 00:24:17
>>601
Javaもめでたくオプソになるらしいし、そのうちC#コンパイラとか
出るんでねえのかなとか思う毎日。…って、APIのサポートがむずいかな。
604:デフォルトの名無しさん
06/08/26 00:26:39
ECMA標準のC#なら余裕だろ
SUNもJava VMを.NET化させるつもりだし
605:デフォルトの名無しさん
06/08/26 00:29:14
Sunっていつも後手後手だよね
606:デフォルトの名無しさん
06/08/26 00:30:09
夏休みもそろそろ終わりなのになぁ。。。
607:デフォルトの名無しさん
06/08/26 00:32:42
>>605 ？？？
夏だな
608:デフォルトの名無しさん
06/08/26 00:36:37
もうJavaもおわりだなと感じる今日この頃
609:デフォルトの名無しさん
06/08/26 00:37:49
JavaOneの聴講者数は年々増加の一途なのだが
610:デフォルトの名無しさん
06/08/26 00:38:56
>>608
そう思われる様になってからが華
611:デフォルトの名無しさん
06/08/26 00:40:26
>>609
それに比例して、馬鹿がますます増えてきたな。
612:デフォルトの名無しさん
06/08/26 00:41:08
Java人口の増加と先進性は反比例
613:デフォルトの名無しさん
06/08/26 00:42:48
>>602
Hoge.classがClass.forName("Hoge")の言語糖衣だと知った時はショックでした。
614:デフォルトの名無しさん
06/08/26 00:47:55
>>597の感想はもっともだよな
後方互換を気にしながらC#の後追いしてるくらいなら
新たな言語環境を提案してくれないかな
もっともSunにもIBMにも無理そうだな
615:デフォルトの名無しさん
06/08/26 00:49:30
>>613
ちがくないか？
Class<Hoge> c = Hoge.class;
と
Class<?> c = Class.forName("Hoge");
でしょ？オレが間違って覚えてるのか。。。？
616:デフォルトの名無しさん
06/08/26 00:49:58
> 新たな言語環境を提案してくれないかな
100%ぽしゃるから。今の時代はライブラリ＞言語仕様
617:デフォルトの名無しさん
06/08/26 00:58:11
>>615
日本語は間違って覚えてるね。
618:デフォルトの名無しさん
06/08/26 01:00:31
>>615
でそのGenericsも糖衣な訳だが
619:デフォルトの名無しさん
06/08/26 01:02:44
Javaの欠点はGUIライブラリの貧弱さ
620:デフォルトの名無しさん
06/08/26 01:04:00
>>619
Swingの実装感は.NETのライブラリとたいして変わらんと思うが。
問題は性能なのか？
621:デフォルトの名無しさん
06/08/26 01:06:06
>>618
そういえばそうか
でも.classリテラルはforName()とは使用場面が異なると思うんだが
それでも糖衣っていうのか。
622:デフォルトの名無しさん
06/08/26 01:08:42
>>621
Hoge.classはコンパイラ通すとClass.forName("Hoge")に
コンパイルされるってこったよ。
623:デフォルトの名無しさん
06/08/26 01:11:59
>>620
クライアントアプリを作るにはまだまだ
たとえるならXToolkitレベル
標準のFontChooserとかGridControllerとかなんで出てこないんだろ
624:デフォルトの名無しさん
06/08/26 01:13:48
>>623
目指すはVBなわけですな…かくてまた馬鹿が増えるのかorz
625:デフォルトの名無しさん
06/08/26 01:15:39
バッドノウハウとグッドラッパーの話だなこりゃ
626:デフォルトの名無しさん
06/08/26 01:19:50
目指すはVBてか、GUIはある程度統一されるべきな訳よ
GnomeやKDEのようにね
あるアプリで選択した色やフォントは、別なアプリでも使いたい
そのためにはJavaももうVMだけじゃなくて
バックグランドで常駐するサービスレイヤーが必要だと思うのね
627:デフォルトの名無しさん
06/08/26 01:21:54
>>626
>バックグランドで常駐するサービスレイヤー
Java6ってそれじゃなかったっけ。
628:デフォルトの名無しさん
06/08/26 01:22:08
>>622
syntax sugar ではあるが Class.forName("Hoge") にコンパイルされるわけではない。
>>623
Swing って SWT/JFace の対応で言う SWT の方 (基本機能) であって
高機能なコンポーネントは自作するorどっかからライブラリを探してくるor買う
もんだと思うんだが。
629:デフォルトの名無しさん
06/08/26 01:22:19
ブラウザがAPIいっぱつでデフォルトをぽんって出すから
そのうちメーラーとかコンパネとかフォントダイアログとか
そういうのもネイティブで出るんじゃないか
630:デフォルトの名無しさん
06/08/26 01:22:22
>>622
しつこいようだが、なんでジェネリックスだけ違うのかわからん。
Class<Hoge> c = Class.forName("Hoge");
がコンパイルしないのは何故？.classだとokなのに。
eraserとかってやつ関係かな？
631:デフォルトの名無しさん
06/08/26 01:26:57
>>623
それだといつまでたっても統一環境ができない
アプリは自作でいいが、サービス層はもっと充実させるべき
632:デフォルトの名無しさん
06/08/26 01:29:16
>>630
そういう場合こんな感じじゃなかったっけ
Class<Hoge> c = Class.<Hoge>forName("Hoge");
633:デフォルトの名無しさん
06/08/26 01:31:05
>>629
ブラウザが基盤だという発想には違和感感じっぱなしの私。
あれは明らかにアプリでしょうに…
634:デフォルトの名無しさん
06/08/26 01:33:30
>>632
よくわかんないけど
forName使う意味なくない？
forNameはコンパイル時にはclassが見えない時につかうんじゃね？
Hogeが手元に無い時とかさ。
635:デフォルトの名無しさん
06/08/26 01:37:21
>>634
そこは一応名前と実際のクラスは別もんということで、、、
クラスローダによってはほんとに別にできると思うけど
636:このネタ書いた人
06/08/26 01:48:59
正直どうでもいいんだけど
Class hoge = Hoge.class
を含むクラスをSunJDKのjavacでコンパイルして、javap -c してみると、
invokestatic Method java/lang/Class.forName:(Ljava/lang/String;)Ljava/lang/Class;
になるわけなんだが、俺なんか勘違いしてる？
637:デフォルトの名無しさん
06/08/26 02:03:04
まあGUIについてはJavaは約20年遅れてる
ってことでおやすみ
638:デフォルトの名無しさん
06/08/26 02:06:03
>>636
バージョンは？
確かにどーでもよいが。
639:デフォルトの名無しさん
06/08/26 02:08:48
>>638
手元のJDKは1.4.2_10。5.0は持ってないのでどうなるかシラン。
640:デフォルトの名無しさん
06/08/26 02:12:02
>>639
1.4までは.classは.forNameと同等
1.5からは扱いが変わったってことかな？
なんでかえる必要があったのか、というのは考えない事にします。
641:デフォルトの名無しさん
06/08/26 02:35:30
どうでもいいことだが、
1.5 からはクラスリテラルではクラスが初期化されない。
642:デフォルトの名無しさん
06/08/26 03:13:55
>>599
自分も、スクリプトフレームワーク側からの要請が
結構でかいんじゃないかと思う。
.NETなIronPythonは結構速いみたいだし、JythonとRhinoも速くなって欲しいな。
643:デフォルトの名無しさん
06/08/26 03:19:24
>>601
というけど、C#のようにはならんと思う。
C#とくらべかなりTypesafeだと思われ。
それだけにGenericsではパラメタライズされたクラスを
実装するのが難しいが。そのかわりタイプセーフが保証されるので
パラメタライズドクラスを便利に、かつ安心して使うことができる。
マイクロソフトに負けたくないってのとはちょっと違う。
っていうかJavaはもうSun私企業のプロダクトじゃなくなってるよ
Java Community ProcessによってだれでもJavaの変更について参加できる。
実際に変更するかどうかはゴスリングあたりが決めるが。
それも、JavaがC++の二の舞にならないようにするためさ。
644:デフォルトの名無しさん
06/08/26 03:20:37
>>604
> ECMA標準のC#なら余裕だろ
> SUNもJava VMを.NET化させるつもりだし
それは初耳。ソースはどこにある？
.NET化というのは.NETと共用するの間違いではないかと予想する。
645:デフォルトの名無しさん
06/08/26 03:21:39
>>614
？ ゴスリングが新しい言語を作りたいとかいってなかったけか？
646:デフォルトの名無しさん
06/08/26 03:23:52
>>611
JavaOne聴講者に馬鹿が増えたと？
去年JavaOneTokyo2005に行ったときはそうでもなかったが。
綺麗な設備に恵まれた東京国際フォーラムを全部貸し切って、
金のかかったイベントだなって気がしたけど。
647:デフォルトの名無しさん
06/08/26 03:24:08
>>612
夏っぽい発言だね
648:デフォルトの名無しさん
06/08/26 03:25:30
>>620
>>619は古い時代のSwingのことを言ってるだけかもしれないよ。
649:デフォルトの名無しさん
06/08/26 03:27:08
>>624
ちょっと違うな。
Java Studio CreatorがVB屋向けっていうけど
あれはなんだか、Dreamweaverに似てる。
デザイナにJavaを憶えさせたいという無謀な考えがSunに
あったのだろうか。
それでもCreatorの完成度は高いけどね。
しかしメモリ食うしかなり重たい・・・
650:デフォルトの名無しさん
06/08/26 06:47:46
なんか開発環境と実行環境がごっちゃになってる香具師がいるようだが？
651:デフォルトの名無しさん
06/08/26 06:49:35
>>648
では聞くけど新しい時代のSwingって何？
652:デフォルトの名無しさん
06/08/26 11:25:56
>>651
Java5とかJava6のSwingじゃね？
もしかしたらJava1.4.2かも知れんが。
少なくともJava1.2やJava1.3のSwingでないことは確か。
653:デフォルトの名無しさん
06/08/26 12:53:54
Java SE 6 は、SwingにもJOGLの3Dレンダリングが使えるようになるんだろ。
654:デフォルトの名無しさん
06/08/26 13:48:54
>>653
それっていいの？
何がどう変わるのさ
655:デフォルトの名無しさん
06/08/26 13:55:21
今までは3Dを使う場合はAWTにする必要があった。
そのためSwingで使う場合AWTで作られたリソースをバイト配列にして再構築していた。
あとLinuxとかならSwingは高速化するんと違うかな
656:デフォルトの名無しさん
06/08/26 22:39:37
>>650
にしても、VBなんて開発環境と言語がわんせっとになった言語だよな
657:デフォルトの名無しさん
06/08/26 22:41:07
>>651
タスクトレイが追加されたりタブのスクロールや移動ができて
かつSWTよりも高速になった時代のSwingだよ。
C++で作られたGUIと比べてもパフォーマンスのほうは大差なくなってきたって事だね
658:デフォルトの名無しさん
06/08/27 02:14:20
>>614
別に後追いばかりってわけじゃないぞ
プリミティブ型のboxing/unboxing、拡張for文、アノテーションあたりは後追い感が強いが
Genericsの仕様はC#のGenericsの仕様が決定するだいぶ前から検討されてたし、
今回の関数型およびクロージャの仕様はC#のデリゲートに比べるとかなり良い仕様に
なっていると思う
659:デフォルトの名無しさん
06/08/27 02:17:15
Java 7のはっちゃけぶりを見るとJVMを残してJavaを捨てる気まんまんだな
660:デフォルトの名無しさん
06/08/27 12:41:57
>>658
後追いといっても、C#とは仕様が異なる感じだな。
アノテーションもboxingも。
後追いのようになってしまったのは、
Java Community ProcessでC#のことをよく知ってる人が
Javaにもこういう機能つけてくれよって提案したからじゃないかな。
661:デフォルトの名無しさん
06/08/27 12:42:38
>>659
Javaの何をすてるんかな。
JVMがどう進化するのか楽しみではあるが
662:デフォルトの名無しさん
06/08/27 13:45:50
>>661
Javaの構文だけを整理したものが残ると思う
663:デフォルトの名無しさん
06/08/27 14:43:35
>>662
何がいいたいのかよくわからないが、
構文を整理したものって一体どういうものを想像している？
気になるので挙げてみておくれ
664:デフォルトの名無しさん
06/08/27 14:57:22
getter, setterとか、addListenerのデリゲート化とか。
あとはjava.ioとjava.nioの関係みたいに
互換性のために統合を避けた部分も整理して欲しいし
StackとかPropertiesみたいに設計に失敗した部分も直す。
Javaの資産はD言語みたいに別言語構文を解釈する制御を入れればいい。
665:デフォルトの名無しさん
06/08/27 16:54:38
それより何より、配列まわりの型の腐りっぷりをさっさとどうにかして欲しい。
666:デフォルトの名無しさん
06/08/27 17:01:18
>>664
> getter, setterとか、addListenerのデリゲート化とか。
たまにJavaスレに紛れ込むドトネト厨だかVB厨かよ。
getter,setterはどうでもいい。その程度ならdelegate化もどうでもいい。
どうせクロージャが追加されるならなおさらどうでもいい。
> あとはjava.ioとjava.nioの関係みたいに
> 互換性のために統合を避けた部分も整理して欲しいし
認識が甘い。そんなとこを統合してどうする。
それとも、整理する必要がどこにあるのか具体的に説明できるか？
> StackとかPropertiesみたいに設計に失敗した部分も直す。
初心者Java質問スレ見てた奴だな？
どう見直すというのか。放置か@Depricatedでいいだろ。
> Javaの資産はD言語みたいに別言語構文を解釈する制御を入れればいい。
Java6ではスクリプト言語を解釈するAPIがあるぞ。
667:デフォルトの名無しさん
06/08/27 17:02:20
>>665
それも、Collectionがあれはどうでもいい。
多次元ジャグ配列なんて滅多に使わないし。
無闇に使う奴は設計能力センスが甘いやつだね。
668:デフォルトの名無しさん
06/08/27 17:07:32
>>666
> getter,setterはどうでもいい。その程度ならdelegate化もどうでもいい。
おまえの主観だろ？多言語出身者は口をそろえて汚い仕様という
> それとも、整理する必要がどこにあるのか具体的に説明できるか？
現状でBufferを使いこなせる技術者は極端に少ない。
ファイルマップすら知らない奴ばっか。
> どう見直すというのか。放置か@Depricatedでいいだろ。
depricatedなクラスがシステムローダにロードされる時点でおかしい
> Java6ではスクリプト言語を解釈するAPIがあるぞ。
根本的な部分でアイタタタ
669:デフォルトの名無しさん
06/08/27 17:11:29
>>668
> 現状でBufferを使いこなせる技術者は極端に少ない。
他は言語環境の改善要求っぽいのに、これは完全な愚痴だな。
670:デフォルトの名無しさん
06/08/27 17:12:55
あちこちでdeprecated のスペル間違えているやつがいるな。
同一人物か
671:デフォルトの名無しさん
06/08/27 17:15:20
>>669
コンセプト違いの重複した機能があちこちにある時点で要改善だろ
672:デフォルトの名無しさん
06/08/27 17:15:54
>>668
> >>666
> > getter,setterはどうでもいい。その程度ならdelegate化もどうでもいい。
> おまえの主観だろ？多言語出身者は口をそろえて汚い仕様という
他言語出身者って、どうせC#やVB, Delphi言語出身者かドトネト厨である
おめえの主観だろw 綺麗な仕様とやらはC#やDelphiのget/set程度の仕様かw
あの程度で綺麗なら、演算子オーバーローディングやunsafeでソースコードが汚くなるのを
どうにかしようとは思わないのか。
> > それとも、整理する必要がどこにあるのか具体的に説明できるか？
> 現状でBufferを使いこなせる技術者は極端に少ない。
> ファイルマップすら知らない奴ばっか。
Bufferはまた別の話だろ。Bufferを使いこなせる奴が少ないのと
配列の型がどうだこうだと一体どう関係があるのか。
Bufferが何のためにあるのかわかって言ってるのか？
> > どう見直すというのか。放置か@Depricatedでいいだろ。
> depricatedなクラスがシステムローダにロードされる時点でおかしい
なにがどうおかしく、どう不具合が出るのか説明できるか？
> > Java6ではスクリプト言語を解釈するAPIがあるぞ。
> 根本的な部分でアイタタタ
お前が痛い。
673:デフォルトの名無しさん
06/08/27 17:16:29
>>670
レス元コピって使っただけだ。単語をひらで書けないのは確かだがｗ
674:デフォルトの名無しさん
06/08/27 17:16:37
>>671
> >>669
> コンセプト違いの重複した機能があちこちにある
たとえばどのあたりが？
675:デフォルトの名無しさん
06/08/27 17:17:58
>>672
お前が.NET中心でしかものを考えられないことは良く分かった。
そのほかの点についてもお前が無知なだけ。調べろ。
676:デフォルトの名無しさん
06/08/27 17:24:23
desktopアプリではflash player >>> JREなのになんでJREはあんなに巨大でなければいけないのか
Java DEとか駄目？1Mくらいのサイズ希望
677:デフォルトの名無しさん
06/08/27 17:29:46
flash って desktopアプリ？ webアプリじゃなくて？
678:デフォルトの名無しさん
06/08/27 17:38:38
>>675
でた厨房にありがちな最後の負け惜しみ逃げ台詞
679:デフォルトの名無しさん
06/08/27 17:40:36
>>678そのものがそれなんだけどなｗ
680:デフォルトの名無しさん
06/08/27 17:43:12
はいはいドトネト厨乙
681:デフォルトの名無しさん
06/08/27 17:44:34
説明の説明の説明を求められなきゃ分からん位の素人にJavaを擁護されてもな
682:デフォルトの名無しさん
06/08/27 17:50:48
意味が分からんよそこ
683:デフォルトの名無しさん
06/08/27 19:26:02
>>677
ブラウザーなくても動くし、おおよそのことはできると思うんだけど。
描画は早いし、ビデオやオーディオも強い
ソケットも使えるから、やろうと思えばDBにも直接接続できなくもない。
Java3dみたいのはないが。。。まだ。
684:デフォルトの名無しさん
06/08/27 21:46:29
自分の理解が足りないことを棚に上げて.NET厨扱いかよｗ
685:デフォルトの名無しさん
06/08/27 22:00:09
どどんとねっとじゃんぬねっと
686:デフォルトの名無しさん
06/08/27 22:09:04
ここはゲイツが悪いということで収めてくれ
687:デフォルトの名無しさん
06/08/27 23:58:56
できればスティーブ・バルマーにしてくれないか？
688:デフォルトの名無しさん
06/08/28 00:11:17
>>683
FlashはAS3で化けたが、描画が早いとかそんなことはない
Javaのほうがはるかに早い
機能が段違いすぎ
少なくともFlashでは単純なものしかロジックは書く気にはならないだろ
689:デフォルトの名無しさん
06/08/28 00:11:20
もう、ゲイツには力は無いよ。
そしてマイクロソフトもGoogleに推されている。
いつかマイクロソフトがGoogleの力によって陥落するのも時間の問題。
690:デフォルトの名無しさん
06/08/28 00:32:22
力がなくなろうがなにしようが悪いのがゲイツ
691:デフォルトの名無しさん
06/08/28 01:50:37
ウィリアムさまの悪口を言うなんて
なんて罰当たりな！w
692:デフォルトの名無しさん
06/08/28 02:57:40
何でいきなりクソスレ化するんだよ
693:デフォルトの名無しさん
06/08/28 04:12:03
必要な機能なら誰かが外部ライブラリで作ってくれるさ
本当に標準に必要なのは何かもうすぐコアライブラリのシュリンクが
入ってもいいんじゃないかと思う
SEが肥大化しすぎていると感じる今日この頃
Jakartaでいいじゃん、っていう機能がコアに
取り込まれてる気がしてなぁ・・・・
まぁ使う側からいえば、ライブラリ追加しなくて楽なんだが
それよりむしろ外部ライブラリを簡単に利用できる
仕組みの方が欲しいかな、JWSのライブラリ取得の仕組みを
もっと積極的に活用してもいいような気がする
694:デフォルトの名無しさん
06/08/28 05:31:07
言語仕様で縛って遅くする＋ライブラリを肥大化させて互換環境を作りにくくする、
ってのがお日様の戦略なんだろ
695:デフォルトの名無しさん
06/08/28 08:57:30
特定の言語が腐ってるとかAPIが腐ってるとか言う奴がよくいるが、
お前が言うところのその程度の腐れが、仕事上でダメージを与えるシーンが
あったのか？そういうことが影響を与えるほど、センシティブな職場で働い
てみたいよｗ
今まで困ったことの例:
・馬鹿なプログラマが意図不明な長大コードを混入させ、そこにバグが
あったため解析と修正を任された…
・頭の悪い上司から仕様不明目的不明ｲﾐﾌﾒｲの処理の実装を指示された…
・自社の自称エリート技術者ドモが、利用者側の要求と全く合致しない
フレームワークの利用を押し付けてきた…
・どこぞの営業が経歴詐称して素人をプロジェクトに押し込んできた…
問題は全部、人依存でした…orz
696:デフォルトの名無しさん
06/08/28 09:14:54
問題は人なんだとしたら、Javaだと開発効率が良くバグも少ないというのは妄想。
697:デフォルトの名無しさん
06/08/28 10:11:18
>>694
そこまで斜めに見なくてもいいんじゃない？
じゃ、ばっさり互換性切り捨てるのがいいってわけでもないと思うが
バージョン変わったら名前は同じだが、まったく違う言語になるよりいいかと。。。
698:デフォルトの名無しさん
06/08/28 13:05:21
>>697
何でもかんでもコアに入れたがるのは、
俺たちにコントロールさせろ、って宣言だ。
SWT見たいな外圧がないと、
まともな高速化をしようともしないくせに、
ベンチマークのでっち上げだけはうまいんだから。
699:デフォルトの名無しさん
06/08/28 14:13:15
次世代のDesktop javaに必要なのは、SWT並みのLAFと、
Swing並みのプログラムしやすさを持ったツールキット。
Windows FormsをJavaから使えるようにできんもんか。
700:デフォルトの名無しさん
06/08/28 18:47:54
>>691
ゲイツはウィリアムテルでもなければ
フランスからイギリスを征服したウィリアム獅子親王でもリチャード王の十字軍でもない。
701:デフォルトの名無しさん
06/08/28 18:48:39
>>694
そりゃお前の脳内で描かれた陳腐な戦略。
702:デフォルトの名無しさん
06/08/28 18:49:34
>>698
でっちあげ？たとえばどんなふうに？
703:デフォルトの名無しさん
06/08/28 18:50:54
>>699
やっぱりJavaスレにたまに現れるドトネト忠だ。
っていうか、逆にドトネト関連スレにもこういう
イチャモンつけてくるアホって
湧いてこないよね。
まるでドトネト忠は日本にイチャモンつける韓国人や中国人みたいだ。
704:デフォルトの名無しさん
06/08/28 20:42:36
>>703
お前はたから見ててひたすら痛いんだけど気づかない？
705:デフォルトの名無しさん
06/08/28 22:03:46
誰でもどっぷり浸かると周りが見えなくなるということなのかなぁ
706:デフォルトの名無しさん
06/08/28 22:54:35
>>704
イタイのはお前だよドトネト忠w
707:デフォルトの名無しさん
06/08/28 23:00:30
救いようが無いなｗ
708:デフォルトの名無しさん
06/08/28 23:02:04
>>688
デスクトップでGUI以外そんなにロジックを組む事もないんじゃないか？
逆にswingでこったGUIを作る気になるか？（例えばOS Xのexposeとか）
swingはHTMLのFormの代わりくらいが限度じゃないか？
速度ではアニメーションや透明度を使う場合、圧倒的にFlash > swingだとおもうけど。
いつか実証してみよう。
709:デフォルトの名無しさん
06/08/28 23:32:37
同じ穴の狢(むじな)
710:デフォルトの名無しさん
06/08/29 00:13:52
「～だと思う」で勝手な持論を展開する人は、何処にでもいるもんだな
711:708
06/08/29 00:48:08
でもあれだ、eclipseとかは到底無理だなflashじゃ。
iTunesくらいだったらflashでもいけるかな。
712:デフォルトの名無しさん
06/08/29 01:02:30
Javaじゃ60fpsは無理だしな。16.6秒の世界でsleepの分解能が15msて。
713:デフォルトの名無しさん
06/08/29 01:04:13
>>712
sleepなんてものつかうなよ
714:デフォルトの名無しさん
06/08/29 01:48:30
>>702
どっかのスレで散々議論されてたんじゃないか。
・JITが効果的に利くオブジェクトをほとんど生成しない
ベンチマークでC/C++と同等のパフォーマンスであると主張。
・Java[Runtime]は低レベルのアクセスしまくりでパフォーマンスを改善。
・上記２つをもって、Java[言語]で書かれたコードはC/C++と同等の
パフォーマンスであると主張。
それを信じて（？）Pure Javaでがりがり書かれたEJBのパフォーマンスときたら
715:デフォルトの名無しさん
06/08/29 02:48:24
しかしEJBのパフォーマンス問題はJavaだからというよりも
シリアライズが噛むからではあるまいか？
716:903
06/08/29 03:00:52
>>713
何を使えと？
717:デフォルトの名無しさん
06/08/29 03:19:40
>>716
PC は知らないが少なくともケータイだと一番分解能があるのは Object#wait だよ
718:デフォルトの名無しさん
06/08/29 03:56:43
>>714
話途中から変わってない?
JDKのパッケージングの問題(>>698)が、
JavaコンパイラのSunの自慢話に変わって、
そのSunの自慢を原因としてEJBの実装を叩いている。
でっちあげじゃなくて、JavaがC/C++より速い領域は結構あるよ。
719:デフォルトの名無しさん
06/08/29 09:14:24
>>714
言っていることが意味不明
> ・JITが効果的に利くオブジェクトをほとんど生成しない
> ベンチマークでC/C++と同等のパフォーマンスであると主張。
JITが効果的に効くオブジェクトをほとんど生成しないなら、
パフォーマンスはむしろ劣化するはずだが、それをもってベンチマーク
でC/C++と同等のパフォーマンスであるとは、どういうこと？
> ・Java[Runtime]は低レベルのアクセスしまくりでパフォーマンスを改善
何の話？ネットワーク、IO、GUIなどの箇所は、確かにネイティブコード(C言語)で書いてあるが、
それ以外のライブラリはほとんどPure Javaのはずだが。あと、そもそも低レベルアクセス
(OSのAPIを直接叩くことか？)すれば、パフォーマンスが改善するってもん
でもない。何故ならJavaからネイティブコードを呼び出すのは、かなりのオーバーヘッドが
かかるから。
720:デフォルトの名無しさん
06/08/29 09:33:01
>>718
> でっちあげじゃなくて、JavaがC/C++より速い領域は結構あるよ。
具体例をどうぞ。
Javaの方がパフォーマンスがいいなんて妄想もいいところ。
JVMがCでできてるんだから、CでJVM（もしくはサブセット）を実装して
その上で実行すればJavaより遅くなるわけが無い。
721:デフォルトの名無しさん
06/08/29 10:02:10
>>720
ハハハ・・・・
722:デフォルトの名無しさん
06/08/29 10:29:00
>>716
Timer関係＋wait関係でおけ
ポーリングしたいのならナノ秒取得するやつ使え
Winだとちゃんと高精度タイマで実装されているぞ
Linuxだとミリ秒の1000*1000倍が返されてたきがした
このへんの制度はVM依存だが、まったく動かないわけではないのでおけ
アクションゲーム関係で60fpsだしたいのなら垂直同期使うわけだし問題なし
723:デフォルトの名無しさん
06/08/29 10:56:44
>>710
アメリカにいけば著名人ですらそうだぞ。
I thinkI thinkI thinkI thinkI thinkI thinkI think
ア イ シ ン ク ッ ！
だ。
論文でもそうだ。さもないと他人の意見をパクった韓国人や中国人
と同等に扱われる。
724:デフォルトの名無しさん
06/08/29 11:00:47
>>723
猿真似は日本人のお家芸。
725:デフォルトの名無しさん
06/08/29 11:02:47
>>711
Flashは4まではJavaのほうが圧倒的に早かった。
今はしらない。
Javaと違い、Flashでできることは限られている。
あれは時系列で開発してゆくからな。
Javaとは畑も開発スタイルも違う。
Flashは簡単なアニメーションなら高速で処理できる。
だが、三角関数や対数関数、指数関数などを徹底的に
駆使した幾何学模様の描画はどうだろう。
是非とも検証してみてくれ。
ActionScriptを使ってちゃんと三角関数などを使って計算してな。
726:デフォルトの名無しさん
06/08/29 11:05:35
>>714
そのEJBのバージョン、
それからプログラムのソースコードや
マシンのスペック、測定データをここに公開する気はないのかね。
まさか古いバージョンのJavaで作られたPetStoreを
例に挙げるわけではあるまい。
もう古くて参考にはならんぞ。
EJBを使ってるところは本当に少ないがな。
多くはEJBの変わりにPOJOを使ってるところばかりだし。
Seasar2とかSping Frameworkとかな。もしくはStruts + Tomcatオンリーとか。
StrtusやJSFすら使わないところも未だにあるが。
727:デフォルトの名無しさん
06/08/29 11:07:27
> Javaの方がパフォーマンスがいいなんて妄想もいいところ。
> JVMがCでできてるんだから、CでJVM（もしくはサブセット）を実装して
> その上で実行すればJavaより遅くなるわけが無い。
こういいきる奴は何度も見てきたが。浅はかで何も解って無いというか、
騙されているというか。Javaの進化に乗り遅れて古い知識しか持っていない
オッサンに多いんだな。
728:デフォルトの名無しさん
06/08/29 11:08:09
>>722
ナノ秒なら
Java5からも実装されたぞ。
System.nanoTime()
729:デフォルトの名無しさん
06/08/29 11:25:25
>>727
そういう小僧は盗んだコードで走る馬鹿だろう？
なんでもおっさん扱いしないでくれよ
730:デフォルトの名無しさん
06/08/29 11:38:05
みんな自分の信ずる言語・環境を支持すればいいだろ
どうしてJavaスレには他の奴らが荒らしにくるんだ？
他の言語・環境がどんなに素晴らしいのかしらんがスレ違いだ
巣に帰れ！
731:デフォルトの名無しさん
06/08/29 12:23:15
次世代を語るところだから、どうしても他の言語と比べた改善点とか要望が出るんじゃない？
732:デフォルトの名無しさん
06/08/29 13:08:47
>>728
言葉が足りなかったかな
すでに実装されている話なんだし次世代の話題じゃないだろうということ
>>716は細かい制御したいのに5.0のコンカレントAPIすらさわってないんだろうなーとかおもっちまう
733:デフォルトの名無しさん
06/08/29 13:53:56
>>731
お前はネイディブコンパイラとのパフォーマンス比較を改善点や要望とでも言うのか？
だたの攻撃だろ？違うのか？
734:デフォルトの名無しさん
06/08/29 14:04:44
>>730
昔懐かしい「C#って死滅しちゃうの？」シリーズスレで
大暴れしていた例のM$厨では？
735:716
06/08/29 14:10:20
>>732
nanoTimeだけじゃアニメーションできなくない？
nanoTimeはsleepの分解能チェックや誤差の補正に使うものかと
結局sleep使わなきゃだめなんじゃないか？
それかObject.waitか。
J2SE6ではDoubleBuffer関係で何らかの改良があると聞いたかが。
そうそうConcurrentは使ってないな。まだ。そんなに必要性も感じてないが。
736:デフォルトの名無しさん
06/08/29 15:08:29
>>727
> > JVMがCでできてるんだから、CでJVM（もしくはサブセット）を実装して
> > その上で実行すればJavaより遅くなるわけが無い。
> こういいきる奴は何度も見てきたが。浅はかで何も解って無いというか、
> 騙されているというか。Javaの進化に乗り遅れて古い知識しか持っていない
？
進化とか古いとか関係ないだろう。CでJavaコンパイラを実装してclassコードを実行するという話をしているのだから
「Javaの方が速い」とならないことは自明なのだが。
恐らく「Javaは実行中にコードの最適化するから速い」とか言いたいんだろうが、
その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
ただ、CでわざわざJVMを再実装するのはコストがかかるから現実的ではないというだけ。
別にそこを認めてもJavaの優位性は変わらないと思うんだけどね。
いつものことだが、JavaしかできないやつはJavaを否定されると自分自身も否定されたような被害妄想を抱くよな。
どっかの宗教団体みたいで嫌だ。いろんな言語触れよ。次世代Javaの議論にも役立つぞ。
737:デフォルトの名無しさん
06/08/29 15:32:33
とんでもない勘違いをしている奴がいるぞｗ
738:デフォルトの名無しさん
06/08/29 15:40:53
痛い子が居るなぁ。
739:デフォルトの名無しさん
06/08/29 15:43:39
>>736 → 737,738
740:デフォルトの名無しさん
06/08/29 15:48:26
>その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
この意味が分からない。絶対と言い切れる根拠はなんなんだろ？
741:デフォルトの名無しさん
06/08/29 15:51:25
Javaで作ってスーパーコンピュータで動かせば速い。
742:デフォルトの名無しさん
06/08/29 15:54:16
>>740
馬鹿には つ き あ う な
743:デフォルトの名無しさん
06/08/29 15:57:28
>>740
> その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
> この意味が分からない。絶対と言い切れる根拠はなんなんだろ？
極論を言えば、
int main(){JavaVM *jvm;JNI_CreateJavaVM(&jvm);jvm->DestroyJavaVM();}
と書けば少なくとも速度は同じになるというだけのこと。
そんなにややこしいことは言ってない。
「JVMがCで書かれている」というのをもうちょっと考えろよ。
744:デフォルトの名無しさん
06/08/29 15:59:54
>>741
JVMの役割を知っていれば、わざわざスーパーコンピューターでJavaを使おうなんて考えないよ。
745:デフォルトの名無しさん
06/08/29 16:01:56
>743の続き
で、JVMのソースコード中から、実行に不要な部分を削除していけば、
JVMをいじれないJavaよりも、Cの方が速くなる。誰でも分かる話だと思うんだがな。
実際にはそんなところに開発コストをかけるのは無駄だから現実的ではないと言ってるだけ。
頭が悪いのか、それとも宗教にはまってるからなのか。。。
746:デフォルトの名無しさん
06/08/29 16:05:00
>>735
nanotimeはポーリング用
定期実行にはTimer方面つかえといっておろう
747:デフォルトの名無しさん
06/08/29 16:06:08
> JVMをいじれないJavaよりも、Cの方が速くなる。誰でも分かる話だと思うんだがな。
JVMはCのライブラリィではないよ（笑）
748:デフォルトの名無しさん
06/08/29 16:46:20
>>742
あい、了解したw
749:716
06/08/29 17:51:39
>>746
アニメーションとかの20msecとかそういう間隔の話をしているつもりだったんだけど、
Timer? ありえなくないか？
750:デフォルトの名無しさん
06/08/29 17:54:46
751:デフォルトの名無しさん
06/08/29 17:55:17
747はとても親切だ。
暴れてるやつは声を出して読むように。
752:デフォルトの名無しさん
06/08/29 18:00:01
>>749
どういう動きかわかってないんじゃない？
基本から勉強したほうがいいよ
753:716
06/08/29 18:07:25
>>752
教えてくれ。
Timerも結局waitを使っているとドキュメントされているが、
waitは正確性を欠く、それをnanoTimeとかで確認してスケジュールを補正するのが教科書とおりなのだが、
Timerを使ってしまうと補正ができなくないのではないか？
次世代になってもwaitとかの精度はそんなに変わらないんだろうな
754:デフォルトの名無しさん
06/08/29 18:15:40
そこまでわかってるなら問題あるまい
垂直同期にこだわらなければ60fpsにする必要もあるまい
垂直同期にしたら自動的にリフレッシュレートであわせられる
Win32ネイティブでやってるのと状況はかわらんよ
755:デフォルトの名無しさん
06/08/29 19:20:49
Windowsのマルチメディアタイマーは1msで寝れたと思うが
756:デフォルトの名無しさん
06/08/29 19:50:44
malloc/freeはどうした？＞最速厨
JVMは都合のいいタイミングまでガベコレを遅延できる。
これをやると、特にSMPで差が開く。
757:デフォルトの名無しさん
06/08/29 20:03:09
蒸し返すな
758:デフォルトの名無しさん
06/08/29 20:09:11
>>756
性能を重視するならmalloc/freeをそのまま使ったりなんてせず、
普通は独自アロケータを定義するでしょ。
759:デフォルトの名無しさん
06/08/29 20:54:34
>>720は、ぐぐってみたところ、
Javaの方が実行速度が速い例がたくさん見つかったので、
>>736>>743でごまかそうと必死w
760:デフォルトの名無しさん
06/08/29 22:55:04
Javaがなんでもかんでも速いというつもりは全然無いんだが、Ｃで組んだっ
て結局実装の仕方次第だろ。malloc/freeを何度も繰り返すような素のＣの
組み方したら、JVMの「そもそもメモリ解放自体めったにしないで確保してる
メモリを使い回す」ような実装より遅くてあたりまえ。
例えばObjective-CはＣのサブセットで、コンパイルすれば完全なバイナリに
なるわけだが、メソッド呼び出し速度とメモリ取得・解放速度でJavaのほうが上回る。
これはオブジェクト周りの実装の仕方の差だろ。
そこを意識して力技なパフォーマンスチューニングを組み込んでＣでゼロから
作れば、速くなるのも当たり前。
JavaがＣより速いとかいう話は、「Ｃで普通に組んだものより、Javaで普通に
組んだものの方が速いことがある。なぜなら、JVM自体にすでにパフォーマン
ス・チューニングがされているから」という意味だってことがわからないのだろうか。
普通に組んだ時のパフォーマンスの差には意味があると思うけどねえ。
761:デフォルトの名無しさん
06/08/29 22:55:23
>>736
C言語原理主義者の言い訳ごくろう。
また「Javaしかできない奴」とステレオタイプ貼り付けとは。
Javaで飯食ってきたかったらJavaしかできないなんてありえんからね。
762:デフォルトの名無しさん
06/08/29 22:57:39
>>758
その独自アロケータとやらは、Javaの世代別GCを超えられるのか？
ヒープアロケーションやデアロケーションに、凝った戦略(実行は超高速)
とってるよ、あれ。フリーリスト管理独自実装とか、ショボイことしてい
る間は越えられんでしょ。
763:デフォルトの名無しさん
06/08/29 23:03:03
コンパイラやＶＭの性能次第で、幾らでも早い言語・遅い言語になるわけだが。
言語の特性とコンパイラ最適化技術辺りは最低限踏まえて議論しような。
764:デフォルトの名無しさん
06/08/29 23:10:49
マイクロベンチしにくい言語だなぁと思うことはよくある。
例えばN秒間の実行回数が4400～5200とか異常な数値を出すこともしばしば。
ヒープサイズは-Xms -Xmxともに同じサイズにしても起こすから原因がつかめない
765:デフォルトの名無しさん
06/08/29 23:12:15
結局、学生とかによくある卓上理論ってやつじゃないのか？
766:デフォルトの名無しさん
06/08/29 23:22:36
机上だと思う。
767:758
06/08/29 23:46:35
> その独自アロケータとやらは、Javaの世代別GCを超えられるのか？
越えられるよ。
つーか、JavaのGCとかboehmGCとか、そういう汎用的なメモリ管理実装に
満足できないから独自実装するわけで。
> ヒープアロケーションやデアロケーションに、凝った戦略(実行は超高速)
> とってるよ
それは独自アロケータでも同じ。
そもそも、あるサブシステムでは特定のサイズのメモリを大量にアロケートするとか、
そういうプログラム固有の事情も考慮した上で最適なアロケータを設計するんだよ。
一般道から高速道までいろいろな状況でもそれなりに速く燃費の良いエンジンを作るのと、
サーキット上での速さの極限を目指したエンジン作りとを比較するようなもの。
そもそも設計方針から全く違う。
768:デフォルトの名無しさん
06/08/29 23:52:47
いずれにしても現実にあるjavaのOOなプログラムは速度の最適化は難しいんじゃないか？
javaだからっていうか、OOだから。
例えば、java3dとか、hibernateとか、
769:デフォルトの名無しさん
06/08/30 00:04:22
じゃあ、比較すんなよ。
770:デフォルトの名無しさん
06/08/30 00:06:31
>>767はなんかすごそうな職人さんのようですね。
必要に迫られて独自にそういうすごいのを作ったのでしょうが、
凡人・汎用ではjava vmぐらいでいいです。ruby gc thread とか遅くても
ちゃんと答えを出してくれればいいです。
771:デフォルトの名無しさん
06/08/30 00:07:08
>> その独自アロケータとやらは、Javaの世代別GCを超えられるのか？
>越えられるよ。
>つーか、JavaのGCとかboehmGCとか、そういう汎用的なメモリ管理実装に
>満足できないから独自実装するわけで。
このように、独自実装厨はチューニングが重ねられた汎用アルゴリズムに
劣る糞コードを生成するわけだ。乙
772:デフォルトの名無しさん
06/08/30 00:08:40
Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
Javaならある意味JVMが勝手にチューニングしてくれるし。
773:デフォルトの名無しさん
06/08/30 00:09:33
生産性を意識すりゃなんだって「それなり」の速度だっての。
うざいから他所でやってくれ、マ板でやることじゃないだろ。
774:デフォルトの名無しさん
06/08/30 00:23:50
>>768-774 みんなから一斉にツッコミのあらし。なんか知らないけど、笑いが止まらねー
775:デフォルトの名無しさん
06/08/30 00:30:06
次世代Javaに速度は強くもとめないということで。
おもいらそれよりSE 6のどこが素敵なのかまとめてくれんか？
776:デフォルトの名無しさん
06/08/30 00:38:07
ヒープ共有とタスクトレイはツール促進に繋がると思う。
777:デフォルトの名無しさん
06/08/30 00:48:00
Java 5.0 で既に十分高速なので議論しても仕方が無い。
それより、Java 6.0 Java 7.0 に予定されている言語拡張・ライブラリについて語ろうぜ。
778:デフォルトの名無しさん
06/08/30 01:08:56
>>11の
＞プロパティのサポート
＞メソッドリファレンスのレポート
＞クロージャのサポート
＞言語レベルでのXMLのサポート
＞JVM上で動作する動的言語のサポート
＞スクリプト言語サポートの拡張
＞モジュール化のサポート
＞Swingアプリケーション開発のためのツールの充実
のうち、今回出てきたのは「メソッドリファレンス（たぶんローカル・ファンクションのこと
だろう）」と「クロージャのサポート」なわけだが、
「プロパティのサポート」はまだ具体例が出てきてないね。
最後のSwingアプリケーション開発のためのツールって
のは、たしかSwingをベースにしたアプリケーション・フレー
ムワークを作るとかだったっけ。
779:デフォルトの名無しさん
06/08/30 01:17:25
最後のはただのNetBeansプラットフォームだったりしてな
780:デフォルトの名無しさん
06/08/30 01:27:48
# クラスパスのワイルドカード指定
これなｗ これが一番重要な更新だったりしてｗ
781:デフォルトの名無しさん
06/08/30 01:48:38
URLﾘﾝｸ(weblogs.java.net)
URLﾘﾝｸ(weblogs.java.net)
782:デフォルトの名無しさん
06/08/30 02:59:33
つ ｽﾚﾘﾝｸ(tech板)
783:デフォルトの名無しさん
06/08/30 03:04:55
Swing Application Frameworkって具体的にはどんなの？
784:デフォルトの名無しさん
06/08/30 03:25:08
>>758,>>767 その経験は選ばし者のみ体験できることぞよ。そこから習得した業をこれからも存分に発揮するが良い。わははははは
785:デフォルトの名無しさん
06/08/30 04:34:32
まずJavaをCたらしめているcloseメソッドをなんとかしろよ
まず名前をdeleteに変えてバカに気づかせろ
786:デフォルトの名無しさん
06/08/30 06:11:40
>>781
ktkr
いったいここまでたどり着くのに何年かけてんだ？
こんなのNEXTSTEPをSolarisにポートした連中なら最初に気が付いてるだろ
787:デフォルトの名無しさん
06/08/30 08:30:02
いやー、これなかなかいい設計だぞ？
今の基準でみると糞みたいなNEXTSTEPのフレームワークと違ってw
788:デフォルトの名無しさん
06/08/30 09:15:32
>>756
> malloc/freeはどうした？＞最速厨
> JVMは都合のいいタイミングまでガベコレを遅延できる。
分からん奴だな。そのガベコレをCで実装すればいい。
>>759
> >>720は、ぐぐってみたところ、
> Javaの方が実行速度が速い例がたくさん見つかったので、
Javaの方が速いっていうのは、C側ベンチでJavaと同じ事をしていないだけのこと。
Javaの挙動全てをCで実装すればJavaと同じ速度になるのは当たり前だと言ってるだけだ。
>>772
> Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
> Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
そんなもの不要。CPUにあわせた動的コンパイルをCで書けばいいだけ。
.classファイルを読み込んでJVM上で実行（もちろんJIT付き）するようなCプログラムを書けば、
Javaの方が速くなるなんてことは無いと言ってるだけなのに何で分からんかな。
789:デフォルトの名無しさん
06/08/30 09:18:19
必死だな。
790:デフォルトの名無しさん
06/08/30 09:22:30
こんなに頭悪い奴だとは思わなかった。
791:デフォルトの名無しさん
06/08/30 09:24:23
>>788
いいたいことはなんとなく分かったが、それを言うことで
あんたが何をしたいのかがさっぱり分からん。
792:デフォルトの名無しさん
06/08/30 09:28:24
自分の無知の隠蔽
793:デフォルトの名無しさん
06/08/30 09:34:40
痛い子が粘着してるな
明日までの辛抱かの
794:デフォルトの名無しさん
06/08/30 10:08:05
>>775
しかし、バージョンアップするたびに高速化してるみたいなんだけど。
次期バージョンJava6もPreJITによってかなり高速化が期待できるんでない？
二回目以降のアクセスからはCのネイティブと同じ扱いになってかなり高速化する、みたいな。
795:デフォルトの名無しさん
06/08/30 10:10:16
>>792
面白すぎる。
マ板で必死にJava叩きしてるおっさんどもを思い出すw
796:デフォルトの名無しさん
06/08/30 11:11:25
>>791
> >>788
> いいたいことはなんとなく分かったが、それを言うことで
このスレで頭がいいのはあんただけのようだな。
> あんたが何をしたいのかがさっぱり分からん。
>>720を理解できない奴が多かったから説明しただけ。
あんたみたいに理解力のある奴ばかりだったらいいんだがな。
>>736に書いた通り、Javaをけなそうとしているわけではないし、Cが素晴らしいなんて言うつもりも全く無い。
797:デフォルトの名無しさん
06/08/30 11:16:38
JVMはCで実装しなきゃいけない決まりでもあるの？
Javaチップ上でベンチ比較する場合についてはどう考えてるの？
この場合Cの処理系をまず用意しないとダメだけど…
798:デフォルトの名無しさん
06/08/30 11:45:08
>>796
どっかの宗教団体みたいなのはお前のほう。
お前の主張がいったい何になるのか説明できんだろ。
お前の意見が何もプラスにもならないならどっかの宗教団体と変わらない。
799:デフォルトの名無しさん
06/08/30 12:46:01
わかったから、アセンブラで書くと最強！
Cはその次！
で良いだろ
実の無い議論しても無駄だろ
800:デフォルトの名無しさん
06/08/30 13:19:58
こいつら一体何なんだ・・・
801:デフォルトの名無しさん
06/08/30 13:34:54
> JVMはCで実装しなきゃいけない決まりでもあるの？
> Javaチップ上でベンチ比較する場合についてはどう考えてるの？
はいはい、机上の仮説はどうでもいいから、
まずはC,C++で実装された現行のJVMにも性能面でひけを取らない
Javaチップを開発してからまた来てね。
802:デフォルトの名無しさん
06/08/30 13:36:25
>>800
Cで１からjvmもどきを書くと現行のJITより高性能をたたき出せる天才プログラマ様らしいよ
803:デフォルトの名無しさん
06/08/30 13:37:01
もうお前等来なくていいよ!
804:デフォルトの名無しさん
06/08/30 13:41:37
>>720 が悪い。
805:デフォルトの名無しさん
06/08/30 13:51:17
> > Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
> > Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
> そんなもの不要。CPUにあわせた動的コンパイルをCで書けばいいだけ。
まあ、CPUのサポートする命令セットに合わせて実行時に自己書換する、なんて
テクニックは大昔からあるよね。
今だって、多くの動画コーデックはSSE等の拡張命令の有無を実行時に調べて
動的に実行コードを生成したりしてるし。
そういう古くからあるテクニックの一部がJVM実装にも取り込まれるように
なってきた、ってだけの話。
806:デフォルトの名無しさん
06/08/30 14:06:40
俺よー、JVMの仕組みよく知らないんだけどJavaって実行時に
何度も実行される箇所はコンパイルしてネイティブコード生成するんだよな？
だから
コンパイル時間 + (CPU最適化コード実行時間 * n) > 386バイナリ実行時間
この式が成り立つ可能性は十分あると思ってる。( n が増加するほどJava有利)
なんかJavaはCを越えられないと言ってる奴はどうも
ネイティブコード生成後もJVMで解釈して実行してると思ってそうなんだが…？
CでもIntelMacのユニバーサルバイナリみたいに全CPUに最適されたコードを含んだ
バイナリを持てばJavaを上回るのは明らかだけど、そんな事してる奴いないよね。
807:デフォルトの名無しさん
06/08/30 14:23:54
> コンパイル時間 + (CPU最適化コード実行時間 * n) > 386バイナリ実行時間
>
> この式が成り立つ可能性は十分あると思ってる。( n が増加するほどJava有利)
だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
>805のような動的実行コード生成をC, C++でもやればいいだけの話。
で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
808:デフォルトの名無しさん
06/08/30 14:32:31
>>807
>> >805のような動的実行コード生成をC, C++でもやればいいだけの話。
必ず同じ事ができるとは限らない。
809:デフォルトの名無しさん
06/08/30 14:34:51
「JavaがCより速い場合がある」ってのは、同じようなアルゴリズムでコードを書いた場合ってことだろ。
そりゃ、最適化したコードで比べればどんな場合でもCの方が速くなるだろうよ。
でも、その最適化したコードをCで書くのは、コストや能力を考えると現実的に不可能だ。
810:デフォルトの名無しさん
06/08/30 14:37:58
> >> >805のような動的実行コード生成をC, C++でもやればいいだけの話。
>
> 必ず同じ事ができるとは限らない。
その理由は?
Cで書かれたJVMにできて、Cで直接書かれたプログラムにできないことって何?
それともJavaチップのことでも言ってるの?(笑
811:デフォルトの名無しさん
06/08/30 14:51:14
>>806
コンパイル時間 << ε
ならば、誤差の範囲内として無視できる。
すると、JavaとCとでは速度はさほど変わらなくなる。
また、
Java実行速度 - C実行速度 << ε
なら、ますます無視できる。
ここでεとは非常に小さな値を表し、 <<は<よりもうんと大きな差があることを意味する。
つまりうんと小さくなるという意味。
812:デフォルトの名無しさん
06/08/30 14:55:54
で、Ｃでできるからなんだよ？
813:デフォルトの名無しさん
06/08/30 14:57:04
>>810
実例を出すと、ベクトル型スパコン。
Cで書かれたプログラムより、FORTRANプログラムの方が速いとされる。
コンパイラはどちらもCで作られている。
これは、ソースレベルでは同じアルゴリズムであっても、FORTRANで記述
されたプログラムの方が、Cよりも最適なベクトル化できるからである。
コンパイラを同じCで作っても、どこまで最適化できるかは、各言語仕様も
関係してくる。
814:デフォルトの名無しさん
06/08/30 15:48:19
あれ、いつの間にここはFORTRANスレになったのかな?
815:デフォルトの名無しさん
06/08/30 15:49:14
>>813
だから、｛Cで書かれたFORTRANコンパイラ＋.Fのソースファイル｝を合わせて、
一つのCで書かれたソフトウェアと見なすって話が延々と続いているわけだ。
論理的には正しいが、実効的な意味はない。
ってのが>>736の最後のパラグラフの意味だと思われ。
816:602
06/08/30 16:04:51
>>778
メソッドリファレンスって俺待望の >>602 で書いたようなことじゃないのかね？
だとしたら、あと5年はjavaを使おうかと思うな
でもSE7からなのか。。。
817:デフォルトの名無しさん
06/08/30 17:09:12
>>788
> >>756
> > malloc/freeはどうした？＞最速厨
> > JVMは都合のいいタイミングまでガベコレを遅延できる。
> 分からん奴だな。そのガベコレをCで実装すればいい。
不可能。メモリ関数の使用を禁止せず、ガベコレを実装できない。
メモリ関数の使用を禁止すれば、ソースを書き直さなければならず、
もはやCのプログラムではなくなる。だから、JavaやC#のような新しい
言語ができたことを理解しろ。
818:デフォルトの名無しさん
06/08/30 17:15:04
>>817
へー、Boehm GCを使ったCプログラムはCのプログラムではないんだ。
819:デフォルトの名無しさん
06/08/30 17:25:20
>>818
ベタベタなコードにコンサバなGCで体裁繕ったらパフォーマンスでないぞ
いい加減みっともないまね続けるなよな
820:デフォルトの名無しさん
06/08/30 17:31:01
>>817
> 不可能。メモリ関数の使用を禁止せず、ガベコレを実装できない。
JVMはどうやってガベコレを実装してるの？
821:デフォルトの名無しさん
06/08/30 17:33:30
>>807
つまり、普通の人はそんなの作らない＆作れないから、
凡人が高速なプログラムを作ろうとしたらJavaで書いて実装した方がいいって事だよね。
理論的にCオンリーの方が早くなるっていうのは別に、誰も否定しないと思うけど
現実的にJavaの方が早くなる【場合がある】っていうのを認められないのは厨房だと思うな。
822:デフォルトの名無しさん
06/08/30 17:34:27
>>820
メモリ関数使ってるに決まってるだろ。馬鹿じゃねぇの？
823:デフォルトの名無しさん
06/08/30 17:38:48
Javaの人は、Cはほどほどに教養程度なんじゃない？
詳しかったらJavaの環境に居ないで、Cの環境（Win32やUnix）に行ってるでしょ。
せいぜい jni 程度でゴニョゴニョで、gc 実装とかそんなディープ話題は
次世代Java環境が気になるJava使いの人はついて来れないと思う。
824:デフォルトの名無しさん
06/08/30 17:42:27
>>823つまり冷やかしもほどほど程度にしとけってことかな？
825:デフォルトの名無しさん
06/08/30 17:47:11
言語仕様も関係するが、それよりも実行形式の抽象度の違いによるんだよ。
826:デフォルトの名無しさん
06/08/30 17:50:09
>>823
当然、おまいはGCの実装経験がある or 実装できるのだな。
各種GCアルゴリズムについて語らないか？
827:デフォルトの名無しさん
06/08/30 17:54:35
>>822は叩かれてる人？泣きそうになってるみたいだけど
828:デフォルトの名無しさん
06/08/30 18:09:04
>>807
>だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
>>805のような動的実行コード生成をC, C++でもやればいいだけの話。
>で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
>OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
if(SSE２命令が利用可能か？) {
// SSE２命令を利用したインラインアセンブラによるコード
}
else {
// SSE２命令を利用しないインラインアセンブラによるコード
}
これのどの辺りが動的実行コード生成になるのか説明してくれんか？
無知は怖いね。
829:デフォルトの名無しさん
06/08/30 18:52:56
高速化高速化いうてるけど
1.4.2のが5.0より速いらしいぞ
SUNのベンチ鵜呑みにするなや
830:デフォルトの名無しさん
06/08/30 18:56:32
>>828
ほらよ。
URLﾘﾝｸ(mkosaki.blog46.fc2.com)
831:デフォルトの名無しさん
06/08/30 19:08:15
> せいぜい jni 程度でゴニョゴニョで、gc 実装とかそんなディープ話題は
> 次世代Java環境が気になるJava使いの人はついて来れないと思う。
だろうね。
というか、そういう話をこのスレでやるのがそもそも間違い。
パフォーマンス厨は↓へ行ってくれ。
ｽﾚﾘﾝｸ(prog板)
832:デフォルトの名無しさん
06/08/30 19:41:39
>>823
いまどきそうやってCはJavaよりも凄く、
「Cを知っていればJavaを知らなくても偉いんだ！」
と勘違いしてCしか知らず、Javaのことろくに勉強しないのも、恥ずかしいことなのだが。
833:デフォルトの名無しさん
06/08/30 19:49:41
いまどきそうやってJavaはCよりも凄く、
「Javaを知っていればCを知らなくても偉いんだ！」
と勘違いしてJavaしか知らず、Cのことろくに勉強しないのも、恥ずかしいことなのだが。
834:デフォルトの名無しさん
06/08/30 20:04:14
いまどきそうやって技術は一般常識よりも凄く、
「技術を知っていれば一般常識を知らなくても偉いんだ！」
と勘違いして技術しか知らず、一般常識のことろくに勉強しないのも、恥ずかしいことなのだが。
835:デフォルトの名無しさん
06/08/30 20:08:04
>>833
お前よ、餓鬼みたいに>>832のコピペしてるのどっかで見たことがあるぞ。
C#死滅スレのVBとC#を崇拝する、継承嫌いの餓鬼だろw
836:デフォルトの名無しさん
06/08/30 20:08:49
>>834
まてまて技術は一般常識の範疇に入るぞ
837:デフォルトの名無しさん
06/08/30 20:12:42
いつまでたっても馬鹿が釣られまくっとるな
ガキが相手するから正常化せんのだが能無しには分からんか
838:デフォルトの名無しさん
06/08/30 20:29:39
>>828
ﾌﾟ
無知は怖いね。
839:デフォルトの名無しさん
06/08/30 20:54:06
嵐が過ぎた後は誰もいなくなっている悪寒。
お前らCがJavaより早くJavaはCより早いのは分かったから
メソッドリファレンスが何なのか情報提供してくれ。
840:デフォルトの名無しさん
06/08/30 21:01:00
>>837
奴はＶＢとC#に詳しいアホだよ。
昔、語尾に「嘲笑激藁」「ﾌﾟﾌﾟ」「ｹﾞﾗ」「ﾜﾗ」「大爆笑」
をつけてた奴、ハンドルが「255」とかつけてた奴に
非常にそっくり。
結局あそこまでC#を持ち上げても、全然はやらなかったな。
どうせ奴は鬱憤晴らしにスレを荒らしてるだけだろう。
841:デフォルトの名無しさん
06/08/30 21:03:33
>>807
つーか、動的生成云々うるさいけど、それってモジュール切り替えでええんじゃないん？
実行時生成なんてしなくても、コンパイルしたモジュールも含めればいいだけの話。
C使いでもめったに使わない技術を得意げに語るのは哀れですらある。
Java厨だってバイトコードの自力生成なんて滅多にしない。
842:デフォルトの名無しさん
06/08/30 21:04:55
レスすんなカス
どこまで脳みそゆるいんだ
843:デフォルトの名無しさん
06/08/30 21:07:33
>>787
いやー盛り上がってるとこ悪いが、20年経ってその台詞恥ずかしくないかw
844:デフォルトの名無しさん
06/08/30 21:13:58
ところでJavaCardって何に使うの？
Java OneとSUNのシンクライアントでつかうくらいしか聞いたこと無い。
Edyのがすごいよ、コンビニ清算最速ってすごくね？
845:デフォルトの名無しさん
06/08/30 21:15:41
ココの住人には>>823は図星なのか？
みんなずいぶん喰らったみたいけど大丈夫か？
846:デフォルトの名無しさん
06/08/30 21:16:00
>>813
C言語にポインタがあるために、ベクトル化による十分な最適化ができないが、
FORTRAN言語にはそのポインタがないので、十分にベクトル化できると聞いた
ことがある。
Java言語が出たとき、JavaもポインタがないのでFORTRAN並に最適化できる
のではないかという極端な記事が、Cマガジンに載っていたような覚えがある。
今となってはJavaの仕様では、FORTRAN並に最適化は無理なのは自明だが・・。
847:デフォルトの名無しさん
06/08/30 21:17:28
>>841
バイトコードの自力生成ってできたの？しらなｋった。
ところで、どうやってやるの
848:デフォルトの名無しさん
06/08/30 21:19:42
図星ってのもあるが正直どうでもいい
特定環境に最適化されたGCなんて興味ないなって感じ
849:デフォルトの名無しさん
06/08/30 21:20:32
>>830
オイオイ、必死に何か探してきたと思ったらコレだ。
自己書き換えと動的実行コード生成は似て非なるものなんだが。
850:デフォルトの名無しさん
06/08/30 21:32:51
>>847
適当なバイト列を作ってClassLoader#defineClass()を呼ぶだけだ。
そのバイト列はJavaVM仕様に合わせて作ればいい。
BCELやasmなどのバイトコード作成用ライブラリもある。
Java5からはClassLoader側で細工しなくてもバイトコード変換ができるように
java.lang.instrumentパッケージ以下のクラスが追加された。
851:デフォルトの名無しさん
06/08/30 21:54:51
>>850 しらなかった、あんがと。Jakarta BCELを読んでみる。
852:デフォルトの名無しさん
06/08/30 21:59:14
>>851
正直言って、BCELは設計が古いというか微妙に使いにくいので、
新規ならASMかJavassist使った方が良いかと
他言語 -> Javaバイトコードのコンパイラ作るなら、Javassistはちょっと使いにくいが
853:デフォルトの名無しさん
06/08/30 22:09:50
今BCEL読んでる最中だけど、これってすげーな。
この技術と言うか概念というか、次のリリースでスクリプト言語を
java vmに取り込むとか言うのより、さらに高次元の話じゃん。
854:デフォルトの名無しさん
06/08/30 22:32:11
大体概要は分かったけど、すごかった。こういうツールが整備されて
徐々に万人向けに使いやすくなっていくと、これからも OSに依存しな
い Java の環境がより強固なものになっていく予感がする。
昔Sunが目指していたNetworkがどうのというやつなのかな。
> 他言語 -> Javaバイトコードのコンパイラ作るなら
>>852さんはこういう系の人なのでしょうか？
そうとは知らずに、言葉遣いが足らず失礼しました。
855:デフォルトの名無しさん
06/08/30 22:50:38
>>854
852だけど、一応そういう系の人です。Java VM上で動作する
とあるスクリプト言語開発してます。超マイナーな言語ですが
一応どんな言語かというと、Javaに似たセマンティクスに
スクリプト言語っぽいシンタックスシュガーをふりかけました
みたいな言語です
> 言葉遣いが足らず失礼しました
？別に特に>>854さんが失礼な言動をしたとは思わなかったけど
856:デフォルトの名無しさん
06/08/30 22:54:35
あ、ひょっとしたら誤解してるかもしれないんで一応いっておくと
>>850さんと>>852(= >>855)は別人なんで
857:デフォルトの名無しさん
06/08/30 23:31:46
いや～、やっぱりここにはいろんな人が来てるね～
＼＿＿＿＿＿ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
∨ |
| まいど、まいど！繁盛、繁盛！！
＼＿ ＿＿＿＿＿＿＿＿＿＿＿
＿＿ ∨
／ ／| ∧＿∧
|￣￣|／| （・∀・ ） (
|￣￣| |￣￣￣|＼＿（＿ ）＿ （・∀・： ）Java は さいきょう じゃ
|￣￣| |＿＿＿| ∧＿∧ ￣￣￣ ／／／／|
|￣￣| |＿＿＿|（ ）＿＿＿_|￣￣￣|／|
|￣￣ （ ○ ） ￣￣￣| |
| ｜ ｜ | | |
| （＿（＿） |／
858:デフォルトの名無しさん
06/08/30 23:44:50
ここで思ったんだが、JVM用のC言語を書くってのはどう？
859:デフォルトの名無しさん
06/08/30 23:47:50
>>858
JVMしか作成できない言語を作るの？
どんなメリットがあるの？
860:デフォルトの名無しさん
06/08/30 23:53:53
ちょっとだけスレを読んでみたけど、
ガベコレ実装しそうな職人とか、
サーバー用ツールと次世代Javaの関係が気になる人とか、
クライアント用(携帯アプリ)の開発者とか、
コンパイラ作る人とか、
CマンセーなのにJavaが気になる人とか、
JVM上で動作するスクリプト開発者とか、
いっぱい居て楽しそうだね～♪
861:デフォルトの名無しさん
06/08/30 23:55:09
>>859
ごめん言葉足らずだったね
JVM上で動くバイナリを吐くC言語だ
862:デフォルトの名無しさん
06/08/31 00:10:41
>>861
> JVM上で動くバイナリを吐くC言語だ
Cのソースからクラスファイルを作るということ？
863:デフォルトの名無しさん
06/08/31 00:20:12
>>855
ちょいと質問なんだが、JRubyやJPyton、GroovyやJavaScriptじゃだめだったの？
独自スクリプト言語を新規開発するに至る動機はナンデスカ？
864:デフォルトの名無しさん
06/08/31 00:54:34
「独自スクリプト言語を新規開発する」どころか、
「独自スクリプト言語を新規開発するためのフレームワーク」が出て来ているのに、
そんな質問するに至る動機はナンデスカ？
せめてどんな特徴があるんですか？くらいにしてくれよ
865:デフォルトの名無しさん
06/08/31 00:56:48
>>862
そんな感じ
それなら単純にJava言語とC言語の比較が出来るだろ
866:デフォルトの名無しさん
06/08/31 01:01:57
>>861
そんな無意味なものを誰が使うんでしょうか。
性能上の要求が高くて、高級アセンブラを使うリスクを拾わなきゃいかん場合に、
仕方なくCを使うのであって、要求が低くてJavaなり何なり使って手抜きできるな
ら、手抜き言語使うんじゃないの。
867:デフォルトの名無しさん
06/08/31 01:02:58
> それなら単純にJava言語とC言語の比較が出来るだろ
言語仕様そのものを比較するわけじゃないから、意味なくない？
868:デフォルトの名無しさん
06/08/31 01:07:26
>>863 私の野生の勘ですが、javascript かjrubyの開発関係の人ですよ、きっと。もしくは学者先生。だからそそうのないように・・
869:sage
06/08/31 01:18:44
>>868
なんで2chで書きこみのリアル人生に気を使う必要があるんだと小一時間(ry
大体、そんなｴﾗｲ人がこんなところでクダまくかいな。
870:デフォルトの名無しさん
06/08/31 01:20:32
>>855
JVM系のスクリプト言語は多くが動的型で、パフォーマンスがJavaに比べて劣るから、
静的型でJavaと同等のパフォーマンスを保ちつつ、手軽に書ける言語が欲しかった
というところ
実際、簡単なベンチマークとってみたら、Javaとほとんど同等の速度が出てた
まあ、セマンティクスがJavaに極めて近いから、速度出るのは当たり前なんだが
とはいえ、予定していた言語仕様はそれなりに実装できたものの、ライブラリをまだ
全然作ってないので、Javaのライブラリを使うしかないという情けない状態になってるが
871:デフォルトの名無しさん
06/08/31 01:27:29
>>870
よくわかりませんが、それって、例えばGroovyみたいな言語
→JVMバイトコードのコンパイラ作ったってことですか？
872:デフォルトの名無しさん
06/08/31 01:27:45
>>858,>>861-862,>>865-867
現時点での実用性で考えると、いらない、意味無いというのは当たり前だと思う。
現状の、Java VMが各OS上のの単なる１サービスや１アプリケーションと考えると
無意味だけど、これとは逆に各OSはJava VM上の１アプリ・１コンテンツと考えると、
状況は変わってくるんじゃないかな？
よく言うところの、ネットワークをでかいプラットホーム見立てて各OSはJavaの環境
で統一って言うやつ。
ちなみに私は>>858じゃないよ。
873:デフォルトの名無しさん
06/08/31 01:28:06
>>869
855だけど
> 大体、そんなｴﾗｲ人がこんなところでクダまくかいな。
まあ、そりゃそうだわなw
リアルではただの大学院生です
ただ、エライ人でも興味ある分野のスレ見てる人は結構居るみたいですが
874:デフォルトの名無しさん
06/08/31 01:29:30
>>871
そういうことです
しかし、自分が言えたセリフじゃないが書き込みのペースが早いなw
875:デフォルトの名無しさん
06/08/31 01:31:55
>>867
だって、JavaとCの比較ならおかしくないだろ
JITとAOTのどっちが早いってだけの話なのか？
876:デフォルトの名無しさん
06/08/31 01:36:29
なんか知ってるかもと思ったので質問。
Java6のHotSpotコンパイラでエスケープ解析が入るのが売りの一つらしい
けど、スタックにオブジェクトが積めるようになるとそんなに性能上がるの？
世代別GCならヒープへのオブジェクトの確保解放はたいしたコストじ
ゃないし、どうせ短寿命なら初回MinorGCでedenからさようなら～なので、
なんかイメージつかないんだけど、ナニがどう軽くなるんでしょう？
877:デフォルトの名無しさん
06/08/31 01:43:02
ところで、JVMで動作するC言語の処理系だけど、既にあるよ
JVMで動作するっていうか、C言語 -> Java言語のプログラムへの
トランスレータだけど。C2Jでぐぐってみるといいと思う
878:デフォルトの名無しさん
06/08/31 01:45:47
>>875
静的コンパイルとHotSpotでどっちが早いというのがテーマなのかねえ…
「HotSpotコンパイル」の中身がどんな最適かなのかわからないことには、
なんともかんとも。
879:デフォルトの名無しさん
06/08/31 01:49:48
もしスクリプト言語作るなら、
個人的には数式処理・代数処理程度で、
それをevelする程度で十分なんですけど。
複素数や行列の独自表記ができたり、(a+b)^2と書けたり
多項式展開や因数分解できたりとかです。
Java VMで動くバイトコードコンパイラ、スクリプトコンパイ
ラ？を作る意義・動機と言うのは、そういう特定用途に特化し
た言語を作るのでもありということだと思うんですけど・・
880:デフォルトの名無しさん
06/08/31 03:49:03
C言語厨である>>841はなぜJava似のC++も使いこなせ
なかったんでしょう
881:デフォルトの名無しさん
06/08/31 03:50:11
>>844
Javaカードは、
住民基本台帳カード、
大日本印刷が作ったカード、
海外の国民健康保険カードに使われているよ
882:デフォルトの名無しさん
06/08/31 04:24:32
>>876
そりゃヒープに取らないで済めば、その分処理が軽くなるでしょう。
ヒープはGC含めてなんだかんだで競合が多いので、
C10Kな時なんかには効いてくる。object poolもしないで済む。
883:デフォルトの名無しさん
06/08/31 05:56:41
>>877
そのトランスレータ使える？ たった一行のCのプログラムもとんでもない量のJavaになるし、
ポインタ演算している所なんか、酷すぎる。
884:デフォルトの名無しさん
06/08/31 07:12:58
>>787
ちょw
まだアプリ間連携もまともにできないJavaなのにw
どうみてもやっと「アプリケーション構成を考えるようになりました」ってレベルだろ？
URLﾘﾝｸ(docs.sun.com)
のデリゲートとか
URLﾘﾝｸ(docs.sun.com)
のサービスにいつ追いつくのやらw
20年前のフレームワークに負けてるってはずかしくね？
885:デフォルトの名無しさん
06/08/31 09:15:02
>>828
> >>807
> >だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
> >>805のような動的実行コード生成をC, C++でもやればいいだけの話。
> >で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
> >OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
> if(SSE２命令が利用可能か？) {
> // SSE２命令を利用したインラインアセンブラによるコード
> }
> else {
> // SSE２命令を利用しないインラインアセンブラによるコード
> }
> これのどの辺りが動的実行コード生成になるのか説明してくれんか？
> 無知は怖いね。
無知晒し上げ