結城さんのJava入門書、「Java言語プログラミングレッスン」がJava7に対応した第３版が出るということで、思い出した話。 まずは出版おめでとうございます、おつかれさまでした。ただ、評価はちょっと厳しめです。 Java言語プログラミングレッスン 第3版(上) Java言語を始めよう 作者: 結城浩出版社/メーカー: SBクリエイティブ発売日: 2012/11/14メディア: 単行本購入: 1人 クリック: 7回この商品を含むブログ (8件) を見るJava言語プログラミングレッスン 第3版(下) オブジェクト指向を始めよう 今回の「Java言語プログラミングレッスン」もやはり上巻でif、for、配列、下巻でクラス、インタフェースという構成になっていて、１冊にまとめれなかったものかという感がぬぐえない。 あわせて5040円というのは入門書として高価だし、上巻だけでは役にたたない。 まだ発

Javaのクラス宣言には5種類ある。 トップレベルクラス・ネストしたクラス・内部クラス・ローカル内部クラス・匿名クラス(無名クラスとも言われる)の5種類だ。 今回はこの5種類のクラス宣言のおさらい。 トップレベルクラス これは普段使っているクラス。拡張子が.javaのファイルを作り、そのファイル名とクラス名を合致させなくてはいけない。そのjavaファイルのトップレベルに位置する。 ネストしたクラス 「ネストしたクラス」(Nested class)とはクラスの中にクラスがネストしている状態。トップレベルクラスの内側にstaticキーワードをつけてクラス宣言を行う。 public class Outer { public static class Nested { } } このネストしたクラスは、トップレベルクラスと同等の機能性を持つ。 クラス名はOuter.Nestedという名前で扱われるが

前年、 #JavaEE開発あるある で呟くとJavaEE6の本がいただけるということで、つぶやいていたらなんと当たりました。 ありがとうございます。 Beginning Java EE 6~GlassFish 3で始めるエンタープライズJava (Programmer's SELECTION) 作者: Antonio Goncalves,日本オラクル株式会社,株式会社プロシステムエルオーシー出版社/メーカー: 翔泳社発売日: 2012/03/09メディア: 大型本購入: 5人 クリック: 147回この商品を含むブログ (29件) を見る 現時点では日本語でのJavaEE6全体に関して解説した書籍はなく、JavaEE6を使ってみたいという人がいても英語の資料を読む必要があり、敷居が高いものになっていました。 それがついに解消されるということで、非常に嬉しいです。JavaEE6が広く使われるよ

本日のエントリーはJava Advent Calendarの25日目です。昨日は @mike_neck さんのmike、mikeなるままに…: hamcrestを拡張してmoreThanとか作ってみたでした。本日はクリスマスですが、Advent Calendarはまだまだ続きます。明日はt.ogisawaさんのhttp://webinter.sakura.ne.jp/pbd/210です。 さて、今年はJava7がリリースされましたね。try-with-resources、diamond operator、invoke dynamic、Folk/Join framework…魅力的な新機能の数々が、多くの人によって紹介されています。が、Java7の変更はそれだけじゃないはず。小粒だが、キラリと光る変更がきっとあるはず。ということで、Java6とJava7のsrc.zipを比較してみました。小

前回のエントリーでは「Java関係ないやん」的なツッコミも受けましたが、 今回からは、Javaを前提にしていきます。 Javaで文字から文字コードを作る 新人くん「Javaで文字から文字コードを作りたいんですが、どうすれば良いんですか？」 先輩社員「getBytesすれば一発だね」 新人くん「getBytesした後のバイト配列から上手く文字列を作れないんですが・・・」 先輩社員「それは別の話だね」 前回のエントリーでは、WordやIMEを利用した文字と文字コードの変換方法を説明しましたが、 では、Javaではどうやれば良いのでしょうか。 Javaで文字から文字コードを作るには、 先輩社員も言っている通り、String#getBytes(charset)するだけです。 具体的なコードは、以下のようになります。 String str = "あいうえお"; byte[] utf8 = str.g

Java出来ますって言ってるのにOpenJDKのコードをチェックアウトした事も無いようならモグリである可能性は高い。 一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選 - 設計と実装の狭間で。 OpenJDKのコードをチェックアウトした事も無いモグリです。こんにちは。 ま、それはともかくw　上記はいいエントリだし参考になります。ただまあモヒカンなのは事実だと思うのでゆとり路線でどういうオープンソースソフトウェアを読むと良いかもしれないって言うのを書いてみたいと思います。かもしれないって書いてるのがすでにゆとりですね。サーセンw JUnit すでに語り尽くされているとは思いますが、これは外せない。 僕自身は下記のJUnit3.8.2を読解する記事を読んでからJUnit3.8.2を読んでみましたね。 Java World (ジャバ・ワールド) 2005年 9月号 出版社/

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ではな

Java5における総称型（generics）の導入に伴い、Javaの型システムは以前と比べて高機能になった反面、理解するためのハードルが高くなっています。もちろん、Javaの型についてきちんと理解するためには言語仕様を勉強すればよいのですが、手っ取り早く理解するための方法としてリフレクションAPIを使ってみるというのが有効です。リフレクションAPIの先祖はJava1.xのころから存在しており、フィールド、メソッド、クラスなどの情報を実行時に取得するためのものですが、総称型に合わせてJava5から新しいAPIが追加されています。ここではリフレクションAPIを使い、Java5の新しい型システムについてまとめてみたいと思います。 JDK1.4までの型はすべてClassクラスのインスタンスに一対一対応する JDK1.4までに存在していた型はパターンに分けると以下の3通りに分類できます。 基本型（i

