Javaって重くね？　その６

語れ。

その１ http://pc8.2ch.net/test/read.cgi/prog/1131448367/
その２ http://pc8.2ch.net/test/read.cgi/prog/1136359572/
その３ http://pc8.2ch.net/test/read.cgi/prog/1138029112/
その４ http://pc8.2ch.net/test/read.cgi/prog/1139707592/
その５ http://pc8.2ch.net/test/read.cgi/prog/1140613666/

前スレ

C言語信者ってもう古くね CMMIレベル1
http://pc8.2ch.net/test/read.cgi/prog/1140616676/

「ストーカーみたいに糞スレばかり乱立させるし」


Cを使った仕事が少なくなってきたことによる
愚痴と新技術に対する詭弁で溢れた口八丁C言語信者の行く末は？

C言語信者の年齢層は30代〜50代。
バブル世代から新人類世代にまで広がる
まさにオッサン世代ですね。だからガーベッジコレクタの
動作原理も知らない化石的思考といわれる。

今、C言語信者の開発環境のCMMIレベルは非常に低い。
アジャイルソフトウェア開発なんてことも彼らの頭から消え去っている。
今じゃ製造業ですらアジャイル開発の影響を受けているにもかかわらずw
彼らは新しい技術を習得するという努力を怠って2chで愚痴を零してばかりいるのだ。
このスレはそんなC言語厨が愚痴を零すためのスレです。
さあ、このスレでC言語厨の強がりや愚痴や僻みや負け惜しみ発言をどーんと眺めてみましょうw

世界中に輸出され国際競争力を持つゲームソフトや情報家電はたいていアセンブラやC/C++。
　任天堂やソニーや松下は2chでは叩かれることも多いが、そこらの製品は世界中に
　あふれてるだろ？

国内に引き籠もり国際競争力ゼロの情報システム分野はたいていCOBOLやJava
　ニューヨークやロンドンの取引所は大量の注文もそつなくこなすのに、東証の
　あのざまはなんだよｗ

「産消逆転」ということばがある。

大規模開発君やエンタープライズ君には申し訳ないが、今の産業界における
IT 投資は内部統制強化などの後ろ向きな投資に追われていて、なかなか
前向きな方向には進んでないんだよ。
逆にコンシューマ側のほうが、産業界よりもずっと進んだ情報技術の恩恵を
受けているというのが現状。

死に技術のJavaをなんでこんなに必死に擁護するか不思議
大規模開発君やエンタープライズ君やビジネスロジック君や
Javaのソケットにポートは使わない君の君らだよ

本スレはこっち。
このスレは終了してね

最近のJavaって軽くね？
http://pc8.2ch.net/test/read.cgi/prog/1137836570/

>>7の言うとおり、向こうにレスしておいた。
Javaに対する愚痴を零しているバカは相手にしないが。

死んでることにしたいだけの人達の集まりですか？
引きこもりはいいね、夢の中だけで生活できてｗ

Java厨でSUNの
JAVA WEB SERVICES DEVELOPER PACK
使いこなしているツワモノいる?
絶対いないに100Java

とりあえずこれでJava厨レスは3日はつかないか、話をそらすかどっちか

おまんこ

え？話しそらしてるのはお前でしょ？

>>6
サーバーサイド分散アプリの場合に、JAVAのJNDI、RMI･IIOPやシリアライズ機能、メッセージサービスのキュー機能他もろもろは強力なんじゃないの？
ホスト集中型ではなく。

>>14
それらは全部Javaの思想からはずれている気がしてならない。
プリミティブ型もなー。

おまんこおまんこ

なんだかマ板ではいつもJavaを叩く
人がいるみたいだけど
なんだかんだいってJava屋はイケメンが多いもんだね。
デブサミやJavaOneに行ってそう感じた。
この板にいるようなJava叩きそっくりなJava屋みたいなのは見られなかった。

それにSeasar2の関係者はイケメン寄りだった

Seasar2のひがやすを は結構イケメンなかんじ。

蛯原友里の画像をブログに大量に
貼り付けていた koichkはよくわからないけど

Seasarについてはこれでも見て遅れＪａｖａに不満があるＣ言語厨さん


Seasar - DI Container with AOP -
http://www.seasar.org/

エビちゃんのどこがいいんだろう
ケバカワ系？みたいなのは需要あるのかな

Ｃ言語厨は作業服で工場勤務のﾄﾞｶﾀだからね。
おしゃれな私服でオフィス街勤務のJavaPGとは全然違うよ。

>>22
オフィス街勤務は当たり前だが
おしゃれな私服ってなんだ？SOHOかよｗ

ブルーカラーはあっちいけ。しっし

スーツも着れないフリーターなんだろうな
んでフリーランスとかほざいてるんだろうな

俺、独立してからもネクタイ締めて仕事してるけどな。
上から作業服を着るのもいい。（これはリーマン時代の習慣だろうけど）

おっさんはネクタイより結婚しろ

あれだろ、チェックのシャツ着てデブなJava厨だろ
最低だなw

>>26
まるで工場作業員みたいだな。
株式会社山武の工場で働いている作業員を想像してしまった。
「コマツ」とか呼ばれてるんだろw

>>28
Java屋でチェックのシャツ来てる奴少ないなあ。
来てる奴は学生かC言語屋くらいじゃないのか？

デブでチェックシャツとPCの傍らに置かれたフィギア
ヲタJava厨よりはいいかと

>>28
Java厨であるひがやすをはそんなキャラクターじゃないな

このブログの写真をみると
ひがやすをは体育会系に見える。

ひがやすを blog
http://d.hatena.ne.jp/higayasuo/

ヲッサンだな

なんで自分じゃない誰かに自分のルックスを保障してもらおうと必死なんですか？

人の目を気にする小心者
それがJava厨

ﾜﾛｽ

Java厨はルックスで仕事するんだなー

楽しいぞ。作業服で仕事するのは。
ああ、オイラはIT関連でも製造業なんだ。人材派遣もしくは商社じゃないんだと思える。

こいつらの必死な自作自演は妄想乙としかいいようがないなw
おまえらのほうがオッサンだろうにw

私服といっても全員ユニクロ

ネクタイって首輪だろ。
社畜ポチは首輪が自慢なのか

Springは重いなー

企業システムを設計する様なクリエイティブな仕事は、フレックスで私服が当然。
組込のおっさんはだっさい作業服着てタイムカード打ってドカタ仕事に従事する。デザイナーとはほど遠い。

Struts→Teeda→・・・

フレームワーク地獄だな

(っ´▽｀)っ
実行効率重視ならJavaじゃなくてC#使うといいよ。
Javaは動的リンクがデフォルトだからね。重いのは当たり前だね。

ハンダ付けのパートのおばちゃんと一緒に社員食堂でNHK連続テレビ小説を視るのが日課。

(っ´▽｀)っ
>>45と過去レスを読まずにレスした私はカスです。

氏ね

>>45
JavaもC#もどっちも一長一短。
C#はFFTの計算だけJavaより速かったり
行列演算、固有値分解では逆にJavaのほうが速かったりと
まちまちなんだよ。

といっても数学も解らない高卒レベルのC言語厨にFFTや固有値分解といっても
通じないかw

>>49
(っ´▽｀)っ
>C#はFFTの計算だけJavaより速かったり
>行列演算、固有値分解では逆にJavaのほうが速かったりと
それってアルゴリズムに依存すると思うんですが。
同一のアルゴリズムをC#とJavaで再現した場合どうなるのでしょうか･･･。

>>50
同一のアルゴリズムで測定した結果でそうなったっていうのがあるんだよ。
どこのサイトだか忘れた。
ﾑ板かマ板のどっかの死滅スレ系過去スレにリンクが張ってある。

アルゴリズムだけじゃなくて実装の仕方(どのオブジェクトをどう使うか)でも変わってくると思うが。

C#もJavaもどっちもネイティブじゃないVM上で動くので
速度はたいしてかわらんよ。

おまんこおまんこおまんこ

どっちもネイティブにするんだからJITの勝負だろ

おまんまん

Cが軽いのは当然だ
アセンブラに近い言語だからな。
その点、Javaは汎用性重視だからCと同等の速度にはなっても、Cより高速になることは成りえない。
ただし、Cでも糞コード書けばJavaより遅くなるから気をつけろ！
オレが言いたいのはそれだけだ。

いや、言ってみたかっただけなのかもしれん・・・許せ

なぜか株式掲示板に
JAVA？のサンプルソース発見しました。

http://messages.yahoo.co.jp/bbs?.mm=FN&action=m&board=1004753&tid=a5aaa5sa1a6a56a1a6a5a8a5ca5b&sid=1004753&mid=1034879

なんなんでしょうね？
これ？

Java と J# とで同一ソースコードでの勝負なら・・・。

高級言語ほど低級な技術で事足りる
低級言語ほど高級な技術を必要とする

>>43
> 企業システムを設計する様なクリエイティブな仕事

それこそデジドカ (笑)

UMLで華麗に纏め上げ
颯爽とビジネスロジックを実装するんだろうな

>>58
それはJavaじゃねえぞアホ。
このド素人が

>>60
低級言語厨の根拠のない言い訳ですな

WSDLでスタブを作ると.NETの3倍の行になるJavaが高級なのか？
行の多さ、負荷の高さ、馬鹿の数で勝負すると確かにJavaは高級。

気のせいかもしれないけど、Java組んでる奴ってネーミングが長い傾向があるんだよな。
ソースを見たときの冗長感が強いのは、そんなところにもあると思う。

C++の方が長いよ、ボケ。

え、iとｊとか短くて分かりにくいというが
C以来の伝統なんだが・・・。

やっぱり、C++みたいにヘッダーにクラスの宣言とか書くようにしたほうがよくね？
カッコの中に関数全部書くのはやっぱりネストがデフォで１増えてよみにくくって・・・

いや、整数にiとかjとかnを使うのはコンピュータ出現以前の数学からだって。

配列の添字にiを使うのがわかりにくいとか逝ってるバカは文系だろ。

>>69
Cだってインライン化するときはクラス定義内に書くじゃん
気にするレベルじゃないな

まぁ、エディタでそういう気遣い出来てもいいかとも思うが

ANSIでプロトタイプ宣言が導入された精神はどこにいったのか。

>>72
inlineつけるよ。俺は。

>>72
>気にするレベルじゃないな
気にするレベルだよ。
すげ、醜いって。
ネストなげーもんｗ
まあ、Eclipseを常に最新にしてれば少しはましな環境になるが・・・
Eclipse限定でもの語っちゃっていいのか？ってもあるし。

ヘッダに書いたらソース丸見えじゃん

定義と実装がごっちゃになるのは嫌。

>>68
だれがそんな話題振った？
JavaでもCでもシーケンシャルアクセス用途のループ変数はiとかjだぞ
それにCだと短すぎる変数名はグローバルに取るなってマナーがあるだろ

Cの標準関数が短すぎて可動性が悪いってだけで
他は基本的にどの言語でも似たようなルールがあるもんだ

そうだな。
本当はＣ言語からグローバル変数は駄目駄目叫んでたしな。
Ｃ言語でグローバル変数無しでどうやってプログラム組むんだとか素でいるしな。

*.hファイルと*.cppと２つのファイルに分かれてるのは面倒くさい。
その点、Javaなら*javaファイルの一つだけ。そのファイルに必要なことは全て書いてある。
シンプルでわかりやすく、美しい。

ネームスペースでスコープ切れば冗長なネーミングは必要ないでしょ。

あっちのファイルを編集してこっちのファイルに追加してってバカみたい。
ﾄﾞｶﾀ作業の極みだよ。合理的じゃないね。

std.mem.memcpy()
うはっ、微妙ｗ

Cの関数で省略が酷く可読性が悪いなんていってたら、Java厨が大好きなun*xの
コマンドやシステムコールはどうなるの？

>>80
やっぱり、はじめはクラスの概要をざっと見渡したいわけよ。
なのにいきなり本体みせられんじゃん？
あれが俺的にゆるせん。

それに気づいた（かどうかはよくわからんが）Eclipseでよこっちょの＋を押すと関数が
縮められるようなエディタに変身したがIDEがそれをサポートしてくれないといけない環境はどうかと思うよ。

なんだなんだまたJava厨があほな事言い出したかｗ

おまいのIDEはクラスをツリービューで見せる機能も無いのか。
最新のツールを使いこなさないと生産性は上がらないぞ。おっさん。

＞Javaなら*javaファイルの一つだけ。そのファイルに必要なことは全て書いてある
素人仕様だからね。

>>84
コマンドなんて暗記して何ぼじゃねーか
ポケットブックが流行ってるのがいい証拠

>>85
> はじめはクラスの概要をざっと見渡したいわけよ。
普通はJavaDoc見るが？

> IDEがそれをサポートしてくれないといけない環境はどうか
逆にC++は.hの定義から実装のメソッドに飛ぶのは完全にエディタに依存してるよな？

>>87
いや、だから、Eclipse使ってるからその辺の一覧は確かにでるんだけど、
なんかIDEべったりで好きじゃないんだよなぁ。
あるとき突然Eclipseが死んだらJavaもいっしょに死亡みたいな空気あるよ。

C++だって*.hに全て書く方向に進んでるじゃん。
あほみたいに二つのファイルを行き来して、プロトタイプ書くの忘れてコンパイラに怒られたり
出力ツール作ったり、あほみたい。80年代のおっさんは何も疑問に感じないかもしれないけど、
テキストエディタとmakeで開発していた16bit時代の遺物だよ。

>>89
>逆にC++は.hの定義から実装のメソッドに飛ぶのは完全にエディタに依存してるよな？
別に飛ばなくてもいいけど。
俺、定義と同じ順序で並べるし。

手作業で同じ順序に書いてるんだね。


ローテクだなｗ

>>92
ならJavaだろうがC++だろうがコードたためなくても文句ねーよな？
自分で言ってる矛盾くらい自分で回収しろやヘボ

>C++だって*.hに全て書く方向に進んでるじゃん。
そんな方向進んでないだろｗ

>あほみたいに二つのファイルを行き来して
わかってねーなお前。
これが便利なんだよ。
cppとhを並べておいて、cppを開くと本体がみれて、hを開くと関数一覧みたいな感じで使えるから便利なんだよ。

>>89
暗記出来ないからポケットブックが流行してる。
また、ポケットブックは、--helpやmanの英文が読めない人のためのもの。

コマンド名の暗記の補完はポケットブックじゃ出来ないよ。

>>94
駄目だよー
一覧と本体を交互にみれないじゃん。
同じソースだから。

>>95
便利と感じたことが一度たりとも無いな
VC++だったらMSDN開くし、結局概要を見るのはドキュメント便りだ

人の書いたクラスを使うのが専門のCﾄﾞｶﾀは一覧表となるhファイルが不可欠なんだろ。
苛めるな。

>>99
ドキュメントを残さない怠慢文化の象徴だからなヘッダファイルは

>>96
> コマンド名の暗記の補完はポケットブックじゃ出来ないよ。
いや出来るだろ何言ってんの？

定義と実装を混ぜるのは嫌。

定義と実装を分けるのは無駄。

またJava厨はおそろしいほど単細胞だなｗ

ﾄﾞｶﾀＣ厨がにげたな

機能から逆引きできないJavaDocって
ドキュメント書きましたってオナニー気分なだけｗ

>>104
完封されたからって分かりやすいあおりいれないの。
いい年してガキすぎんだよ

あんな糞なJavaDocでうれしがってるJava厨は真性。。ｗ

ヘッダファイルがインターフェースの定義になる様にプロトタイプ宣言があるんだが。。。

でさ、そんな俺（みんな）の期待に応えるかのようにEclipseですでに実現済みなんだよこれが。

http://www.okisoft.co.jp/esc/eclipse3/eclipse3-1.html
同一ファイルを複数のウィンドウで表示

とりあえずIDEがJavaのウンコなところを吸収してはいる。

Eclipseで+押して18秒またされても我慢して使っているお前は偉い！！

doxygenとかJavaDocを使ってドキュメント生成したところで、
それがコードと一致している保証はないしな。
ドキュメント生成ツールは、あくまでもコード凍結後に使うもので、
開発中に使ってドキュメントを更新していくためのものじゃない。

と、思う。

Eclipseのインテリセンスって　obj.って打ってから
32秒またされるのは勘弁してほしい(3.12)

単語補間とかおかしな方向へいっててﾌｲﾀｗ

Eclipseって開発環境を語る以前のできばえなんだよなー

>>115
軽くはなってると思うぞ。

>>112
> doxygenとかJavaDocを使ってドキュメント生成したところで、
> それがコードと一致している保証はないしな。
普通一致するが？？？
コード凍結してないものを外部に公開なんてしないだろ

>>110
何？このVC？

netBeans使えよ。

戦況が不利になると大抵Eclipseを話題に出すドカタさん

>>119
やだよ。
みんな使ってないもん。

*hと*.cppを行ったり来たりご苦労なこった。

>>121
ざけんな、うんこ踏んで転べや

おまんこ

C厨の完全敗北だったな。
そろそろ飲みに出かけるけど、また来るよ。じゃあな。

>>80
javaって1ファイル1クラスでしょ

>>81
それが使えてないんだが

ヘッダって可読性のためじゃなくてリンカのため

漏れは宣言部分は一つのヘッダーに纏めて、
実装は複数のcppに分けてる。

実装と宣言部分分けるのはコードの可読性とか
ミス無くす為に必要だと思う。

でもクラスをたくさん作ると4，5行のヘッダーが
増えるので、短い宣言はヘッダーを纏める事で解決。
宣言するヘッダーも似たようなもんだいし。
厳密にクラス追加すればコンパイルに怒られる事ないし。

アホ発見！
昔のCにはプロトタイプ宣言なかったぞ。

>>108
お前Doxygen使った事がないのか？
C言語厨なら知ってるはずだぞ。
しらなかったら「俺はC言語ができる」とは言わせないぞ。

>>126
複数のクラスを書くことも出来る。

>>113
スペックはいくつだ？
３GHｚ、メモリ１GBのマシンでは
そんなことはありえん。

リンカがヘッダを参照するとは初めて聞いた

>>112
Java5から登場したアノテーションを
使えばある程度信用できる
ドキュメントを書くことも可能になった。
ドキュメントを書くというよりも
ドキュメントに余計な事をかかずに
アノテーションで代用できるようになっただけだが。

信頼性を高めるには分割統治だ。
メソッドを分割してそれぞれのメソッドについての
ドキュメントを書く。
それからJUnitによるテストも怠らないこと。
テストレポートなども書くこと。
テストレポート自動生成ツールは数多くあるので
それを利用する事。Apache Mavenを使うと
テストレポートの生成が容易になる。

java pressにCより早いって書いてあるんだぞ！！！！

javaのほうが早いんだ！！！！！

>>132
Java厨叩きほいほいは要らんから。

>>130
別にdoxygenなんて必須じゃねぇだろｗ

>>137
つかわなあかんのはどきゅめんとも整理もされてないど糞してるとこだ

Java厨叩き厨を釣るためのホイホイが
大量に投下されてますので皆さん足元にご注意を

>>98
VC+＋依存症か。
C++玄人ならVisual Studioなんか使わず
Emacsかviをつかうもんだろ。

最近、自分自身が重くなってます。

>>141
ぴざ食えば軽くなるらしいぜ

最近のぴざはすごいらしい

>>142
でたな。腐れハッカー。

皆さん聞いてください。>>142は盗聴ハッカーです。

>>90
> >>87
> いや、だから、Eclipse使ってるからその辺の一覧は確かにでるんだけど、
> なんかIDEべったりで好きじゃないんだよなぁ。
> あるとき突然Eclipseが死んだらJavaもいっしょに死亡みたいな空気あるよ。

NetBeansやJavaStudioCreator、AntやMavenがあるからJava
はそう簡単には死なないとまず言っておくが、
言わなくてもEclipseは死なない。
オープンソースでかつ、ただで配布されているんだから。
Eclipseの評価がさらに上に上がるのも時間の問題。
多くの企業によって開発支援されているのだから。

> Emacsかviをつかうもんだろ。
使わんよ。使えると使わないは別。

>>142
国の機関だろうがTV局でも何でも良い。
コイツを問い詰めて逮捕しろ。

こいつは盗聴ハッカーだ。

マジで捕まえてくれ

>>142
↑
身元確認しろ

コイツを追え！！！！！！！！

>>70
iやjは電気系だったら複素数に使いたい。
Javaで使うことは少ないが。

>>147
ん？リアルでピザ食ってて慌てふためいてるのか？
そこらへんを詳しく実況してくれ、ピザ

>>146
素人みたいじゃないか。
それでJavaをたたくなんて数兆年早い

>>142は犯罪者だよ。＞警察

でたなハッカー
犯人はNT○社員っぽいな

ごめん、一名ほどファビョってるピザがいるんだが、何？

>>142
↑
つーかほんとまじでコイツを調べる必要があるぞ。

俺はハッカーにより精神的苦痛を２年前から受けてる

>>145
>NetBeansやJavaStudioCreator、AntやMavenがあるから
そんなウンコだされてもねぇｗ
やっぱりEclipseしかありえないな。

ハッカーにより精神的苦痛を受け始めてから鬱に陥り人生おかしくなった

>>155
事情を説明しろやピザ
現状調べる必要があるのはお前の脳だ

ｸｸ…てめーらには無理

>>66
> 気のせいかもしれないけど、Java組んでる奴ってネーミングが長い傾向があるんだよな。
> ソースを見たときの冗長感が強いのは、そんなところにもあると思う。


Javaコーディング規約では
クラス名やオブジェクト名はなるべく名詞形になるように
メソッド名は動詞形になるように記述することが推奨されている。
何かを比較するメソッドでは
compareTo(Object)とし、メソッド名は
メソッド引数が目的語になるように
同士+ 前置詞にする。

だから若干ながくなるわけだが。
極端に長すぎる場合は設計が間違っているか
packageをうまく使えていない。
その点についての解決方法は『実践UML』を参照すること。
継承や委譲、集約などをうまくつかえば
わかりやすい名前を保持したまま、英語で発音でき意味を保ったまま
ほとんどの名前をスリムにすることができる。

>>157
あ、言ったな。NetBeansはSwing GUI開発では
Eclipseとは比べ物にならないくらい開発効率が高いぞ。
それにEclipseよりも軽い。

それからJavaStudioCreator2は
JSF開発ではやはりEclipseと比べ
比べ物にならないくらい開発効率が高い。
これもEclipseよりも軽い。
しかもMacromedia Dreamweaverのように
ウェブページを作る事ができるようになった。
それにデータベース関係の連携、JSP同士の
リンクなどの設定も容易。

Java Studio Creater（無料）のswfデモ
http://developers.sun.com/prodtech/javatools/jscreator/overview/tours/prodtour/flash/index.html

>>162
>NetBeans
誰もつかってないじゃん。

>JavaStudioCreator2
なにいってんの？
これ推奨環境のメモリ１ＧＢとか要求する鬼仕様だよ。
動作激重で話にならない。

>>164
> >>162
> >NetBeans
> 誰もつかってないじゃん。
使っている。日本でも本が二冊出ている。
ム板見れ。使ってる香具師が増えてきている。

> >JavaStudioCreator2
> なにいってんの？
> これ推奨環境のメモリ１ＧＢとか要求する鬼仕様だよ。
> 動作激重で話にならない。

ウェブデザイナもターゲットにしているらしいから
それくらい用意しろって話なんだろうな。

メモリ２GB積んでるがEclipseより快適だぞ。
Eclipseの場合はメモリ１GBあれば十分だが
CPUは若干必要らしいな。

Javaは、とにかくメモリさえあれば高速になるっちゅーこった。

Javaってメモリさえあれば軽くね？

>>164
>>NetBeans
>誰もつかってないじゃん。
使ってるよ！うんこ踏め糞野郎

>>JavaStudioCreator2
>なにいってんの？
>これ推奨環境のメモリ１ＧＢとか要求する鬼仕様だよ。
>動作激重で話にならない。
俺もそう思う。お前の相手はHomepageBuilderだろと何度言っても聞かない。

>>165
>使っている。日本でも本が二冊出ている
風前の灯火だなｗ

>Javaは、とにかくメモリさえあれば高速になるっちゅーこった。
　そ　う　じ　ゃ　な　い　も　の　っ　て　あ　る　ん　で　す　か　？

昔は厨を釣るスレだったのに、
すっかり厨になりきるスレになったな。

>>169
なりきる？
馬鹿言っちゃいけない。
厨しかいないでしょ。

>>142は間違いなくハッカーだ
逮捕して＞警察

>>142
とにかく、捕まえれてくれえええええええええええ

マジで調べる必要は大有りだ＞警察

全ての元凶なんだ！！！！！！！！！！
俺が壊れたのもハッカーの>>142が原因

全てを盗聴し、外部に漏らし一人の人間に精神的苦痛を与え、犯罪者に仕立てる。

全てはアイツのネットストーカー行為から始まった・・・
アイツさえいなければTVでネタにされる事もなかっただろうに。

警察見てるんだったらマジで調べてくれ！！！！！！！！！！

何故ピザが>>142に発狂してるのか
いつになったらその説明がされるのだろうか

一人の人間を操り社会を崩壊させようとする元凶だ

頃してーーーーー！！！！！！！！！！！！！！

やっぱりＰＧの仕事長く続けると>>178のようにアタマがおかしくなるのかな？

本と頼むから>>142を調査してくれ＞警察

あの忌まわしい事件も>>142がいなければ起こる事はなかった。
全てはハッカーを釣る為にやったことが間違いの始まりだった。

>>142は俺の人生を狂わせた人間だ

>160 ：142：2006/03/25(土) 18:58:02
>ｸｸ…てめーらには無理

