JAVA厨ってCheckstyleが無いと糞コードになる
■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん
2005/12/30(金) 23:18:360003仕様書無しさん
2005/12/31(土) 00:00:300004仕様書無しさん
2005/12/31(土) 11:22:14あとMavenとFindbugsとAnt。アホだぜ。
0005仕様書無しさん
2005/12/31(土) 13:00:15上流JavaプログラマによってJava厨は統制されなければならないのです。
上流Javaプログラマが全体の実装アーキテクチャをダイアグラムをクラス設計をメソッド設計を
配置をコンパイル環境を単体・結合テスト設計を運用監視計画、作業スケジュール等を計画した上で
初めてJava厨が人並みに仕事をこなすことができるのです。
厨でも人並みの仕事をこなすことが出来る言語など過去をさかのぼっても未来永劫Javaしかありえません。
姉歯設計のC/C++やら.NET, 論外のスクリプト言語等に騙されたくなければ
あなたもJavaを選択しましょう！
0007仕様書無しさん
2006/01/02(月) 02:11:12こだわりすぎるのもどうかと思うが、便利なら使うのは当然だろう。
手作業にはミスが入り込む余地がどうしても出来る。
それを排除するために道具を使うんじゃないか。
0008仕様書無しさん
2006/01/02(月) 02:14:51例、料理人の包丁
三流の道具とは、道具の奴隷になること
例、Java厨のCheckstyle
0009仕様書無しさん
2006/01/02(月) 10:38:230010仕様書無しさん
2006/01/02(月) 13:57:05補完とリファクタリングが無いと何もできない。
0011仕様書無しさん
2006/01/02(月) 15:05:590012仕様書無しさん
2006/01/02(月) 19:23:13楽しいのか?Java厨ってほんとただのものだと文句は言わないんだなw
0013仕様書無しさん
2006/01/02(月) 19:27:46猿に刃物を与えたみたいになるから。
0014仕様書無しさん
2006/01/02(月) 20:20:46VS厨なのか?makeなしでビルドできないとmake厨?
一生機械語かいてろこのボケが。
0016仕様書無しさん
2006/01/02(月) 20:48:22比較の対象にはならんと思うよ
0017仕様書無しさん
2006/01/02(月) 20:49:47デバッグトレースで1000倍速い
Eclipseはデバッグトレースで使う気がしない
0018仕様書無しさん
2006/01/02(月) 20:52:200019仕様書無しさん
2006/01/02(月) 20:55:55何万回も呼ばれるメソットを
インライン展開して、String#internで==比較
するようにしたら、バグだと言われました
説明しても解って貰えません
どうみてもCheckstyle厨です
本当にありがとうございました
0020仕様書無しさん
2006/01/02(月) 21:05:36いわく、Checkstyle厨、オブジェクト厨、オプン厨
いずれおとらぬ馬鹿ぞろいなのが特徴だ
0021仕様書無しさん
2006/01/02(月) 21:14:48Eclipseを立ち上げるのは救い様の無いアホだな。
0022仕様書無しさん
2006/01/02(月) 21:19:27Eclipseでやれと行って使わしたよ
まぁ〜WinCVSが糞過ぎるから仕方がない
0023仕様書無しさん
2006/01/02(月) 23:47:37叩き所が違うぞ。
Java叩きにも何にもなっていない。
Emacsを使ってる奴がEmacsプラグインを使っていたら
こんな糞スレを立てるのか？
裸の王様みたいで恥ずかしいぞ。
0024仕様書無しさん
2006/01/03(火) 00:36:14あ〜、俺は触れないわ＞素のCVS
前にDBを直接触ってて丸ごとフッ飛ばした事もある。
ても、俺の仮想環境内でだから他所には迷惑掛けてないけど
ただ、自力で復旧できなくて運用さんを呼ぶハメになったのは
かなり恥ずかしかったorz
0027仕様書無しさん
2006/01/03(火) 10:28:23いまどきメモリぐらいで文句いうのかw
この貧乏人
0029仕様書無しさん
2006/01/03(火) 13:50:180030仕様書無しさん
2006/01/03(火) 13:51:32VS.NET 2005 が重たくて使えない言い訳がそれか。
それじゃVS.NETがEclipseよりも優れている説得力ある
根拠にはならんぞ
0031仕様書無しさん
2006/01/03(火) 15:35:510032仕様書無しさん
2006/01/03(火) 16:05:500034仕様書無しさん
2006/01/03(火) 20:19:26いらね
0035仕様書無しさん
2006/01/03(火) 21:59:27なぜこれが分からんのか不思議
0036仕様書無しさん
2006/01/03(火) 23:22:330037仕様書無しさん
2006/01/04(水) 15:25:27設定ファイルを自分で弄ってカスタマイズすれば
おせっかいな警告を減らすことができるぞ
っていうかEclipse使え。
Checkstyleプラグイン
楽になるぞ
0038仕様書無しさん
2006/01/04(水) 15:30:50Javaは起動してから常駐しっぱなしというサーバアプリケーションの
スタイルがあるから起動については深く考えないでいた傾向があったりする。
Tomcat一度起動したらもう何年も再起動する必要がないケースだって
よくありうるしね
0039仕様書無しさん
2006/01/04(水) 17:21:110040仕様書無しさん
2006/01/04(水) 17:53:17ないね。あいつよくリークするじゃねえかw
0041仕様書無しさん
2006/01/04(水) 21:42:46フレームワークなら、それはいちおうバクと指摘する方が正しい。
0043仕様書無しさん
2006/01/05(木) 01:31:46おまいはcheckstyleの設定変更方法も知らないのか。
アホか？
XMLファイルを弄れ。
わからなければEclipseのCheckstyleプラグインを
使え。マウスで余計な設定を除外することができる。
細かい設定もできる。新たに追加することもできる。
使ってみよ。
0045仕様書無しさん
2006/01/05(木) 06:59:06有る意味、指摘は正しい事だと思うよ
フレームワークでインライン展開とかコード的には糞だし
でもパフォーマンス要件が達成できないのでしょうがない
駄目なら代替え案ぐらい出せと厨に言いたいよ(´･ω･`)
>>19
アホはおまえだな
プロジェクト全体に適用されている
XML変更または除外の申請しても
レビュアーが厨だから理解できないという話です
0046仕様書無しさん
2006/01/05(木) 07:48:560047仕様書無しさん
2006/01/05(木) 11:35:59リークするのはコンテナのバグだろう
どんなコード書いてもリークしないのがVMだろうが、ちがうのか?
0048仕様書無しさん
2006/01/05(木) 11:38:03とかあったなw
4.1.24のLinux版はオッケーだったんだが
0050仕様書無しさん
2006/01/05(木) 11:45:35理想論の能書きだけだと言うことがわかりましたね皆さん
能書きだけは100人前のJava厨って本当にかわいそうですね
チャンチャン
0051仕様書無しさん
2006/01/05(木) 12:57:10古いTomcatをいつまでも使い続けるお前が悪い。
というかWindowsをサーバにして稼働させるお前がアフォ。
beanの変数に_を使うのもアフォ。
Checkstyleの恩恵を預かってるなら命名規則くらい守れや。
やっぱり出直してこい。
0052仕様書無しさん
2006/01/05(木) 12:58:54お前は自分の書いたプログラムでOutOfMemoryErrorが
出たらろくに調べもせずに何もかもコンテナのせいにするのか。
ただ駄々をこねているだけの問題自己解決能力も無い向上心も無い低脳な餓鬼だな。
それじゃお前の所のプロジェクトもなかなか前に進まないわけだ。
0054仕様書無しさん
2006/01/05(木) 13:09:5151-使ってないよ、糞猫を使う理由がない
52-OutOfMemoryErrorなど出す分けないよ、も前のような馬鹿と違うからね
繰り返すがコンテナのバグだよ
53-漏れはC++が専門
0055仕様書無しさん
2006/01/05(木) 13:11:30チャンチャン
0057仕様書無しさん
2006/01/05(木) 13:15:02でた!IISはLinux Apacheよりも1G倍性能がいいぜ
0058仕様書無しさん
2006/01/05(木) 18:08:55もまえがもちつけ
レス番に>>付け忘れてるぞ。
そんなにC++ができるならC++だけでServletの代替物を
作って公開してみてくれ
0059仕様書無しさん
2006/01/05(木) 18:21:48ISAPIがまさにそうだよ、認証からセッション管理すべて可能だ
0060仕様書無しさん
2006/01/05(木) 18:29:340061仕様書無しさん
2006/01/05(木) 18:49:230063仕様書無しさん
2006/01/05(木) 21:34:16PHPはJavaと変わらないスクリプト言語駄目ダサイ
ネイティブISAPIは無敵
0064仕様書無しさん
2006/01/05(木) 22:11:160065仕様書無しさん
2006/01/05(木) 22:39:23アプリケーションサーバの性能や使い勝手はここでは関係ないぞ
↓という事で話の流れを元に戻そう
0067仕様書無しさん
2006/01/06(金) 01:07:16Checkstyleを使えば品質が向上すると勘違いし
回りくどいロジックをつみかさねる厨をあざ笑うすれかな
0068仕様書無しさん
2006/01/06(金) 01:15:56訂正
チャンチャン
0069仕様書無しさん
2006/01/06(金) 01:50:440070仕様書無しさん
2006/01/07(土) 00:25:46> >>1
> JAVA厨はCheckstyleさえあれば糞コードにならない。
もし>>1がそう思っているなら
>>1はさっさとCheckstyleを導入すべきだ。
>>1の性格じゃ何を導入したって糞コードにしかならんだろうが。
> VB厨は何があっても糞コードになる。
そのケースは多そうだな。
0071仕様書無しさん
2006/01/07(土) 00:27:53FindBugsも使って貰わなければならん。
それから、EclipseのCode Analysis Plugin
で分析して貰おう。
メトリクスプラグインで糞っぽいコードを検出して貰おう。
Profilerプラグインで糞ロジックを検出して貰おう。
ソースコード整形のためにJalopyも使って貰おう。
0072仕様書無しさん
2006/01/07(土) 01:18:47マッチねぇと火もおこせねぇのかよ！って木製発火装置ゴシゴシやって
悦に入ってんのと一緒だろーがよ。程度は違えど。
CheckstyleのうざってぇならEclipseのコードフォーマッタ設定して
Ctrl+Shift+F一発かませよ。
そんだけで結果見た目キレイなコードできるんだ。これが生産性って奴じゃねぇのか？
そもそもJava使えてないような奴はCheckstyle有ったって
見た目だけキレイなクソコードしか書けねぇだろ
0073仕様書無しさん
2006/01/07(土) 14:28:19> CheckstyleのうざってぇならEclipseのコードフォーマッタ設定して
> Ctrl+Shift+F一発かませよ。
> そんだけで結果見た目キレイなコードできるんだ。これが生産性って奴じゃねぇのか？
それだけでも汚い糞コードが多い・・・
黄色いエクス婦らネーションマークがついた警告が警告ビューに
何万とリストアップされてEclipseがフリーズしかけるほどなのです・・・・・
それにCheckStyleプラグインを合わせるともっと凄いことに・・・・とんでもないことに！
0074仕様書無しさん
2006/01/07(土) 16:00:180076仕様書無しさん
2006/01/07(土) 17:11:090077仕様書無しさん
2006/01/07(土) 17:31:10それはもうどうしようもないんじゃね？
そもそも、コーディング規約を間違わないよう予防的に使うもんだろCheckstyleは。
もともと汚いコードに後から規約適用とか、そんな無茶は潔く諦めましょうよ＾＾
0080仕様書無しさん
2006/01/07(土) 17:44:23Javaしかできない派遣の年寄りで
ひどい馬鹿な椰子
「お前はEJBを知っておろうな」から発生
0081仕様書無しさん
2006/01/07(土) 17:46:30汚いコードしか書けない奴は首にする法律でもあればいいのにね。
資格制度のようにCheckStyleが機能してくれるといい。
CheckStyleに従わないものは業界追放。
それが嫌ならChekcstyleで出る警告の数だけ賠償金を支払う制度を
導入する。
顧客がこちらにソースコードを渡してきて
買いとる手続きをするときに、CheckStyleを使って
警告数に応じて買い取り料を減らす。
下手すると顧客はタダでソースコードをうらなければならなくなる。
Checkstyleで警告が大量に出るコードは基本的に
無価値なるコードを見なすよう大義名分を仕立てるべきだ。
0082仕様書無しさん
2006/01/07(土) 17:47:550083仕様書無しさん
2006/01/07(土) 17:48:180084仕様書無しさん
2006/01/07(土) 17:49:46EJBを知っていると言うことは
データベースも知っていて当たり前だし
データベースをサーバ上で使いこなすには
サーバOS管理の知識も必要になる。
ネットワークの知識も必要だ。
よってEJBを知っていてJavaしか知らない奴なんて
まずいないってことだ。
0085仕様書無しさん
2006/01/07(土) 17:54:59できないんだなあこれが
0086仕様書無しさん
2006/01/07(土) 17:59:590087仕様書無しさん
2006/01/07(土) 18:16:41俺も聞いてていい気分しない。放置でいいじゃん。
0088仕様書無しさん
2006/01/07(土) 18:20:04金儲けなんだからＪａｖａだろがＣ＋＋だろがやりゃあいいじゃんか。
おれみたく両方やれ。
PerlでもPHPでも金がもうかりゃやるさ。
もちろんドトネトもな。ＣＯＢＯＬもだ。
仕事がありゃやる。
0089仕様書無しさん
2006/01/07(土) 18:56:18おまえの脳内に潜む仮想敵はその「おろうなメンツー」なんだな
よくわからんが。
おまいに一体どんなトラウマがあるか知らんが、
お前が憎いと思ってる香具師の話なんかもうどうでもええよ。
0091仕様書無しさん
2006/01/08(日) 12:32:230093仕様書無しさん
2006/01/08(日) 19:49:100094仕様書無しさん
2006/01/08(日) 19:51:58能無しプログラマは流行言語に群れるの法則をしらない若造だな。
0095仕様書無しさん
2006/01/08(日) 20:15:100096仕様書無しさん
2006/01/08(日) 21:13:55まあ上から下までJava厨軍団だったからどうやってもクレーム付けられたんだろうが
今はどうですか？
0097仕様書無しさん
2006/01/08(日) 21:39:020098仕様書無しさん
2006/01/08(日) 22:19:550099仕様書無しさん
2006/01/08(日) 22:21:510100仕様書無しさん
2006/01/08(日) 22:23:030101仕様書無しさん
2006/01/08(日) 22:33:25今のままではとてもつかえない。
0102仕様書無しさん
2006/01/08(日) 22:38:590103仕様書無しさん
2006/01/08(日) 22:41:13Javaということでいいですね
0104仕様書無しさん
2006/01/08(日) 22:42:130105仕様書無しさん
2006/01/08(日) 22:44:41ダサ杉、さすがJava
0106仕様書無しさん
2006/01/08(日) 22:45:51VM-VMでサービス実行
きっと遅杉状態の連続に
0107仕様書無しさん
2006/01/08(日) 22:50:02攻め立てられて、狭間で手間だけかかる恐竜のように滅びる。
残るのは携帯Javaだけだが、これがまた全然Javaしてないのは良く知られた話。
0108仕様書無しさん
2006/01/08(日) 23:25:530109仕様書無しさん
2006/01/09(月) 00:09:470110仕様書無しさん
2006/01/09(月) 00:13:560111仕様書無しさん
2006/01/09(月) 00:34:190113仕様書無しさん
2006/01/09(月) 00:46:26どんな僻地で仕事やってんだろ?
0114仕様書無しさん
2006/01/09(月) 00:55:18Win鯖を使ったらライセンス料にいくら取られると思ってんだよ。
0116仕様書無しさん
2006/01/09(月) 01:01:400117仕様書無しさん
2006/01/09(月) 01:43:280118仕様書無しさん
2006/01/09(月) 01:53:380119仕様書無しさん
2006/01/09(月) 09:20:11Javaのたとえとしてｳﾏｲ
そのとおりだと思う
0120仕様書無しさん
2006/01/09(月) 09:25:14購入、維持を考えると逆にユーザが使いたがらない場合もある。
ユーザが皆金持ちで即応性を最優先するならともかく、
コストを優先する客の場合は、自分達の利益を出すためにも
オープンソース系で固めざるを得ない場合もある
0121仕様書無しさん
2006/01/09(月) 09:28:30きっと赤字にしかならないようなものばかりと思われる
0122仕様書無しさん
2006/01/09(月) 09:31:23Java厨をかきあつめて糞コードを量産するでいいですか?
0123仕様書無しさん
2006/01/09(月) 10:50:30JAVA厨ってCheckstyleがあっても無くても糞コードになる
のだ
にしよう
0124仕様書無しさん
2006/01/09(月) 11:00:43Java厨はなんでテンプレートがサポートされていない事に対して
10年も文句を言わなかったのだろうか・・・
0125仕様書無しさん
2006/01/09(月) 16:56:17コストってかけるから儲かるんだよな。
0126仕様書無しさん
2006/01/09(月) 17:12:24いや、そういうPOJO厨には仕事は回ってこない。
ホントに。EJBのほうが金になりますから。
サーバとJBossをセットで販売したがる企業がいるので
EJBは金稼ぎたければかなり重宝します。
0127仕様書無しさん
2006/01/09(月) 17:13:45SOAPに限定するところはまだまだ浅知恵だな。
WSDLのほうがプロトコルに依存しないので
SOAPより普及する
0128仕様書無しさん
2006/01/09(月) 17:16:18Checkstyleを使わないと糞コードが書けてしまうが、
C#だともっと簡単に糞コードが書けてしまうんだなこれが。
そしてC++だともっともっと酷い糞コードだらけにすることが簡単にできてしまう。
0129仕様書無しさん
2006/01/09(月) 17:16:520130仕様書無しさん
2006/01/09(月) 17:18:19また同じことしか言わないC言語厨まで沸いてきたか。
Java GenericsとC++Templateが同義だとでも思っているのか。
あれはまったく違うぞ。
C++にはない優れた機構がJava Genericsにはあるわけだが。
0131仕様書無しさん
2006/01/09(月) 17:21:030132仕様書無しさん
2006/01/09(月) 17:31:23> >>110の頭は化石
> いまやWin鯖=IISが一番
IISアブね。Apacheのほうが信頼と実績が強く
安定している。しかもWindows以外でも使えて
無料で使える。よっておまいのほうが化石
0133仕様書無しさん
2006/01/09(月) 17:35:050134仕様書無しさん
2006/01/09(月) 17:40:48馬鹿たれw
10年たってやっと似たような機能が実装された事を叩いているだけだよ
10年文句言わない馬鹿Java厨をあざ笑っているだけだ
0135仕様書無しさん
2006/01/09(月) 17:42:060136仕様書無しさん
2006/01/09(月) 17:45:140137仕様書無しさん
2006/01/09(月) 17:48:56↑ﾜﾛｽ
0138仕様書無しさん
2006/01/09(月) 17:49:06ほーよかったなw
C++にはない優れた遅さがJava 全般にはあるわけだが
0139仕様書無しさん
2006/01/09(月) 17:51:470140仕様書無しさん
2006/01/09(月) 18:00:07JAVA厨アンチだからなw
0141仕様書無しさん
2006/01/09(月) 18:06:51どうせ腐れ派遣をかき集めて、毎プロジェクトで火を吹くアホ会社だろ。
Javaをこよなく愛する技術者は謙虚であり寡黙だ。
何をするか常に考え手を動かす。口だけ２ちゃんねらーとは違う。
この掲示板をみろよ。殆どが愚痴じゃないか。
心が病んだ人は心療内科に行った方が良いぞ。
0142仕様書無しさん
2006/01/09(月) 21:25:49こいつが一番ヤバイｗｗｗｗ
0145仕様書無しさん
2006/01/10(火) 08:14:28物まねJavaとは違うオリジナルの味わい
0146仕様書無しさん
2006/01/10(火) 08:25:30Java使ったことがないことがよくわかる。
Javaの仕組みやC++との違いもわかってなさそうだし
0147仕様書無しさん
2006/01/10(火) 08:26:35VBだったら最強クラスの糞コードを簡単に書けてしまえるかもしれない
がな
0148仕様書無しさん
2006/01/10(火) 08:33:00全然ものまねじゃないぞ。
C++TemplateとJava Genericsは根本から全く仕組みが違うものだ。
同じものだったらすでに採用している。
だがC++Templateと全く同じ機能をすぐにJavaに採用しなかったのは
セキュリティ上の問題があったからだ。
C++のTemplateは欠陥だらけで欠点だらけだったということだ。
そこでC++の二の舞を踏まないように、C++の欠点まで
Javaに持ち込まないように慎重に考慮し議論されてJava Genericsを
作ったのだ。
だからJava5からは一気に数々の標準APIのクラスがGenerics対応になった。
一気に対応させないとコードが煩雑になるからだ。
それだけでなく、既存のAPIでも即座にGenericsを使えるように
しておかないとC++のSTLのように外部の機構に頼る羽目になるからだ。
それから簡単にGenericsを導入できなかったのは、既存のJavaコードに
悪影響を与えないような配慮をどうすべきかを考慮してたからだ。
標準Java APIは上位互換性だけは大幅に考慮している。
Genericsの導入によって上位互換性が損なわれるわけにはいかない。
一度でも下手な仕様を導入してしまうといつまでもそれを引きずってしまい、
言語の利用者が減ってしまい、言語仕様が乱立してしまうからだ。
0149仕様書無しさん
2006/01/10(火) 08:35:47Javaの持つボトルネック箇所(VM)のパワーを考慮して実装されたのかな
ロードするクラスオブジェクトサイズが増加しただけではないのかなw
0150仕様書無しさん
2006/01/10(火) 12:06:04けどCHeckstyle使ってくれないと
どうしようもない汚いコードを書く人がいるんだよ。
もうあれには困ったよ。
重複したコードにわかりにくいメソッド名。
コーディング規約何一つ守れない人のコードを解析するのはもうウンザリ。
40代でC言語に詳しい人がそういうコード書いていた。
最悪だったなあれは
0151仕様書無しさん
2006/01/10(火) 12:06:35大して負担にもならないんだけどな
0152仕様書無しさん
2006/01/10(火) 12:32:260153仕様書無しさん
2006/01/10(火) 14:20:120154仕様書無しさん
2006/01/10(火) 18:47:56Jakartaが吐き出すコードだからJava厨からみれば綺麗なんっすよね
0155仕様書無しさん
2006/01/10(火) 18:59:33漏れ「これこれこの仕様でUDPサーバ作成してください」
そいつ「すみません、UDPは経験ありません」
漏れ「TCPはあるんでしょう?ほとんどおなじだけど」
そいつ「ごめんなさい他の人に回してください」
漏れ「じゃあTCPでこれこれこの仕様のサーバ担当をしてください」
そいつ「これって実装言語はなんでもいいんですか?」
漏れ「この仕事はWinsock2でC++で作成します。ではお願いします」
そいつ「あのう漏れはJavaでなきゃできません」
漏れ「(少しキレてきて)JavaもC++もたいしてちがわないじゃねーの、面接の時ネットワークならなんでも大丈夫って言いましたよね(怒)」
そいつ「いまどきJavaでシステム作らない会社なんてついていけませんのでやめます」
・・・・・・
0156仕様書無しさん
2006/01/10(火) 19:26:50時代錯誤にもほどがある
0157仕様書無しさん
2006/01/10(火) 19:31:090158仕様書無しさん
2006/01/10(火) 21:23:56いきなりUDPサーバ作成して下さいって、ちょｗｗｗｗ待てってｗｗｗｗｗ
それ何するサーバよ？
それに対してUDPは経験ありませんって、ちょｗｗｗｗ待てってｗｗｗｗｗ
ボケにボケ返してどうすんだっての、誰かつっこめよ！
0159仕様書無しさん
2006/01/10(火) 21:41:000160仕様書無しさん
2006/01/10(火) 21:45:04派遣ﾄﾞｶﾀにinetdでも作れってかｗｗｗｗｗｗｗ
プロパあふぉすぎｗｗｗｗｗｗｗ
0161仕様書無しさん
2006/01/10(火) 22:57:510162仕様書無しさん
2006/01/10(火) 23:05:330164仕様書無しさん
2006/01/10(火) 23:20:200165仕様書無しさん
2006/01/10(火) 23:32:48スマソ亀だが
そりゃあいっしょにしてほしくないよ、ネイティブはVMの箱庭奴隷環境は
必要ねーもんw
0167仕様書無しさん
2006/01/11(水) 14:29:37普通だろ生ソケットたたくのって
0168仕様書無しさん
2006/01/11(水) 19:18:02それよりも
＞面接の時ネットワークならなんでも大丈夫って言いましたよね
が笑いどころじゃね?
「ネットワークなら何でも」なんて言う奴も言う奴だが、
それを真に受けるような奴も面接なんぞ担当するべきじゃない。
つか、そいつにとっては「ネットワーク」ってのが「Webアプリ」を
意味する言葉だったんだろうが、>>155にとってはどういう意味
だったのかが気になる。
WebアプリからATMスイッチの組み込みまで全部に精通しているとでも
思ったのだろうか?
まあ何にせよ、JavaとかC++以前のコミュニケーション能力の欠如だな、双方の。
0169仕様書無しさん
2006/01/11(水) 23:19:040170仕様書無しさん
2006/01/11(水) 23:45:14「ネットワークなら何でも」
とか、職欲しさにホラ吹く派遣を完全に型に嵌める気満々じゃん。
氏ね！
0171仕様書無しさん
2006/01/11(水) 23:54:21>それを真に受けるような奴も面接なんぞ担当するべきじゃない。
が笑いどころじゃね？
漏れのprjに来た、と書いてあるんだからもう手遅れだろ
新しいドカタが会社から支給されたから面接したんだろ
採用段階で面接したなら最初からおらんわ
0172仕様書無しさん
2006/01/12(木) 01:08:000173仕様書無しさん
2006/01/12(木) 01:18:490174155
2006/01/12(木) 09:56:55Javaやってますよ。各社のAPサーバを利用してます。
たまたま漏れの担当prjがC++のサービス開発だったからなんですが。
面接は漏れはしてません。ただスキルシートの補足事項に
ネットワークプログラミングは多数経験あり、問題なしと書かれてました。
0175仕様書無しさん
2006/01/12(木) 15:45:05JavaからSOAPサービス(WSDL)を呼び出したいときに
Web参照を解決してくれるツールってあるの?
.NETだとWeb参照はIDEが解決してくれのでC#のコードを3行書けば
即SOAPが使えるんだけど。Javaだと何行書く必要があるの?
0176175
2006/01/12(木) 16:05:06補足だけどXML関連を勝手にツールが作成してくれるのかってトコを
聞きたいんだ
0177仕様書無しさん
2006/01/12(木) 16:12:070178仕様書無しさん
2006/01/12(木) 16:33:160179仕様書無しさん
2006/01/12(木) 16:42:200180仕様書無しさん
2006/01/12(木) 16:43:180181仕様書無しさん
2006/01/12(木) 21:06:00金だして、IBMの開発環境の高い奴買えよ
0182仕様書無しさん
2006/01/13(金) 00:03:38AXIS(http://ws.apache.org/axis/ja/)の wsdl2java というコマンドラインアプリで、
wsdlからwebサービスへのアクセスプログラム(4つのクラス)を作ることが出来ます。
後は出来たアクセスプログラムを以下のように使えばいい。Javaでもざっと3行ですね
---
XXXService service = new XXXServiceLocator();
XXXSerciceSoap stub = service.getXXXServiceSoap( url );
Object ret = stub.yyyyy( argument ); // <-Webサービス呼び出し
---
商用のJ2EEコンテナなら、Wizardでサービスとクライアントが生成されたりします
・IBMのWebsphere-WSAD
・WeblogicのWeblogic Workshop
・FujitsuのInterstage-APWorks(WSADのロゴを変えただけ?)
なんか
0183仕様書無しさん
2006/01/13(金) 08:35:08コードもC#の勝ちかな、2行だった
HogeSoap.HogeSoapSvc hs = new HogeSoap.HogeSoapSvc();
hs.Hoge(TextFrom.Text); //<-Webサービス呼び出し
0184仕様書無しさん
2006/01/13(金) 12:44:15>コードもC#の勝ちかな、2行だった
Object ret = new XXXServiceLocator().getXXXServiceSoap(url).yyyyy(argument);
1行になった、逆転！
て、そういう問題か？何かが激しく間違ってるｗ
0186仕様書無しさん
2006/01/14(土) 00:42:450187仕様書無しさん
2006/01/14(土) 11:41:23C#厨のヘボさを如実にあらわしてる。
0188仕様書無しさん
2006/01/14(土) 12:54:51↓
低パフォーマンスのVMの負荷が増える
↓
さらに遅くなる
0189仕様書無しさん
2006/01/14(土) 14:03:150190仕様書無しさん
2006/01/14(土) 16:17:12マクロ展開しようにもJavaにはマクロが無い。
そこで 人 間 プ リ プ ロ セ ッ サですよ。
0191仕様書無しさん
2006/01/14(土) 17:28:01そこで 人 間 ロ リ プ ロ セ ッ サですよ。
にみえた
0192仕様書無しさん
2006/01/14(土) 17:28:49発生したのはJava厨の糞コードがすべての原因だ
0193仕様書無しさん
2006/01/14(土) 17:44:20VBやAccessも一時期酷かったろ。
0194仕様書無しさん
2006/01/14(土) 17:54:45かき集めてコード書かせてるんだもの。必然だよ。
COBOLの糞コードだって、COBOLのせいであんなに糞なわけじゃない。
書いてる奴が糞なんだ。
0195仕様書無しさん
2006/01/14(土) 21:51:13前のバージョンは管理するアプリが1本だった
今回はn本のアプリを管理する仕様に変更になった。
表示をコントロールするクラスを継承したサブクラスを新規に起こし
起こしたサブクラスでアプリを管理する作業を行うようにした。
継承元のクラスで定義されたprivateメンバをprotectedに書き換える
必要があったので変更した。
ここから本題
Java厨「あれあれこまるなあークラスはすべてprivateにするんですよ、規約違反です。」
漏れ「別にいーじゃありませんか、ここはprotectedが正義ですよ。」
Java厨「これだからcheckstyleも使えないC厨さんはﾌﾞﾂﾌﾞﾂ」
漏れ「ではなにか良い解決策を教えてください。」
Java厨「オブジェクト指向は神聖なものなのです、自分で考えてください。」
漏れ「約束の日時まで仕上げなきゃならんのです、お願いします。」
Java厨「まずはオプンの神であるｼﾞｬｶﾞﾀﾗ豚キャットのソースを解析してください!!話はそれからです。」
★文句いうくせに解決するためのアルゴリズムは絶対提示しないのがJava厨さんなんですよね。。
0196仕様書無しさん
2006/01/14(土) 22:16:38オライリーのJava魂でprivateよりprotectedを勧めていたのはこういう場面があるからなんだね。
まぁでも他の本でprotectedメンバを使う場面とかまじめに解説してるのあんま見た事ないし、
それもあって「なにがなんでもメンバフィールドはprivate」って人結構多いんじゃない？
0197仕様書無しさん
2006/01/14(土) 22:17:340198仕様書無しさん
2006/01/14(土) 22:35:44ほとんどのJava厨が馬鹿のひとつおぼえでこれを推奨してくれます
0199仕様書無しさん
2006/01/14(土) 22:37:14隠したいものはちゃんとprivateにしとけよ
0200仕様書無しさん
2006/01/14(土) 22:37:350201仕様書無しさん
2006/01/14(土) 22:38:060202仕様書無しさん
2006/01/14(土) 22:39:110203仕様書無しさん
2006/01/14(土) 22:59:22なんかやばいネーミングだな。それでprotected推奨しながら
例題と具体的な説明がないの?それこそJAVA厨魂だぞ
0204仕様書無しさん
2006/01/14(土) 23:23:15なんだ？継承元クラスの改修が可能で、protectedメンバが禁止なら、
protectedなgetter、setter追加すりゃいいだけじゃんよ。
そんなのJavaがどうこう関係ないじゃんよ。
アフォしかいないのか君の会社は。
0205仕様書無しさん
2006/01/14(土) 23:56:59影響がでるぞ。
0206仕様書無しさん
2006/01/15(日) 00:03:56そのままprotectedに変更するのはオススメしないな
だからといって全てprivateてのもアレだが・・・
つーか、その程度の事は設計者と打ち合わせて決めろよ
0207仕様書無しさん
2006/01/15(日) 00:10:44なんだ逃げないでも前の結論を言ってくれよw
0208206
2006/01/15(日) 00:33:44結論＝相談して決めろ
とちゃんと書いたつもりなんだけどね
つーか、お前の日本語ちょっとおかしいぞ？
0209仕様書無しさん
2006/01/15(日) 01:12:530210仕様書無しさん
2006/01/15(日) 01:21:08原題は『Hard Core Java』なんだけど、なぜか邦題が『Java魂』になってるね。
本の中では例題とか説明とかあったよ。
俺的にはEffective Javaと並ぶくらいいい本だと思うんだけど、タイトルでちょっと損してる気がするよねー。
0211仕様書無しさん
2006/01/15(日) 01:30:30> クラスは
であってフィールドの話じゃないの？
そうするとprotectedってどういういみ？
0212仕様書無しさん
2006/01/15(日) 01:38:16さすがにprivateクラスを勝手にprotectedにしろってのは無茶過ぎるし、
そもそも全てのクラスをprivateにしたら、自分で作ったクラス使えないじゃん・・・
0213仕様書無しさん
2006/01/15(日) 11:11:37○Java厨「あれあれこまるなあークラスに含まれるメンバはすべてprivateにするんですよ、規約違反です。」
0214仕様書無しさん
2006/01/16(月) 00:44:130215仕様書無しさん
2006/01/16(月) 17:39:330216仕様書無しさん
2006/01/16(月) 17:42:35サブクラスが継承されて拡張されるなと思った場合だけだが
継承されたクラスでもルートクラスと並列な仕様で操作できるのがメリット
デメリットは複雑な仕様が入り混じる継承がある場合はやらないほうが良い
0217仕様書無しさん
2006/01/16(月) 17:46:20○複雑な仕様が入り混じる継承がある場合は見通しが悪くなるのがデメリット
0218仕様書無しさん
2006/01/16(月) 18:09:21同意。
>>205
privateなメンバを何にも考えずにprotectedにするのも付け焼刃的。
フィールドであれメソッドであれ、publicやprotectedなものは
全てインターフェースだ。
だから、privateなメンバをprotectedにするというのは立派な
インターフェースの変更なんだよ。
で、この点を分かってる奴ばかりならprotectedやpublicの
フィールドにも何の問題もないんだけどね。
getter/setterの追加は「局所的な付け焼刃実装」と呼ぶくせに
privateなメンバをprotectedにすることには問題を感じないような奴が
いるから、getter/setterメソッドを強制することで
「それもあくまでもインターフェースである」ということを
意識してもらう必要があるわけ。
>>206
つか、privateメンバはインターフェースでなく実装の詳細という扱いだろ。
0219仕様書無しさん
2006/01/16(月) 18:15:46言語道断だが、時と場合によっては変更をする必要があるケースもあるわけだ
もちろん閉じたクラスであるのが前提だがな。IFが完全であり続ける保証は
無い
0220仕様書無しさん
2006/01/16(月) 22:38:59触らぬ神に祟りなし
コレが一番！
0221218
2006/01/17(火) 00:20:35>>219
もちろんその通りで、>>204氏の言う「継承元クラスの改修が可能で、
protectedメンバ(フィールド)が禁止」という状況を前提としている。
そうでなければ、そもそもgetter/setterも追加できないし。
その上で、「フィールドは必ずprivateで、必要に応じて
protected/publicなgetter/setterを使う」という類の
コーディング規約の意味について述べたつもり。
あと、「IFが完全であり続ける保証は無い」からこそ、
IFを出来るだけ完全に近く保つ努力が必要なんでないかな。
0222仕様書無しさん
2006/01/17(火) 02:14:39おまい「規約は破ってませんよ」
Java厨「うん、これならばっちりだ」
って言うに決まってる。もちろんリフレクションのコードは理解できてない。
0223仕様書無しさん
2006/01/17(火) 05:55:32多用するとすぱげちーになりやすいんだよね
0224仕様書無しさん
2006/01/17(火) 08:10:50これが最強かな
0225仕様書無しさん
2006/01/17(火) 10:25:49作り捨てのシステムならすぱげちにならないようにリファクタリングするんだと思うぞ
0227仕様書無しさん
2006/01/17(火) 11:39:46＞「あれあれこまるなあークラスはすべてprivateにするんですよ、規約違反です。」
意味がわからんこいつは一体何が言いたいのか。
privateにできるクラスなんて内部クラスくらいしかないんだが。
所詮は、Javaのことをよくわからずに適当に
脳内妄想で作り上げた作り話をしているだけか。
checkstyleは重複コードを削減することに役立つので
使っておけ。オブジェクト指向になっていないコードでもcheckstyleは機能する。
コードがオブジェクト指向として再利用性や拡張性が高められているか
どうか確認するにはCheckstyleだけでは無理だぞ。
Code Analysisプラグインを使うなり、自力でコードを分析するなりしないと
何も始まらんぞ。
0229225
2006/01/17(火) 13:41:13素で読み間違えたｗ
0230仕様書無しさん
2006/01/17(火) 14:22:01JavaでもSTLと設計思想がちがってすばらしいテンプレートがあるとか
どつかのおりこうさんが言ってたような気がするんだがw
0232仕様書無しさん
2006/01/18(水) 01:06:020233仕様書無しさん
2006/01/18(水) 01:39:33C++では、テンプレートを利用してIPやGPの様なメタプログラミングが模索
されてるけど、Javaではリフレクションを利用したメタプログラミングが模索
されてる。
面白いのは、両者共メタプログラミングというパラダイムに添ってはいても
C++がプリプロセッサ化していくという静的な方向なのに対して、Javaはイ
ンタープリタ化していくという動的な方向に向かってる点。
同じパラダイムの上に居ながらも、とことん正対する関係に向かうのは宿
命なんだろうか？ｗ
0234仕様書無しさん
2006/01/18(水) 08:51:580235仕様書無しさん
2006/01/18(水) 08:55:09コンパイル時にはネイティブコードに解決されている。
だがJavaはｗ
メタクラスを解析しながら逐次テンプレート導出し、ただでさえ悲鳴
をあげている糞重たいVM君に過大なる負荷をかける仕様なんだねｗ
0236仕様書無しさん
2006/01/18(水) 10:33:26それじゃクラスとしての意味がないだろ。
>>195が>>213の意味でいっているなら
>>195は本当に馬鹿だな。
作り話も下手くそ。
0238仕様書無しさん
2006/01/18(水) 12:35:50VMの箱庭に縛られ
女にもてずにかわいそうだな
0239仕様書無しさん
2006/01/18(水) 13:05:47だから、次バージョンではVM内からのコンパイラの起動方法の標準化が進められる
その場でコンパイルしてバイトコードに変換してクラスローダから読み込んでしまえば
既にあるコードと遜色なく実行できる様になる
0240仕様書無しさん
2006/01/18(水) 13:37:28無駄な糞クラスも含めてメモリに無理やり持たせるということでつね
0241仕様書無しさん
2006/01/18(水) 13:43:07ホントに仕事が減って焦ってるんだろう。
可哀想に。今度飲みにいかないか。
俺のおごりで。
0242仕様書無しさん
2006/01/18(水) 14:35:39プリプロセスな実装を行うのに、VMの何が制限になるの？
例えばAOPの実装として、AspectJはプリプロセスな実装を選択し
コンテナ郡(JBoss、Spring、Seasar等)はインタープリットな実装を
選択してる。
この互いに異なる選択は思惑や思想によるもので、VMが云々は
関係ない。
>>235
インタープリットな実装とは言っても、その負荷は生成時に限定さ
れる。一旦生成されて後は、通常のクラスと全く同じ負荷で使用で
きる。
それも、Javaコンパイラを起動するJSPよりも負荷は遥かに小さい。
0243仕様書無しさん
2006/01/18(水) 16:20:54またくだらねえ事でシステムリソースを無駄に使いまくるのか
しょうもねえなあ
0244仕様書無しさん
2006/01/18(水) 19:18:37じゃあ、こんな燃料を投与するのは危険だったりするのかな?w
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml
0245仕様書無しさん
2006/01/18(水) 19:57:49検証できないし、Javaのパフォーマンスなんてしたくもないからね
W○A○の起動時間はすごく遅い。O$ACLEのDB管理コンソールも遅い。
Java全体としてのパフォーマンストレンドはやっぱり遅い。
おっとクライアントアプリだから遅い、サーバは速いって無しだぜ。
遅いものは遅い。これ真実。
0246仕様書無しさん
2006/01/18(水) 22:22:55こいつ使えねーくせに「protectedが正義ですよ」って、
コーディング規約すらロクに守りやしねー。
一々相手してられるか俺は忙しいんだ知りたいなら独習しろ。
教材ならJakarta系のソースがいくらでもあるだろーが。
約束の日時まで仕上げなきゃならんのです? ああ是非とも納期は
やぶって欲しいね、そうすりゃこいつを突っ返してもっとマトモな奴と
交換できる…といいんだけどなあ…
0247仕様書無しさん
2006/01/18(水) 22:47:52こいつ設計書もわたさねえで「コーディング規約違反だ」と、はあ、
せめて静的なクラス図くらい書いてわたせっつうんだよカス!
口も利きたくもないが仕事だか仕方ねえ。
やんわりと解決策を聞いてやるよ。
まあこいつの上司に設計書もFixしてないのに作業指示はだせるわけないだろうと
とりあえず明日報告ね。
0248仕様書無しさん
2006/01/18(水) 22:58:32そんなPCじゃVS.NETすらマトモに動かないぞ・・・
0249仕様書無しさん
2006/01/18(水) 23:16:440250仕様書無しさん
2006/01/18(水) 23:23:270251仕様書無しさん
2006/01/19(木) 00:31:03サーバサイドに限定すればその理屈は成立するけど、今後クライアント
サイド(例えば、WEBサービスに対するクライアントアプリ)を想定した場
合、その理屈は通用しなくなる。
そこで、VMをOSと同時に起動して、極力をそれを効率よく使い回す。
クラスローダーをより上位の権限でブリッジして、複数のプロセスの独
立性は維持したまま、クラスプーリングを行うといった話に繋がってい
くのがJAVA6。
0252仕様書無しさん
2006/01/19(木) 00:36:280253仕様書無しさん
2006/01/19(木) 00:38:14JAVA6はうまい汁を吸う、それに騙される厨
0254仕様書無しさん
2006/01/19(木) 00:39:43全く変わらないという間抜けさ
0255仕様書無しさん
2006/01/19(木) 00:55:32マシン立ち上げた後とりあえず一服するとか一発抜いてくるとかすれば良いだけの事じゃないか
0256仕様書無しさん
2006/01/19(木) 00:59:22見えてない奴等だな。
要は単一のVM上で各Javaプロセスの独立性は維持したまま
更にスレッドの実行効率低下も防ぎつつ、クラスローディング
のコストも下げようという点がキモだ。
どのタイミングで起動するかは重要じゃない。
重要なのは、メモリ上にローディングされてるものは再ローデ
ィングしないという方針だ。
0257仕様書無しさん
2006/01/19(木) 01:06:19＞検証できないし、Javaのパフォーマンスなんてしたくもないからね
＞遅いものは遅い。これ真実。
検証(を実際にしているソースがあるのだが)なんぞしたくも無い、
俺が遅いと言ったら遅いのが事実。
こういう脳内お花畑で生きている奴に、いくら現実世界を見せようと
努力しても、単なる無駄。
0258仕様書無しさん
2006/01/19(木) 01:34:23これは単なるベンチ上で速くなっただけなのか？
0259仕様書無しさん
2006/01/19(木) 01:35:200260仕様書無しさん
2006/01/19(木) 08:06:47JAVA6ってどのリンクを押せば落とせるの？
レジストリが汚れるので最近JREとかJ2SEとかいれた事がないからなあ
特別試験環境を用意したからそこにインストールしてやるよ
JAVA6なんてどこにもないけどなw
正確なプロダクト名を教えてくれよ
0261仕様書無しさん
2006/01/19(木) 08:14:52>ィングしないという方針だ
へっ、こんなの当たり前の事じゃねーの、当たり前の事をすごい事の
ように言うJAVA厨って
0262仕様書無しさん
2006/01/19(木) 08:30:42https://mustang.dev.java.net/
最低限、JSRくらいは追えよ。
学ぶ技術のない奴は何やっても駄目だと思うけどな。
0263仕様書無しさん
2006/01/19(木) 08:46:490264仕様書無しさん
2006/01/19(木) 09:38:20ネイティブクライアントがXMLサービスをがんがん利用するようになる
Javaのサーバ主導+Thinクライアントはすぐに破綻するから
クライアントの起動時間やパフォーマンスをマジに考えないと
明日はなくなるよ
0265仕様書無しさん
2006/01/19(木) 13:05:57そこでJavaDesktopですよ
0266仕様書無しさん
2006/01/19(木) 13:58:390267仕様書無しさん
2006/01/20(金) 00:55:04クライアントをJavaデスクトップ。
遅いもの同士で同期が取れ、待ちが生じない。
ﾒﾃﾞﾀｼﾒﾃﾞﾀｼ
0268仕様書無しさん
2006/01/20(金) 01:24:10> メソッドかプロパティの事を指してるんだろ
>
> さすがにprivateクラスを勝手にprotectedにしろってのは無茶過ぎるし、
> そもそも全てのクラスをprivateにしたら、自分で作ったクラス使えないじゃん・・・
アフォクラスだわなそりゃ。デフォルトコンストラクタをがアルじゃないか
とでもいいたいだけなんだろうか。ってかそれやメソッドはすべてstaticでコンストラクタ専用かw
さすがレベルの低いアンチの妄想だw
それからprotectedもクラスがpackage privateなら無茶じゃないともいえるわな。
package privateのときはdefault(アクセス修飾子指定無)でもええな。
0269仕様書無しさん
2006/01/20(金) 06:56:48SOAPは既におわっとる
0270仕様書無しさん
2006/01/20(金) 10:27:23>さすがレベルの低いアンチの妄想
Javaのデフォルトパッケージスコープを持ち出してくるところなんざ
真性JAVA厨の称号をつかわすぞ
0271仕様書無しさん
2006/01/20(金) 17:40:41近年の若者は俊敏さに劣り、感覚が鈍っていると報告された。
特に顕著に現れるのがJAVAを仕事にしているJAVA厨という若者グループだ。
彼らはソフトウエアを起動してから5分間の間ぼーとしてなにもしない。
人に声をかけられても3分後にしか返事ができない。これはJAVAの実行・開発
環境に馴染んだため反応仕様がJAVAと同じになった事と考えられている。
0272仕様書無しさん
2006/01/20(金) 19:01:410273仕様書無しさん
2006/01/20(金) 19:55:370274仕様書無しさん
2006/01/20(金) 22:04:13どう見てもコンプレックスです。
ありがとうございました。
0275仕様書無しさん
2006/01/21(土) 02:33:24ﾜﾗﾀ
っていうか彼はJavaに大してコンプレックスを持っているどころか
恐れをなしているぞw 彼のJavaに対する畏怖の念は非常に強力だ
0276仕様書無しさん
2006/01/21(土) 09:45:160277仕様書無しさん
2006/01/21(土) 10:11:531.1〜1.2の時代にメインだったPentiumPro 200MHz 256MB 8GB位のマシンに、
Java6をインストールしてみろよ。笑えるから。
0278仕様書無しさん
2006/01/21(土) 10:55:26JAVAの速くなった度合いはあまりにも小さい
0279仕様書無しさん
2006/01/21(土) 11:03:130280仕様書無しさん
2006/01/21(土) 11:11:510281仕様書無しさん
2006/01/21(土) 12:58:110283仕様書無しさん
2006/01/21(土) 13:36:580284仕様書無しさん
2006/01/21(土) 13:38:49アレくらいの速度だった。ベンチマークという特定条件下で少々速くなっても、
今はサーバサイドが普通だから、超強力ハードでもとろい。
少々速くなっても、ハードが進化しても、追いついていないよ。めでたいな。
遅いという証明だと思うんだが、
C++なんか仮想関数でvtblはさむだけで『おせぇ』とかいう話になる世界なのに。
0286仕様書無しさん
2006/01/21(土) 13:49:360287仕様書無しさん
2006/01/21(土) 13:52:09プロセッサのスピードは20倍になっているのに
JAVAはたったの2倍だってさ
0288仕様書無しさん
2006/01/21(土) 13:53:23年度末に処分される前にApacheとTomcat、JDK1.4を入れてみるかな。動くかなぁ。
0289仕様書無しさん
2006/01/21(土) 13:54:170290仕様書無しさん
2006/01/21(土) 13:57:04おもしれえ、漏れもPenPro 200MHzの鯖に同じことしてみよう
0291仕様書無しさん
2006/01/21(土) 13:58:3448倍になってるよ
0292仕様書無しさん
2006/01/21(土) 14:00:42C/C++の場合はPenPro〜PenIII/PenMのP6アーキテクチャにあわせてコンパイル
するのが普通だけどさ。
0293仕様書無しさん
2006/01/21(土) 14:01:33どれも同様にとろくせえｗ
0294仕様書無しさん
2006/01/21(土) 14:12:11これならいかがでしょうか？
0295仕様書無しさん
2006/01/21(土) 14:35:000296仕様書無しさん
2006/01/24(火) 20:20:170297仕様書無しさん
2006/01/24(火) 22:06:44JAVAは正式なロゴだぜ、馬鹿はも前
0298仕様書無しさん
2006/01/24(火) 22:08:01節操がないJAVA
0299仕様書無しさん
2006/01/25(水) 01:10:130300仕様書無しさん
2006/01/25(水) 22:52:390301仕様書無しさん
2006/01/26(木) 12:10:26VM上で動いてるんだから起動が遅いのは当然だし、
全体としてC++に勝てないのも当然だろ。
なんでそこを否定するかなー。
すでに領域の住み分けも進んでるんだし、
C++とJavaをキチガイのように比較する意味が分からん。
仕事があれば両方使う、がこの板的には正しいだろうがよ。ｗ
0302仕様書無しさん
2006/01/27(金) 00:00:59JVMさえ動けば、とりあえず何とかなるからね
その点、C++だとどうしても処理系依存があるから大変
逆にメジャーな処理系の場合はC++の方がパフォーマンスも良くて小回りがきいて楽
確かに両方使えるとかなり仕事の幅は広がるな
0303仕様書無しさん
2006/01/27(金) 00:39:44＞すでに領域の住み分けも進んでるんだし、
を認めれば
＞全体としてC++に勝てないのも当然だろ。
は意味不明だな。
領域によってはJavaの方が勝っているからこそ住み分けも起こるのだが。
>>302
Javaの案件の多くはインテル系の上で動くLinuxの上なんだが…
Linuxは「謎な処理系」じゃないよな、メジャーだよな?
0305仕様書無しさん
2006/01/27(金) 13:10:19Solarisとか、Windowsの方が案件数は多いだろ
稼働台数ベースだと解らんだろ
0306仕様書無しさん
2006/01/27(金) 19:36:06JDKはがんがんアップデートしましょう。
1.2から1.5まで一揆なんて楽勝でしょうね。何事もなく平気で動くはずですよね。
なんたって世界に誇るオブジェクト指向の粋を集めた言語ですから。
(注 もしなんかあっても責任はとれませんのであしからず。自己責任で
ご判断下さいね。)
0307仕様書無しさん
2006/01/27(金) 19:40:180309仕様書無しさん
2006/01/27(金) 21:11:360310仕様書無しさん
2006/01/27(金) 21:20:210311仕様書無しさん
2006/01/27(金) 21:31:320312仕様書無しさん
2006/01/27(金) 21:33:090314仕様書無しさん
2006/01/27(金) 22:59:27そうですか・・・
0315仕様書無しさん
2006/01/28(土) 00:35:59Write Once, Debug Everywhere.
って言ってたな > Java
そんなのに気楽にアップデートしていいのかと言いたい。
0316仕様書無しさん
2006/01/28(土) 21:28:250317仕様書無しさん
2006/01/28(土) 21:50:380318仕様書無しさん
2006/01/28(土) 22:18:27この最新のWindowsの持つ能力を活かしたソフトウェアを募集します。ソフトウェアのジャンルは問いません。
ぜひ、この機会にソフトウェア作りに挑戦してみてください。
http://win64xp.impress.co.jp/
0319仕様書無しさん
2006/01/30(月) 13:44:08畑もまったく違うのに
ハードウェアとソフトウェアとでそんな速度変化を気にしている
お前は脳みそがとろけているのか。
Javaが倍以上になってCPUも20倍になったら
Javaの速度は昔に比べて 2 * 20 = 40倍 以上も速くなった
ということでそれはそれで非常にいいことじゃないか。
0320仕様書無しさん
2006/01/30(月) 13:53:181.3 -> 1.4
1.4 -> 5.0(1.5)
というバージョン一つ違いであれば1.3以降からは
上位互換性は保たれている。
1.1, 1.2は若干癖がある。
だが、コーディング規約を守っていれば
互換性問題に悩まされる可能性はかなり少ない。
たとえばimport宣言に *を使っている部分。
あるクラスを使うとき、複数のパッケージを*でまとめて
importすると1.5から新たに追加された名前が同じクラスが
登場したことでエラーになる。
Javaコーディング規約としてはimportに*を使うことは推奨されていないので
その部分を直せばすぐに解決するのでそこは無問題。EclipseなどのIDEを
使ってCtrl + Shift + O を押せば一発で直ってしまうものだが。
コーディング規約をしっかり守って横着さえしなければこのような
上位互換性問題で引っかかる可能性は非常に低い。
あとは新たに追加されたキーワードと同じ名前を変数名に使っている場合。
1.4から登場したキーワードassertはJUnitに使われていたメソッドassert問題で見事に引っかかった。
だがJUnitも即座に最新バージョンが出てメソッド名はassertEquals()などの名前に変わってあっというまに
解決した。
ほかに、極まれだとは思うけれども変数名にenumとか変なものを使っているとエラーになる。
0321仕様書無しさん
2006/01/30(月) 13:56:04すくなくともセキュリティ上の問題から上げたほうが
いいとApacheが言っているならあげるべき。
>>311
Tomcatはバージョン5.5からJava5専用になり
さらに高速化したのでお勧めしたいところ。
だがTomcatの使い方、server.xmlの扱い次第では
慣れない者が扱うとバージョンアップに多少手間がかかることもある。
$CATALINA_HOME/commons/libに入っているものも中身が若干違っているからな。
0322仕様書無しさん
2006/01/30(月) 22:58:060323仕様書無しさん
2006/01/31(火) 01:43:36JDK1.2に変わったときにclearしてlengthとcapacityを0にしようとするとcapacityが16になるという仕様変更でちょっと困った
0324仕様書無しさん
2006/01/31(火) 21:50:160325仕様書無しさん
2006/02/02(木) 21:49:09お前さてはcapacity==0という条件を何かのフラグ代わりに使ってたな。
StringBufferのcapacityは、あくまでも最適化の為に公開されているんであって、
必要に応じてensureCapacityを発行するためのもの。
これをフラグ代わりに用いるような流用は、Javaに限らず悪しき風習だ。
メモリに余程の制約のある組み込み環境以外ではするべきではない。
0326仕様書無しさん
2006/02/07(火) 13:04:590327仕様書無しさん
2006/02/07(火) 13:51:05違うやcapacityへの0代入は無かった
setLength(0)でクリアをするとコンストラクタで指定していたcapacityがクリアされて16になってしまうって所だｗ
0328仕様書無しさん
2006/02/07(火) 14:34:56javax.xml.namespaceとかちょっと前と仕様が変わってない？
0329仕様書無しさん
2006/02/07(火) 21:22:44サービスの起動するのがデフォルトになった。いいね。
0330仕様書無しさん
2006/02/07(火) 21:24:44>コーディング規約を守っていれば
>互換性問題に悩まされる可能性はかなり少ない
枝番規約さえ守っていればEclispeのトラブルに
悩まされる可能性はかなり少ない でいいんでしょ
0331仕様書無しさん
2006/02/08(水) 20:46:02JDKのバージョンなんて客が決めるし
メンバーは毎回寄せ集めのJava厨だし
0332仕様書無しさん
2006/02/08(水) 23:16:250333仕様書無しさん
2006/02/12(日) 19:28:03そのためにこのスレタイになっているCheckstyleやFindBugsを使って
コーディング規約を守らせるんだろ。
守ってない奴のコードは警告数がとんでもないことになるぜ。
50万とかざらにあったもんじゃない。
0334仕様書無しさん
2006/02/12(日) 19:30:56> コーディング規約なんて誰も守らないし
> JDKのバージョンなんて客が決めるし
それはM$JVMの影響だな。
純正Javaで1.3以降だったらこっちが説得しやすい。
こちらがバージョン互換性のことについて
全責任を取りやすい。古いコードを描いている
JARファイルがあると厄介だが、
そのJARを切り離して書き直すか
JAR描いた奴を最新版に対応させるようにしておくなどが
できれば開発効率が上がる。
なんでもかんでも客に逆らえないようでは
開発効率に支障をきたす。
そのことを顧客にわからせないといけない。
0335仕様書無しさん
2006/02/12(日) 19:32:43> >>320
> >コーディング規約を守っていれば
> >互換性問題に悩まされる可能性はかなり少ない
>
> 枝番規約さえ守っていればEclispeのトラブルに
> 悩まされる可能性はかなり少ない でいいんでしょ
Eclipseについても 3.1.1 -> 3.1.2へのアップデートではたいして問題ないが。
3.0 -> 3.1にいくときには変なプラグインに気をつけないといけない。
フィーチャーもアップデートサイトもないプラグインはほぼ怪しいとみたほうがいい。
2.x -> 3.xへのアップブレードとくらべればましだが。
0336仕様書無しさん
2006/02/12(日) 23:29:15どっかの誰かが言っている事と違いすぎるね。
0337仕様書無しさん
2006/02/13(月) 01:25:340338仕様書無しさん
2006/02/13(月) 01:39:340339仕様書無しさん
2006/02/13(月) 08:35:430340仕様書無しさん
2006/02/16(木) 11:39:50だからJavaは問題ないと。
それからEclipseはEclipse標準プラグインだけなら
まず互換性問題で苦しむ事はない。
0341仕様書無しさん
2006/02/16(木) 11:42:56オープンソースだから富士通の中にいる一部の駄目な連中
によってEclipseの品質が悪化させられる事はない。
まだまだIBMが大きく牽引しているからな。
あのIBMだ。世界最大の特許数を誇り、世界最大の研究期間を
誇るあのIBMの研究成果が、まさにEclipseに対して急速にコミットされている。
Eclipseは、技術力もしっかりして、Javaの研究もしっかりしているＩＢＭが
作った製品だ。
富士通どもの連中だけではEclipseというすばらしいプロダクトを
作ることはできない。
0342仕様書無しさん
2006/02/16(木) 12:57:00が・たまに進むべき道を誤るときがある。
ひとつは OS2
もうひとつは Javaへの傾倒これは危険だ。SUN互換の考えからは
そろそろ手を引いてネイティブIBM extendJAVAへの拡張をマジで
考えてほしい。それによりJavaの環境は飛躍的に向上するのでは
ないかと思うがみなさんはいかがかな？
0343仕様書無しさん
2006/02/16(木) 13:09:16IBMとSunとMSが綱引きをしている現状がすばらしいのであって
IBMがそこから抜ける状況は望ましくない
0344仕様書無しさん
2006/02/16(木) 13:12:55将来的にはリプレースでまだ金が取れる。
すばらしいシステムなんじゃねーかな。
馬鹿馬鹿しいとも思うけどな。
0345仕様書無しさん
2006/04/11(火) 11:43:37サルでも （ (
,,.ｒ'' ゛~~` ''ッ,, 立てねーぞ ) ）
､ ゛ ,,,,,,,,,,,,,,,,,,,,, ヾ. こんなスレ ,.、 / ／
ﾐ ﾐ゛,へ.__, ,_ﾉヽ 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'､...,,,___
＾＾＾＾ !ｗニこ)こ)二）｀) （＿,,,..- ､...二⊃_).)
0346[email protected]
2006/04/24(月) 23:26:100347仕様書無しさん
2006/05/28(日) 23:08:29■ このスレッドは過去ログ倉庫に格納されています