タグ

Javaに関するsinsengumi-2のブックマーク (165)

  • Javaでスレッドを使う際の注意点 | 株式会社シンメトリック公式ブログ - 携帯開発から生まれる技術情報

    Javaでスレッドを使う際の注意点|株式会社シンメトリック公式ブログ - 携帯開発から生まれる技術情報| 携帯サイト開発から生まれる技術情報ブログ どんなプログラム言語でもそうなのですが、マルチスレッド下でプログラムを組むときは、シングルスレッドとは違うところに色々気を使わないといけません。 今回は、Javaマルチスレッドプログラムでは基的なことですが(自分だけかもしれませんが)よく忘れて、不可解な動作に首を傾げてしまうポイントについて説明していきます。 ヒープ領域にあるデータの更新タイミングをちゃんと把握する Javaプログラムからアクセスできるメモリ領域には、大きくわけて、スタック領域(以下スタック)とヒープ領域(以下ヒープ)の2種類が存在します。 スタックは、ローカル変数や、メソッドの引数・戻り値情報を持ち、ヒープは newされたオブジェクトや、ロードされたclass情

  • 取り立ては無いの?

    キャッシングは、お金を借りることですから、返済が遅れた場合にテレビドラマ等で見かける「早く金返せやっ!」という風に怒鳴るような取り立て行為があったら怖いですよね。 しかし、銀行系でのキャッシングや大手カ-ド会社・大手消費者金融なら、このような取り立てはほぼありません。これらの会社は、キャッシングの返済期日が過ぎた場合に、電話やメ-ルで「お支払期日が過ぎておりますので、、」的な事務連絡が入る程度です。 そして、ちゃんと「○月○日までに支払います」と答えれば、その約束が破られるまではほぼ連絡が入りません。 これは、貸金業法という法律で取り立て行為の規制という規定があり、更に、この規定を金融庁のガイドラインという形で具体的に「朝9時から夜の8時までに正当な理由なく取り立ての訪問や電話をしてはならない」・「電話の回数は1日3回まで」・「電話や訪問でも、暴力的な態度や言葉を使用してはならない」等が禁

  • StringBuilderを使うべきかどうか。 - Return to Saisse’s Wiki

    なんか、StringBuilderを使った方が速いって勘違いしている人がいるので、ぐぐってみたら↓あたりが.... http://d.hatena.ne.jp/suer/20090427/1240758191 http://akitosblog.seesaa.net/article/163550555.html この辺、StringとStringBuilderの特性を知らないで計測しているので、Stringの+演算子ががとんでもなく遅いことになっていますけど、全くそんなことないです。問題は2つあって一つがStringの書き方で最適化が効かないような書き方をしている点とStringが不得意な巨大なStringを作り出している点。 一般的にあるような文字列連結なら、最適化が効いてStringBuilderと同じようなコードに置き換えてくれるので、うん百倍の性能差が出ることは無いです。 impo

    StringBuilderを使うべきかどうか。 - Return to Saisse’s Wiki
  • 実用を考えると、文字列リテラルとの比較は文字列リテラルが先のほうが見やすい - きしだのHatena

    もう落ち着いた話題だけど、SwingWorkerのサンプル書いて思い出した。 文字列リテラルの比較の話だけど、"リテラル".equals(s)よりもs.equals("リテラル")のほうが見やすいとか意味を反映しているとかあった。 けど、実際にJavaで文字列リテラルの比較などという無粋なことをする場合は、select〜case的な使い方をすることがほとんどであるような気がする。 PropertyChangeListenerであれば if("progress".equals(evt.getName(){ ・・・プログレスバーの処理 } else if("width".equals(evt.getName()){ ・・・幅がかわったときの処理 } else if("height".equals(evt.getName()){ ・・・高さがかわったときの処理 } のような。 HTTPだと if

    実用を考えると、文字列リテラルとの比較は文字列リテラルが先のほうが見やすい - きしだのHatena
  • nullはJavaのWeakポイント - Return to Saisse’s Wiki

    純粋にオブジェクト指向的に考えた場合、オブジェクト間の通信にnullを使用するなんてことはあってはならない事だ。 ある値がnullであるということは何かの状態を表しているわけで、その状態をnullで表してしまうと人間の頭にとっては扱い難い存在となる。 例えばあなたがコーヒーカップを持っているとしてコーヒーカップがnullだでは想像で補うことは可能であっても意味が通じない。状態をnullで表すのを止めてコーヒーカップが空だと言えば格段にわかりやすくなる。 ここで重要なのは名前がついているかどうか?ということだ。名前を付けることによって人間の頭は高速に処理できるようになる。名前を省略されるとそもそも状態があることを認識することが困難になる。 このことからnullはコンピュータのメモリの状態を表す言葉であって実装であるといえる。つまりnullはカプセル化の対象であって、インターフェース間でやりと

    nullはJavaのWeakポイント - Return to Saisse’s Wiki
  • 一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選 - 設計と実装の狭間で。

    10万行コード読んだらJava分かるよってTwitterに書いたらすげぇ勢いでRTされたので、調子に乗って捕捉エントリ書くよ。 Java Core API JDKインストールしたディレクトリに入ってるsrc.zipを展開すると入ってるから読むと良いよ。 すぐ近くにあるのから読むってのはメンタル的に楽でいい。 厳密にはOSSじゃなくて単に公開されてるってだけなんだけども、JavaプログラマなのにコアAPIのコード読んでないとか無いよね? どれから読めば良いか分からんかったら、 java.lang java.util java.io java.text 辺りをまずはキチンと理解すること。当然コードを読み終わったら、それを使ってコードを書く事。 OpenJDK http://hg.openjdk.java.net/jdk7/jdk7 OpenJDKを読むことで、プログラム言語してのJavaではな

    一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選 - 設計と実装の狭間で。
  • オブジェクト指向のソースを読むのが難しい理由 - 都元ダイスケ IT-PRESS

    ダラダラ書かない予定だよ。ざっくり行くよ。あと、分かってる人には当たり前な事だと思うよ。 あるクラスについて知りたかったら、まずその基底クラスを知れ 例えば、Integerクラスについて知りたいと思ったら、Integer.java だけを読んでいてはダメだ。確かに「Integerに特化した責務・構造・操作」は読み取れるかもしれないが、数値としての基的な責務・構造・操作はNumberに書かれている。それを読まずして、Integerが保つ数値という一面を知ることはできない。Integer.javaには「Integer - Number」*1の情報しか書いてないのだよ。差分プログラミング。 さらに、忘れちゃいけない。Object.javaを読め。全ての道は暗黙的にObjectにつながっている。Objectを知らずしてJavaのクラスを知る事は絶対にできない。Objectなんて、みんな「知った気

    オブジェクト指向のソースを読むのが難しい理由 - 都元ダイスケ IT-PRESS
  • TDD(テスト駆動開発)をはじめたい人にオススメの資料(無料) | Act as Professional

    TDDBC in TokyoをPHPUnitでやる予定なので、TDD関連資料をあさってました。 実際に手を動かして、1から2時間で最後までやり通せるTDDの資料を見つけました。 TDDに興味を持った方が最初にやるのにちょうど良い内容なので、お知らせします。 オブラブで公開されている車窓からのTDDです。Java+JUnitの構成で書かれていますが、PHP+PHPUnitで、ほとんどPHPっぽく書き直せば問題なくTDDの雰囲気を学べる内容です。 Fake It 三角測量 リファクタリングなどのタイミングを具体的に理解できるストーリー仕立てになっています。内容のボリュームもお手軽なので、TDDに興味のある方は、やってみてはいかがでしょうか?TDDの良さが体験できると思います。 PHPのコードをgithubで公開しています。「PHPでどう書くの?」って思った方は参考にしてください。

    TDD(テスト駆動開発)をはじめたい人にオススメの資料(無料) | Act as Professional
  • http://asklife.info/archives/1626

    http://asklife.info/archives/1626
  • Ant から eclipse コンパイラを使う - ..たれろぐ..

    Ant から eclipse 内蔵コンパイラを使ってコンパイルするのにつまづいたのでメモ。 EclipseWiki見ただけじゃ解決せず。 調べていったらJavalobbyに答えがあった。 まず、Ant の build.xml には、コンパイルタスクの前に build.compiler プロパティに org.eclipse.jdt.core.JDTCompilerAdapter を指定する。 <property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter"/> その build.xml をプロジェクトに取り込んだ後に、 [右クリック] → [実行] → [Ant ビルド...] と選択。 Ant ビルドの実行構成ダイアログが開くので、[JRE]タブを開き、上の方にある [ワークスペースと同じJREで

    Ant から eclipse コンパイラを使う - ..たれろぐ..
  • SerializableとserialVersionUID - 都元ダイスケ IT-PRESS

    以前、Javaのシリアライズ仕様がよくわからなくてエントリを書いた。 難解なSerializableという仕様について俺が知っていること、というか俺の理解 - 都元ダイスケ IT-PRESS まぁ、わからないまま書いたので論点もあっちゃこっちゃ飛びながらのエントリだったわけだけど、一年経ってコメントを頂いた。 serialVersionUIDに関しては、定義をしない場合にはクラスの構造を解釈して勝手にコンパイラが生成してくれます。 つまり、クラスのフィールドを変更したら勝手に変更してくれます。 問題点としては、コンパイラが勝手に計算してくれるので、複数のコンパイラをまたぐ場合に同じ定義のはずだけれども失敗することがある(らしい)ということです。 つまり、記事に書いてあることとは逆ですね。 JavaDocに記載されているのでご参照ください。 http://java.sun.com/j2se/

    SerializableとserialVersionUID - 都元ダイスケ IT-PRESS
  • Javaの冗長な記法って小クラス主義の現れではないかな - 矢野勉のはてな日記

    Java以下は無駄に長い駄文です。なんか書いてみたはいいもののうまくまとまらなかった。ごく一部しか表せなかった気がする。これではInputStreamReaderとかがたくさんオブジェクトを連結しないと使えないめんどくささをなぜ許容できるか、しか表せてない... もともとは「 Java における質的でない記述がどのように大規模開発に役立つのか - kwatchの日記」がらみの話です。文中にいくつか「アクセッサが簡潔に定義できない」「FileReader に文字コードを渡せない」のような例があって、「それらが改善されたら大規模開発になにか不利益があるのかどうか」という具体的な質問があったので私はそこにコメントしときました。私はコメント欄に「不利益なんてないよ」と回答しました。実際のところ、後方互換性が維持され、言語としての統一性が維持されるなら別に不利益なんてあるわけない。あるとしたらマネ

  • 構成管理 実践入門 Appendix Maven2はまり道 はまりその5 クリーンなビルドを

    第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その1 メインライン コードライン編その2 コードラインポリシー コードライン編その3 プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その1 リリース管理 リリース編その2 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか? Maven2のインストール まずは試してみよう さらに開発を進めよう ソースディレクトリの作成 依存ライブラ

  • Maven2で環境に合わせて設定ファイルを切り替える方法(改訂版) - TrinityT's BLOG

    新案件でpom.xmlの設定を見直したら、以前のエントリの方法が冗長だったので書き直し。 各環境で共通の設定部分をprojectタグ直下のbuildタグ内にまとめたことで、よりDRYな構成となった。 1.resourcesフォルダ以下のように分け、上書き変更したいファイルを置く。 src/main/resources/config.properties (開発) src/integration/resources/config.properties (結合テスト環境) src/production/resources/config.properties (番) 2.pom.xmlを以下のように記述 (※2008/5/21 一部修正) <?xml version="1.0" encoding="UTF-8"?> <project> 〜 <build>  ← 共通設定はすべてprojectタ

    Maven2で環境に合わせて設定ファイルを切り替える方法(改訂版) - TrinityT's BLOG
  • myeclipseide.jp

    This domain may be for sale!

  • 暇人プログラマの日記

    相変わらずお仕事が忙しく中々更新できません 今日はJavaにおけるコンパイル後のファイル名について勉強してみました Test.java //コンパイル後はTest.class public class Test { public static void main(String[] args) { //コンパイル後はTest$1Test3.class class Test3 { public Test2 getTest() { //コンパイル後はTest$1Test3$1.class return new Test2(){ void test() { System.out.println("Hello World!!!!"); } }; } } new Test().getTest().test(); new Test3().getTest().test(); } public Test2

  • 内部クラスをめぐる冒険。 - いもあらい。

    今書いているプログラムで、ちょこっと内部クラスを使ったりしているのですが、今日コンパイルしたときに、見知らぬクラスファイルが出来ていることに気がついて。 具体的には、 class Pieces { class PiecesOnBoard { ... } class PiecesInHand { ... } ... } という感じのコードなのですが、正しくコンパイルが通れば、Pieces.classとPieces$PiecesOnBoard.class、Pieces$PiecesInHand.classの3つのクラスファイルが出来るはずなのに、なぜかPieces$1.classというクラスファイルも。 どこにも無名クラスを使っていないはずだったので、どこかでなんかミスしたんじゃないかとずっとソースコードを見直してみたものの、ミスが見つからず。 この解答は最後に回すとして、内部クラスに関してい

    内部クラスをめぐる冒険。 - いもあらい。
  • Java 暗号化拡張機能 JDK5.0

    Java Is the Language of Possibilities Java is powering the innovation behind our digital world. Harness this potential with Java resources for student coders, hobbyists, developers, and IT leaders.

  • Javaプログラマに知っておいて欲しい「どうでもいいと思われがちな」xこのこと - 続・年中Sage進行

    Javaプログラマが知るべきxこのこと - @katzchang.contexts この筆者は同僚のクソファッキンなJavaコードを読んでうんざりすることがきっと日常なんだろうな。 上記記事はJavaでご飯をべている人には是非読んで欲しい良記事。 提言のほとんどはJavaに限らずC++/C#などのJavaに近いオブジェクト指向言語を扱う上でもとても有用な内容である。 Javaの初心者であっても、上記の内容を実践するだけでだいぶレベルが上がるはず。 この記事を読んで、先日珍しく複数人に同じ課題でコードを書いてもらった上で、お互いにコードをレビューするという仕事(研修というほうが近いかもしれない)があったのを思い出した。 せっかくなので複数人に目立った指摘事項をいくつか公開してみる。 上記の記事に比べれば細かくどうでもいいと思われがちな事項ではあるが、コードを書く上ではこういう方面

  • myeclipseide.jp

    This domain may be for sale!