警察には無理？
と言う事はお前が警察か国の機関ということか？

国が精神的苦痛を与えてるなんて他の国に分かったらどうなるか分かっているのか？

俺がお前に追い回される前に何をした？

ノイローゼなPGさんが自分と一緒にスレまで崩壊させてるingですか？
じゃあ他所に移るか

何か犯罪でもやったのか？おいコラ！！！！！

社会を崩壊させて何を企んでいる？

これが間接的テロリズムなのか

本当に警察御願いします。
>>142、>>160調査の余地ありです。

おい。壊れてる奴！
おまいはC厨・Java厨かどっちだ？

俺を操作して日本国を破壊するテロリストだ。

NetBeansが貶されて狂っちゃったか？ｗ
あきらめろ。
みんなEclipseしか使ってないからｗ

>>195
NetBeansは使ってるって言ってるだろ
うんこ野郎はしつこいな！

お前はどれだけ日本国に迷惑かけているか分かってるのか！！！！！！！！！

>>196
Eclipseの本はたくさんでてるのに、やけに少なくないですか？
NetBeansってもう消えちゃうんですか？

Java厨 同士仲良く

これだけの時間何も反応がないって事はほぼ犯人だ

>>198
逆だよ逆。netBeansがクローズアップされてきたのはここ最近。
4.2から人気が出始めて、最近5.0の日本語版公式が出た。
まだまだ腹立つ部分もあるけどeclipseより快適。

ヒロシです・・・
NetBeansをダウンロードしようとすると名前とEメールを聞かれて怖くてやめてしまうとです。
ヒロシです・・・
勇気をだしてNetBeansをダウンロードしても、エラーがでてインストールできなかったとです。
ヒロシです・・・
やっとのことでインストールしても、エディタの入力からタブが消せんとです。
ヒロシです・・・
情報がすくなすぎることが、アプリケーションの価値を下げるといまごろ気づいたとです。
マイナーであることの意味をやっと理解できたとです。
ヒロシです・・・
ヒロシです・・・

全てを外部に流出させ、俺を操作し、
あの惨劇を起こさせ犯罪者にしたて、
日本国を崩壊に導く。

国がやってるなんて信じられない・・・・・・

俺は国に操作されているのか？
国は何を企んでいるのか・・・・・・・・

>>202
それ入力せず次へ行けばいいだけだよ
個人情報は一切提供しなくていいようになってる

日本国って一体なんなんだ？

テロ組織なのか・・・？

なぜ平和を嫌うのか・・・。
理解に苦しむ。

人間不信に陥る要素を作り出している元凶

お前らの実体は闇の組織なのか・・・・・・・・

>>208
お前がさっきまでやってたエロゲじゃね？

国が国に対してテロを行うという事はないと思うから。
法に触れないよう苦痛を与えて俺を頃す気なんだろうな

外部には知られていない闇の○庁が存在するかもしれない。

札人○・・・・・・・・・

>>210
そうそう。エロゲの台紙ｗ

スレの住人様、管理人様。
失礼しました。

2chに誘導して俺のやる気を削ぐわ何がしたいわけ？
足を引っ張る風潮ってこれか？

気のせいかもしれないけど、Java組んでる奴ってネーミングが長い傾向があるんだよな。
ソースを見たときの冗長感が強いのは、そんなところにもあると思う。

〜〜By〜〜〜〜
妙に長いと思ったらByの後に引数全部書いてあった。
EclipseでJUnitのテストクラスを自動生成させたときみたいな。

>>216
最初StringTokenizerと出くわしたときは面食らった。
コード補完前提の言語だとは思うが、
慣れれば長いほうが分かりやすいとも思った。

>>132
3G 1.5Gメモリだが WTP2.0だぞ

Java厨って狂っている椰子ばっかりだったんだね

>>220
さっきのピザはどう見てもC厨だった

とかそういう押し付け合いはやめよう。
痛すぎて話題にしたいと思わない・・

気のせいかもしれないけど、Java組んでる奴ってうんこが長い傾向があるんだよな。
トイレの後で悪臭感が強いのは、そんなところにもあると思う。

222 名前：仕様書無しさん [] ：2006/03/25(土) 21:28:12
気のせいかもしれないけど、Java組んでる奴ってうんこが長い傾向があるんだよな。
トイレの後で悪臭感が強いのは、そんなところにもあると思う。

こういう頭の悪いレスが付けられるのがC厨なのです

出たな。犯罪者。

いい加減にしろ犯罪者。

テンプレートプログラミングがデフォだからついね

Java厨にはテンプレートの文化はないもんな

くどぐとビジネスロジックを泥臭くクラスの外枠に貼り付けていくだけ

最近のNetBeansって良いらしいね

最近はGUIの部品使う時ってAwt？Swing?

何とか話をそらそうと必死だな。JAVA厨よ。

JavaってJustInTimeコンパイラ使っても重いの？

おまんこまんこ

>>227
ん？あるけど？
テンプレート機能そのものは5.0のGenericsからだが
パターンプログラミングによって普通に実装されてきたことだよ。

ジェネリックスなんか使ったらますます遅くなるよ。

ならねーよ、ありゃObjectとキャストをラップしてるだけだ

Javaは型に厳密な言語だからな。

>>63
冷静なコメントをありがとう・・。

NetBeansってWebサービスクライアントあたりの操作性は
Eclipseより上か?

エクリプスは糞

エクリプスが大ぐそなのは同意

えらいバグっぽいのがエクリプスの特徴
バグのありかがどのプラグインか特定できないのもまた特徴

起動時にプラグインを全部読み込むアホ仕様を
なんとかしないかぎり、エクリプスはいつか破綻する。

>>243
非同期読み込みの考えがないJava厨文化のなせるわざかなw

ばーか、Eclipseは貧乏人の触るようなツールじゃねーよｗ
お子様やニートはEmacsでも使ったらｗｗｗ
EclipseはCPU４GHｚ、メモリ８GBを積んだマシンで超快適に動く
お洒落な大人にしか使いこなせないツールってことだｗｗｗ



何点くらい？添削よろしく。

>>244
遅延読み込みはJavaの言語仕様そのものがそうなのだが？
Eclipseの設計のおかしさは普及当初より言われてたことだよ

おしゃれな大人はキセル乗車するような
エクリプスなんて使わないと思うよ

質感のよい本物を選択すると思う。

「プロの道具」
「一眼レフカメラ」

これを忘れてるな。

>>246
その程度のものだからオプンに放流したわけだよな

豆をインスコした。絵栗糞よりも軽いな。
Webサービスクライアントも標準だ。やるな。Axis 2.0Betaを
食わせてテストしてやろうか。

絵栗糞よりずいぶんいいね、ねっと豆。
Webサービスの解析が甘いのはWTPとおなじようだが
レスポンスや全体の動作感は得栗糞というよりは
VS.NET 2003のような軽い感じ。いいね。

ネット豆のWSDLは完璧だった。最初は解析エラーになったが
マシンを再起動したらオペレーションのテストがばしばし動くよ。
Axis2.0のサービス、.NETのサービス
相互運用のテストもらくらくだ。Eclipseで悩んでた事が解決。
やっぱり得栗糞は糞だった。間違いない。

でも、誰も使ってないけどねｗ

電子政府も縦割り弊害　各種申請、同一ＰＣで無理
ttp://www.asahi.com/kansai/news/OSK200603250032.html

プロにはプロの道具がある。
例えば、プロのカメラマンはバカでも使える「写るんです」は使わないし、ましてや携帯に
ついてる糞カメラで仕事をしたりしない。
状況に合わせてレンズを選び、フィルムを選ぶ。
カメラはそのプラットフォームとなるにふさわしい、一流ブランドの一眼レフカメラを選択する。
（キヤノンやニコンのような）

IBMという世界一流の企業から生まれ、世界中の天才プログラマーの高潔な無償の貢献により、
エンタープライズ分野でプロの道具として磨き上げられたEclipseは、状況に合わせてプラグインで
武装することができる、ソフトウェア開発における真のプロの道具と言えよう。

VisualStudioも素人のホビー用としてはいいかもしれないね。使ったこと無いけど。

Javaの生まれしSunMicrosystemsから生を受けたNetBeansこそプロの道具だ。爺。

Visual Studioのインテリセンスはイイ。
同様の機能はEclipseにも付いてるけど遅すぎで使えない。

IBMは社食が高い。カツ丼680円はねえだろ。よって３流企業にｹﾃｲ

素人にはプロの道具は使いこなせないからね。
女子高生にEOS-1Dを与えても壊すだけ。

すべては、エンタープライズアーキテクトの限りない創造力のために、
プロフェッショナルの絶え間ない挑戦のために。
IBMとオープンソフトウェアコミニティの妥協なき挑戦の結晶、Eclipse。

>>138
C厨なら使って常識。
つまりお前らはｿｰｽコードに何もコメントかかないのか。
何のためのメソッドであるかを説明もせず、
メソッドが導入されたバージョンも(自動ででも)明記せず、
出力される例外条件の説明もせず、
メソッドの引数の説明、戻り値の説明も書かず、
引数に入力可能な値、戻り値の条件も説明せず、
このメソッドを使用することで「現在のオブジェクト」
がどう変化することも書かないないのか。

さすがC言語厨は程度が低いな。
どうりてローテクで開発効率が悪いわけだ。
そりゃデスマーチになるわな

>>168
> >>165
> >使っている。日本でも本が二冊出ている
> 風前の灯火だなｗ
これから増えるところだな。
EclipseがNetBeansよりも軽ければ
消えるだろうが、まだまだというところだな。

> >Javaは、とにかくメモリさえあれば高速になるっちゅーこった。
> 　そ　う　じ　ゃ　な　い　も　の　っ　て　あ　る　ん　で　す　か　？

CPUやメモリサイズにもよるだろう。どれくらいの容量のメモリが欲しいのか？
そのあたりを明確にしないとだれもお前の質問には答えまい。

>>193
C厨だと思う。
なぜ警察の話がでるのかわからんが

>>195
だれが貶したって？
JavaでGUI使う香具師は確かに少ないが。
NetBeansはこれから一時的に増えるだろうと見ている。
プラグインの豊富さではEclipseにはかなわないが。

>>198
これから増える。
というかJavaでGUIを作ろうと考えている者が
少ないからサーバサイドアプリ開発などで人気があるEclipse
よりも利用者が少ないのは当然。

これからだろうね。このスレタイのようにJavaは遅いということが頭から
離れない香具師が多いからNetBeansがEclipseと違って100%PureJava
というだけでEclipseより重たくて使えないと勘違いしている香具師が多いんだろう。

それ以外にも　Eclipseはプラグインが豊富にあるのに
NetBeans２は少ない。それも利用者が少ない原因だろう。

>>202
JavaStudioCreatorと違って、
ダウンロードには名前とメールを聞かれることはない。
名前とメールを入力するのは任意。

エラーが出る？プロキシの設定が中途半端ということはないよな。
情報が少ないのは日本だけだと思うが。

英語嫁れば問題なし。というかNetBeansはEclipseよりもシンプル。
マイナーとかのレベルではあくGUI開発がEclipseよりも
非常にやりやすくサクッっとできることがNetBeansの強みだろう。

>>216
コピペするな。
マルチウザイぞ。
その話はあっちのスレでやれ

>>217
次世代JUnitであるTestNGを使え。
NGはNext Generationの略だ。
Java5から追加されたアノテーションを
うまくつかっており、無駄に長いメソッド名が
かってにつくことはないし、
メソッド名の先頭にtestが就くこともない。
@Testというアノテーションが負荷されるだけの
スグレモノだ。もとはC#のNUnitの影響が
受けたものだろうが、かなりスッキリすることだろう。

それから今JUNit.orgでは次期バージョンJUnit4の開発が
勧められている。それに期待せよ。

>>220
いや、こいつらはＪａｖａもCも知らない厨か
もしくはC言語厨だろう

>>227
C言語厨にすらないだろ。
C++厨にはあってもな。
というかJavaでもGenericsでできるんだが。
C++にあるような無駄な機能は省いて。

>>230
Swing.
AWTは論外。

>>243
> 起動時にプラグインを全部読み込むアホ仕様を
> なんとかしないかぎり、エクリプスはいつか破綻する。

そんなAdobe Softwareみたいなアホ仕様にはなっとらん

>>255
お前珍しく人を貶さなくなったな。
以前は散々Javaを貶していたのに。

>>257
> Visual Studioのインテリセンスはイイ。
> 同様の機能はEclipseにも付いてるけど遅すぎで使えない。
> IBMは社食が高い。カツ丼680円はねえだろ。よって３流企業にｹﾃｲ

