1) Introduction In today's networking environments, particularly corporate ones, application developers have to deal with proxies almost as often as system administrators. In some cases the application should use the system default settings, in other cases it will we want to have a very tight control over what goes through which proxy, and, somewhere in the middle, most applications will be happy
以前書いた「バイナリサーチ」徹底解説の続編みたいなものである。筆者はこのところ、業務プログラムを書き倒しているのだが、その時に結構頻繁に遭遇するちょっとした問題を解決するにあたって、同僚たちがあまりうまいやり方を知らない....というのを、少し気にしているのである。その問題とはこういうタイプのものだ。 データベースのあるテーブルが、実際には階層構造になっているにも関わらず、フラットに定義されているために、実際に欲しい階層データを構築するのに何回も SQL を呼んでいる....サブキーを考慮して order by してやれば、正しい順番で1回で取れるのにねぇ... そういうデータで、階層ごとに合計が欲しいんだが、Map を使って合計やってるぞ...これも Map とか使わずに、1回ループさせるだけでできるのにね.... という問題だ。これ要するに、階層データがベタな SQL のテーブル1個で
一般に、モジュールにはバージョン番号が割り当てられる。多くのオープンソースプロジェクトはlog4j-1.2.15.jarのように名付けられたリリースをつくる。これによって開発者は、実行時の手動検査によってではあるが、オープンソースライブラリの特定のあるバージョンが使われているかどうかをクラスパスを調査することによって決定することができる。しかし、プログラムは異なるバージョンのライブラリに対してコンパイルされていることが多い:暗黙の仮定はlog4j-1.2.3.jarに対してコンパイルしてlog4j-1.2.15.jarに対して動かしても挙動としては互換性がある、ということだ。次のマイナーバージョンにアップグレードするだけなら一般には互換性がある(これが log4j 1.3 での問題が結果として互換性のない新しいブランチ 2.0を作り出すことになった理由である)。これらの多くは一般的に制約よ
Recently, I landed a new library for JRuby that will be part of JRuby 1.5. Before I start I want to conjure the image you see below this text: that’s Right! Mr. Potato Head: a role model for us all. Something that delights us for hours (or at least, probably did, at one point in our lives), is flexible, and is not only a toy, but also a starchy food product. Bear with me for a second, and excuse w
これからの当然の結果として、同じ名前の異なった Classオブジェクトを持つVM中に、複数のクラスローダを持つことができる、ということである。com.infoq.example.Appという名前のクラスを、同じVM上のバンドルcom.infoq.exampleのバージョン1とバージョン2の両方によってエクスポートできる。バージョン1にバインドされたクライアントバンドルは、バージョン1のクラスを得る。バージョン2にバインドされたクライアントバンドルは、バージョン2のクラスを得る。このことは、モジュールシステムにかなり普通に起きることである。同じVM上で、あるコードは、ライブラリの古いバージョンをロードする必要があり、一方(他のバンドルにある)新しいコードは、ライブラリの新しいバージョンが必要な場合である。幸いにも、OSGiは、そのような推移的な依存性を管理し、非互換なクラスに起因する問題がな
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる〜から派生して、 「他の例外クラスを継承しただけの例外クラスを作らない」に不同意の理由 - Diary of Dary、 例外クラスの指針 - 猫とC#について書くmatarilloの雑記や、さらには Twitter で Java の検査例外と非検査例外についての議論へと発展したので例外についてまじめに考えてみた。 あくまで、今の自分の考えなので真に受けない方がいいかも!そもそも経験が少ないので、トンチンカンなことを言ってるかもしれません。 あ、それと、用語は基本的に Java から取ってきています。ただ、メソッドじゃなくて関数を使っているけど、これに深い意味はありません。多分。 例外とは まず、例外とは一体何者なのか、ということ。 ここでは面倒を避けるために、Meyer 先生の定義を借りること
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
読者の皆さんは、「OSGi」という技術を耳にしたことはありますか? ソフトウェア統合開発環境の1つ「Eclipse」のコア技術というとピンと来る方も多いと思います。本稿では、ここ数年さまざまなアプリケーションの(SpringやJBoss、GlassFishでも)基盤技術として採用されているOSGiについて解説します。 日本企業も多数参加している「OSGi Alliance」 OSGiを一言でいうと、「Javaモジュールの動的追加や実行を管理するための基盤システム」です。この基盤システムの仕様をOSGi Service Platform仕様として、非営利団体であるOSGi Allianceが規定しています。 このOSGiの仕様を規定するOSGi Allianceは、1999年に「Open Service Gateway Initiative」という名称で設立されました。「Gateway」とい
JavaScript を呼び出す Java アプレットを JUnit などで単体テストする場合、当然ながら正式なアプレットの実行環境ではないため JSObject#getWindow() の呼び出しで例外が発生してしまうことになる。テストのために JSObject を自作のスタブで置き換えられると便利であろう。今回はこの JSObject の置き換えについて調べてみる。なお調査に使用する JDK は以下の通りである。 java version "1.5.0_10" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode, sharing) netscape.javascript.JSObje
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く