次世代Javaの動向　２

次世代Javaの動向　２ ..

520:デフォルトの名無しさん
06/07/17 21:12:37
==使わない限りDoubleでさほど問題ないのでは？

521:デフォルトの名無しさん
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 だよ

次ページ