凄いこと言ってるな。　お前の会社と比べたら(ry

eclipseはJava謹製だろ？実際あれ重いじゃん。

同一パソコンで申請できなくなる不具合、電子政府も「縦割り」弊害
http://live22x.2ch.net/test/read.cgi/news/1143342960/

1 名前：trickψ ★[] 投稿日：2006/03/26(日) 12:16:00.83 ID:???0 ?#
　インターネットによる国への電子申請で、一つの申請ができるようにパソコンを設定すると、
同じパソコンからは別の省庁などに申請できなくなる不具合があることがわかった。各省庁が
連携なしに申請システムを作ったためで、不具合解消のため、総務省は４月３日、電子政府の
ホームページに総合受付コーナーを設ける。大半の申請をそこからできるよう、各省庁が
２年間でシステムを接続する予定だが、接続しないシステムもあり、電子政府の足元が
揺らいでいる。

続き
ttp://www.asahi.com/politics/update/0326/004.html

依頼
http://live22x.2ch.net/test/read.cgi/news/1143189819/701


＞総務省によると、文部科学省以外の電子申請にはパソコンにあらかじめ、米サン・
＞マイクロシステムズ社のＪＲＥというプログラムを導入する必要がある。
＞パソコンの基本ソフトであるＯＳが違っても申請のための操作を可能にするためだ。

＞しかし、ＪＲＥは随時、バージョンアップされており、各省庁の申請の種類によって
＞バージョンがばらばらになっている。総務省によると、新版を入れたパソコンは旧版
＞対応の申請ができないことが多く、旧版を入れたパソコンは新版対応の申請が難しくなるという。

また覚えなおし＆分化かよ
JUnit→TestNG
　　└→JUnit4
eclipseを構成するプラグインがそれぞれ分化しすぎていて
環境を整えるのが面倒

eclipseを使いこなせてこそプロフェッショナル。

Agitatorでテストは自動化だろ。

>>275
システム系の部が無かったと仮定した場合
こういうのは庶務課がやればいいことじゃないのか？
ファームウェアの更新みたいなことは庶務ではないということか

全てのバージョンのＪＲＥをインストールしろ

Ｊａｖａでは良くある話。
枝番バージョンの組み合わせが爆発して収拾がつかなくなる。

JVM切り替えればいいだけじゃん、と思ったが、JVMって04とか06とか
所謂ビルドバージョンですらディレクトリ分けるよな
上書きするか聞いてOKなら上書きしてほしい

アホみたいにバージョンがあるから・・・

バージョンの組み合わせって何だよ、最新版入れて終わりじゃないか
DirectX並みの上位互換性は確保できてるよ

＞しかし、ＪＲＥは随時、バージョンアップされており、各省庁の申請の種類によって
＞バージョンがばらばらになっている。総務省によると、新版を入れたパソコンは旧版
＞対応の申請ができないことが多く、旧版を入れたパソコンは新版対応の申請が難しくなるという。

>総務省によると、新版を入れたパソコンは旧版対応の申請ができないことが多く、
>旧版を入れたパソコンは新版対応の申請が難しくなるという。
JREだけのことじゃないだろ？JREが気にする必要があるのは後者

やっぱ、役人はアフォだな。

>>274
C++ネイティブで動くところもある。

穢れてる。やはり100%Pure Javaでなくては。

>>276
> また覚えなおし＆分化かよ
> JUnit→TestNG
> 　　└→JUnit4
> eclipseを構成するプラグインがそれぞれ分化しすぎていて
> 環境を整えるのが面倒

おいおい、マニュアルをよく見ろ臆病者w
覚え直すほどのものじゃねえぞw
去年末か今年頃に出たJavaPressの記事を読め。

TestNGならプラグインですぐに導入できる。
JUnit4が出ればTestNGは要らなくなるだろう。
何せ、JUnitはXPで有名なあのケントベックとエリックガンマによって作られているからな。

しかもJUnitのライセンスはオープンソースではあるが
勝手に改変してはならないというライセンスがある。
勝手に改変したものが出回って誤ったテストを行われたら
JUnitにタイする誤った誤解が広まるからな。

XUnitが引き起こす問題はJavaに限った話では無いがな。

>>275のようなアンチJava厨はバカが引き起こした問題をすべてJavaのせいに
する性質があるらしい。

これはSIerに責任があるんだろ。Javaに責任はないぞ。
FとかNとかHがアフォぞろいのﾁﾝｶｽ野郎だからだ。

JAVA PRESS廃刊ですよ。

>>292
そう、Javaは悪くない
Javaを使った奴が悪い

>勝手に改変してはならないというライセンスがある。
なにそれ？ストールマンに喧嘩売ってんの？ｗ

確かに。すげーw

javaの成分解析結果 :

javaの73%は知識で出来ています。
javaの17%は毒物で出来ています。
javaの5%は白い何かで出来ています。
javaの2%は黒インクで出来ています。
javaの1%は運で出来ています。
javaの1%は努力で出来ています。
javaの1%は世の無常さで出来ています。



http://tekipaki.jp/~clock/software/index.html

リチャード・ストールマンの成分解析結果 :

リチャード・ストールマンの52%は嘘で出来ています。
リチャード・ストールマンの48%は蛇の抜け殻で出来ています。


ジェネラルパブリックライセンスの成分解析結果 :

ジェネラルパブリックライセンスの85%は陰謀で出来ています。
ジェネラルパブリックライセンスの5%は欲望で出来ています。
ジェネラルパブリックライセンスの5%は知識で出来ています。
ジェネラルパブリックライセンスの4%は花崗岩で出来ています。
ジェネラルパブリックライセンスの1%は愛で出来ています。

((((((；ﾟДﾟ))))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>295
JUnitはGPLじゃなかった。はず

GPL3版はリーナスにも嫌われてるし
GNU原理主義者とその他オプソ界PGとで壁が作られつつあるな

水35L、炭素20�s、アンモニア4L、石灰1.5�s、リン800ｇ塩分250ｇ、硝石100ｇ
イオウ80ｇ、フッ素7.5ｇ鉄5ｇケイ素3ｇ、その他少量の15の元素で人体は構成されている

>>301
そのうち、ちんこを構成するのはどれですか？

つその他少量の15の元素

その他少量の１５の元素”とは、　硼素、フッ素、珪素、ヴァナジウム、クロム、モリブデン、
コバルト、ニッケル、銅、砒素、セレン、マンガン、スズ、ヨウ素、亜鉛　らしい

JUnitとが素晴らしいとか言っている人に質問。

単体試験にJUnit使ったら、ソース規模が3倍になった上、正常／準正常系の入出力試験ぐらいしか
出来ないんだけど、これでいいの？
あまりに試験内容が薄いので俺の所はいつもの単体試験をやってから出したので、
品質はいつも通りだったが、JUnit分のコードは作った意味がなかった。
しかしJUnitだけしかやらなかった別チームは、結合試験で大量にバグが出て期間が3倍に延びた上、
総合試験やっている今でも、相変わらず単体試験レベルバグが出まくりなんだけそど。
まあ、単体試験で内部異常系ルートをチェックしてない（JUnitではできない）のだから当然だが。

単体試験でJUnit使う利点は何？

テストの作り方間違ってたんじゃね？

>>305
ん？単体試験以外でJUnitって何に使えるの？
JUnitは先にテストコードだけ仕様どおりに作って結果を真っ赤にしておき
オールグリーンになったら出荷するためのものだよね？

またＣ言語ﾄﾞｶﾀが知ったかこいて恥かいてますね。

>>300
だからCPLやApacheライセンスがあるわけだが。
このあたりがいまのところ安定してそうな
オープンソースライセンス。

BSDライセンスは微妙だな。
M$みたいな変な会社に乗っ取られる可能性があるし。

GPLは厳しすぎる。
本当にタダで使いたい人が多い場合のみに
適用すべきライセンスだな。
空気や水と同じように扱うべきソフトウェアとか。

LGPLなんてのもあるが。

>>301
実際には、人体を構成する元素はかなり多い。
あの人体に有毒なヒ素ですら我々の体内には含まれており
必要不可欠なのだ。

>>305
ケントベックが書いた「テスト駆動開発入門」
を読むことをお勧めする。
非常に素晴らしい。

それからJUnitイン・アクション。
テクニック画家いてある。

>>305
テスト駆動開発では
あなたの会社のように
テストコードを書く者と
実装を書く者とを分離するという
愚かなことはしない。

TDDのテストと既存のテストは別の物。
TDDを導入すれば既存のテストが不要になるって話は
アジャイルを導入すれば仕様書が不要になるって話と
同じくらいとんでも。

まあ彼の会社はJUnitの使い方を
間違えているというか解ってないことには
変わりないが。

>>313
TDDはUTだろ？
設計→UT→コーディング→連結TとUTの位置をずらしたものだと思うが

テスト駆動開発は
テストをしながらコーディングを
なんども繰り返すものなのだが。
あのバーの色を何度も赤くしたり緑色にしたりを
繰り返しながらプログラムを完成させてゆく。

>>316
> あのバーの色を何度も赤くしたり緑色にしたり
おかしくないか？テスト設計してないだろ？

TDDってトライ＆エラーみたいなもん？
プロトタイプみたいなもん？

普通はモジュールの仕様としてありえるパターンを先に網羅しとくもんだしな

>>315
UTってユニットテストの事よね？
う〜ん、この単語は結構意味が広いんでどういう文脈で使ってるかによる。

うちの場合、TDDのテストは網羅性を要求されない。
あくまでコーディングする為のテストで、性能や品質を保証する為のテストとは
みなしてない。
そもそも、本格的なテストはテスターさんが書くものでプログラマは書かないと
いうのがうちの開発スタイル。

それじゃあ、TDDのテストを何だと思ってるの？とか問われそうなんで、その
辺をツラツラと書いてみる。

TDDを採用しない場合、先ずはこの前提で以下の話を進める。
とにかく何かをプログラミングする。コンパイルが通ったら即コミット！
プログラマとは、ソースコードを見ただけで正しく動作する事を確信できるものなのだ！
って、そんな奴が居たら絞め殺してやりたくならね？羨ましすぎてｗ

少なくとも俺の様な凡人プログラマにはそんな事はとても無理。
小さなプログラムを書いてみて、正しく動作する事を必ず確認してみる。
そして、大概は正しく動かない＿|￣|○||| ﾅｾﾞﾀﾞ…？
だから、修正しては動作させ、修正しては動作させ、時々２ちゃんで憂さを晴らしたり
しながら苦労して完成まで辿り着く。

ところで、小さなプログラムって？テストコード？てか、テスト？
「TDDを採用しない場合、先ずはこの前提で以下の話を進める。」はずだったのにorz

TDDの最も原始的な部分、スタート地点とも言える部分は各自が無意識にやってた
コーディングスタイルを体系化し文書化したにすぎない。

各自が勝手気ままに書いてた小さなプログラムは十人十色でその使い方も人それ
ぞれで、後でもう一回使おうだとか他の人がこれを必要とするかもしれないという意
識はとても低かった。中にはデバッグ終了後ポイ捨てしてしまう人も普通にいた。
勿体ない！

JUnitに代表されるテストフレームワークは無味乾燥で役目が終わればポイ捨てさ
れる事すらあった小さなプログラム達にリボンを掛けて末永く(できれば創造主以外
からも)可愛がってもらえる様にする為の仕掛け。

TDDのテストとは？誰もが何となく書いてた小さなプログラム。
ただし、リボンと衣装で可愛さ100倍ｗ

まぁ、この辺が基本でしょ？
てか、この辺から入ってかないと、('A`)ﾏﾝﾄﾞｸｾってなってTDD自体に拒否反応
起こしちゃうんだよな。

TDDは目覚しく発展を続けてて、今語った様な基本だけでは収まらなくなってき
てるのも事実だけど、それは基本を学んでから自身で取捨選択すればいい。
土台さえしっかりすれば、上物を自分で選択できる様になる。
土台もないのに上物を欲張ると崩れる。当たり前！

>>318
あんた凄いね。
俺が糞の様な長文で書いた話を、一言で表現しやがった＿|￣|○|||

>>317
レッドフェーズ、グリーンフェーズって
聞いたこと無いか？

>>322
> JUnitに代表されるテストフレームワークは無味乾燥で役目が終わればポイ捨てさ
> れる事すらあった小さなプログラム達にリボンを掛けて末永く(できれば創造主以外
> からも)可愛がってもらえる様にする為の仕掛け。
> TDDのテストとは？誰もが何となく書いてた小さなプログラム。
> ただし、リボンと衣装で可愛さ100倍ｗ

そんな表現は非常に大きな誤解を受ける。
やっても無駄だとという誤解をね。
TDDで開発を進めると、デバッグの負担を減らす効果と、
TDDをやった結果、ソースコードの信頼性が高まり、
コード修正によって起きる弊害を減らす効果があるわけだが。

１．まず実装クラスのソースコードの
スケルトンを書いていく。
　(クラス、メソッドは書くがメソッドの中身は空)

２．メソッドの引数と戻り値が
こうであって欲しいというテストコードをassert系メソッドコールよって書く。
３．スケルトンになっているメソッドにそうなるようにコードを実装してゆく。
４．２に戻る。

初めのうちは単純にこの繰り返しがTDDの基本ととらえておけばいい。

ドカタはゴミを書くからね。

>>326
その部分は説明できたと思ってるんだが・・・・・・
プログラミング時には誰もが動作確認用の小さなプログラムを書いてみる。
TDDのテストとはそれと同一のものだ。って言ってるのに、無駄って反論
は成立しないだろ？
それを無駄だと言うなら、動作確認用の小さなプログラムは書かないって
言ってる事になる。そしてそのプログラミングスタイルはかなり無理がある。

TDDのもう一つの本質は何故テストを先に書くのか？って部分。
この部分がTDDのテストはソースコードの形をした要件定義って話に繋
がっていくんだけど、どうやっても短く纏まらなかった(前回以上の超長文
になるｗ)んで説明を諦めたんだが、どうせつっこむならこっちを頼むｗ

質問の要点が曖昧だったな。
JUnitで「メソッドの中の全ルートを試験出来るのか？」と言うのを聞きたい。

つまり「メソッドの中で他のメソッドの値を判定してログファイルを書くけど、リターン値は正常と同じ。」や
「リソース不足などのシステムエラールートの試験」と言うような物を試験出来るのかと言うことだ。
俺が出来たのはあくまで「サンプリングの入出力試験」。
つまり、入力パラメータの範囲の最小、最大、代表値を入れてリターン値や例外を判定して試験しただけ。

色々な雑誌やサイトを見てみたが、みんなこの程度のレベルのことしかやっていない。
いつも仕事で試験しているレベルに比べると単純に項目数で1/3程度になる上に、
重要な判定文、繰り返し文の全ルート試験が完全でない。
この使い方が間違っているのかも知りたい。

漏れもJUnitでカバレージ100%の試験できるもんなのか知りたい。

あと単体試験でJUnitのような「自動化ツール」に意味があるのかと言う疑問がある。
よく要件が満たされているかのチェックのためと言うが、それは結合試験からの問題だろう。
おそらく昔からの「Unix/Cユーザ」では、結合試験の自動化は当然のように行われていただろう。
画面がなく入出力情報もファイルやDBのみの場合、試験用の入力データと正しく動作した時の
出力ダンプを取っておいて、保守メンテナンスで変更になった場合に、最後の確認として
そのデータを使った試験を行い、出力結果を比較するという物だ。
これの有用性は良く分かっている。ただしメンテナンス用だ。

これにJUnitを使うというならば、それなりの効果があると思うが、なぜ開発途中で修正の可能性の高い
システムの試験自動化を行おうとするのだろうか？

>>330
間違ってない。寧ろTDDのテストをその様な試験と同一視してはいけない。
同一視しようとするとコミットのタイミングが大幅に遅れるし、実装と試験が
直列化するから「人数を進捗へ転換する」という多人数開発の大前提すら
阻害されてしまう。
実装を担当するのはプログラマ、試験を担当するのはテスター。
両者を分ける利点は・・・・・・・ちゃんとした試験を知ってる人には釈迦に説
法かorz

>>330
おまいさんが書かなくちゃいかんだろ。
JUnitはテストプログラムを蹴飛ばすだけだよ。
たとえばＤＢに書き込んだ値を検証するなら、プログラム実行後
ＤＢを読み込んでその値と調べないといかん。ＤＢ系だと初期テーブル
データと期待値データを用意しないとな。まぁdbunitというものがあるけど。

たまに、JUnitつかってるのに、検証値をログに出して目でチェックしてたＪａｖａ厨がいるけど。
そんなタコはふつうにメインでやっとけ、同じことだ。
完全自動テストまで仕込まないとJUnitは意味ないな。

>>329
なぜ長文で説明することを躊躇う。
一部の2chを単なる煽り程度だけにしか使いたくない
人間が長文を嫌って煽ってなんとかして長文を
欠かせないような風潮を必死に与えようとしているだけだろう。
そんな煽りは無視しろ。

>>330
> 質問の要点が曖昧だったな。
> JUnitで「メソッドの中の全ルートを試験出来るのか？」と言うのを聞きたい。
JUnitだけだと入力と出力のみ程度になるわな。
インスタンスメソッドで有ればオブジェクトの状態がどう変わったかを
assert系()で確認できる。

メソッドの内部の細かいところまでどうしてもテストしたかったら
メソッドを分割統治することも視野にいれておくといいかもしれない。
分割統治すればその分のテストできない部分のテストもできるようになる。
それも限界があるならデバッガに頼る。

>>335
物事には限度というものがあるｗ
会話ではなく演説したいだけならブログに書いてリンク貼れって話になってしまう。

>>332
> あと単体試験でJUnitのような「自動化ツール」に意味があるのかと言う疑問がある。
> よく要件が満たされているかのチェックのためと言うが、それは結合試験からの問題だろう。
> おそらく昔からの「Unix/Cユーザ」では、結合試験の自動化は当然のように行われていただろう。
> 画面がなく入出力情報もファイルやDBのみの場合、試験用の入力データと正しく動作した時の

直接は関係ないかも知れないが、
JUnitをベースとしたDBUnitというテストツールがあるぞ。
INSERTやSELECTなどのテストができる。
ファイルの場合、ファイルから取り出す部分は自分でテストケースの中に書く。
JUnitに仕様するテスト用試験データを外部においてテストできる
ツールまたはEclipseのプラグインなんてものもあったと思うが。
Mycomの記事を検索すればでてくるかもしれない。つい最近のモノで。

>>331
どんなテストも100%は無理じゃねえかな。

>>332
修正の可能性が高いからこそ自動化するんじゃないか？
て言っても、JUnitのテストは厳密な試験じゃないし、単なるテストスイートの
一括実行という以上の意味はないが・・・・・・

厳密でないテストに何の意味があるのか？と問われそうだが、それならどう
せ書く動作確認用の小さなプログラムをテストとして有効利用する(それは単
にビルド可能か否かというよりは詳細な情報をプログラマに与えてくれる)事
に何の問題があるのか？と逆に問いたい。

>>334
> >>330
> おまいさんが書かなくちゃいかんだろ。
> JUnitはテストプログラムを蹴飛ばすだけだよ。
> たとえばＤＢに書き込んだ値を検証するなら、プログラム実行後
> ＤＢを読み込んでその値と調べないといかん。ＤＢ系だと初期テーブル

もう一度いうが、DBUnitというテストツールがある。
それからServletのテストをするにはCactusというテストツールを使う。

それから面倒くさがり屋にはJUnitと合わせて
テストに使用するMockObjectもお勧めだ。
オブジェクトなどデータを偽装できる。こいつを使ってJUnitでテストする。
Cacuts使うのが面倒くさいと言う香具師にもお勧めだったりする。

> データと期待値データを用意しないとな。まぁdbunitというものがあるけど。
データの用意を別ファイルに記述できるテストツールもある。
もちろんJUnit専用で。Eclipseのプラグインだったと思った。
まさにDBUnit、それだ。使え。

> たまに、JUnitつかってるのに、検証値をログに出して目でチェックしてたＪａｖａ厨がいるけど。
> そんなタコはふつうにメインでやっとけ、同じことだ。


まてまてテストコードと実装コードを分離するだけでも結構重要。
テスト用main()まで実装コードに含むのはどうかと。
テストするときログも重要なわけだが。それはまた別のテストにはなるが
同時にやっておけばネットワークが関与するテストでも困りにくい。


> 完全自動テストまで仕込まないとJUnitは意味ないな。
完全に自動テストするならJUnitだけでは足りないぞ。
どんな環境かにもよるが。

>>337
> >>335
> 物事には限度というものがあるｗ
> 会話ではなく演説したいだけならブログに書いてリンク貼れって話になってしまう。

2chはチャット(会話式システム)ではない。掲示板だ。
文句をいわないこと。

>>334
> >>330
> おまいさんが書かなくちゃいかんだろ。
> JUnitはテストプログラムを蹴飛ばすだけだよ。
たんにお前がJUnitを必死に蹴飛ばそうとしてるだけのバブル世代の糞低脳C言語厨の
オッサンに見えるのだが。

>>340
> >>332
> 修正の可能性が高いからこそ自動化するんじゃないか？
> て言っても、JUnitのテストは厳密な試験じゃないし、単なるテストスイートの
> 一括実行という以上の意味はないが・・・・・・
> 厳密でないテストに何の意味があるのか？と問われそうだが、それならどう
> せ書く動作確認用の小さなプログラムをテストとして有効利用する(それは単
> にビルド可能か否かというよりは詳細な情報をプログラマに与えてくれる)事
> に何の問題があるのか？と逆に問いたい。

問題があると思ってる奴は、多分、JUnitによって
暴かれるバグを隠すことに抵抗しているんだよ。
JUnitを使うと、
わざとバグを書いてソースコードをわかりにくくするという手が
通じなくなる。誤魔化しもきかなくなる。それを恐れている
わざとJUnitを否定しようとしているんだよ。

JUnitってツールは、洋裁でいえば型紙やしつけぬいみたいなもんだと思うんだが、
かれらは型紙やしつけ縫い無しでいきなりはさみで布を切ろうとするんだろう。
職人みたいな人間がそういうものを嫌うわけだ。

> たまに、JUnitつかってるのに、検証値をログに出して目でチェックしてたＪａｖａ厨がいるけど。
> そんなタコはふつうにメインでやっとけ、同じことだ。

そんな奴はC言語注だろうとだれでもいる。Javaに特化していうのは
こいつはよほどJava嫌いなJavaを目の敵にするアホと見た。

テストコードそのものが真であると証明するためのテスティングツールってある？

それより要求定義の妥当性をチェックするツールをくれ。

>>348
JUnitの質問をしたのはお前による自作自演か？
そんなツールはお前の脳みその中にある。

>>347
それは愚問だ。
ナイフでナイフを斬るにはどうすればいいんですか？
と聞いてるようなものだ。

>>347
アジャイルとか何とか言ってる連中は、「テストコード＝仕様」と言う
香具師もいたような。
それはそれで筋が通ってると思う。機械可読なプログラミング言語のほうが、
自然言語やポンチ絵なんぞよりはるかに厳密に仕様は定義できるだろうし。

>>もう一度いうが、DBUnitというテストツールがある。
だから、漏れはあらゆる検証パターンをテストメソッドに仕込め、
ＤＢ系に関してはdbunitがあるよん、という意味なのだが、おまいら熱いな。

JUnitの目的は起動一発でオールプログラムの自動検証だよね。
３００テストのオールグリーンが壮観ではあるな。さて仕事しよ。

それじゃまさしくｺｰﾀﾞ

>>352

> JUnitの目的は起動一発でオールプログラムの自動検証だよね。

やっぱりお前浅はかだ。お前みたいなのがチームリーダーだったり
上司だったりする会社は最悪だな。社内で会社の癌だとか言われたりしない？

次スレはこちらでよろ〜

Javaが遅いという奴は遅れたバブル世代じゃね？　２
http://pc8.2ch.net/test/read.cgi/prog/1143560237/


このスレが終わったらあっちのバブルスレに以降しよう

>>347
JUnitのテストの為にJunitを使うのさ。
で無限ループ。
まぁ、テストメソッドもデバックが必要だしな。
本体の実装コードより数十倍の規模になる。

リーダがテストはJUnitを採用するぞ、と言う場合は
その工数は見積もってますよね、とすかさず質問さ。

で、仕様変更があった場合には、テストデータとか
微妙に変わるから赤になるし。

まあ、アホコーダにまともなコードを組ませるためには不可欠だよ。
まかせとくとゴミ作るからね。

つまり、ファイルやDBをダンプしたり、標準クラスの替わりになるスタブやドライバを作ったり、
他のツールを組み合わせたりして、カバーしろと言うことだな。
もう俺の言いたいことを言っている人もいるが、
・そのスタブやドライバのテストはどうするのか。
　これにはJUnitでやると答えている人がいるが、次に問題になるのは、
・いったいどれだけテストコードを書かなければならないのか。
と言う事になる。
実際、JUnitだけでサンプリング入出力試験をやるだけでも規模は3倍になる。
さらにスタブや他のツールを組み合わせたりすると、すごい規模になる。

本来なら「全ルートの試験項目書」を書いて「デバッカを使ってステップトレース」で済む試験のために、
母体の数倍となる試験コードを書いて、それも一緒にメンテナンスしていかなければならなくなる。
本当にこんな物を「素晴らしい」と言うのか？

ドカタだから仕方ないな

assertじゃ駄目なの？

小さな仕様変更とか機能追加があったとき、仕様通りの動きをチェックするテストケースは非常に役立つと思う。
他の機能に影響が出てないか流すだけで分かるし、
機能追加で色々とデータを追加したりしないといけない場合は、設計が既存のシステムに影響が出ないように考えられてないんじゃないかな。

大きな仕様の変更があるときは作り直したほうが楽だったりもする。
テストコードをメンテナンスするって考えてる間は、テストツールに振り回されてるだけなんじゃないかね。

「同じような処理があるから」って画面ごとのクラスで似通ったところをコピペし違うところを追加していくような人がいるけど、
その人のテストコードは無駄に初期化が長くなったり、パラメータ一つ追加しただけで全てのテストケースを修正したりと大変。

俺が作るときにテストを考慮しすぎてるってのもあるかもしれないけど、
テストコードの修正が仕様の変更の量と見合ってなければ、作り方がおかしいんだって思ったほうがいいんじゃないかな。

>>356
> >>347
> JUnitのテストの為にJunitを使うのさ。
> で無限ループ。
おまえ、ケントベックとエリックガンマが設計した
テストツールを否定するか。
JUnitが正しいかどうかは各種assertメソッドの
動きで判断すればいいだけじゃねえかと。

>>357
JUnit否定派というか使いたくないで逃げたい派の
必死な煽り乙
おまえみたいなアホを矯正治療するにもJUnitはもってこいだ

ロジカルなバグは回避できないのが理解できないJava厨さん。
毎日が正月気分。

Unitテストは振る舞いの定義。
メソッド単位で INとOUTを検証して、
定義通りの振る舞いをしているか否かを
確認するためのもんだろ？

個人的には、UnitTestが実用的な範囲は、
共通関数や共通モジュールの挙動確認レベルだと思うが。

>>358
過剰テストしそうな香具師だな。
そういうとろまで無理してJUnitを使うことはないだろう。
だがメソッドのテストくらいはやっておき。

>>364
意味がわからんがそんなことができないのはJava厨であってJavaエンジニアでは
ないということだな。いずれにせよこのスレにはJava厨と呼ばれる者は一人もいないがな。

あれ。このスレって自称優秀なJava屋さんのホームグラウンドになったの？ｗ

>>358
> つまり、ファイルやDBをダンプしたり、標準クラスの替わりになるスタブやドライバを作ったり、
DBについてはDBUnitでいいとして
スタブはMockObjectとしてテスト用に自作するものだ。
ドライバがJDBCドライバでJava製ならJUnitだけでテストできないことはない。
ドライバまで一から作るよりもドライバが接するメソッドの入出力テストをしたほうが
いいと思うが。ドライバまでいちいち作っていては過剰テスト。
どうしてもドライバまでたっぷり時間をかけてテスト用に作らないとしたらどこかドライバ呼び出しの
設計に問題があるかもしれないことを疑ってみてもいいだろう。


> 実際、JUnitだけでサンプリング入出力試験をやるだけでも規模は3倍になる。
> さらにスタブや他のツールを組み合わせたりすると、すごい規模になる。
> 本来なら「全ルートの試験項目書」を書いて「デバッカを使ってステップトレース」で済む試験のために、
> 母体の数倍となる試験コードを書いて、それも一緒にメンテナンスしていかなければならなくなる。
> 本当にこんな物を「素晴らしい」と言うのか？

そこでJUnitを否定し使用禁止にするには説得力語り無いな。
「逃げ」と見なされる。会社によっては某N社だが、JUnitを使ってテストしろなんて
言いだすところがある。そこでJUnitは使っても意味がないといっても通じない。
彼らはJUnitを使ってどういうテスト結果が欲しかったのか具体的には言わなかったが。
JUnitを使いこなすには訓練が必要だ。さもないとあんたみたいに過剰テストに拘るようになる。
一度null判定テストしたメソッドを通っているのに、そのメソッドの中にさらにnull判定した変数を
引数に入れて動かすメソッドについてもさらにnull判定テストするなんて無駄に二重テストを
しているに過ぎない。過剰テストにならないようにする工夫も必要だ。

もはやJavaの速度話ではなくなったな。

>>358
> つまり、ファイルやDBをダンプしたり、標準クラスの替わりになるスタブやドライバを作ったり、
> 他のツールを組み合わせたりして、カバーしろと言うことだな。
> もう俺の言いたいことを言っている人もいるが、
> ・そのスタブやドライバのテストはどうするのか。
> 　これにはJUnitでやると答えている人がいるが、次に問題になるのは、
> ・いったいどれだけテストコードを書かなければならないのか。
> と言う事になる。

そもそも。JUnitというのはメソッドがこう動いて欲しいという道しるべみたいなのだと
思った方が良い。その道しるべに反したらテストに失敗したと。
それによってバグを大幅に減らすことができる。
さらに機能追加によってコードを修正したことによってメソッドの性質が変わって
しまうことも防ぐ。修正するとメソッドが間違いを出してきたら、何が
いけなかったのかすぐにわかる。だからテストファーストの恩恵は非常にでかいんだよ。
精神的にも自信がつくし、それだけでなくコードを追加修正するときの手戻りも少なくなる。

> 実際、JUnitだけでサンプリング入出力試験をやるだけでも規模は3倍になる。
> さらにスタブや他のツールを組み合わせたりすると、すごい規模になる。

上にも誰かが書いているようにテストデータを別ファイルに置いて
JUnitでテストできるツールが既にある。ぐぐってみ。

> 本来なら「全ルートの試験項目書」を書いて「デバッカを使ってステップトレース」で済む試験のために、
> 母体の数倍となる試験コードを書いて、それも一緒にメンテナンスしていかなければならなくなる。

そこまでやるなら自動化についても見当にいれたほうがいい。
XDocletなど使ってな。

どうしても>>358がやりたいテストを
JUnitで行うとしたら
Javaプログラム側で例外処理を
しっかりと記述して、例外クラスも自作して
しっかりとthrowやthrowsを使って
JUnit側で例外処理のテストを書くことだな。

Fileが見つからないときはFileNotFoundExceptionを
投げて貰うようにするとか。

xUnit系はあくまで詳細設計レベルに対応するテスト用だろう。
要件設計レベルに対応するテストは別に用意する必要がある。

あとDBUnitがあれば解決するかもしれないが、DBアクセス部のモジュール試験には、JUnitじゃテストコード自体とDBデータを別々に管理しないといけないという面倒がある。テスト用DBとか別に作ってデータを固定にしといてもいろいろ他の面倒もある。

あと、GUIの試験では、現状JUnitは対応してたっけ？

アジャイルでの総合試験の位置づけとかどうなってるのかまだちょっとわからないところがある。JUnitだけでは完璧に満たされないと思うのだが。

>>372
＞DBアクセス部のモジュール試験
先に出ているMockObject系のツール使いましょう。

＞あと、GUIの試験では、現状JUnitは対応してたっけ？
JUnit不可。jfcunit（ちと古い）とかMarathonとかJakareto, Abbotとか。単に入力繰り返すだけのもあるので注意。

＞アジャイルでの総合試験の位置づけとかどうなってるのかまだちょっとわからないところがある。
＞JUnitだけでは完璧に満たされないと思うのだが。
もっと勉強汁。ツールとしてはFit, Fitnessあたりを調べてください。。

Jakarta Cactusは統合テストができるんでなかったっけ？

うわぁ！
Javaのコードのような回りくどい長文の嵐だ

>>369が書くコードって君が大好きな長文と同じ論理構造なんだろうなあと
予測する。

ＶＢやろうぜ！

重いと言うか、他にもサーバサイドで使われる言語は数あれど、Javaだけ際立って必須メモリが
多いってことかな。

それでも使われるJava
まあ理解できないならVBでも使っとけよ

JUnitプラグインが視覚的に「緑のバー」を出すのも怪しい。
テストケースの網羅性が保証されている訳ではないのに、あたかもちゃんと試験しているように見える。
実際、数値の入力値で1〜300を取り得るメソッドの試験に、1〜300までのケースを作って、
「試験項目書300件作成しました」などと言う奴も存在する。
またリターン値がOKとNGの2種類しかないので、1ステップのメソッドも100ステップのメソッドも、
「テストケースは2つです」と言う奴も存在する。
真面目な人は「分岐、ループの全ルートは試験しているか」と聞かれて、正直にスタブやドライバを
大量に作成して数倍の時間を費やしたりする。

はっきり言ってJUnitでの試験は「試験をやっていると言うアピールだけ」である。
大手ベンダーでも「流行り物好きPL」の方針で使うことはあるが、こんな物で品質は確保されない。

最近はPHPが増えてきたぞ。

>>380
自作自演乙。

必死で反論してくるjava厨ｶﾜｲｽ

>>381
ソースは？

>>380
あのさ。例に挙げてるのって、馬鹿はどんなことするかってことでしょ。
確かにホワイトボックステストのツールであるJUnitでブラックボックステストする馬鹿は絶えない。
けど、だからと言ってJUnitによる試験がどうこうって結論に結びつかないんだけど。

JUnitの有用な所は

・バグが発生したときにその部分の正しい挙動を検証する為の
　テストケースを書いてからそれがグリーンになるように修正する
・時間が無くて糞コードを書いてしまってた部分をりファクタリングするときのガイド

の2点だと思うんだがどうよ。

もっとも、これを満たそうとするとテストがしやすいクラス設計をしないといけないという
少々本末転倒な状況を受け入れなければならない。
つまり、テストが要求機能よりも実装方式に強制力を持つようになる。
これがテスト駆動開発。

人によっては「たりぃ」って思うだろうな。漏れもたりぃ。
何？DBUnitって。テストデータ作るの糞めんどくさいんですけど？
XMLで作るの？ふざけんな。って思ったりする。

て言うか、意図的なループは有名な荒らし技だから反応しないのが吉。
話題を変えたい時に使うと効果的だから覚えとけｗ

>>380
開発者自身の保身のためのテストであって、テストケースの結果でプログラムの質とかを問うのは間違ってるな。
jcoverage流して100%全て通ってます！みたいな事をやってたこともあるが、
全部通すために無駄なテスト入れたり、間違ってても通ればOKみたいな感じで酷かった。
（言語仕様レベルで間違ってる場合は、どうやってもif分岐に入らないとかで発見することは出来たが）

100%通ってエラーなくてもシステムとしてバグが出れば、作った人間が非難されるのは普通なんじゃね？
「テストケースでOKだったので大丈夫だと思ってました」なんて言ってるなら、再教育するか使わなくすればいい

>>375
君にはソフトウェア開発は向いていないよ。
せいぜい組み込み系で汚いコードを書いているのがお似合いだね。

>>380
> JUnitプラグインが視覚的に「緑のバー」を出すのも怪しい。
そりゃ作られたテストケースの品質によるからな。

> テストケースの網羅性が保証されている訳ではないのに、あたかもちゃんと試験しているように見える。
> 実際、数値の入力値で1〜300を取り得るメソッドの試験に、1〜300までのケースを作って、
> 「試験項目書300件作成しました」などと言う奴も存在する。

ソースコードを見ないで騙された、JUnitがどういうものか
解らない奴が悪いわけだが。
こういうときこそSOX法の力を借りたい。

顧客はテスト用ソースコードも見ないといけないんだよ。
N社のバカはソースコードを読む能力が弱いみたいだが。
だからそんな誤魔化しが起きる。N社はJUnitというものがどういうものか
見事にわかっていなかったわけだが。

N社はJUnitでソースコードの行数に応じた割合で
適当にテスト項目を作ってそのうち2割はわざと失敗させろだからな。
N社にとってのテストとは所詮おまじないにすぎないわけだ。
バカ組織の指示でプロジェクトにJUnitを使わせてもJUnitの真価が発揮されないとはまさにこのことだな。

> 真面目な人は「分岐、ループの全ルートは試験しているか」と聞かれて、正直にスタブやドライバを
> 大量に作成して数倍の時間を費やしたりする。

それもどうかと思うが。同じモノを作って過剰に試験を行ってないか疑わしいものだ。

> はっきり言ってJUnitでの試験は「試験をやっていると言うアピールだけ」である。
いや、バカにJUnitを使わせようとしたお前の会社のレベルが低いだけだよ。
無知ばかりが集まってる組織にJUnitを使わせると「試験をやっていると言うアピールだけ」
しかできないだけだ。

> 大手ベンダーでも「流行り物好きPL」の方針で使うことはあるが、こんな物で品質は確保されない。
その大手企業の室が低いんだよ。日本の大手企業はどこもソフトウェア管理品質レベルが低いみたいだがな。

>>378
それだったらJavaは重たくないということだな。
組み込み機器のメモリ容量が増えれば軽くなっていくと。

>>376
君は知っているか？　
JUnitではコードをわざと冗長に書いて
どんなテストをしているかわかりやすく書く必要があるということを。
テストケースでは通常は嫌われているハードコーディングやマジックナンバー
が推奨されている。
そのかわりforやwhileなどのループを使うこともお勧めしていない。
だからかなり冗長に見えて長文に見える。
だが何のテストをやっているのかほぼ人目でわかる。

>>381
最近では、業界も、
ちっちゃな仕事ではPHP、でかい仕事ではJavaという
勢力に二分されているようだね。

PHPでもPHPUnit, PHPUnit2というテスティングフレームワークが
出ているね。
使い方はJUnitとほぼ一緒でブラウザにテスト結果を表示できるのが
面白いね。

>>383
必死で反論しているのはC言語厨だよ。

>>387
> て言うか、意図的なループは有名な荒らし技だから反応しないのが吉。
厨の短文によるしつこいレスかね？

> 話題を変えたい時に使うと効果的だから覚えとけｗ
何が効果的なんだ？　言いたいことがよくわからないので
もっと詳しく

>>388
> >>380
> 開発者自身の保身のためのテストであって、
JUnitを間違った使い方をするとそうなる。

> jcoverage流して100%全て通ってます！みたいな事をやってたこともあるが、
> 全部通すために無駄なテスト入れたり、間違ってても通ればOKみたいな感じで酷かった。
だからこそ、テストではテスト用コードもわかりやすくそこだけでは
わざと意図的にハードコーディングを行うのだ。

> （言語仕様レベルで間違ってる場合は、どうやってもif分岐に入らないとかで発見することは出来たが）
> 100%通ってエラーなくてもシステムとしてバグが出れば、作った人間が非難されるのは普通なんじゃね？
> 「テストケースでOKだったので大丈夫だと思ってました」なんて言ってるなら、再教育するか使わなくすればいい
JUnitを使わなくすればいいというのもどうかと思うが。
替わりになるツールで補うのでもなければ。

>>386
その2点は確かにでかい。

ほかに拡張性を高める効果もある。

依存関係にあるクラスを新たに追加したとき
依存元クラスの信頼性をJUnitで確認できるという利点。
依存元はすでにテストで信頼性が高まっている。

>>397
すまん、最後の使わなくってのはテストツールじゃなくて技術者

Javaはオープンソースによる無償のフレームワーク、ツールが充実しており、
最先端の開発手法を適用するのも容易です。
最近のシステム開発のキーワードはスピード。
刻々と変化する市場に合わせて迅速に開発・展開し、変更と拡張を加えることが出来るJavaで
システムを構築することこそ、顧客のニーズに応え選ばれる企業となる条件と言えるでしょう。

>>刻々と変化する市場に合わせて迅速に開発・展開し、変更と拡張を加えることが出来るJava
大企業の社員さんが言いそうですね。（そんな感じのプレゼンでもしてるのかな）
大企業の社員さんは実際にJava使わんもんな。
迅速に開発・展開し、変更と拡張を加える能力はJavaとは関係ないよ。
できない奴はJava使ってもできない。

ほんと、プレゼンみたいだね>>400って。
言ってることは立派だけど、実践できるの？って思う。
でもって、実践できるレベルの会社なら、たいていJavaである必要はないわけで。

最新のツールがあってもそれを使いこなせるようになるのに
時間が掛かるのでとても迅速に開発や変更はできないよ。

繰り返し使うことで習熟度が上がるって考えがすっぱり抜け落ちてる罠。

ここにいらっしゃる優秀なるJavaマンに聞きたいのですが
javaのbyte型ってunsignedなの？

またウジムシがあつまってきた。
しっし

一番疑問なのが「JUnit万歳」な奴が、単体試験の試験項目表の書き方すら知らない事が多いと言う事だ。
「単体試験の内容が曖昧」、「JUnitがダメなら何のツールを使うのか？」、
「開発者の自主性に任せる」、「単体試験項目表って何ですか？」、「全ルートなんて出来ないよ」
などと言っている人には単体試験を分かっていない人が多い。

確かに学校では教えないし、雑誌の特集になるような事もない地味な内容だ。
しかし大手のベンダーなら必ず「単体試験の内容を詳しく定めた資料」がある。
ただ大手の社員でも全員が実践している訳ではない。
多いパターンとしては新人の時に1回は見るのだが、内容が理解出来ずに自己流でやってしまい、
その人が先輩になって教えるので、内容が統一されず曖昧なまま広まってしまうなど。
他にも単体試験は学校で教えないため、先輩から「単体試験をやれ」と言われた新人が雑誌で調べるが、
たまたま特集していた「JUnit」を見つけてそれが単体試験の全てだと思ってしまう例もある。
また、記述されている内容が「全てを網羅出来るように書かれている」ため、そのシステムに該当しない
パターン（ファイルを使用していないシステムでのファイルの妥当性試験など）が多く、
全てが形式的な物だと勘違いして、実施しなくなってしまった例もある。
中堅の企業でも試験項目表すら使い回していた「コボラー」が上司になって、試験項目表を使い回せとか、
C言語やJavaとCOBOLのモジュール単位の違い理解出来ないため、結合試験を単体試験と区別出来ない
人もいた。
またベンチャーでは単体試験を実施しない所すらある。

>>401
> 大企業の社員さんは実際にJava使わんもんな。

は？　使っているが。使っていないという根拠が示せるなら示してみてくれ。


> 迅速に開発・展開し、変更と拡張を加える能力はJavaとは関係ないよ。
大規模開発ではJavaのほうがほかの言語よりも開発効率が高まる可能性が高いことは
今のところ、ほとんど否定できないだろう。

> できない奴はJava使ってもできない。

そりゃそうだ。

>>407
JUnitですら学校では教えないだろ。

>>407
> 一番疑問なのが「JUnit万歳」な奴が、単体試験の試験項目表の書き方すら知らない事が多いと言う事だ。

その一社の独自フォーマットの試験項目表の書き方を覚えたところで
他社に転職してからその書き方で通用するか？　なんだがね。

>>405
これをよく見ろ

定数フィールド値 (Java 2 Platform SE 5.0)
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/constant-values.html#java.lang.Byte.MIN_VALUE

単体試験が良く分からない人は、大手の社員なら「単体試験実施要項」を確認して欲しい。
自社に資料がない人でも大手と仕事をする事はあるだろうから、
「参考までに単体試験実施要項を見せてくれ」と言えば多くの場合は見せてもらえるだろう。
しかし社外秘になっている事も多い。
ただ、新人が見ても理解するのは難しいかもしれない。2、3年やって慣れて来た頃が望ましい。
また全部を行う必要はない。どれが必要かを判断するのは注意がいるが、2、3年やっていれば分かるだろう。
詳しいことは書けないが、例えばN社では大きく分けて、正常系で3種、異常系で4種類の大項目があった。
N社のあるプロジェクトではそのうち3種が必須で、残りは場合によって任意で行っていた。
ちなみにJUnitではこのうちの1種しかできない。

つまりJUnitがどうのと言う前に、基本をマスターしろと言う事だ。
雑誌やWEBサイトで調べる前に、自社の「単体試験実施要項」を勉強しろ。

http://sjc-p.obx21.com/word/jk/primitivedatatype.html#main
>>411 どうもです。
byte型は符号付なんですね。暗号化とかビットシフト操作は
byteではすんなりとできないJavaでいいですね。

テスト・試験・品管のノウハウを持ってる奴はかなりのツワモノ。
PDCを回すって意味のわからないドカタの多いこと多いこと。

ドカタは回される立場だから。
回すってのはPLの立場。

フォーマットなんてのは表現形態にすぎないよ。
試験に必要な概念はどこも一緒。
理解できていればフォーマットの相違なんざ標準に目を通すだけで大丈夫。

単体試験のテストコードを書くのって無駄

>>412
そのN社がJUnitを使ってあれこれテストしろと言ってくるわけだが。
JUnitのこともろくにわからないくせにね。

しかも非常に時代遅れで古臭いと思ったのは今だに
ソースコードの行数だけで工数を計ること。これじゃ
int a, b, c, d, e, f;
と書くと工数1だが

int a;
int b;
int c;
int d;
int e;
int f;
と書くと工数6も達成したことになる。
しかもこれらの変数が一回も使われて無くても計算される。
一切使われていない変数だろうとメソッドであろうと計算される。

これがN社に実態だよ。
そんないい加減な会社がテストについて偉そうに語るのは数兆年いや数京年いや数無量大数年早いね。

>418
>数兆年いや数京年いや数無量大数年

おまいは小学生かっｗｗ

じゃ、

10の無量大数乗年

無量大数の無量大数乗年のほうがもっとでかい

無量大数の無量大数の無量大数乗乗年のほうがもっとでかい。

俺は不可思議の方が好きだ。

COSMOSのスポンサーだった日本ＩＢＭのＣＭが思い出される

だれかキャプって、ないよな

ttp://science4.2ch.net/test/read.cgi/sky/987778547/243

スレ違い、ｺﾞﾒｿ

ちなみに7項目のうち3項目がどうのというのは、NE○ではなくNT○の事である。
しかしNE○にも他の大手ベンダーも同様の物がある。ただ私の知っている限りではNT○が一番厳しい。
また実際に「JUnitを知らないまま使ってみる」事を行う大手も多い。
例に挙げた通り、大手社員でも試験を理解しないまま中堅になっている所も多い。
しかし大手には出来る社員や優秀なプロジェクトチームが多いのも確かだ。
ただ私の経験から言うと、均等に存在する訳ではなく、固まっている場合が多い。
あなたのプロジェクトがそうだからと言って、その会社の全てのプロジェクトがダメだと判断するのは早計だ。

また、ステップ数の計測方法に疑問を持っているようだが、それが何に使われて、
その中で重要な事は何かを理解して言っているのだろうか？
「冗長に書いた方が、たくさん仕事をしているように思われるのでずるい」と言うレベルなら、
試験管理を勉強し直した方がいい。
ステップ数は他のチームと比べて優越感を得るためにある訳ではなく、多くの場合は
「試験密度」「試験進捗率」「バグ収束率」を見るための指標として使われる。
ただし、これを理解せずに形式ばかり残っている所が多いのも確かだ。

スレ違い甚だしいが、なかなかためになる
そのへんまとめた本とかねーもんかな？

ちなみにうちの会社にはちゃんとした試験実施要項なんてなかった！

おいおい、いくら強がっても
Javaそのものの多大なバグをどう解決するんだよｗ
だれかなおすまでﾏﾂﾏﾂ厨きめこむのか

Javaそのものは誤解があるな。
糞プラグインのパグに訂正。

Javaが悪いわけじゃない。

JSP&Servlet以外は糞

>>426
>「試験密度」「試験進捗率」「バグ収束率」

このへんに絡んで、ステップ数からバグ件数を想定していることがあるんだよな。
俺は、あれは全く当てにならん気がするんだが。
コードを同じ行数書いたからって、書いた香具師のレベルが違えば、
出るバグの件数も内容も全く違う傾向を示すだろ？
それなのに、ステップ数とバグ件数だけに着目して、
「この行数あればバグはこれくらい出るはずだから、
　バグが少ないのはテスト出来てない証拠だ」とかごねるバカが居るわけさ。
そりゃ、統計的にはそうかもしれんけど、それはあくまで統計値であって、
全てのシーンでそれが適用できるかと言えば、そんなこと無いわけだ。
一方、糞みたいなバグが大量に出て、ひーこら言ってる連中は、
ステップ数あたりのバグ件数を満たしているとかいってテスト出来ていることになっていたりする。
ちょっとまてと。あいつらは単体テストレベルで滞っているだけじゃねーかと。
こう言うのを目にすると、もうステップ数とかアホかって気になるぞ。

>>また実際に「JUnitを知らないまま使ってみる」事を行う大手も多い。
大手は気の向くままに言うだけだからな。
JUnitはテストそのものは提供しない訳だし、
まともなプログラマならJUnit使わずとも、テストコードを書くだうし。

でも、いるんだよな、テストコードなんて「無い」というJava厨が、たまに。
本人は完璧なコードだと思ってるらしいんだが、漏れにには理解できない精神世界だ。

俺もステップあたりのバグ検出って苦手。
他人の倍速で完成させたとしても、他人の半分のバグもでない。
まぁ処理が明解に分かってるからこその早さなんだけど。

>>395
どこが？

つうか業務システムのバグなんてみてすぐに分かるようなものばかりだろう。
みてすぐ分かるようなバグは実装時に気をつければほとんど無くなる。
なのになんでテストツールで大騒ぎするんだ。1/M 3万行とか担当できる
能力があるのならば分からないでもないが、どうせ1/M 1000行ぐらいしか
書けない能力なんだろ。
コードを見てすくなくとも自分の担当の全体を理解できない人はやめたほうが良い。

>432
プログラマによってテスト前の品質が違うのは当然だし、新規か改造か、または安定した技術か新技術かに
よって品質が違うのも当然だ。各社の算出方法の中にはプログラマの習熟度の係数があったり、
内容によって係数を変えたりする物もあるが、あまりに複雑になったり、客観的でなくなるので良くない。
一番いいのはその個人やチーム内で集計して個別に判断する事だ。
重ねて言うが、あくまでも他人や他チームと比較する物ではないのである。
確かにそれを理解せずに「ここはバグが残っている」と言う超能力者は多い。
そういう奴がいたら「あなたは試験管理を理解しているのか？」と聞いてみるといい。
ただ営業的に数字を合わせなければいけばい場合があるので、その場合は営業をいじめずに協力してやってくれ。

またバグが多く出ている所はそれこそがバグ傾向解析の出番だ。
バグ収束率とはまた話は違うが、これは出ているバグの内容から「原因」特定する作業だ。
これもよく理解していない人が多い。
「○○処理のバグが多いですね気をつけましょう。」
で終わりなどと言うのも多い。
場合によって違う時もあるが、基本的にこれはバグ発生箇所から、
「バグを多く出している個人を割り出して、そいつの担当分を全部他の奴にチェックさせるための解析」
なのである。人権保護家は個人を特定するのを嫌うが、習熟度が個人により違うのは当然だ。
しかし、その個人を辞めさせろとか給料下げろとか言っている訳ではない。
ちゃんと教育すればいいだけだ。

あと、自社に単体試験実施要項がない場合は作れ。
N社と取引があるなら参考にして見るのもいいだろう。全部取り入れる必要はない。
これでまともな会社の仲間入りだ。

jarファイルの扱いで日本語ファイル名が化けるというバグが
いつまで経っても直らないのだがｗ

そもそもこれだけバグとテストに神経質になるということは
Java厨軍団全体の技術品質が最低レベルだと言う事でいいのかな？

ということにしたいのですね？

>>426
じゃ、おまえは
public abstract class Test {
　public abstract doMethod();
}

これも3行とみなすのわけか。


NTTも胡散臭いんだな。
あっちはNECよりも頭が堅い

>>426
JUnitでスタブなどのテストする方法を知りたければ
「JUnit イン　アクション」を嫁。
お前が疑問に思っている答えはほぼ載っている。

>>439
大手企業の社内の年長者のレベルが低すぎるんだよ。
Javaのことをよくわかってないバカが大杉。
頭の中は30年前と変わってないバカどもっていうか。
管理を厳しくすればバグは少なくなるだろうなんて
アホな思いこみをして過剰な管理体制で無駄にコストをかける。
連中どもには自動化をうまくつかえと言いたい。

>>441
どう見ても３行なのだが。

中身も無いのに3行とみなすのか？
おかしいだろ
0行に等しいだろ

for'(int i = 0; i > 10; i++){
　//iを使って10回何か処理
}

とforを使わずに同じ事を10行書いたら
10行とみなされてforを使った場合は3行と
見なされる。

それもおかしい。糞いい加減じゃねえか。

こんなんで作業量きめつけられたらたまったもんじゃない。

>>445
中身がない？
おまえは抽象クラスを書くことに理由がないのか？
理由もなく抽象クラスを書くのか？


俺釣られた？

テストにおける対象ライン数と
作業量をはかるライン数は話が別だろ。

インタフェースや抽象クラスでコードのコピペやそれによるバグの発生を防げるのなら、3行以上で数えてもいい感じだ。

統計量の扱い方を知らないだけだな

あくまで指標であって絶対的ではないのに

>>448
釣られますた、釣られますた、釣られますた、釣られますた、釣られますた。ﾀﾌﾞﾝ

４４５がリアルで居たらおもしろっす。ｼﾈﾖ

http://developers.sun.com/img/home/shannon.jpg
↑java厨はこんな顔ばっかり

という訳で「JUnitはクソ」だと言う事は理解していただけたと思う。
これで、「EJB」「O/Rマッピング」「JUnit」のクソが証明された訳だ。
次は何をやる？
「WEBサービス」か「UML」かな？

とりあえず「WEBサービス」いってみるか。
誰か「WEBサービス」の利点を教えてくれ。
「イントラネット」でなくて「インターネット」で使うのを想定して教えてくれ。

>>454
どういう根拠で糞なんだ。
JUnitを否定すると言うことは、同時にお前の大好きなCppUnitをも否定しているわけだが。
さらにケントベックやエリックガンマをも否定しているわけだが。


そもそもO/Rマッピングまで否定していたら給料減るぞw

Webサービス＝VBで作ったビジネスアプリの更新を簡単にする
最初はこういう目標だったはず

>>455
お前にとっては、(お前にとって)新しい技術は
すべて糞に見えるわけだな。
さすが色メガネ君は言うことが違うね。

O/RマッピングはJava厨に甘んじている俺ですら糞だと思うがなｗ
JUnitは見た目が楽しくてモジュールテスト組むめんどくささを緩和してくれるから好き

ビジネスロジックの実装のみだからま・いいか。

>>455
Webサービスは現在のJava厨の鬼門です。レスつかないよ。
話題そらして逃げるか、3日レスがつかないかどっちか。

そもそもWebサービスって何？

VBしかしらない人はWebServicesについて貧しい考え方をお持ちのようですね。

>>459みたいに、Hibernateの一部の機能しか使ったことが
ないでO/Rマッピングのすべてを知ったつもりになって糞だと
ほざいているだけC言語厨が最近Javaスレに沸いてきたな。

>>461
そうやって煽っていればwebサービスの使い方に
ついて教えてくれると思ってるところがC言語厨の甘いところだね。
嘲笑われるのがオチw

>>464
全てを理解しないと使い物にならない糞ってことだろ
自分で墓穴掘ってんじゃないよｗ

Javaはwebアプリと携帯アプリしか使えない。
webサービスにはまったく使えない。

Webサービスって何？
WebStartのようなクライアント更新機能とは違うもの？

サービス指向でシステムを構築するなんざ、今の４０代とその子分が
絶滅しない限り無理。分身は延々、何とかＳＩと言う会社で生まれるから
結局、永遠無理。たった数万クラスのシステムでさえコンポーネントは
おろか、クラスさえつくれんのに何ができるんじゃ。

VB.NETでWebServicesとSmartClient使いまくってるが何か？

コボラな先輩が多い会社は大変だねｗｗｗ

XML Webサービスのことだろう。

え？WEBサービスってJavaでも出来るだろ？
いや、実際にやった事無いけど出来るって聞いたぞ？

・・・ところで、
32日（土）になってるのはエイプリルフールにちなんだ洒落なんだろうか？？？
非常に突っ込みにくい・・・下手に突っ込んだら自爆の可能性を秘めている・・・orz

今年は財政難で中止だってさ。
http://news19.2ch.net/test/read.cgi/newsplus/1143820467/l50

さてさて、このすれでJUnitの話がでたことで。
JUnitの応用であるJakarta Cactusの話でもしようか。
おれも本格的にCactusを使いこなしたくてさ。

みんなでCactusを職場に広めるためにCactusの勉強しようじゃないか。

The Ja-Jakarta Site - Top
http://www.jajakarta.org/cactus/

Cactus へようこそ

Cactus は サーバー側の java のコードをテストするための簡潔なテスト用フレームワークです。
（サーブレット、EJB、 JSP のタグライブラリ、フィルター、...）

Cactus の目的とするところはサーバー側で実行されるコードに対してテストを書く為の手間や掛か
る時間を低くする事です。Cactus は JUnit をベースに、それを拡張したものです。

Cactus は自動テストのアイディアの実現を念頭に開発されてきています、そしてサーバー上でのテス
トを自動的に行う為に Ant を連動して動作する、簡単でパッケージ化された機能を提供します。

Cactus は コンテナーを内部に持つような戦略を採用しました。（それがどのように働くかを理解する為
に下のダイアグラムをクリックしてください。） Cactus ではサポートされていませんが、それを補うような
取組み方としては モック・オブジェクトを用いるものがあります。（Cactus との違いや Cactus がなぜ内
部コンテナー戦略の有用性を信じているのかを理解するために モック対コンテナーのページを参照して
ください。）

Cactus は、Apache Software Foundationに後援されているJakarta プロジェクトの中のサブプロジェクト
の一つです。 Cactus の公式ホームページは http://jakarta.apache.org/cactus/index.html です。

Cactus is a simple test framework for unit testing server-side java code (Servlets, EJBs, Tag Libs, Filters, ...).

Cactus は サーバー側の java のコードの単体テストを行うための簡潔なテスト
用フレームワークです。 （Servlet、EJB、JSP のタグライブラリ、フィルター、...）

The intent of Cactus is to lower the cost of writing tests for server-side code. It uses JUnit and extends it.

Cactus の目的とするところはサーバー側で実行されるコードに対して、 テスト
を書く為の手間や掛かる時間を下げる事です。 Cactus は JUnit をベースに、
それを拡張したものです。

Cactus has been developed with the idea of automatic testing in mind and it
provides a packaged and simple mechanism based on Ant to automate server-side testing.

Cactus は自動テストのアイディアの実現を念頭に開発されてきています、 そして
サーバー上でのテストを自動的に行う為に Ant と連動して動作する、 簡単でパッ
ケージ化された機能を提供します。

Cactus implements an in-container strategy (click on the diagram below to
understand how it works). An alternative but complementary approach not
covered by Cactus is to use Mock Objects (see the Mock vs Container page
to understand the differences and why Cactus believes in the usefulness of
an in-container approach).

Cactus は コンテナー内戦略を採用しました。 （それがどのように働くかを理解する為に
下のダイアグラムをクリックしてください。） Cactus ではカバーされていませんが、これを
補うようなアプローチとして、 モック・オブジェクトを利用するものがあります。 （Cactus と
の違いや Cactus がなぜコンテナー内戦略の有用性を信じているのかを理解するために
モック対コンテナーのページを参照してください。）

なんでJREなんかインスコしないといけないの？
ﾒﾝﾄﾞｸｾ

なんでアプリなんてインスコしなきゃなんないの？
なんでVisualStudioなんてインスコしなきゃなんないの？
なんで禿丸なんてインスコしなきゃなんないの？
：


メんどくせ。

単体テストの分類について/Different kinds of unit tests

There are several kinds of unit testing frameworks. We categorize them in 3 types :

単体テストのフレームワークの種類は幾つかありますが、私達はそれを3つのタイプに分類します。

1. Type 1 : code logic unit testing. Probably the best strategy for these tests is to
　use a Mock Objects type framework.
2. タイプ 1 : コートロジック単体テスト. 多分にこうしたテストのための最適な戦略は
　Mock Objects型のフレームワークを用いる事でしょう。
3. Type 2 : integration unit testing. Cactus is typically in this category (I'll let you
　 judge if it is the best or not :)). These tests will exercise the interactions with the container.
4. タイプ 2 : 統合型単体テスト. Cactus は典型的にこのカテゴリーに入ります。 (それ
　がベストかどうかはあなたの判断に任せますが。:)) これらのテストはコンテナーとの相互に
　連携して動作します。
5. Type 3 : functional unit testing. These unit tests will let you test the returned values
　 from your server code. This is for example HttpUnit (Note that HttpUnit also performs
　standard functional testing - as opposed to functional unit testing -, which let you test full
　 use cases - a login use case for example, which is comprised of several requests/responses).
6. タイプ 3 : 機能的単体テスト. これらの単体テストによって、 あなたはサーバー側の
　コードからの返り値をテストすることになるでしょう。 これらの例としては HttpUnit かあります。
　 (HttpUnit はまた標準的な機能テストとしても働くことに注意してください。 機能的単体テストと
　は対照的に、そこでは全てのユースケースをテストするこ とになります。例えばとあるログイン
　処理のユースケースがそうです。 それらは何回かのリクエスト／レスポンスを含みます。）

カークタース！

サボテンカクタス

Ideally you would use 3 different frameworks just to unit test your code ! Then you have to think about
acceptance testing, system integration testing, ...

理想的には3つの異なるフレームワークをあなたのコードの単体テストに用いるべきかも知れません。
それからあなたはさらに考えていかなければいけません。 受け入れテストやシステム統合テスト等々・・・

Cactus was developed to fit Type 2 but also to be a very good compromise for Type 1 and 3, with the
idea that it is much easier to have to write tests for a single framework than for several ! Moreover,
you can never fully test your code. We believe Cactus provides a middle ground that provides a high
confidence that your code will run when deployed. However, it is your choice and you can use Cactus
only for Type 2 if you wish.

Cactus はタイプ２に合うように開発されましたが、タイプ１や３に対しても非常 によい代替案にもなるように
開発されています、それは単一のフレームワークで テストを書いていく事は、複数のフレームワークを使っ
てやる事より、ずっと容易 であるという考えに基いています。 それ以上に、あなたのコードを完全にもれなく
テストする事は決してできません。 私達は Cactus は 運用時にあなたのコードが正常に動作する事を、高
く保証する 中間案を提供していると信じています。しかしながらそれはあなたの選択すべき 事であり、もし望
むならタイプ２のテストのためだけに Cactus を用いる事も出 来ます。

このスレで業務系ならJavaみたいな話があるけどさ、
昔のCOBOLのバッチみたいなのをJavaでリプレースとかあるの？

Javaでバッチとかは適材適所ではないんじゃないか。
新世代COBOLとかに載せ直す方がソリューションとしてはよくないか？

それに業務系ならJavaって本当かなー。
逆の、Javaなら業務系なら使えるかもしれんです、ってならわかるけど。

新世代COBOLってなんだべ？

実は、たったの２４時間で、
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
あなたの今後のネット収益を倍増するスキルがあります。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
それを知りたい方は、他にいませんか？

アフィリエイトを使わずにホームページとＥメールだけで3,000万以上稼いだ
インターネット・マーケッターの宮川さんが、

巨大な現金の山を作り出す門外不出の一生涯使えるノウハウを
下記のサイトで公開しています。

その内容をお知りになりたい方は、下記をクリックしてください。

【たったの２４時間で あなたの今後のネット収益を倍増するスキルとは？　】
http://infostore.jp/dp.do?af=moneyclick&ip=successpreneur&pd=01

>>487
COBOL2000のことかね

>>488
平秀信も同じようなこといってたな。
そのサイト。平秀信の「非道徳的マーケティング」のパクリ？

おいおい
糞Javaの無駄コードみたいな長文はやめてくれ

>>485
いくらでもあるよ。
わざわざ、他言語を使う必要もない。

ただ、バッチ個々にＪＶＭを起動するのはいくないと思うぞ。>>漏れのプロジェクト

>>491
糞Ｃ言語のコピペだらけで似て非なるメソッドが乱立しただけの
無駄コードと比べたらたいしたことがないが。

なんだ、だれもJakarta Cactusのことを知らないのか。
肝っ玉ちいせえなぁーーーーＣ言語厨わぁ

>>493
あー、うちのプロジェクトパッチごとにVM起動しまくり。何が悪いかおしえてくれー。
サーバーが複数台あるからTomcatとかに組み込むよりもcronで一台に設定するほうがらくなんよね。

Cactusなんて完全に終わってんだろ。。

Jakartaすべてが気に入らない

WebサービスのレスをCactusに挿げ替えたかｗ

ﾌﾟﾌﾟ　>>495は
Tomcatでロードバランサを設定できることを知らないクズC言語厨(嘲笑

とんちんかん、これだからJava厨は馬鹿にされるんだよ。

バカにされてるのはC言語厨のほうだよ。
これだからバカにされると気づかないC言語厨は
からかわれるんだよ。

>>499
いや、お前のほうがわかってないよ。
サーバー複数代あるけど、全部同じプログラムが走ってる。
バッチは複数台で走ったら駄目だから、そいつだけcronで走らせてる。
Tomcatとかコンテナに組み込みたいんだけど、
そうするとひとつのコンテナだけ設定が
変わっちゃうからリスクが増えて嫌だって言う話だよ。

ロードバランサとか、C言語とか全然出てこないよ。

今日もアンチスレにいっぱい群がりにきてたんだないくら埋めてもスレは立てるのに

レス数からしてもこっちが本スレで軽くね？がアンチスレだろ。

Javaは重いが定説なのに嘘を流そうと必死な軽いスレ。

>>504
Javaよりお前みたいなアンチのほうが重いのが定説。
こっちを本スレにしたくてとにかくJavaを蔑まないと気が済まない
Javaのせいで仕事を失った連中がJavaに対する
恨みがあるためにたてた糞スレだろこのスレは。

数日開けてスレを見た。100レス飛ばしても意味が通じるのが素敵。

　　( ﾟ∀ﾟ )
＿(__つ/￣￣￣/＿　
　　＼/　　　　/
　　　　￣￣￣

どことどこのレスを100レスよばしても通じるんだろう

だからO/Rマッピングが糞じゃないなら「一括削除」の方法を教えろって言ってるだろ。ボケ！！
JUnitが糞じゃないならデバッカ使用より簡単なメソッド内部の全分岐ルート試験の方法教えろ。
使ったこともないカスが、英文訳して使った気になっているんじゃねーよ。ばーか。

ちなみにWEBサービスってのは、サーバ間通信の技術で、Javaのメソッドを呼び出すだけで
他のサーバ（自分のサーバも可能）とデータの受け渡しが出来る。
実際の処理としてはメソッドを呼び出すと、「XMLファイル」を自動生成して送信を行い、
受信後にメソッドのパラメータに戻すため、面倒な変換や通信を考えなくていいと言うのが売り。
Javaに限らずVBやPerlでも使用可能なため、言語やOSに依存せずに通信可能と言う理想があった。

用途としては従来CSVのファイル受け渡し等を使用していた企業間データ転送に替わる物として
期待されていた。イントラネットだけでなくインターネットを使用した企業間取引を想定している。
またWEBサービスを使用した情報サービス提供する企業が増えて、ビジネスチャンスが増えるのも
期待されていた。

がJava軍団はAxis 1.xでサービスがサポートに不足があることに気づき
Axis 2.xを準備中だがいまだ正式リリースには至らず。遅れが激しいJava軍。
Eclipseプラグインも相互運用と歌いつつ.NETのXMLをすんなりと解釈してくれず
遅れているJava軍。しかしJava厨は.NETのタグが悪いとか悪態をつくだけ。
ｸﾚｸﾚ、ﾏﾂﾏﾂをきめこんでJacartaに技術提供する気概はさらさらない。

>>508
O/Rマッピングでは効率的な「一括削除」はできないし、
普通の業務アプリではそういう使い方はしないのでは？
(ユーザアプリは受注テーブルや在庫テーブルの一レコードに
削除フラグを立てておいて、後で月次バッチが削除)

それから、SQLはかなり強力な言語なので、なんでもO/R
マッピングしないで使い分けることが重要。
（最近のORマッピングフレームワークではSQL文を直接
発行出来るような仕組み(Hibernate Criteria/iBatis)
が用意されている)

>>508
JUnitは、基本的に引数と返値の組を検証する
ブラックボックステストを **一日に何度も** する物。
RDBが絡む物に関してはDbUnitなどの仕組みを使うことによって
操作の副作用まで検証する（グレイボックステスト）。

ホワイトボックスは・・・最近やらないんじゃないの :-)

>>509
Webサービスって今のところ離陸できいんじゃないの？

インターネットを通じた、B2B連携は立ち上がっていない。
サーバールーム内での役割分担(Web-業務ロジック)なら、
CORBA ( RMI-IIOP )で十分。
WAN間のクローズドなB2B連携(変なプロトコルの魑魅魍魎)
は新たにWebサービス化するよりEAIを使った方が正解でしょう。

ただ、今はわざわざWebサービスを使う必要がないというだけで
Web2.0の次あたりで使われ出すかも・・・

Java鯖でGETしてHTML解析してPOSTみたいなことやってるとこが多い。
webサービスで実装されてれば無駄な金をとられないとエンドユーザーにばれるまでは広まるまい。

webサービスもクソな設計すると台無し
モジュールの結合度とか理解してない馬鹿が設計すると大変なことになる

>>511
> >>508
> （最近のORマッピングフレームワークではSQL文を直接
> 発行出来るような仕組み(Hibernate Criteria/iBatis)
> が用意されている)

甘い、それをいうとC言語厨が勘違いして鬼のクビを取ったように
アホみたいに喜び出すぞw
実際には真のSQL文ではないんだがｗ

>511
業務プログラムでは月次でしか一括削除をしない？
オマエさあ、そんな事はないと分かっていて言っているだろ。素直になれよ。
フラグを立てておいて削除？結局うちでは作成日時をキーに同じような事をやっているが、
本当はそんな事したくないんだよ。「使い分け」と、「機能的に出来ないから仕方ない」は違うだろ。
HibernateでSQLが使える？本当は使ったことないだろ？それは検索だけだぞ。

JUnitは入出力試験を行う物だってのは知ってるよ。
しかし一日に何回も同じ試験をやるのは意味ないと言うのも少し考えれば分かるだろう？
ルート試験は最近やる奴がいない？まさにその通りだよ。
単体試験しない素人が腐れツール使って試験した気になっているのが問題なんだよ。

WEBサービスもやっぱみんなろくに使ったことがないんだな。
「各社タグ付けの問題」ぐらいしか出て来ないんだから。
本気で使おうと思ったら、「セキュリティー」や「バイナリの扱い」や「配列の扱い」なんかすぐに
問題になるからな。まあ使う必要性がないから使ってないと言うのは利口ではあるがな。
そういうのは構わないが、使ったことがないのに簡単だとか素晴らしいと言うのはやめてくれ、マジで。

おまえ、後ろ向きなやつだなあ、そんなことじゃ仕事とれないぞ

削除フラグたってるのに、それを消す仕組みのないアホシステムに関わっています。
既に数千万件になり、遅くなったと問題になってます。
バックレたほうがよろしいでしょうか。
消してもいいんじゃないですかといっても聞いてもらえません。
リアルコボラでしょうか。

>単体試験しない素人が腐れツール使って試験した気になっているのが問題なんだよ。
あはは。いえてるなｗ

>WEBサービスもやっぱみんなろくに使ったことがないんだな
Java屋はサービス開発はしないからね。ｸﾚｸﾚGoogleさん使わせてｸﾚだけだし。

それ以前に、業務屋にはサービス指向な発想がない。
バッチﾌﾞﾝﾌﾞﾝ

業務屋ってシステムはリテラル埋め込みまくるし。
業務屋のコードって絶対再利用できないよね。
オブジェクト指向の皮をかぶった構造化以前の糞コードが実態。

つか、なんで削除フラグなんてのがあるんだ？

Webサービスの話になると沈黙か話をそらすか逆ギレするかの
Java厨。業務に特化しているのがよく分かる。

汎用化されたらおまんま食えなくなるから。

>>522
論理削除にしたかったんだろ。

静的トランザクションログ=削除フラグ(マーク)

JAVAが分散で強いのは、根幹のJVMからしてバイトコードだからだと思うな
ネットワーク上に流すには、昔々のテレックスの頃から２バイト単位
バイトコードのバイナリなら、そのままＭＩＭＥ変換使えるから、そのまま流して、そのまま対向で使える＞シリアライズが容易

メモリオブジェクトをシリアライズすると
そのまま眠りの森のブス化していつまでも起きてくれないのが問題。

>527訂正
MIME変換＞BASE64

別に7bitアスキーでもバイトバイナリでもbase64変換してファイルアタッチなどで使うじゃないの？
何がいい鯛かわからんJava厨さん。

>528
CPUによって命令セット違うし、当然他のマシンに流せばそうだろうけど(JVMは仮想マシンというある種の命令セット)、
１個体マシン上でなら、binHexとかuuencodeとか「テキスト化」するから問題なんじゃないの？
文字コードで00〜ffは制御コードで使えない。
8bit単位→6bit単位に変換してそのコードが含まれていても使えるようにしてくれるのがBASE64。
JAVAでBASE64がどれくらい・・・と言われると、まだベンキョ不足で分からないけど。

Java厨ならばbase64の事など微塵も知らなくても問題ないでしょう。
ビジネスロジックせっせと書けばいいんだし。

やっぱりJava厨さんは
やれ大規模開発だ
ビジネスロジックだ
ツールのスキルだ
と騒いでいるのがよく似合うな。

けど「できるのか？」と聞かれて「はい」と答えるにはやっぱJAVAになっちゃうでしょう、特に分散環境では。
一からパッケージを作りこむなら、そうそう答えられない。
標準C++はコンパイラこそ違えぞ、どこでも共通だし、他にいい選択肢ができればいいけれど。

C++でWebサービスがんがん書くと
Javaのプログラムが簡単になるよな。
汚いビジネスロジックの洪水はかんべん。
業務単位で分割されたサービスの組み合わせでシステムを作りたい。
/*略*/ doPost{
callWebSvcMethod();
//これだけ
}
はっJava厨の仕事がなくなる。そっかだからJava厨はWebサービスしないんだ。

Java厨はその「これだけ」コーディングして得意満面ですよ
たいしたやつらです

C++厨は仕事がなくて暴れていますなｗ

そんなにC++でWebサービスしている職場があるのか？

JAVAでサービスを主に作って必要ならCでapacheのモジュール書いてって
いう形態が多いんじゃないの？

WEBサービスが普及しないのは「無料でWEBサービスを提供しても儲からない」からだろ。
さらに「有料サービスに使うにはセキュリティーが御粗末すぎる」上に、
「MS系とその他UNIX系で互換性がない」からだ。言語がどうのって問題じゃない。
それにWEBサービスでJavaが遅れている訳でもない。むしろCの方が遥かに遅れている。
実際、Java同士のWEBサービスは少量の変更でつながる。
MS内のWEBサービスは全く問題なくつながる。まあ、MSだけでやっているんだから当然だが。
ただMSと他との接続は全然ダメだ。まあMSとしても互換性を持たせる訳ないよな。
「Windowsで揃えてください」って言いたいんだから。

互換性って？W3Cがあるのに？
Javaのパーサがお粗末なだけじゃねーの？

だから各社ベンダーがそれに従わないんだよ。W3Cが偉かったのは各企業の利益が一致してたからだ。
むしろ意識的に互換性を壊しているのはMSの方だ。そりゃMSの立場からすれば当然だろ。

>535
それで、JAVAが用いている分散API「JTS」のような関数がC++にあるともっといいな
JAVAでもRMI･IIOP使っていてこれが主流だから、これを用いるのが旨い

その理解は正しくないと思うよ。
Axisでパースエラーになる。これはAxisの問題。Java側の実装がダサい。
NetBeansでのテストだとMSモジュールを完璧に動作する。UNIXの世界はしらないが
Javaの実装が完璧だとこのようになる。

だからJavaの実装に多数の問題を抱えている。
でいーんでないの。

C++は根の技術ではあるけれど、実際の環境で使うとなると、
「根」であるだけに、「マシン間」での「リモートプロシージャコール」に難があって、
さらに、多くのProcess、Taskを協調・排他制御させるには、余りに遠い、それらの関数群をどう充実させるか。
マシンによって命令セットが違うから、バイナリーコードも違う、JAVAはJVMという仮想マシンでマシン差異の互換性を維持してるけど、
標準C++で他にどうやって実現するか(CORBAなどに則ってやるのか)
だと思う。ＷＥＢサービスなら必須の条件。

RPCは無駄

ものすごいデムパが湧いてるな

なんで？
プロトコルSOAPで内部はなにで作ろうが気にする事はないじゃないの

たぶん、彼は根本的にわかってない。

まんまソースをどこでも使えるとはいかないまでも、
マシン間通信という意味で、
まんまコピペだけど、
・CORBAは分散環境におけるオブジェクト通信の基盤技術で、
プログラミング言語に依存しないオープンな技術として広く利用されています。

であるから、JAVA以外で分散環境を模索する一つのヒントではあると思うよ。

XML webサービスにおいて、標準に準拠していないのはJava。
unixはだめだめ

新年度早々盛り上がってますね！

>>549

CORBA のRCPはCOMとの相互運用ができない(しにくい)
そこで出てきたのがSOAPプロトコルなんだけど。
ようはCORBAは過去の技術なんだよ。基盤としては現役だろうけどね。

うっせえおっさん

自作自演乙

必死なJava厨乙

Java厨の長文こぴぺがなければ良スレだなと思うよマジで。

J厨スレはもはやマ板の名物

うん。お酒飲みながらこのスレ読むのは楽しいぞ。

鯖でPOST/GETしたりHTML解析して他のサイトに発注してるようなWebアプリは、
Webサービス化すると簡単になるし、もっと活発になると思うんだけど、エンドユーザーが
そういうサービスを提供したらビジネスチャンスが増えると認識していない。
また、上のような実装は今はJava鯖全盛なので、わざわざ自分達の仕事を奪われるようなことを
するわけも無く、SIerも売り込んだりしない。よって、Webサービスは未だに火がつかない。

69式などと名乗る香具師は
アル中で死んでしまうのが相応しい

（（　　　）　　　　　　　　（
　　　　） ﾉ　　　　　　　　　 ）　　　　(
　　　（ _⌒)　　　　　　　　（　(　　　　）
　　　　　）ﾉ　　　　　　　　　ヽヽ　　ﾉ
　　　　 （ (　　　　　　　　　　　）　）)
　 ∧＿∧)ﾉ　ｳﾏｰ　　　　　　（,, （
　（　・∀・）O＿＿＿＿＿＿＿）ﾉ
　 ﾉ つ（;;;;;;;;;;;;;;;;;;;;;;;（　　　　　((;;）
　（,,⌒つと)　￣￣￣￣￣￣

JAVAでCOMコンポーネントの利用のケースの場合、JAVAが司るのはCOM部品操作の起動と終了だけじゃなくて？(トランザクションも管理できるのかという意味)この辺、全然知らないんだけど。
COMを使ったRMCの場合は、あとはトランザクションの管理やらはCOMがやってるんじゃないのかなCOMのポート番号通して。
何が言いたいかというと、CORBA仕様のIIOP(サーバーサイドJAVAで利用)とCOMのプロトコルは併用で動くんじゃないのかなと別々のポート番号通して。
あと、SOAPは埋込み用の簡易言語で、HTMLやXMLと同じく、メッセージ交換であってトランザクションの管理のような、なんというのか、動的なことはできないでしょう。

>562訂正
RMC>RPC

アル中氏ね

そういえば、JDBC-ODBC(COM)ブリッジがあった...
自明だった..

でも、
>CORBA のRCPはCOMとの相互運用ができない(しにくい)
というのも分かるなあ
例えば、JAVAだってEJBからJDBC-ODBC経由でDBにアクセスして、
EJBの排他制御とODBCのbegintransしての排他制御が一緒にかかってデッドロックなんて往々にしてありそうだ
なかなか難しそうだ

>>562
SOAPは相互運用のためのシンプルな公開仕様なだけ
SOAP(WSDL) Web XMLサービス内部の実装は実装する側がどうするか決める事。
トランザクションやセッション管理の必要があればする。
暗号化しないとだめならばする。
で積み上げる。
要求サービスがなにを求めているかで実装が違うのは当然。

オナニー

追加
動的な事はばんばんなんでもできる。
実装言語は C++/CLI または素のC++がお勧め。Javaだとドライバアクセス
とかOSそのものにダイレクトにアクセスできねーからね。
だいたいサービスの要求なんて泥臭いものが多いからJavaで実装だと実現しない。
動作も遅い(レスポンスが悪い)、動作が遅い理由はコンテナがパッシベートする
勝手にしやがる。アクチベートする時間とVMの解釈、XMLのパーシング、エンドポイントへの
アタッチ、サービスポートへのHTTPセッション送信とやる事が多いXML サービスの実装は
できるだけ軽くするのが望ましい。マスタメンテナンス機能をセキュリティを伴い内部
イントラに対するWeb参照でサービス公開するなんて仕様ならばJavaでもいいかもしれないが
なんたらマッピングをXMLサービスにかぶせてもレスポンスは大丈夫なのかという検証を
Java厨がきちんとするとは思えないのが心配。

こんどはドトネト厨が長文垂れましたか

と話についてこれない勉強嫌いのJava厨が申しております

Webサービスってどうも誤解があるよね。

Googleのように公に公開するサービスと
内部イントラ参照利用する分散コンポーネントの役目を忘れてはいけないと思う。
Javaでサービス作るのがめんどうならばC#でサービス作ってJavaで利用する
なんてのがありだと思うし、サーバライセンスが高いとか言うならば
同時10接続以内の限定ならばXP Proでコンポーネントサービスをするなんてのも
あり。

おちんちん

さあ、そろそろツールとオブジェクト指向と
業務ロジックとテストツールの長文がきますよー

Webサービスは現在のJava厨の鬼門です。レスつかないよ。
話題そらして逃げるか、3日レスがつかないかどっちか。

鬼門である根拠は？
Apache BeehiveやJBossで
今JavaのほうがﾄﾞﾄﾈﾄよりもWebサービスについては
進んでいるはずなんだけど。

うちもWASとかWebLogic使いまくりだけどうまくまわってる。
鬼門とはよくわからん。

>576
どこらへんが進んでるの？

WebLogicだけ使ってやっていれば、完璧に動作する。
WASだけ使ってやっていれば、完璧に動作する。
TOMCATだけ使ってやっていれば、完璧に動作する。

特にWebLogicのWEBサービスは全自動でコードを自動生成する。
おそらくこれが一番進んでいる。

WebLogic高杉。
なんであんなにぼるのかわからん。

Togetherよりマシ。
効果のほども微妙なのに、あの価格。それも指名ライセンス。
別ライセンス方式は応相談て、誰がコンタクトするか馬鹿って感じ。

＞特にWebLogicのWEBサービスは全自動でコードを自動生成する。
＞おそらくこれが一番進んでいる。

.NETも全自動かと。
.NETだけつかってやっていれば、完璧に動作する。

WebLogicの旨みはTuxedo連携にある。
WS-Transactionの実装待ちではあるが。(設計上も問題積まれてるか)

顔がでかい

つまりどこのベンダーも自分の所の製品だけ使えって言っているんだよ。
つーか、盛り上がらないな。WebServicsマイナーすぎたか。
UML行くか、UML。
誰かUMLの素晴らしさを語って。

Javaと関係ないところじゃね？

じゃEJBにするか？EJBはWebService以上に食い付きが悪いぞ。

EclipseとかnetBeansみたいな開発ツールが一番食いつきがいい。
大半がﾄﾞｶﾀであることの証左といえよう。

>>576,577
たいてい、Javaの素晴らしさを語る人間が現れるのだが、
それが現れないところから鬼門と思われる。

アナル

それは菊(ry

>>586
そこでPOJOですよ

>>588
Javaの仕事が多くてもJava + WebServicesという
仕事があまりにも少ないことが話題が少ない原因かと思われ。
いまだにTomcatだけで十分だというところが多いし。
そうでなくてもTomcatにプラスSeasar2だけ、プラスStrutsだけ
っていうところがかなり多い。
ドトネトなんてもっと仕事が少ないから同じようなもんでしょうなあ。
じゃJavaやドトネト以外の言語でほどよくwebservicesを実現しているもの
はあるのかっていうとほぼ存在しないといってもいいくらい希少でしょうな。

PHPやPerlでWebサービス？　ちょっと現実的じゃないなあ。
C++でwebサービス？　もっと現実的じゃないなあ。

前から思ってたんだが、Javaって別言語との連携を前提とした
プロジェクトってあるの？

＞鯖でPOST/GETしたりHTML解析して他のサイトに発注してるようなWebアプリは、

たとえば？

javaでwebサービスって何？
しょうもない業務アプリでしか使われてないでしょ？

しょうもなくはないが、一部のイントラだけだな。

じゃEclipse行くか。
って、俺はEclipse賛成派だよ。
豊富なプラグインに洗練されたインタフェース。開発からデバックまでこれ1つでOK。
さらになんと無料！！
Eclipseに文句のある挑戦者求む。

重い

おもちゃ箱
プラモデルIDE

JavaでWebサービスするのが一番現実的じゃねえんじゃねーか？

Webサービスの方向性は疎結合、つまり別プラットフォーム間のやり取り、
をまず前提としている。Javaってそこら辺得意なの？

>>600
はあ？
なんで疎結合にプラットフォームが関係してくるんだよｗ

ＥＪＢってなんで喰いつき悪いんですか？そんなに使われてない？
たしかに、WEBコンテナ(servletやjsp)とは別こんてなのEJBコンテナで動作していて、
直接やりとりできない、コンテナの底のJVM上である直接動いてるJavaBeansを間に噛ませてやりとりするってポイント押さえとけば、
jspにはjavaBeansを使うタグがあるし、その値をservletとお互いに使えるし、
javaBeanはEJB同士と同じようにEJBとつながるし、
使いやすいと思うんだけどＥＪＢ．

>>601
逆に？何言いたいのかわからん。
疎結合っつーのはコンポーネント間の結びつきが緩い、
ぶっちゃけ、プラットフォームが違くてもやり取りが出来るように
したものだと理解していたのだが違うの？

プラットフォームの違いを気にせず情報のやり取りを行えるが
WEBサービスのキモなんだから、それが構築できる言語なら何でも良いんだよ。
だからそれぞれの環境で最も適切な道具をチョイスするのが一番現実的なんだ。
それなのに何でJAVAが一番現実的なんて意見が出てくるんだ？

言語同士で補完しあうのがWebサービス。
それで、自己完結性が高いのがJAVAだろ？

相性は悪いとは言わないが、その特性から
あえてする意味がないんじゃね？

>>592自身も十分だと逝ってるし。

屋根の上に家建てるのがJavaだとしたら、
Webサービスは家の窓の間に吊橋をつける
ようなもんだと思うんだが。

＞Webサービスは家の窓の間に吊橋をつける
＞ようなもんだと思うんだが。

おもしろい。なるほどね。

>>602
> ＥＪＢってなんで喰いつき悪いんですか？そんなに使われてない？

EJB勢力に反発して、POJOという勢力が生まれたわけだが。
しかしアンチEJBでポジョポジョいってると仕事がなくなるぞ。

お前ら何でPHPを無視しますか？

窓につり橋？ちと違うな。

電話交換機や
スイッチングハブ、ルーターみたいなもんだろ。

いや、HTTPプロトコルみたいなもんだろ

>>608
webサービスを使うほどのレベルでもなく、話にならないから。
どうせXML-RPC、やGETやPOSTくらいしか使わないんだろ。

EJBについて質問なんだけど、EJBって何のためにあるの？

いやWEBサービスを使いたい訳じゃなくて、サービスを提供したい訳だろ。
サービスを提供するシステムが先にある訳だから、そのシステムが何で作られているかが問題だろう。
Perlで何でも作れる訳じゃないし。
JavaかCならほぼ何でも作れるだろうから、JavaかCが現実的って事だろう。

Javaで書かれたソフトはJVMのある環境でしか動かない。

ソースからのコンパイル方法によってはJVMでなくても
動かすことはできるが。

逆アセンブルによってはJVMを使わなくても動かせるようにできるが。

マジ？
ご教授ください。
おながいします。

JREをインストールできません。

>>614
実際、個人とかオープン系で主に使われているOSにはJVMがサポートされているから
実用上は問題ない。

>>616
>>615はあるにはあるが、JVMを実行ファイルに静的結合しているようなものだから、
ファイルサイズがすごいことになるって聞いたことがある。


ところで、Javaマシンはマダー？ｗ

>>618
つJava Chip

>>619
スタバのJava chipフラペチーノは650Kカロリーですよ

javaによるwebアプリのデバッグ時に
デバッガって使える？
eclipseとか

使える使える、EclipseのTOMCATプラグイン最高。Weblogicプラグインでもいいよ。
逆アセンブルのJadプラグインも入れておくとクラスの中も見える。
あー最高。
もうdbxには戻れない。

>>620
なに、そのカツ丼みたいな高カロリー

　　　　　　｜
　　　　　　｜ﾊﾟｸ
　　　　　／V＼
　　　　/◎;;;,;,,,,ヽ
　＿　ﾑ::::(,,ﾟДﾟ)::| そんな餌で俺様が釣られると思ってるのか!
ヽﾂ.（ﾉ:::::::::.:::::.:..|）
　 ヾソ:::::::::::::::::.:ﾉ
　　 ｀ ー U'"U'

>>612
EJBはJAVAアプリケーションの中でも、特に分散トランザクションを強化していて、
何にでも繋げて、本のまんまだけど、「何にでもつなげるスーパーミドルウェア」と詠われる。
実際、どんなものでも繋げるわけではないけど、
・ODBCと同じくオープン系ＤＢほぼすべて、JAVAでインターフェース接続可能な汎用機(但し、汎用機側はもちろんだけど、ローカル接続(コンテナ使わず直接JAVA)になるから、ミドルウェアとしてのプログラムは必要になるけれど、
EJBの分散トランザクション機能は充分堪能できる)。
・ＥＲＰも対応している。
・キュー機能を持つ(メッセージングサービス)
これらはプログラムの羅列は必要なく、荒っぽく言うと設定程度で済む。
特に、分散環境でのトランザクションを協力にサポートするところが強み。

だと思う。

あと、「何にでもつながる」と少々大げさに詠われる理由は、まるで、いわゆるインターネットのような、
リモートネーミング&ディレクトリサービスを持っていることにあると思う(JNDIと呼ばれている)。
ローカル、リモートともに、いわゆるＤＮＳのような機能を持っていて、
当然DNSというからには、つながる対象が変われば(当然同じアプリという制限はあるけど)、設定をかえてやるだけで、プログラムには大勢の影響はない。
JNDIに関して、ローカルに対してはAPIを利用し、リモートに対しては更にSPIを利用している。
更にJNDIは、リモートに対してトランザクションを実現するために、LDAPサーバ、COSネームサーバ、ＤＮＳサーバ以外の機能として、RMIレジストリサーバを持っている。
こっからは、推測の域を出ない部分もあるけれど(勉強不足ゆえ)、
リモートのオブジェクトをまるでローカルのオブジェクトのように利用している素は、
JAVAの参照(実体はリモートにある)と、EJBのインターフェースにまさしく言葉どおりのJAVAのinterface機能を利用していると思う。
interfaceは抽象クラスであるから、実際にオブジェクトとして宣言はできないけれど、直接interfaceのメンバ関数を呼んでやると、実際にはその派生クラスの実体ができる。(これはまるで、C++の仮想関数が呼ばれると、実際には派生クラスが呼ばれるのと似ている)。
そして、参照とインターフェースをCORBAの分散オブジェクト環境に調和させて、RMI・IIOP通信を築いている。
と思う。
酔った勢いで書いたんで突っ込みヨロ。

>>625,626
へぇ、まるでＣＯＭですね。

>>627
ただ、ＣＯＭは「言語を選ばない」けれど、実際には窓でしか効果がない。
なんとなれば、ＣＯＭの部品が多いのは窓であって、更にＣＯＭの部品を作ること自体が難しく(少なくとも自分には)、広まっていず、
自分の知る限り、ＣＯＭ部品を作るにはVisualStdioのATLウィザードしか知らない(無知w)。
逆に、JAVAで(プラットフォームという言葉を借りさせてもらうと)、さまざまなプラットフォームで利用するには、
やっぱりJNIを使ったりしてC++を使うことになるんだろうと思う、そうなると、JAVAアプリの底にあるJVMが速度の点で障壁になってくるとは思う。

COMはVBScriptやJScriptでも書けるよ。

>>621
Eclipse Tomcat リモートデバッグで
ぐぐれ

>>627
EJBを古臭いCOMと一緒になのではと聞くことはかなり愚問らしい

それで前から疑問なんだけど、ＣＯＭって結局接着剤なわけだけど、
ＪＡＶＡって別の言語との接着剤的な運用ってできるの？

聞いた感じでは結局ＪＡＶＡで閉じた世界にしか見えないけど。

WebサーバーとDBとの接着材です！
なくてもくっつくすぐれもの

>>632
ひとつのOSで閉じた世界より
Javaで閉じた世界のほうがまし。
っていうかJNI矢JVMはC/C++の世界なので
Javaは完全に閉じてないけど。

>>634
それって最近のトレンドから外れていない？
プラットホーム戦争は等の昔に終わって、
最近は複数のプラットホームとか言語を組み合わせて
コストパフォーマンスを上げるのが主流なような・・・。

じゃあ、ぶっちゃけＪａｖａって実は時代遅れ？
だったら、悪い点目瞑ればＣの方がマシじゃん。

>>630
ｻﾝｸｽ

WTPで一式もってくるのがラクだよ

つか
みんなEJBとかCOMを普通に使ってるの？

俺は単なる社内SEなんで
全然必要性を感じないんだけど

ここのスレはレベル高いなー

COMは皆使ってるだろ。
ActiveXともOCXとも言うけど。

>>638
漏れはCOM作って、別の言語に情報渡している。
ｻｰﾊﾞとかｻｰﾋﾞｽっぽいけど実は、ｸﾗｲｱﾝﾄｱﾌﾟﾘ。
実はJavaで一括して作れるんだけど、プロセス間
通信の問題でJavaめんどくせとなっている。

>>635
> >>634
> それって最近のトレンドから外れていない？
> プラットホーム戦争は等の昔に終わって、
> 最近は複数のプラットホームとか言語を組み合わせて
> コストパフォーマンスを上げるのが主流なような・・・。

MSのドトネトの宣伝みたいだな。
Javaに不向きのシステムや
適材適所なんて昔から当たり前だし。

既存の資産を再利用したいって考えは昔から変わってないんだし。
新規に開発をするときだけJavaをメインに置くケースもよくあるが。

Javaは使い捨てカメラのようなソフトを作るのには向いて無く
なんども再利用でき、長期的に使えるソフトを開発することに向いていることは
Javaが出た当初から変わってない。

> じゃあ、ぶっちゃけＪａｖａって実は時代遅れ？

そういう解釈をしちゃうのも短絡的だと思う。


> だったら、悪い点目瞑ればＣの方がマシじゃん。

それも本末転倒というか。開発効率を考えると特に。

>>638
EJB使ってるとこなんてほんの僅かだよ。
Java開発者の8割以上はEJB開発経験が無いんじゃないかな。
非EJBたるPOJO(Plain Old Java Object)な人が大半だと思う。

>>639
実際の所使っているうちには入らないケースがほとんどだろう。
知らぬ間にCOMを使ってるレベル。EJB並みに使いこなしている
とは言えず、POJOと同じレベルでしか使ってないだろう。

>>641
>Javaに不向きのシステムや 
>適材適所なんて昔から当たり前だし。 

そりゃ当たり前だが、問題点は適材適所を考えて
割り当てても、JAVAは独立性が高いから与えられないっツー事。
他との組み合わせが苦手と今まで発言でいってるようなもんだぞ。
一般論で適材適所って言うのは矛盾している。

>Javaは使い捨てカメラのようなソフトを作るのには向いて無く 
>なんども再利用でき、長期的に使えるソフトを開発することに向いていることは 
>Javaが出た当初から変わってない。 

つまり、開発環境がさほど変わらないという前提で中長期的な戦略
やる所に向いていると言うわけですね。

>それも本末転倒というか。開発効率を考えると特に。 
パッケージ製品の開発効率ってJava良いの？

適材適所だなんだって言ったって、サーバサイドでC++使って
カリカリにチューンされたコードを書ける人なんかほとんどいない。
いたとしても労働市場には出てこない。

特に高速性が必要なケースでC++ で高効率でやろうとしても、
上から下までC++、というかハイパフォーマンスコンピューティングに
ついてわかる人を当てがう必要がでてきて、当然それは無理なので
結局金かけて高価なサーバを用いたJavaの大規模開発になって
しまうのが普通。

だと思う。インハウスのシステムなら別かもしれないけど。

Javaが適用されている業務系分野ってさ、言語以前に使用的に再利用が
困難な分野なんだよね。所謂ビジネスロジックっていうやつ。

んなもんで、結局一番効率的な再利用法はコピペだったりしているわけで。

ああ、派遣市場で流通している程度のﾄﾞｶﾀをかき集めてでも、サーバソフトが書けちゃう
ってのがJavaの最大の長所かもな。

24時間運用が前提のソフト（サービス・デーモン含む）をC/C++でアフォに書かせるととんでも
ないことになるもんね。

Javaだとアフォでも24時間前提のソフトが書けちゃう、ってことですかい？
まぁ、アフォを救うためにAP鯖が頑張ってくれてるんだろけど。

Javaはあれだ、アウトソーシングだね。
例えばメモリリークしたらJVMの制作元に丸投げすれば責任回避できるから、
これだけでもビジネス的には荷が軽くなるってモンだ。
JVMにバグがあってもそれをうまく避けるコーディングがデキル技術を持ってるところが生き残るんだろうけどね。

>>646
インハウスの業務系なら
ビジネスロジックの再利用も可能では？

>>649
それは確かにあるなー。
強力なバッチ処理能力が必要ならIBMのエージェントフレームワークとかね。

>>645
> 適材適所だなんだって言ったって、サーバサイドでC++使って
それで適材適所というのはどうかと。
サーバサイドでJavaのHttpServletを扱うところ以外のロジックだけを
C++に委譲しておくというなら適材適所になりうる。よほどサーバの性能が
悪くない限りそんなことはしないが。
GUI関係ならC++に委譲することはありだろう。

>>646
> Javaが適用されている業務系分野ってさ、言語以前に使用的に再利用が
> 困難な分野なんだよね。所謂ビジネスロジックっていうやつ。
> んなもんで、結局一番効率的な再利用法はコピペだったりしているわけで。


多分、Javaで再利用が困難と言ってる連中は、Java開発経験が浅いだけだろうな。
経験がある奴なら再利用性を高める術を知っている。そのためには
まずはAntやXDocletの使い方くらいは覚えないといけない。

>>647
> ああ、派遣市場で流通している程度のﾄﾞｶﾀをかき集めてでも、サーバソフトが書けちゃう
> ってのがJavaの最大の長所かもな。

そんな根拠の無い煽りをすれば何か新しい情報をこのスレで得られるとでも思っているのか？
かりにドカタを集めただけでサーバソフトが欠けたとしてもそのサーバソフトの品質は
所詮ドカタの品質。どうせ自動化ツールも使いこなせないドカタが書いたものだから
Javaの特性を生かし切れていないことには変わりないわけだ。
ドカタにJavaを使わせるってことはJavaを有効利用したことには一切ならない。

そういう表層的な使い方を言っているんじゃないと思われ

また降臨ですか。

>>649
> Javaはあれだ、アウトソーシングだね。
> 例えばメモリリークしたらJVMの制作元に丸投げすれば責任回避できるから、

お前はSunやJavaCommunityProcessに丸投げしたことあるのかw
丸投げコストと時間的ロスは通常の下請けを上回るぞw

>>648
> Javaだとアフォでも24時間前提のソフトが書けちゃう、ってことですかい？
> まぁ、アフォを救うためにAP鯖が頑張ってくれてるんだろけど。
アフォにJavaを使わせてもアフォな使い捨てソフトしか作れんよ。
それじゃ再利用性なんてますます遠のいていく。

>>655
バカでも使えるとかドカタでも使えるとかいってる奴の
ほうがよっぽど表層的、っていうかただ煽っているだけで
自己満足して幼稚、小学生並みの知能しかない証拠。

>>656
誰が？　言ってみ？

バカにはJavaを使いこなせないって事さ。
JavaはPHPやPerlやVBやC言語のように馬鹿でも使える？　それは幻想さ。
真の意味でJavaを使いこなすにはそうとうの鍛錬が必要であることには
かわりないわけだ。

その通り。
だからどこもかしこもデスマ。

Java で ant がどうとか言ってる奴はさ、
一度その変の現場の様子見てみればいいんだよ。

圧倒的多数は仕様どおりにビジネスロジックをコツコツ組むことしか
できない(or やらない)奴ばっかりなんだから。

ってかJavaプログラマは大抵が下請けか派遣なんだから、
言われたことを言われたとおりに実装するのが当たり前。
高度な知識など要求されないケースが多い。

煽りでもないし、Java が C より劣るとかじゃなくて、単純に今の業界の姿が
そうなってるのは事実じゃないか？

と言ったあとであれなんだけど、携帯電話開発ではどうやら>>663
の逆のことが発生している模様ですよね　(質の悪いCプログラマを
大量に集めて開発してる）。

サーバサイドは普通にCとか思ってるのですが変でしょうか・・・。
つーかWebサーバのみがサーバじゃないよね？

WEBサーバ (Apache, IIS 等) もCで書かれてるよね。
そういう意味？

普遍的な真理はC/C++が一番
JavaでLinux作ってくれ。作ったらJavaを認めてやる。

アフォなSEはコネクションなどのクローズをfinalizeでやろうとする。
finalizeが走るまでリソースが握られっぱなしになることに気がつかない。

業務ドカタは言語がもつパワーレベルを
業務開発に絞って比較する事しかできないのが問題なんだな。

>サーバサイドは普通にCとか思ってるのですが変でしょうか・・・。
>つーかWebサーバのみがサーバじゃないよね？

665はまともだな。おJava馬鹿さんたちは自分らの土壌である
(エンタープライズ)Webアプリケーションが開発の全てと思っている。
だからいつまでも話は平行線。

Java厨は弱い格闘家みたいだな。
挑戦をうけるとまずK-1ルールを自分の有利な方向に固める
(1)業務開発
(2)エンタープライズWeb業務アプリケーション

この前提で話を進めていく傾向がある。

＠ＩＴの記事の一部抜粋

>得てしてプログラマの立場では、自分が現在使っている言語を持ち上げたり、
>派閥を作ったりして排斥したりするものだが、そのような振る舞いは、
>ITアーキテクトにとって百害あって一利なしと、この際なので断言してしまおう

やっぱり人間性の問題かね？

Javaは再利用性ありまくりだお？
なんたってVMが何度もつかいまわせるんだぜ〜

ん、VMがパラレルVMにいつからなったの？
すげえなー

まとめると

●Java厨はサーバというとWebサーバしか頭にない
●開発といえば業務アプリしか頭にない
●Webサービスの話題をふると話がとまる。でたとしてもせいぜい
　サービスを利用するクライアントで使っているとえばるだけ。

■結論はJava厨は弱い格闘家

だからなんでもかんでもHTTPに載せてサーブレットなんだよなー。

>>676
それは回答の一つだけど、それがファイナルアンサーじゃないし、
別の回答もあるという事を当たり前に認められないのがJava厨。

ぶっちゃけWebサービスは非同期通信であることが肝、
非同期通信だと開発効率はライブラリーが素晴らしかろうが
平等に低下する。組んでポンはやっていけないからな。
単純な動作ﾃｽﾄも同様。

おまんこおまんこ

>>663
> Java で ant がどうとか言ってる奴はさ、
> 一度その変の現場の様子見てみればいいんだよ。
> 圧倒的多数は仕様どおりにビジネスロジックをコツコツ組むことしか
> できない(or やらない)奴ばっかりなんだから。
> ってかJavaプログラマは大抵が下請けか派遣なんだから、
> 言われたことを言われたとおりに実装するのが当たり前。

そんなやつのどこがJavaプログラマなんだ。
そんなやつにJavaプログラマなどと名乗らせることが間違い。
勘違い君としてかなりイタイやつだ。

> 高度な知識など要求されないケースが多い。
それでJavaの特性を生かせず、せっかく大学で高度な
知識を学んでもフイにするのか。才能あるやつも才能を開花させる
ことなく尾wる。まさに人生の無駄遣いというやつだ。

> 煽りでもないし、Java が C より劣るとかじゃなくて、単純に今の業界の姿が
> そうなってるのは事実じゃないか？
そんなことをしているからデスマになっているということも事実なわけだが。
Javaを使わせる人間にドカタ程度の仕事しか与えないからデスマに陥る。

>>675
> まとめると
> ●Java厨はサーバというとWebサーバしか頭にない
とりあえず、そんなやつはこんな板には一人もいないから安心せい。
君の頭の中にだけは存在するようだが。
多くのJavaアーキテクトが、データベースサーバ、
DNSサーバ、SMTPサーバ、などのサーバ類を熟知している。
それらを知らない人間をJavaプログラマとは呼ばせるべきではない。

やっぱりただの煽りスレに成り下がっていたのか。
みんなJavaを認めたくないだけでかってに
無理やりこじつけで話を進めているに過ぎないんだな。

スレタイの思い軽いは既にどっかに行っちゃったみたいだしね

それらのサーバはJavaからは使うものであって作るものじゃないけどね。

JavaでDBつくるんすか？
重そう。

>>684
HSQLDBやApache Derbyを知らんのか？ないもののように言うと、恥かくぞ。

で？
あるから何？

ゴミは所詮ゴミ

>>677
ぶっちゃけWebサービスは非同期通信であることが肝、
非同期通信だと開発効率はライブラリーが素晴らしかろうが
平等に低下する。

そうだと思います。
例えば、汎用系とつなぐ場合、メッセージングサービス(JMS)の機能(キュー機能)を使うとする。
一般的に言って、メッセージサーバとのインターフェースであるJMSメッセージリスナーは
・順次処理(一つが終わるまで次に移れない)
・複数のJMSリスナーを並列処理できる
という相反しそうな２つの機能を持っているから、２つのリスナーにくるそれぞれのオブジェクトを司っているそれぞれの元オブジェクトの片方が実は、
もう一方のリスナーの処理待ちというような、順次処理に起因するデッドロックも充分ありうる。
そして、メッセージサービスは速度という点で問題あり。
だと思います。

というか、サーバアプリやサービスの話だと思ってたんだが・・・。
ここまで来ると釣りとおもってしまいそうだ。
普通に思考が狭いんだねJavaプログラマーって・・・。

ぶっちゃけドカタというのは酷いと思ってたんだが。
納得しつつある。

＞６８９
ＷＥＢと内部環境との共通点は、「非同期」だと現状では思うけれど。
非同期というのはお互いにメッセージをやり取りする、
たとえば、htmlやxmlやsoapのような。
そこで、ＷＥＢに対して、内部環境でのＪＡＶＡアプリケーションの「非同期」機能であるメッセージングサービスを参考するのは別に話としては通っていると思う。

キャンセルする命令があった場合の取り消し処理とかがあったり
した場合は内部処理部分のメッセージキューイングも問題になってくる。
そういった処理は当たり前だがライブラリーは解決してくれない。

マルチスレッドよか非同期通信はある意味難しい。
命令の正当性は確立されないわけで、処理の割り込みとかが
必要になってくる。バグの温床だな。

ちなみに勘違いしてる人が多そうだけど、
＞サーバサイドは普通にCとか思ってるのですが変でしょうか・・・。
＞つーかWebサーバのみがサーバじゃないよね？
とか。
>Webサーバのみがサーバじゃないよね
全くそうのとおりで、現状サーバサイドJAVAというと
WEBサーバ　−　アプリケーションサーバ(ここ！)　−DBとか他の外部システム
の「ここ！」のことを言っている。製品も揃っているし、ある程度確立している。
ただ、問題なのは、製品のアプリケーションサーバで対応していない環境や製品(例えばC++などで作られた)に対してどうかというと言うことと、
ＷＥＢ環境ではこれが往々にしてあるということ、でしょう今までの論点は。

非同期での
>命令の正当性は確立されないわけで
例えば、かつての多拠点分散ＤＢであった、「どうやって命令の正当性を確認するか」というのは一つの問題でしょう。
この場合、片方に返事が返ってこないと、片方がCOMMITして正常完了で、片方がROLLBACK？みたいな。
ただ、JAVAだと、EJBが分散トランザクションに関しては、強力にサポートしているから、主軸はそこに則ってやればよいのだと思う。

はあ？
サーバアプリはサーブレットで書くのが効率と安定性の
両立させてるという点でもはや最強だろ。
C++で書くなんてバカのやることだ。

>>694
そうですけど、ＷＥＢ環境だと、
WEBサーバのすぐ裏で動くのがJAVAのオープン系のSERVLET、JSPとは限らない。
その場合どうするのか。
片方のWEBサーバのすぐ裏にJAVAアプリサーバをはさむか、或いは、サーバサイドJAVA側でC++、JNIなどでインターフェースを作るか。
後者の場合、JVMという一種のコンテナが速度のじゃまになるし、ロードされてるかされてないか、オブジェクトがactivateされてるかpassivateされてるかで速度が変わってくる。

＞６９５訂正
後者の場合＞JAVAを使うと

所で、ｸﾗｲｱﾝﾄがﾌﾞﾗｳｻﾞだと誰が規定したの？

ブラウザが標準だから

なるほど非常によく納得できた。

やっとわかったか。

このスレって「サーバ」と「DB」をNGワードにすると短文の煽りばかりになるね

通信用語の基礎知識
ttp://www.wdic.org/w/MOE/%E3%81%98%E3%82%83%E3%81%B0%E3%81%93

じゃばこ
Javaの非公式マスコットキャラで、二頭身のロリロリかぶり物キャラ。
曰く、本家のマスコットDukeは余りにも「じゃばこ」発案者たちの感性から逸脱しており、
マスコットとして受け入れることは非常に困難であった。
そこで、本物のマスコットを被った少女として作られたのが「じゃばこ」である、とされる。
語尾に "じゃば〜" を伴う。

>サーバアプリ
ﾌﾟｯ　業務系でサーバで動作する非サービス系
>サーバサービス
業務系とは違う高度系

Java厨って単にWebサーバで普通のアプリ書くから
サーバアプリなんですねw

ビジネスロジックの次は

【サーバアプリ】　だなw

は？

携帯ﾄﾞｶﾀが勘違いしています。

WebサーバとJavaのアプリケーションサーバはhttp通信(もちろんssl含む)してるから、
同一マシン上でも別マシン上でもどちらでも構わない。
ただ、ServletとJSPは同一Webコンテナ上で動き、もとい、コンテナの底にある同一JVM上で動くから、
直接JVM上で動くJavaBeansと共に、同じマシン上になければならない。
EJBは、同一マシン上でもいいけれど(速度や利用の仕方によって)、別マシンでしかも複数存在するためにある(分散環境)。

>>703
煽りだよな？バカすぎるぞ

>708の注記
JavaBeansはEJBもそうだけど無きゃいけない訳じゃない、
ServletやJSPで事足りるならそれでいい。
つらつら長いコードが嫌でないなら、Servletだけだっていい。

皆さん、注目してください！！！！！！！！！！！！！！！！！
　
C言語厨の正体は高卒であることが発覚しました！
さあ、Java叩きに必死になっているC言語を思う存分報復し虐めてあげましょう！！！


専門卒や高卒でPG/SEの人っているの？Part2
http://pc8.2ch.net/test/read.cgi/prog/1141003614/

>>711
いやもう必死なお前を見てるだけでお腹いっぱいです。

>>686
DerbyやHSQLDBを使ってくれといってくる顧客もいるわけだが。

>>689
> というか、サーバアプリやサービスの話だと思ってたんだが・・・。
> ここまで来ると釣りとおもってしまいそうだ。
> 普通に思考が狭いんだねJavaプログラマーって・・・。
Javaプログラマーの定義は
Javaで開発した経験がある者をいうわけだが。
会社に「これをJavaで作ってくれ」とお前が
いわれたらその瞬間からお前は無条件で
自動的にJavaプログラマーになる。
それでお前はドカタではないと言い張るのだな？
逝っていることが矛盾しているぞ。

お前はJavaを批判するまえに論理学を勉強しろ。

フレームワークに脆弱性が見つかったり、大変よ。

ひとことにフレームワークといっても無数にあるわけだが。
個々のフレームワークそのものに共通して脆弱性があるわけじゃない。
それをC言語厨やドトネト厨は勘違いしているようだ。

それは、C言語厨のレベルの低さ、低学歴な体質を物語っている証拠だ。

>>714
一般的な物言い理解できない程劣っていたのか・・・。
さくっと”Javaのソース読めるのならモマエもJavaプラグラマーだな(w"
と、一行レスしてほしい。

低劣で頭堅いんだから、物言い位気を使え。
罵倒の方がまだしも気が楽になる。

いや俺は修士卒でC言語厨だが・・・・
あれか？博士卒になると今度はJava厨になるってパターンか？

おれも修士卒だがJava厨
おれがもし博士号とったらD言語厨とかアスペクト指向厨に
なるってパターンか？

>>718
お前制御系の研究でもしていただろ。

>>720
いや人工知能の研究でした。
CommonLISPやPrologもやった。

エージェント指向の研究はちゃんとやったか？

>>722
やったが結局アレは絵に描いた餅だとわかった。
今で言えばWebServicesとグリッドが目指す先がアレですな。

>>721
Prologやったよ・・・大学時代だけど。
院時代は情報工学でも非コンピュータだったのに、
コンピュータ業界に入っている漏れって。

>>721
おまいは俺の取引先か。

おまえらやっぱりC/C++がいいだろう。

高級言語と低級言語の狭間で究極のバランスを実現したのがC
そのCを踏まえて、それに対する拡張を個々の場で適用できるように互換性最重要視で
付加したのがC++。

サールゥ・Ｃ言語リラ・チンパンジ〜♪

>>723
そもそも人工知能の研究なんて
すること事態がアフォだぞ。
頭の良い教授に馬鹿にされなかったかw

速度と使い勝手の究極のアンバランスを実現したのがEJB
そのEJBを踏まえて、それに対する拡張を個々の場で適用できるように互換性重視
でだめな実装をしたI/Oマッピング

>>726
Javaの研究をしているところもあるわけだが。
そりゃJVMの研究なのでC/C++が関係ないとは言えんがな。
だがJavaが研究には関係ないと言ったら大嘘だ。
Javaに関する論文はいくつも出ている。
タイトルのJavaとつく論文も無数にある。
にもかかわらずJavaを攻撃するとは非常に愚かだ

Java＝ドカタのスコップ

eclipse=作業服

随分高貴なドカタと高価なスコップと高価な作業服ですね。

でもただで手に入るんだよね

囚人服は支給されるもの。

作業服と囚人服は異なるものだね。

Eclipseがタダっていっても44億円相当もするんだけど

有料じゃ誰も使わねえよ

Eclipseの上位版WSADを使う者はけっこういるんだけど。

上位版は作業服、下位版は囚人服

胸に刺繍が入ってるかどうかの違い

オプソマンセーならemacs使え。腐れJava厨ども

【IT】米Red Hat、JavaアプリケーションサーバのJBossを3億5000万ドルで買収へ
ttp://news18.2ch.net/test/read.cgi/bizplus/1144700222/

お金もちやなー

Eclipseもオープンソースであることを知らずにEmacsだけを使えと行う
C言語厨の馬鹿共は浅はか委譲の何者でも無いな。

JAVA　悟空


　　　　　　　　　　　　　　　　　　　　　　　　　　サルでも　　　　　　　　　　　　　 （　　(
　　　　　　　　　　　　　　　　　 　,,.ｒ'' ゛~~` ''ッ,,　　立てねーぞ　　　　　　　　　　　　　) 　 ）
　　　　　　　　　　　　　　　　　､ ゛　 ,,,,,,,,,,,,,,,,,,,,, ヾ.　　 こんなスレ 　 　 ,.、　　　/ ／
　　　　　　　　　　　　　 　 　 ﾐ　　 ﾐ゛,へ.__, ,_ﾉヽ i.　　　　　 　 　 　 　 　 .| |l　　　l ,´
　　　　　　　　　　　　　　　 ﾐ　　　 ﾐ,　( ・) {・ﾌ 〉 ﾐ.　　　　　　　 　 ＿-､i::| |ニニii '
　　　　　　　　　　　　、,,,,ツi:　　　　 ﾐ,｀~´ ヽ~〈　 .ﾐ　　　　　　　　/,‐ヽヽ`､||
　　　　　　　　　　､ｼ`｀　　 i:　　　 　 ,ゞ 　'ｎ.inヽ. .ﾐ　　　　　　　　　　（ .〉〉/
　　　　　　　　　ｼ　 ／／　　　　　　ﾐ｀　　　 l.l　ヽ"、　　　　　 　 　／　 ノ
　　　　　　　 ﾐ/ ｼ　　　　　　　　 　 彡　,＝こ二=.{　ﾐ,,　　　　　 ,ｒ'´　,,､'゛
　　　　　 　 ﾐi. / 　/　　　　　　　' ! w､｀~^' vwｖ '､ 　 ﾐ 　 　 　〃　.ﾐ
　　　　　　 .ﾐ /　　　　 i: 　/　　　　　　｀＾^　　　　 ＼ ."　　　〃 　ﾐ
　　　　　　.ﾐ.:/　/　/　i:　　　　　　ｖ　　　　!　　,,　　　＼ ､　〃　　ﾐ
　　　　　　：i;　　　　 .i:　　　ｗ　　　　　　!!　　 ミ!:　　　ﾐ ＼＼(　⌒ヽ
　　　　　　:i;　　/ 　 i:　　　　　　!!　　　　　　 .ミ ｷ　 　 , ⌒｀、_　　)　 ）
　　　　　 :iｌ　　　　 .i:　　　　!　　　　ｗ!　　　 ミ　.:i.　　　（_ (　　_,ノ　　） ,
　　　　　:iｌ　　　!　 i:　　　　　　　　　　　! ,〃゛　　ｷ　　 　ゞ、 __,　 ノ ,
　　　　 .:iｌ　!　 　／~~｀｀``` " '''' ＝ ‐- ､ﾐ　　_,,,,_ﾐ,　　il　`　　ー　´
　　　　 :iｌ　　　´ ―　￣　- ,,. -‐‐-､、　ヽ. ヾ、　　ゞ､　`　 〃
　　　　　ゝ､ｗｘ.mn.!!++ナ'~ 　　　　　ヾ~ヽ、　ヽ、　,,　~^^}´
　　　　　　　　彡　　 〃　　〃　　　　 }｝　/〉.〉〉〉i''"　　 〃
　　　　　　　　　彡､ 　　　 ｛{　　　　 〃,__!////l |　 　 〃
　　　　　　　　　　 X,,　　　　》.　　　≪.__`‐'.' '´,Uwwvw'､...,,,___
　　　　　　　　　　　　＾＾＾＾ !ｗニこ)こ)二）｀) （＿,,,..- ､...二⊃_).)

JAVA　悟空


　　　　　　　　　　　　　　　　　　　　　　　　　　サルでも　　　　　　　　　　　　　 （　　(
　　　　　　　　　　　　　　　　　 　,,.ｒ'' ゛~~` ''ッ,,　　立てねーぞ　　　　　　　　　　　　　) 　 ）
　　　　　　　　　　　　　　　　　､ ゛　 ,,,,,,,,,,,,,,,,,,,,, ヾ.　　 こんなスレ 　 　 ,.、　　　/ ／
　　　　　　　　　　　　　 　 　 ﾐ　　 ﾐ゛,へ.__, ,_ﾉヽ i.　　　　　 　 　 　 　 　 .| |l　　　l ,´
　　　　　　　　　　　　　　　 ﾐ　　　 ﾐ,　( ・) {・ﾌ 〉 ﾐ.　　　　　　　 　 ＿-､i::| |ニニii '
　　　　　　　　　　　　、,,,,ツi:　　　　 ﾐ,｀~´ ヽ~〈　 .ﾐ　　　　　　　　/,‐ヽヽ`､||
　　　　　　　　　　､ｼ`｀　　 i:　　　 　 ,ゞ 　'ｎ.inヽ. .ﾐ　　　　　　　　　　（ .〉〉/
　　　　　　　　　ｼ　 ／／　　　　　　ﾐ｀　　　 l.l　ヽ"、　　　　　 　 　／　 ノ
　　　　　　　 ﾐ/ ｼ　　　　　　　　 　 彡　,＝こ二=.{　ﾐ,,　　　　　 ,ｒ'´　,,､'゛
　　　　　 　 ﾐi. / 　/　　　　　　　' ! w､｀~^' vwｖ '､ 　 ﾐ 　 　 　〃　.ﾐ
　　　　　　 .ﾐ /　　　　 i: 　/　　　　　　｀＾^　　　　 ＼ ."　　　〃 　ﾐ
　　　　　　.ﾐ.:/　/　/　i:　　　　　　ｖ　　　　!　　,,　　　＼ ､　〃　　ﾐ
　　　　　　：i;　　　　 .i:　　　ｗ　　　　　　!!　　 ミ!:　　　ﾐ ＼＼(　⌒ヽ
　　　　　　:i;　　/ 　 i:　　　　　　!!　　　　　　 .ミ ｷ　 　 , ⌒｀、_　　)　 ）
　　　　　 :iｌ　　　　 .i:　　　　!　　　　ｗ!　　　 ミ　.:i.　　　（_ (　　_,ノ　　） ,
　　　　　:iｌ　　　!　 i:　　　　　　　　　　　! ,〃゛　　ｷ　　 　ゞ、 __,　 ノ ,
　　　　 .:iｌ　!　 　／~~｀｀``` " '''' ＝ ‐- ､ﾐ　　_,,,,_ﾐ,　　il　`　　ー　´
　　　　 :iｌ　　　´ ―　￣　- ,,. -‐‐-､、　ヽ. ヾ、　　ゞ､　`　 〃
　　　　　ゝ､ｗｘ.mn.!!++ナ'~ 　　　　　ヾ~ヽ、　ヽ、　,,　~^^}´
　　　　　　　　彡　　 〃　　〃　　　　 }｝　/〉.〉〉〉i''"　　 〃
　　　　　　　　　彡､ 　　　 ｛{　　　　 〃,__!////l |　 　 〃
　　　　　　　　　　 X,,　　　　》.　　　≪.__`‐'.' '´,Uwwvw'､...,,,___
　　　　　　　　　　　　＾＾＾＾ !ｗニこ)こ)二）｀) （＿,,,..- ､...二⊃_).)

