Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS
Throwable、Exception、RuntimeException(RTE)、Errorあたりを整理しながら、色々考えてみた。私見に基づくので、間違っているかもしれないけれど、自分としては頭が整理できたかな、と感じたので晒してみる。異論があったらコメントください。 まず、一番基礎的なところで、継承関係の整理から。こんなツリーになっています。 Throwable Error Exception RuntimeException そして、本稿での用語の定義。caller＝呼出す側のコード callee＝呼出される側（throwする側）のコードとします。 Throwable Throwableは「throw文に指定できる何か」という意味ですね。 Instances of two subclasses, Error and Exception, are conventionally used
殺伐としたプログラム - きしだのHatena
@daichan4649に「殺伐としたプログラムしか見ていないのでいつも癒されます」と言われたのだけど、「殺伐としたプログラム」ってどんなのだろう？ こうですか？わかりません ＞＜ lockしたらunlockしません。早い者勝ち ソースはこれ import java.awt.*; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; import javax.swing.*; public class LockSample { private static Lock lock = new ReentrantLock(); public static void main(String args[]) { JFrame f = new JFrame("殺伐としたプログラム
Servlet(サーブレット) / JSP入門 : Javaサーバサイドアプリ
サーバ側で動作するJavaアプリケーションを作成するにはサーブレットやJSPを使います。サーブレットとJSPは基本的に同じことを行いますが、サーブレットはJavaプログラムと同様に作成するのに対し、JSPはPHPのようにスクリプト言語のような記述します。そこで画面表示部分の作成にはJSPが適しており、データベースとの接続などバックエンドで動く部分はサーブレットで作成するのが適しています。 ここではサーブレット及びJSPの使い方に関して具体的なサンプルを使いながら確認していきます。 なおサーブレットやJSPはサーバ側でJavaアプリケーションを作成するための仕様であり、実装したアプリケーションとして無料で提供されているTomcatを使っていきます。TomcatはWebサーバとしての機能も持っておりTomacat単体で試していきますが、Apacheなどと組み合わせる場合は『Tomcatとの連携
ReadWriteLockのサンプル - きしだのHatena
では、ReadWriteLockのサンプル。 読み込みスレッドは互いにロックせず、書き込みスレッドは他のスレッドとは同時に動かせない、というロックです。 サンプルでは、「か電車」が書き込みスレッド、「電車」が読み込みスレッドです。「か電車」が動くときには他のスレッドは動けません。 ReadWriteLockの実装としては、再入可能なReentrantReadWriteLockが用意されているので、これを使います。 ReadWriteLock lock = new ReentrantReadWriteLock(); 実際にロックするときは、ReadWriteLockオブジェクトからwriteLock/readLockメソッドで書き込み用ロックか読み込み用ロックを取得します。 Lock reallock = writer ? lock.writeLock() : lock.readLock()
銀行の言語事情 - novtan別館
といってもグローバルに活躍するためのマルチリンガルな話ではありませんよ。 今やメガバンクになってしまいましたが、僕がIT業界に入ったときはまだ都銀と呼ばれていた某銀行でのお話。用語について一切説明せずに行ってみる。世代チェッカーかも。 ホスト系 今やメインフレームだからといってホストでもない時代ではありますが、都銀のシステムはトランザクション量やダウンタイムの問題からやっぱりメインフレーム、で、過去の遺産がありすぎてホスト型。 言語はCOBOLが中心ですが、コア部分に近づくとPL/Iだったりアセンブラだったりする。大事なスキルはJCLを書けること。まあ、JCL自体はシェルプログラミングと変わりません。VOL-=SELの指定とか面倒だけど。基本的に端末のI/Fを想定しているから、SNAとかFNAとかで通信しなきゃいけなくて手続きはめんどくさい。メモリとかディスクの容量が少なかったときの設計を
いつもの - しげるメモ
いつもどうやってんの？と急に聞かれたので。自分で書いててどうかなと思ったりも。 全体 人間が考えやすい言語で脳に定着させて、それが揮発する前にコードに起こすのが一番速そう。 登場人物と、その役割を決める とりあえずインターフェースを書く UMLでクラス図を描くよりなぜか速い *1 振る舞いを決めて、メソッドにする 登場人物が役割をこなすために必要なものの最低限 クラス図で印刷して、関係に矛盾がないか確認 依存性を線でつないで、相互依存等がないか調べておく 勢いでJavadocを書く 正常系は1行 副作用は全部列挙 異常系は全部列挙 勢いで全部の実装を書く Javadocに書かれていないことは絶対にしない バグっぽくても無視。あとでどうせテストする 複雑なロジックはパッケージプライベートのstaticにおいだしておく テスト性のため Javadoc必須 勢いで全部の単体テストを書く Java
ActionScript3.0 とかいろいろ
Link:ActionScript3.0 サンプル 色温度(33d) Hibernate データ操作(43d) Hibernate Middlegen(44d) Hibernate 基本(44d) Tomcat ベーシック認証(44d) Java javaコマンド(52d) Java JDBC(60d) Java サニタイズ(61d) Java logging(66d) Java JDBC ConnectionHelper(67d) BlazeDS めも(72d) BlazeDS messaging framework(73d) BlazeDS BlazeDSとは？(73d) MS-DOSプロンプト メモ(79d) ActionScript3.0 コアクラス EventDispatcher(81d) Tomcat メモ(81d) Apache tomcat連携(ajp)(86d) MySQ
Javaの冗長な記法って小クラス主義の現れではないかな - 矢野勉のはてな日記
Java以下は無駄に長い駄文です。なんか書いてみたはいいもののうまくまとまらなかった。ごく一部しか表せなかった気がする。これではInputStreamReaderとかがたくさんオブジェクトを連結しないと使えないめんどくささをなぜ許容できるか、しか表せてない... もともとは「 Java における本質的でない記述がどのように大規模開発に役立つのか - kwatchの日記」がらみの話です。文中にいくつか「アクセッサが簡潔に定義できない」「FileReader に文字コードを渡せない」のような例があって、「それらが改善されたら大規模開発になにか不利益があるのかどうか」という具体的な質問があったので私はそこにコメントしときました。私はコメント欄に「不利益なんてないよ」と回答しました。実際のところ、後方互換性が維持され、言語としての統一性が維持されるなら別に不利益なんてあるわけない。あるとしたらマネ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラマーの常識をJavaで身につける