ジェネリック（総称あるいは汎用）プログラミング（英: generic programming）は、具体的なデータ型に直接依存しない、抽象的かつ汎用的なコード記述を可能にするコンピュータプログラミング手法である。 ジェネリックプログラミングはデータ型でコードをインスタンス化するのか、あるいはデータ型をパラメータとして渡すかということにかかわらず、同じソースコードを利用できる[1]。ジェネリックプログラミングは言語により異なる形で実装されている。ジェネリックプログラミングの機能は1970年代にCLUやAdaのような言語に搭載され、次にBETA、C++、D、Eiffel、Java、その後DECのTrellis/Owl言語などの数多くのオブジェクトベース (object-based) およびオブジェクト指向 (object-oriented) 言語に採用された。 1995年の書籍デザインパターン[

はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ

public class foo { final static String bar = "a" + "b"; public foo() { } public String bar(String baz) { return "a" + "b" + baz + "c" + "d"; } } コンパイルしてデコンパイル # javac -version javac 1.6.0_24 # javac foo.java # jad foo.class // Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.geocities.com/kpdus/jad.html // Decompiler options: packimports(3) // Source File Na

元ネタはこちらですが、「優れたJavaプログラマ」を見分ける質問ではありません*1。次のような状況を想定してください。 受託業務を中心にしている弊社は、Javaで業務系ウェブアプリケーションの開発を行う事になりました。しかし社内のリソースを使うにも１−２名足らない事が見積もりから解っています。そこで、中堅エンジニアを1−2名募集することになりました。正社員か派遣かは問いませんが、経験が３年程度の中堅プログラマが必要です。同等またはそれ以上のスキルを持つ正社員がプロジェクトを牽引しますが、ゼロから教えながら教育することはできないので、必要最低限のスキルを持っていることが条件になります。 こんな状況を想定して、面接の質問を考えてみました。経験が３年程度あれば、問題なく答えられるはずです*2。尚、質問はホーム言語がJavaである前提です。 下記質問にそれぞれ50文字以内を目安に簡単に説明すること

ネタ元 業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 結論から先に言うと、3と10以外は結構直接的にscalaで解決できるというか、javaに比べてscalaの方が便利だとおもいます。*1 あと、元ネタのblogの人はgroovy詳しいみたいですが・・・ groovyとscala比べるとgroovyの方が手軽で便利だったり、scalaのほうが型安全だったり*2いろいろあるかもしれませんが、groovyあまり詳しくないので、その辺の言及というか、比較はやめておきます。*3 1.標準APIのチェック例外が扱いにくい チェック例外ってなにそれおいしいの?(・ω・) java Field field; try { field = getClass().getField("testField"); Object value = field.get(this); }

Java: The Good Partsの本のタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は本当にGood Partなのか？ - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす

追記： 指摘の通りで、現実的な連結回数での計測でもないですし、統計手法を用いた分析をしていないので、このエントリの計測値は当てにしないでください。なので以下のブログを参考にしてください。 currentTimeMillis()で計測しておいて plusTime:14780, concatTime:7053, sbuilderTime:7, sbufferTime:13 とか、その7とか13の有効数字はいくつだっての。 激しく今更感があるタイトルですが(；・∀・) 昔に取り上げたのですが、 文字列の結合をやるからといって、すぐにStringの+をつかってはいけない - じゅんいち☆かとうの技術日誌 Stringの+演算子は間違った使い方するとパフォーマンスが低下しますよっていう話題。若干ネタ成分ありますが、ご容赦ください。 これ系の話題は自分的にはオワコンなんですが、最近、また話題を見つけた

前回でパフォーマンス計測に用いるタイマーについての理解を深めたので、やっとパフォーマンスの計測を始めることができる。 今回のテーマはJavaの文字列連結だ。タイムリーだね。 文字列連結についての基礎知識 Javaの文字列連結についての言語仕様まわりは Stringの連結はそう簡単なものではない - じゅんいち☆かとうの技術日誌 が詳しい。しかし、パフォーマンス計測がなっちゃない。パフォーマンスの計測はそう簡単なものではない。 currentTimeMillis()で計測しておいて plusTime:14780, concatTime:7053, sbuilderTime:7, sbufferTime:13 とか、その7とか13の有効数字はいくつだっての*1。 そんなわけで、計測方法を工夫してみよう。二重ループとし、内側を1000回、それを500回繰り返す。ループが1回まわる間に1回ずつSy

駄目だ。大問題だ。 long t1 = System.currentTimeMillis(); long t2 = System.currentTimeMillis(); System.out.println(t2-t1); 結果はなんとでるか？ 99.9%以上の確率で0が表示される。そもそもSystem.currentTimeMillis()は時刻をミリ秒で返す。1行のプログラムを実行するのに1ミリ秒もかかってたら、たかだか1000行分動いただけで1秒かかってしまう。今のコンピュータはそんなに遅くない。 そもそもドキュメントをちゃんと読むと ミリ秒で表される現在の時間を返します。戻り値の時間単位はミリ秒ですが、値の粒度は基本となるオペレーティングシステムによって異なり、単位がより大きくなる場合があります。たとえば、多くのオペレーティングシステムでは、時間を 10 ミリ秒の単位で計測します

共通関数継承とは、あるクラスで共通的に使うだろう関数やメンバを、親クラスのメソッドやメンバとして定義するパターンだ。Constant interfaceパターンやimport staticあたりが関係するアンチパターンとされるモノの一つで、神様ルートクラスを嫌い、POJOを好むのあたりの、ごく初歩な議論になるだろうと思う。 package spike; public abstract class SuperUtil { /** * 時刻形式の文字列から、日付部分を抜き出す */ protected String timestamp2Date(String timestamp) { if (validTimestamp(timestamp)) return timestamp.substring(0, 10); return ""; } /** * 時刻形式の文字列から、時間部分を抜き出す