お、EJB知っている奴が出て来たか。
おーい、EJB使って早くなった事あるか？
NSの営業に分散して早くなるって聞いたんだが、早くならないどころか「劇的に遅くなった」んだけど。
マシンを増やせば早くなるって言ってたけど、CPUボード増やした方がずっと安上がりで高速なんだけど。

EJBってJBossの事？

しらねぇ。
javaって省略した言葉ばっかりあってそれが何を指すのか全くわからない。
調べても今度は長い単語とその意味が全くわからない。
いくらなんでもネーミングセンス悪過ぎだろｗ

ハヤリモノには乞食が群がるのが世の常だが
ITとかいう (それだけで胡散臭い) 業界の乞食は
　　「難しそうな単語で素人を煙に巻く」
　　「素人は解ったような解らんような気になる」
　　「不安になった素人は乞食に金を出す」
という手段で儲けているわけよ。
で、そいつらの操る単語を調べてみると
こっち (コンピュータ業界) だと10年も前からある技術を
ただ言い換えただけだったりね。

流行りものに飛びついて痛い目にあっての繰り返しだよな。この業界は。
ここ10年ほどは特にその傾向が顕著に。

そうして今日も深夜のjarファイル交換

EJBがはやりものとして古事記によって
飛びつかれるような胡散臭いものであったかどうか
別としてＥＪＢのライバルとして鳴り物入りとして登場した
.NETは最初だけハヤリモノとしてもてはやされ２番手として
期待されていたものの結局枯れることも普及することも
市場が拡大することも無かったな。

>>747
営業の言うことを鵜呑みにしただけで
実際に開発のノウハウを身に着けずに
計画的に設計しないから
そういうことになるんだよ。

どんなに優れた技術でも素人が使えば
性能をいかしきれないことは常識だ。

【IT】米Red Hat、JavaアプリケーションサーバのJBossを3億5000万ドルで買収へ
http://news18.2ch.net/test/read.cgi/bizplus/1144700222/

>>748
EJBが使えるオープンソース製J2EEサーバ
ってことであってＥＪＢＪＢｏｓｓはそのものでもなく
JBossはEJBそのものでもない。

なにが重いってEJBほど重いもんはない

EJB直したらJBOSS再起動

作業は深夜

再起動に10分

WindowsServerの起動より時間かかるなんてもう。

ありえねぇ・・・・

リデプロイメントって必ず変にならね？
だから一回jboss落としてからデプロイして起動する

おせえよ

>>758はホットデプロイを知らない大場か者だという
ことが発覚しました！！！！！！！！！！！！！！！！！！！！
！！！！！！！！！！！！！！！！！！！！！！！(強調表示)
！！！！！！！！！！！！！！！！！！！！！！！(強調表示)
！！！！！！！！！！！！！！！！！！！！！！！(強調表示)
！！！！！！！！！！！！！！！！！！！！！！！(強調表示)
！！！！！！！！！！！！！！！！！！！！！！！(強調表示)
！！！！！！！！！！！！！！！！！！！！！！！(強調表示)
！！！！！！！！！！！！！！！！！！！！！！！(強調表示)
！！！！！！！！！！！！！！！！！！！！！！！(強調表示)
！！！！！！！！！！！！！！！！！！！！！！！(強調表示)
！！！！！！！！！！！！！！！！！！！！！！！(強調表示)

稼動中の鯖でホットデプロイして問題が絶対におきないことを
客に保証できればな

無理だろ（ｗ

EJBなんて知りたくもねぇ

>>766みたいな馬鹿にはEJBを使いこなすことができないからなw

ホットデプロイはEJBの仕様じゃなくAP鯖の独自仕様だろ。

つーか、EJBが糞なのはもう確定事項だろ

お前がクソだ

いやいや、EJBがクソでしょ

SessionBeanとMessageDrivenBeanはそんなに悪くないと思う

まずBeanとかいう名前からして糞

ごめん

どうやら>>771のようなクソにはなんでもクソに見えるらしい

>>773
じゃドトネト厨みたいにPropertyとでもいうのか(ﾜﾗ

それにJavaという名前からしてクソだし

EJB知らない人に説明すると、
EJBとは「Javaのクラス」を「EJBサーバ」上で管理／動作させるようにして、共有を可能にした物。
処理能力が足りなくなった場合は「EJBサーバ」を追加することにより分散が可能になる。
アプリケーション−EJBサーバ間は通信を行うため、呼び出し回数が多いと非常に低速である。
EJBとして作成するクラスの他にリモート側IFとローカル側IFが必要だが、最近は自動生成される。

ちなみにEJBサーバはかなり重く、P400などでは実用に耐えない。
昔のプロジェクトでは起動やEJB登録に15分かかったりした。
このEJBを、
「使い方が悪い」とか言っている奴。
どうしたら正しく使えるのかを是非聞きたい。
EJBを使って「EJBなし」より早くするのは可能なのか？

こんな大げさな仕組み危なくて使えない。
とてもエンタープライズな世界では使えない。
よってEJBはいらない。クソ

RPCというのが高速だった試しはないだろ。
そもそも分散処理するんだったら、回線がボトルネックになるんだからよほどの疎結合じゃなければ低速になって当たり前。
おまけにJavaは仮想マシンだからもともと重いよな。
クラス間のデータ交換の頻度と量が極小になるポイントで分割するようなシステム設計できない限り
これ便利だから共有スッペとか、これ面倒だから共有スッペのレベルになっちまえば破綻するのは当然。

構内専用でギガイーサで張ってあるとかATM直結とかそういうとこならまだしも、
公衆回線に近いインターネット経由でんなこと本気でやる奴がいるとしたら能天気なJava厨ぐらいだと思うが
やっぱりそういうことで理解は正しいのか？

漏れは素人だから説明してくれ>>778

もうすこしわからないので更に聞いておく。

Javaだとオブジェクトを生成してオブジェクトを引き渡すわけだから、こんな感じになるんか？
　・最初にクライアント側でインタフェースを生成
　・通信でサーバ側にオブジェクト生成を依頼
　　・サーバ側はオブジェクトとインタフェースを生成　場合によっては別サーバに依頼することもあり
　・クライアント側で引数に渡すオブジェクトを生成
　・通信でインタフェース越しに引き渡されるオブジェクトをシリアライズしてサーバ側に送信

　　（ここで劇重いローカルOSとインターネット介在？）

　・サーバ側はデシリアライズして受け取ったオブジェクトを再構築。
　・サーバ側がオブジェクト動作実行
　・サーバ側はクライアント側に引き渡すオブジェクトを生成
　・通信で生成したオブジェクトをシリアライズしてクライアント側に送信

　（同上）

　・クライアント側でインタフェースが受け取ったオブジェクトをデシリアライズして呼び出し側オブジェクトに返す。

用語とかは適当だ。かなりまんどくさそうだな。

糞ってか「やりすぎ」ってのが多いよなJavaの周辺は。

イソターネット上で分散が可能と主張する人はおらんでしょ

データセンター内にたくさんサーバ入れてくれれば速くなる or
可用性が高くなる（可能性が無いとはいえない）とは思うけど

定義したクラス次第ではピンポンのようにトランザクションが大量に発生する悪寒がするが気のせいか？

CORBAの昔から細かくオブジェクトをやりとりしないように適当なコンテナに入れて
まるごと送受するような感じ。無理にリモートオブジェクトを使うとメソッドを
呼び出すたびに通信が発生する、のでお勧めできない。

>781
778ではないけれど、それを修正させてもらうと、
・インターフェースは事前にJARファイルとしてまとめられる。
・サーバ側からクライアント側に渡すのは「参照」オブジェクトであって、
実体はサーバ側にある。クライアントはJAVA言語の「参照」の機能とRMI・IIOP通信(CORBAの派生)を使って、
サーバ側にある「実体」を「参照」する。参照オブジェクトを送るときも、実体を参照するときも、当然シリアライズされる。

>アプリケーション−EJBサーバ間は通信を行うため、呼び出し回数が多いと非常に低速である。

いずれにしろ、これには変わりないと感じる。使い方が悪いのか、下手なのか。

クラスのメソッドは、ネットワーク経由で呼び出すには粒度が細かすぎるような気はするよね。

#例えギガビットでも

簡単に言うと、
サーバはクライアントから依頼を受けると、サーバはクライアントに参照オブジェクトまんまを渡して(例えば参照関数まるごと)、
クライアント側では、(C++でもJavaでも参照あるけど)、参照をリモートに対して行っている。
と思えばいい。

また、
サーバ側で、参照オブジェクトを作る際、サーバローカルに無い場合は、ネーミング&ディレクトリサービスであるJNDIを用いる。
JNDIはローカル利用のAPIとリモート利用のSPIを含む(EJBにはLDAPサーバ、COSネームサーバ、DNSサーバ、DNSサーバなんかが含まれてる)。
使い方は、
１．クライアントがJNDIに問い合わせて、場所を聞く。
２．サーバはクライアントに、リモートオブジェクトオブジェクト作成の参照を返す。
３．クライアントはサーバにリモートオブジェクト作成依頼を出す。
４．サーバはリモートオブジェクト参照を作成し、それをリモートに渡す。
５．リモートで、リモートオブジェクト参照は、ＥＪＢをインスタンス化してＥＪＢの実体を作る。
そして、サーバはこのリモートオブジェクト参照をクライアントに渡す。
６．クライアントにあるリモートオブジェクト参照がリモートのＥＪＢ実体を参照する。

かなり多い。

訂正。
４、と５、のリモートオブジェクト参照＞リモートオブジェクト
(参照を削る)

但し、５、の
>そして、サーバはこのリモートオブジェクト参照をクライアントに渡す。

ここの「参照」は省かなくていい

＞７８８もう一個訂正
＞DNSサーバ、DNSサーバ

RMIレジストリサーバ、DNSサーバ

おちんちん

>>777
ドトネトなんて名前はもっとクソだなw
なにせ怒濤熱湯だからなw

>>780
> RPCというのが高速だった試しはないだろ。
> そもそも分散処理するんだったら、回線がボトルネックになるんだからよほどの疎結合じゃなければ低速になって当たり前。
> おまけにJavaは仮想マシンだからもともと重いよな。
> クラス間のデータ交換の頻度と量が極小になるポイントで分割するようなシステム設計できない限り
> これ便利だから共有スッペとか、これ面倒だから共有スッペのレベルになっちまえば破綻するのは当然。
> 構内専用でギガイーサで張ってあるとかATM直結とかそういうとこならまだしも、
> 公衆回線に近いインターネット経由でんなこと本気でやる奴がいるとしたら能天気なJava厨ぐらいだと思うが

そんなことを想像するのはお前みたいな世間知らずなC言語厨くらいだが。
そんな管欄理由でEJBが使えないとぬかしているものならアホ

>>780
> RPCというのが高速だった試しはないだろ。
> そもそも分散処理するんだったら、回線がボトルネックになるんだからよほどの疎結合じゃなければ低速になって当たり前。
> おまけにJavaは仮想マシンだからもともと重いよな。
そこでその部分だけC++にすれば劇的に早くなってかつJavaからリプレースする
価値があることを示すベンチマークがあるなら提示してくれ。
回線速度がJavaによって著しく低下することを示すデータも提示してくれ。

>>781

> 　・通信でインタフェース越しに引き渡されるオブジェクトをシリアライズしてサーバ側に送信
> 　　（ここで劇重いローカルOSとインターネット介在？）

EJBが常にクライアントサーバ間の通信だけにしか使わないとでも思っているのか。
通常は、EJB周りは同じネットワーク内で分散処理に使うものなのだが。
インターネットを介するならWSDL等を使うのが普通。

>>784
transientかExternalizeでググれ

>>785
> CORBAの昔から細かくオブジェクトをやりとりしないように適当なコンテナに入れて
> まるごと送受するような感じ。無理にリモートオブジェクトを使うとメソッドを
> 呼び出すたびに通信が発生する、のでお勧めできない。

なにいってんだお前。

>>786
> >アプリケーション−EJBサーバ間は通信を行うため、呼び出し回数が多いと非常に低速である。
> いずれにしろ、これには変わりないと感じる。使い方が悪いのか、下手なのか。

プーリングくらいしておけ。

呼び出し回数が少ないとそれはそれでパッシベートされちまうぞ

EJB に関する Pravin Tulachan との Sun コミュニティチャット

・粒度の小さなメソッドをネットワーク越しに呼び出すような形態は避けてください。
　　代わりに、バリューオブジェクトやセッション・ファサードといったデザインパターンを使いましょう。

>>798
理解できないなら黙ってろ、低脳

JAVAにするだけで重くなる例なら山ほどあるな。
JAVAのメリットがあるとすれば「アホなプログラマに作らせた場合の不具合が減る可能性がある（単純だから）」という点につきる。
屋下に屋を架すというのがJAVAの本質。本当はそんなもの使いたくないけど、仕方がないとき使う。

JAVA厨が必死な理由＝自分が楽が出来るから。
アホだとばれて他の言語移行できない能力の低さが露呈すると困る輩がわめいてるんだと思われる。
「客先はどとねっとがいいっていうんだが・・」　「なにいってるんですか、JAVAがいいんですよJAVAにするだけでこれだけメリットが！」

SUNの工作員がこんな低俗なアホどもの訳はないから当たってると思うぞ。

同じネットワーク内でも遅いって。
イーサネットの通信は一瞬、０とみなすのが業務系ﾄﾞｶﾀの特徴。
100ミリ秒以下は計れないのがJava脳

> JAVA厨が必死な理由＝自分が楽が出来るから。
ホントに楽できるならいいやん。
楽できるように見えて、後で性能で泣くのがJava。

Javaはエンドユーザと直接接しない派遣ﾄﾞｶﾀさんにとっては楽だと思うよ。
ツール類は無償のものが多いし、限定された環境では簡単によく動く。
営業や紺猿も楽だ。@IT、IBM、SUNのサイトを歩き回ればﾏﾝｾｰ文書が
いくらでもある。それをコピペして切り貼りし修正すれば、プレゼン資料のいっちょあがり。

一番辛いのは、運用する側の人間。実際の環境では問題が噴出し、修正しようにも
長時間の再起動時間が必要で深夜にしか作業ができず、地獄を見ることになる。

ITライターも楽
インストールや簡単なサンプル作成で記事になる。
これがMS製品だとその辺は自動化されてたりドキュメント化されてるから、
もっと突っ込んだ記事を求められる。

>>一番辛いのは、運用する側の人間。実際の環境では問題が噴出し、修正しようにも
運用の仕事だけはお断りだ！

>>楽できるように見えて、後で性能で泣くのがJava。
フレームワーク作った奴だけが楽できる。
他の奴は、それを理解できなくて泣きを見る。

で、他の奴がスパケッティを作って、結局フレームワーク作った奴も泣く。
このパターンだろ。

>>もっと突っ込んだ記事を求められる。
.NETの流行らない理由か？

90年代後半に、営業やSヨがM$が糞なんですカードを切り過ぎてしまい
いまさらMS製品で提案できない。

コネクションプールは、対データベース用に使い回しできるデータソース集合(既にDBから引っ張ってきたもの)ですね。
これらをＥＩＳなんかにも使えということでしょうか？

EJBがｲｲとか言ってるのは
ﾈｯﾄﾜｰｸｲﾝﾌﾗも込みで提供しているｿﾘｭｰｼｮﾝ屋だけ

>>801
理解できないじゃねえ、無駄なことしてんじゃねえぞっていってるんだ低脳

>>802

> JAVA厨が必死な理由＝自分が楽が出来るから。

C言語厨が必死な理由＝Javaの価値が高まるとC/C++ができるというだけでは尊敬されなくなるから
だろ。図星か？

>>804
> JAVA厨が必死な理由＝自分が楽が出来るから。
> ホントに楽できるならいいやん。
> 楽できるように見えて、後で性能で泣くのがJava。

お前にパフォーマンスチューニングスキルが無いから
泣きを見るんだよ。
「Javaはアホでもできる」とタカをくくった無能なＣ言語厨
がそういう無きを見るわけだ。

>>805
> Javaはエンドユーザと直接接しない派遣ﾄﾞｶﾀさんにとっては楽だと思うよ。
甘いなお前は。すぐに辞めてしまう派遣やドカタにJavaを
使わせてもJavaの真価を発揮させることができないぞ。
かわりにドトネトやC言語ならやる仕事も減ってきているので派遣やドカタに
任せれば済むが。

> ツール類は無償のものが多いし、限定された環境では簡単によく動く。
有償ツールに依存しているお前のスキルに問題があることをよく考えてみることだな。

> 営業や紺猿も楽だ。@IT、IBM、SUNのサイトを歩き回ればﾏﾝｾｰ文書が
> いくらでもある。それをコピペして切り貼りし修正すれば、プレゼン資料のいっちょあがり。

その程度でプレゼンができあがるならお前も苦労しないなw

> 一番辛いのは、運用する側の人間。実際の環境では問題が噴出し、修正しようにも
> 長時間の再起動時間が必要で深夜にしか作業ができず、地獄を見ることになる。

それは長時間の再起動が必要になるような設計しかできない能力程度しかないお前が悪いわけだが。

>>806
> ITライターも楽
> インストールや簡単なサンプル作成で記事になる。
> これがMS製品だとその辺は自動化されてたりドキュメント化されてるから、
> もっと突っ込んだ記事を求められる。

ドトネトは単なるJavaのパクリだからJavaｙよりも優れた利点を
突っ込まれて当然なわけだが。
Javaの二番煎じなドトネトにJavaとは異なる新規性がどれだけあるんだw

>>807
> 一番辛いのは、運用する側の人間。実際の環境では問題が噴出し、修正しようにも
> 運用の仕事だけはお断りだ！
> >>楽できるように見えて、後で性能で泣くのがJava。
> フレームワーク作った奴だけが楽できる。
> 他の奴は、それを理解できなくて泣きを見る。
> で、他の奴がスパケッティを作って、結局フレームワーク作った奴も泣く。
> このパターンだろ。
> >>もっと突っ込んだ記事を求められる。
> .NETの流行らない理由か？

ドトネトが流行らない理由はJavaをパクッタだけで
新規性が無いからだよ。Javaのような斬新さがないと意味が無い。

言ってしまえば。ドトネトは中国初の有人宇宙飛行みたいなもんさ。
中国人や中国政府にとっては誇りだが欧米人からすればなにをいまさらというものだ。
アメリカやロシアではもう何十年も前に有人宇宙探査(Java)に成功してアポロ計画も実現した
というのに中国(.NET)は21世紀になっていまごろ有人宇宙飛行を実現させている。
アメリカやロシアの技術をパクッタだけで自己満足しているあほ。それが,NET(ドトネト)の実態。
それが愚かなんだよ。

>>808
> 90年代後半に、営業やSヨがM$が糞なんですカードを切り過ぎてしまい
> いまさらMS製品で提案できない。

ドトネト製品はクライアントサイドでしか役に立たないことがすでに解っている。
サーバではさすがに長い信頼と実績と歴史を誇るJavaには勝てないからな。

Javaを叩いている奴がC言語厨とは限らないわけだが。
必死にM$製品の話を持ち出すドトネト厨も沸いているわけだが。

いまさらドトネトの宣伝をしても
笑えてしまうが、
ドトネトは仕事も無いしそんなことで
必死にM$製品の宣伝アピールしても本当に必死としか言いようがないわけだが。
C言語厨よりも必死だな。
C言語厨はBREW絡みで多少仕事は残っているからな。
それにくらべドトネト厨の仕事は本当にごく僅かだな。

>>802
> JAVAにするだけで重くなる例なら山ほどあるな。
> JAVAのメリットがあるとすれば「アホなプログラマに作らせた場合の不具合が減る可能性がある（単純だから）」という点につきる。

尽きない。アホに作らせても不具合は減らねえよ。
そんなにアホにでも作れるならお前らC言語厨の仕事は完全に無くなっているはずだ。

>>802はレスの流れからドトネト厨である可能性も否定できないわけだな。
ドトネト厨の自作自演による詭弁には気をつけねば。

> 屋下に屋を架すというのがJAVAの本質。本当はそんなもの使いたくないけど、仕方がないとき使う。
そういう心理にかられているのはお前みたいな新体制に反発する
時代遅れなバブルさせ代以降の抵抗勢力だけだよ。

> アホだとばれて他の言語移行できない能力の低さが露呈すると困る輩がわめいてるんだと思われる。

アホだとばれてドトネトから他の非ドトネト言語に移行できない能力の低さが露呈すると困る輩として
おまえみたいなドトネト厨やVB厨がわめいているわけなんだなw


「客先はJavaとPHPがいいっていうんだが・・」
　「なにいってるんですか、ドットネットがいいんですよドットネットにするだけでこれだけメリットが！」
M$の工作員がこんな低俗なアホどもの訳はないから当たってると思うぞ。

今度はM$厨が沸いているのか

Javaの代わりにドトネトを使ったところで
速さは劇的に変わるどころか一切変わらないんだが。
どっちもVMの上で動くんじゃね。

しかもIISというセキュリティの弱いサーバ上で
動くことを前提としているドトネトじゃ、Javaのように簡単には流行らないわけだ

M$の信頼性がもろにドトネトの現状にでているわけだ

なんかJava厨房が必死だけど
一つも反論になってないのが笑える。
「なぜJavaは重いのか。JavaはWindowsに寄生してる虫のようなものではないのか。
Java使いはなぜ一つの言語にこだわるのか」

まねまねいうならJavaって坂村のTRON構想のまんまぱくりだろ？ｗ

>>822 これからはVistaになる。
Vistaの標準コンパイラはC++/CLIだ。

いやおうなしにJavaコンパイラもJVMもVistaで動かすならばCLIになる。
つうことは、２重の仮想マシンで動く劇的に重い時代遅れのものになる。

糞高いLinux専用サーバ上ででも金持ちが動かす道楽者専用になるな。

本来、JavaとSolarisとSPARCという閉じた世界があって、その閉鎖性を強引に
クライアントであるPC側に吸収させようというのがJava啓蒙の理由なんだが理解してるか？
PCベースで無償のJavaつかってるということは、ただの道化なんだよ。
パフォーマンスが悪い？ではSolarisをどうぞ。
まだうまくいかない？それはｘ８６のせいです。SPARCをどうぞ。

これがSUNの戦略であり実態でもある。
お先棒担いでるJava厨房はおぷそ厨房にも似て哀れそのもの。
無償で宣伝の手伝いm9(^Д^)ぷぎゃー

>>824
> なんかJava厨房が必死だけど

どちからというと「なんかドットネット厨房が必死だけど
といったほうがしっくりくるんだけど。

>>824
> 一つも反論になってないのが笑える。

ドトネト厨房のほうが一つも反論になってないのが笑えるんだけど。

> 「なぜJavaは重いのか。JavaはWindowsに寄生してる虫のようなものではないのか。
「なぜ.NETは重いのか。.NETはM$に寄生してる虫のようなものではないのか。
とはいえないかね？

VB使いはなぜ一つの.NET環境にこだわるのか

ドトネト厨房はなぜサーバ環境ですらWindowsに拘るのか。

詭弁にもなってないな。

 これからはVistaになる。
 Vistaの標準コンパイラはC++/CLIだ。

 いやおうなしにJavaコンパイラもJVMもVistaで動かすならばCLIになる。
 つうことは、２重の仮想マシンで動く劇的に重い時代遅れのものになる。

 糞高いLinux専用サーバ上ででも金持ちが動かす道楽者専用になるな。
 本来、JavaとSolarisとSPARCという閉じた世界があって、その閉鎖性を強引に
 クライアントであるPC側に吸収させようというのがJava啓蒙の理由なんだが理解してるか？
 PCベースで無償のJavaつかってるということは、ただの道化なんだよ。
 パフォーマンスが悪い？ではSolarisをどうぞ。
 まだうまくいかない？それはｘ８６のせいです。SPARCをどうぞ。

 これがSUNの戦略であり実態でもある。
 お先棒担いでるJava厨房はおぷそ厨房にも似て哀れそのもの。
 無償で宣伝の手伝いm9(^Д^)ぷぎゃー

>>825
> >>822 これからはVistaになる。
> Vistaの標準コンパイラはC++/CLIだ。
> いやおうなしにJavaコンパイラもJVMもVistaで動かすならばCLIになる。

ならねえよ。今まで以前のOSで動いていたアプリがJavaであるでないに関わらず
全部CLIの上で動くとでもいうのか？

馬鹿も休み休みに言え

>>826
> 本来、JavaとSolarisとSPARCという閉じた世界があって、その閉鎖性を強引に
> クライアントであるPC側に吸収させようというのがJava啓蒙の理由なんだが理解してるか？

どうしたらそんなホラを吹けるんだドトネト厨馬鹿はw

>>831
> 詭弁にもなってないな。
ドトネト厨の発言は何から何まですべてが詭弁なんだよ。

> これからはVistaになる。
5年前にこれからはC#だC#だJavaは廃れるとか言っていた
馬鹿そっくりだな。結局C#は流行らなくなりJavaも廃れることがなかったしなw

> いやおうなしにJavaコンパイラもJVMもVistaで動かすならばCLIになる。
> つうことは、２重の仮想マシンで動く劇的に重い時代遅れのものになる。

それに似た嘘八百をよく2chで並べていたドトネト厨が4年前によくいたよなw

ドントネット厨が必死ですね

こいつはドトネト厨というか例のVB厨だろ3年も前からム板を
荒らしているあの餓鬼

閉鎖性の高い高価なサーバ専用マシンではJavaは生き残るのかもしれない。
しかし、安価に量産されるPCベースのマシンでは、Javaはもはや不要。
もっとも、JavaがJavaであることを捨て、CLIを受け入れればいいのかもしれない。
しかしそうなると高価なサーバ側のJavaとのバイトコードレベルでの互換性はなくなり
さまざまな「分散ソリューション」が破綻する。

Java厨房に明日はないかもしれない。

ＶＢしかできない口先だけの知ったか君が
ドトネトを宣伝しながらJavaを否定しているのか
説得力無いなあ

まあ、SUNと心中するか
泥沼の携帯JAVAでの生き残りをはかってみればいいんじゃね？

>>837
> 閉鎖性の高い高価なサーバ専用マシンではJavaは生き残るのかもしれない。
高価なサーバ＝閉鎖性が高いという根拠は？

> しかし、安価に量産されるPCベースのマシンでは、Javaはもはや不要。
そこでJavaが不要ならドトネトですら不要なんだが。
Swingのパフォーマンスが十分高速化した今、
JavaWebStartをパクってClickOnceみたいなもの程度しか作れないようでは
先も無いなドトネトには。

> もっとも、JavaがJavaであることを捨て、CLIを受け入れればいいのかもしれない。
SunとM$との約束によりそれもありえないなw

それと、DISC系でコンテンツ記述のマクロにJava採用とか言う話もあるそうだから
裏ビデオのコンテンツ編集なんかでJava厨房のいきるみちがあるかもしれねーな。

Javaを使うとSunと心中する恐れがあると信じている>>839みたいな馬鹿が
今だにいるんだねｗw

まさかいまだにJava Community Processを知らないなんてアホなことを
言うわけではあるまいw

>>841
寝言はJavaの仕事の件数と.ＮＥＴの仕事の件数を比較してから言ってみな

>>841現状では仕事の無いのはドトネト厨のほうだから
まさにそういう仕事をならドトネトで生き残る可能性はあるだろうなw

ドットネット厨房の生き残る道は裏ビデオ編集ソフトを作成することだけでしたww

件数と金額を掛け合わせたほうがいいと思うぞ。

究極、M$支配下ではPC系の仕事は激減するはずだしな。

MS 裏ビデオ.NET

>>846
それって今の現状じゃんw

だからサーバ系に強いPHPやJavaの仕事が
圧倒的に多いわけだw

>>846
金額はJavaは多い方だよ。
一件にかかる金額はPHPよりJavaの方が多く
おいしい。とくにJBoss絡みは

開発がPCの仕事しかないと思っている>>846って

誰もソフトを作る必要のない世界がM$の希求するところで、創造性はM$様のソフトの上で
別様に開花してもらえばいいって絵がかかれてて、実際にそうなってきてる。

Javaで独自性をと模索しても、クライアントのほとんどがM$支配下である現状を考えるとどうなんだろうな。
無論、携帯という世界はある。

あるけど、サーバサイドでサービス構築って構築屋もうかるんじゃなくて、あくまでビジネス展開した連中だろ？
みきたにとかほりえは儲かるが

まのおまいらはですまだけを請け負うだけ。

>>847

MSというより

SM 裏ビデオ.NET


これがマイクロソフトの新製品ですw

>>851

> まのおまいらはですまだけを請け負うだけ。

個人事業主にもなれない馬鹿が請け負い請け負いと何を必死になっているんだ

調べてみるといい。

裏ビデオのコンテンツ記述の仕事あると思うがな。これからはJavaになるそうだからJava厨は早く転向したほうがいい。

>>854
必死だな。調べてみるといい。
.NETの仕事が少ないことを。
裏ビデオの編集ならJavaよりも
GUIに強いドトネトのほうが向いているはずだが。

Java、ああそんな言語もありましたね〜

ってひも近いな。

完成度が高い上に、EUCできてしまうから外部に仕事が発生しにくいんだろ。

Javaってセンスがないと思う。
これにつきる。
.netはセンスがある。

.netは後発ですからｗ

さあ理性がなくなってまいりました

Javaは不安定だからなー

>>856
4年前にそんな煽りをしている奴がいたが
結局ドトネトがそう言われる羽目になったわけだがw

>>858
お前はJavaやドトネトよりもセンスが無いよ

なんだこりゃww
誰か触れてはいけないことでも書き込んだのか？

>>864
お前、それで煽ってるつもりかw
ドトネト厨は煽り方が幼稚で本当に煽りのセンス無いなw

Javaの重さなんとかならない？

>>825 >>831
＞これからはVistaになる。
＞Vistaの標準コンパイラはC++/CLIだ。

やっぱり OS 開発はネイティブコード?
http://slashdot.jp/article.pl?sid=06/03/16/1143227&from=rss

> この調査から、Grimes氏は以下のように結論づけている。
> 「Microsoft はネイティブコードでの Vista の開発に注力しているようだ。
> NET で実装されたサービスは無いし、エクスプローラは .NET ランタイムをホスト
> していない。これは Vista のシェルは .NET に基づくものではないことを意味している。
> つまり、これらの結果から、 OS の開発に使用するのは .NET Framework よ
> ネイティブコードの方が良いという決定を Microsoft は下したという結論が得られる」

＞ttp://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050517/160986/
その一方で，.NET作戦にとっては衝撃的な宣言が飛び出した。
Gates会長は「次世代プラットフォーム」を「Win32 and WinFX」と表現したのである。
Win32はLonghornでも新機能用に拡張され，寿命が一段と延びることになった。


＞Windows Vista β1に感じた期待と不安
＞ttp://pc.watch.impress.co.jp/docs/2005/0804/mobile301.htm
マイクロソフトOBでWindows 1.xの時代からWindowsの開発に関わっていた方(2000年に退職)から
コメントをいただいた。引用させていただくと

“私の住むシアトル近辺のマイクロソフトOBの間では、2004年の前半に「Longhornがキャンセルに
なったらしい」という噂がさかんに交わされ、その後次々と「OFSはLonghornとは別」、
「Managed APIは採用しない」とのアナウンスがありました。結局の所、もともと計画していた
Longhorn は出せなくなったけれども、いまさらキャンセルになったとは言えないので、出せるもの
だけかき集めてLonghornと呼ぶことにした、という見方がこちらでは一般的です”

だ・か・ら〜　OSと単なる１アプリケーションに過ぎないJavaを同一視するのが詭弁の詭弁たるところだなｗ

更に言えば、Javaのようなオーバヘッド著しい言語処理系はOS開発などのクリティカルな部分には
まったく使い物にならないということの証座でもある。

証座 の検索結果のうち 日本語のページ 約 160 件中 1 - 20 件目 (0.64 秒)
…Σ（ ﾟДﾟ）

えっと、証左と似たような意味ですかね？

華麗にスルーさせてもらう

>>868
ドトネッツは激重だし、ネイティブコールのオーバーヘッドがあって、Ｏ＄と相性が悪いらしい。
Ｗｉｎのバージョンうｐでブビが動かなくなった如く。

突っ込まれたのにスルーてｗｗ

>>869
C/C++いっさいなし、Javaだけで開発されたOS - JNode
ttp://pcweb.mycom.co.jp/news/2006/03/03/341.html

O$自体をいかようにも変更可能なM$と、どうにもできないSUNを同列で比較してるスレッドはここですか？

比較けっか：
ｳﾞｨｽﾀｲﾗﾈ

ま、ハード不具合のないPCでこそ行えた試行実験の類でしょう。
作り上げた根性は理解できるけど、実用性はあるのか？

乗り換えるなら好きに汁。漏れはとめないｗｗ

>ｳﾞｨｽﾀｲﾗﾈ

　　　　 ∧＿∧　ミ　ｷﾞｬｰｯﾊｯﾊｯﾊｯ！ ざぶとん三枚！
　o/⌒（. ;´∀｀）つ
　 と＿）__つノ　　☆　ﾊﾞﾝﾊﾞﾝ

そういいながらVistaの前でうなってる>>878の姿は容易に想像できるな。
いや確定したといってもいいｗ

ところでEJBはクソって事でいいよね。
高速に動作する使用方法や、成功した例を提示出来る奴はいなかった訳だから。

でvistaって何？MSのVM？
誰か簡単に説明して。

つ http://www.microsoft.com/japan/windowsvista/default.aspx

つ http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%A8%E3%82%BF%E3%83%BB%E3%83%93%E3%82%B9%E3%82%BF

昨年度で干されたニート派遣JavaPGが暴れたと聞いて様子を見にきますた。

何？どのレスが火をつけたわけ？>>802-808あたり？

木曜日の昼からコレだけ書きこめるのは羨ましい。

Ｊａｖａは悪くない。Sunの処理系が悪い！

Ｊａｖａは悪くない。糞コードを撒き散らすﾃﾞｼﾞﾄﾞｶが悪い！

Ｊａｖａがﾃﾞｼﾞﾄﾞｶを生み出しているからＪａｖａが悪い！！

EJB使うとかいいだすアーキテクトが悪い！！

いや、(^_^;
ﾃﾞｼﾞﾄﾞｶはCOBOLの時代からいるよ。

>>826は面白いな。確かにJavaが生まれた頃はx86よりSparcのほうが速くてハイエンドだったんだよな。
今ではx86がぶち抜いてはるかに速いけど。

Javaごときに高い金払うクライアントが悪い！

いまはｘ８６はWindowsのためのアーキテクチャな訳で。
もうJavaは携帯だけで滅びる運命なんじゃまいかと。

おいおいlinuxを忘れるなよ。
それをいうならPC(Mac)のためのだろ。

ところで、.NETはWindows以外でも使えるのですか？

つか、.netとJavaを比較するなんて.netに失礼極まりない。
江戸時代なら切腹だな。

Windowsだけで十分おなかいっぱい。

>>893
使えるよ。

>>869
> 更に言えば、Javaのようなオーバヘッド著しい言語処理系はOS開発などのクリティカルな部分には

今じゃCPUもＪＶＭも高速化して大したオーバーヘッドにもならないんだけどね。
それでも遅いというならドトネトを使ってもどっちみち遅いことには変わらないよ。

クラスのロードが遅い

>>813
藻前のようなヤツばかりだったら、問い合わせが減って楽なんだが。

>>869
> 更に言えば、Javaのようなオーバヘッド著しい言語処理系はOS開発などのクリティカルな部分には
Javaこそクリティカルな部分では非常に使い物になるわけだが。
だから金融系などでよく使われるわけだが。
ドトネトやPHP、Perlみたいな言語じゃあぶなっかしくて使ってられないよw

>>875
> O$自体をいかようにも変更可能なM$と、どうにもできないSUNを同列で比較してるスレッドはここですか？

Sunも変更可能なOSを持っているんだけど。
っていうかM$はいくらOSを変更可能でもサーバOSで収入を得ることはほとんどできないでしょ

>>880
お前がクソだよ。
寝言はEJB3.0の仕様をみてから言え。
EJBの代わりになるものは何たるかを言ってみろ。

はっきりいうが、金融系では非EJBでもPOJO以外はクソだぞ。

>>891
> いまはｘ８６はWindowsのためのアーキテクチャな訳で。
> もうJavaは携帯だけで滅びる運命なんじゃまいかと。

そんなことを言い続けて4年、ドトネトがサーバでどれだけ普及したのかね。
仕事もろくに無い、情報もろくに少ないJavaよりもこれといって優れた特長もない
そんなドトネトに一体どんな魅力があるというのかね。

>>894
> つか、.netとJavaを比較するなんて.netに失礼極まりない。
> 江戸時代なら切腹だな。
都合が悪くなるとすぐに人を斬りたくなるとはまったく
ドトネト厨房ってのは朝鮮人みたいに短気なんだね。

>>896
まともに使えないだろ。
互換性も貧弱だしGUIなんかとくに。
しかもLinux版ではパフォーマンスも劣化する。
そのあたりJavaに劣る。

Javaで使われている金融系ってなに？
せいぜいオンラインバンクとかでしょ？

リアルタイムで変化するＦＸクライアントなんて
すべてがリッチクライアント、
そしてJavaなんかじゃ書かれてないよ

>>903
ASP.NETでめちゃめちゃ増えてるよ
おまえ現状しらねえだろ

>902
EJB3.0の仕様？
インタフェース作成が自動化されるから、EJBにするかどうかを気にせずに使えるとか言う話か？
BEAのWeblogicで半自動化されている現状の使いにくさを理解しての発言か？
EJBの代わり？
そんなものはない。というかEJBは処理能力も冗長性もクリアしていない。
処理能力の面で言うならCPUボード増設で、冗長性の面で言うならロードバランサーだ。
金融系では非EJBのPUJO以外はクソ？
イマイチ意味が分からん。「金融系」は「信頼性が重要なシステム」を言っているのか？
しかし「非EJBのPUJO以外」が何を指すのかわからん。
「非EJB」が「PUJO」にかかるのか「PUJO以外」にかかるのかわからん。
「PUJO」にかかるなら内容は分かるが、「EJB否定」の意見だから文脈に合わない。
「PUJO以外」にかかるなら、何を指しているのか不明。
EJB肯定論者なら、
「金融系ではEJB使わないシステムはクソ」
と言う流れだと思うが、そういう意味かな？

金融系はバッチ処理が普通。
EJBなんか使わないよ。
信頼性皆無じゃん。

さーぶれっとでやっと息をふきかえした当時を思い出す。

PUJOってタイポなのか？素で何も知らない奴だったらそうしようorz

フランスの車

JavaNativeのMachineってどうなったの？普及したの？Javaが爆速で動くんでしょ？

そういえば昔はニューロマシンとかも考案されてたな。話題的なもてはやされ方も今のJavaと似たようなもんだった。こぞってシミュレータ作って流行りまくり。国家規模で第何世代プロジェクトとか懐かしいな。

ああ、今のニューラルネットの扱いが、将来のJavaの扱いの予測になるかもな。

Javaがメーカー系に支持されたのは重くて高速なマシンが必要になったからだよ。
それなのに専用チップで早くしたら意味ないじゃん。
チップ1個売るのとマシン1台売るのじゃ儲けが全然違うだろう。

javaを作ったのがハード屋のsunで、
その後の普及に勤めてるのがソリューションベンダに成り下がったibmだから
javaはできるだけ遅くて堅牢で冗長であった方が
彼らのメリットになるわけ。

はあ？
バージョンアップの度に高速化している事実があるわけだが。
おっさんの妄想はデムパがかってるな。

>>916 へー（棒読み）
んじゃまあ、Javaが出た頃最新だったPentium75あたりで今のJava動かして貰おうかｗｗｗ
激しく馬鹿すぎｗｗｗ久々ワロスｗｗｗ

おまんこ

アイフル

そもそも、OS自体が肥大化したのでそんな骨董品では動きません。
Java以前の愚問
認知症ですか

逆ギレにしか聞こえないんだが？

Javaはいつだって重い。これからも重いだろう。始まりの日から終わりの日まで、Javaは重い。

これは正しい。

チョッと前からvb.netの仕事始めた。
javaのがやっぱしっくりくるなぁ。
vb.netなんだかごちゃごちゃしすぎ。

>>922 中毒からのリハビリガンバレ

おい。おまいら一人で何役やってるんだ？

javaのランタイムは144MBもある

馬鹿か？

>>920
OSが重かろうが軽かろうが普通のアプリは互換性が
有るか限りOSに依存しないから関係ない。

write once, run anywhereだろ？
できてねえじゃん

Javaはいつだってﾎﾓい。これからもﾎﾓいだろう。始まりの日から終わりの日まで、Javaはﾎﾓい。

これは正しい。

ﾊﾞｰｶ

JavaとMSが仲良くやってくれていたらなぁ。

>>927
Javaの事ではないが?
95向けに書いたアプリは98だろうとMEだろうと動くし、
Linuxならディストリビュージョン違っても大抵動く。
そういう意味で互換性があると書いたんだが。

嘘つけ

Javaってプラグイン間の互換性が最低だよね

OSに対する互換性を高々と歌うわりには
枝番の互換性は史上最低

Javaって金儲けのためならば鉄筋の数を平気で嘘ついて
コンストラクトする建築屋のための言語

耐震強度が足りない場合は
高いサーバで補強工事しましょうと金を取り続けるビジネスモデル
開発工数(ドカタ)を長期間見積れる仕組みを実現する

結果ユーザには全くもって不利益な建築工法である

>>916
前から思ってたんだがどうして高速化されたのかって
Java厨って知ってるの？

高速化した理由を説明できないかぎり実際に高速化されても
納得はできねぇぞ。

特定の常態で高速化は出来るけど汎用的につかうとパフォーマンス
が落ちるってのはどこでもある話。

たかだがJava厨にブラックボックスの中身をしれなんて無茶イワンから
ブラックボックスの但し書きじゃなくて説明書・仕様書を自分也に解釈
してから“どういう風に高速化”したか言ってくれ。

但し書きはもうごめんこうむる。

おっさんが大漁。

だってどうせJava仮想マシンの仕様すら知らないJava厨房がスレたてまくってあおってるだけだし。
まともに相手するのがアホかと。

JavaしかできないJava厨はコンプレックスの塊だからね。