タグ

ブックマーク / megascus.hatenablog.com (14)

  • Javaのスレッドで発生したキャッチされてない例外をログに出力する - 水まんじゅう2

    概要 Thread#setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler) を呼び出すことでアプリケーション全体のログ設定を変更することができる。 上の設定をThreadGroupで上書きすることができる。ただし、ThreadGroup自体がUncaughtExceptionHandlerを継承しているため、ThreadGroupのサブクラスを自前で作成する必要がある。 上の設定をThread#setUncaughtExceptionHandler(Thread.UncaughtExceptionHandler)を呼び出すことで上書きすることができる。 説明 Javaのスレッドの実行では、通常、エラーハンドリングは自前で行うのですが、キャッチされないRuntimeExceptionの処理を忘れてしまったりするこ

    Javaのスレッドで発生したキャッチされてない例外をログに出力する - 水まんじゅう2
  • どこからも使用されてないクラスを列挙する - 水まんじゅう2

    これはJava Advent Calendarの2日目の記事です。 さて、Javaで開発をしているといつの間にかどこからも使用されていないクラスというものが出てきてしまいます。 リファクタリングや仕様変更の結果、呼び出されてなくなったクラスです。 それら、どこからも使用されてないクラスを一覧化してみます。 まず、使用されているクラスを一覧化します。 一覧化にはjdepsを使用します。 jdepsの概要についてはCLOVERの記事を参照してください。 CLOVERの記事ではclassもしくはjarを指定していますが、実はパッケージ(フォルダ)を指定することで、その下のクラスの依存先をすべて出力してくれます。 使用されているクラスの一覧が出来たら、全体のクラスの一覧から引き算してあげます。 package 配下のクラス一覧を取得する方法はいろいろあるようですが、今回はGuavaのClassPa

    どこからも使用されてないクラスを列挙する - 水まんじゅう2
  • Java 8u92から増えた -XX:+CrashOnOutOfMemoryErrorと-XX:+ExitOnOutOfMemoryErrorを試してみた - 水まんじゅう2

    ※91だと思ってたら増えたのは92からでした。 試したのはWindowsで。OOM発生時にJVMを確実に落とすオプションらしい。 -XX:+CrashOnOutOfMemoryError >java -XX:+CrashOnOutOfMemoryError Main Aborting due to java.lang.OutOfMemoryError: Java heap space # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (debug.cpp:308), pid=6760, tid=0x00000000000026a4 # fatal error: OutOfMemory encountered: Java heap space # # JRE vers

    Java 8u92から増えた -XX:+CrashOnOutOfMemoryErrorと-XX:+ExitOnOutOfMemoryErrorを試してみた - 水まんじゅう2
  • Java Advent Calendar 2014 リソースごとに同時アクセス数の制限を行う - 水まんじゅう2

    これはJava Advent Calendar 2014の6日目の記事です。 昨日はbiblichorさんの「Jersey2×SpringSecurityのハマりポイント三選」でした。 Webシステム等、多数の処理を同時に行う場合、処理に使用するリソース毎に同時に処理ができる上限値を決めたくなることがあります。 たとえば、某拝承系SIerが開発しているCosminexusではURL毎に同時アクセスの最大数を設定でき、同時アクセス数を超えた場合はキューに溜めるという機能が存在します。 http://itdoc.hitachi.co.jp/manuals/link/cosmi_v0870/APSE/EU030187.HTM このようなエンタープライズなアプリケーション・サーバーを使わなくてもJavaではjava.util.concurrent.Semaphoreを使用することで、単純なアクセス

    Java Advent Calendar 2014 リソースごとに同時アクセス数の制限を行う - 水まんじゅう2
  • Java EE 7徹底入門を読んだ(JSFあたり) - 水まんじゅう2

    新年あけましておめでとうございます。 今年もよろしくお願いします。 さて、期間が空いてしまいましたが、JSFあたりを読みました。 JSFは2,3,4章が割り当てられており、このの1/3近くを占めています。 JSFについてはこのの中で一番良く書かれていると思いました。 JSF歴史的経緯もあり、他の最近のJava EEの仕様に比べると実装と仕様の区別が甘く、 仕様がどうであれ動くようにしか動かないところがあります。 その中で、JSF歴史を補足しながらJava EE 7の仕様までちゃんと説明できているというのは良いと思いました。 Java EE 5(もしくはJSF1.X系)は知ってるけれども最近のJSFは知らないという人が、JSFを使わなければいけなくなった時には読めばいいと思います。 新しく増えたFlashScopeやブックマーク可能なJSFのページの作り方もちゃんと載ってますよ。 た

    Java EE 7徹底入門を読んだ(JSFあたり) - 水まんじゅう2
  • Java EE 7徹底入門を読んだ(JAX-RSあたり) - 水まんじゅう2

    次はJSFを読むと約束したな。あれは嘘だ。 JAX-RSは9章ですね。 RESTとSOAPの目指すべきところ このでは違うと言ってますがたぶん一緒。 歴史的に見て、RESTよりもSOAPの方が先に出てきました。 しかし、SOAPはHTTPを使用する場合はすべてのアクセスをGETもしくはPOSTでしか受け付けない規定があるため、データの検索や、データの更新がすべてGET/POSTで行われてしまい、インフラレイヤーからだとどのアクセスが更新なのか、どのアクセスが検索なのかが判らず、どのデータをキャッシュしてもよいのかの判断ができないということが問題となります。 それを解消するためにURLごとにこのURLは更新作業なのでキャッシュしてはいけない、このURLは検索なのでキャッシュしても大丈夫〜みたいなのを定義していたのですが、それは面倒くさい。 HTTPの(ほぼ使われていなかった)METHODに

    Java EE 7徹底入門を読んだ(JAX-RSあたり) - 水まんじゅう2
  • Java EE 7徹底入門を読んだ(jBatch) - 水まんじゅう2

    アンケートとったら次はjBatchを読めという話になったので、今日はjBatchです。 jBatch自体はJava EE 7から新しく増えた仕様で、現時点ではアプリケーションサーバーでjBatch自体の実装は行われていますが、jBatchを開発するツール類はまったくというほど整備されていません。 かつて何かが通った道と同じようにclassを定義してそれらをxmlで組み合わせて使用するという祖結合にしたいんだろうなぁというのはわかるけれども、実際にはデータ形式をそれぞれのjobで併せて使用しないといけないので、javaの型の恩恵を得られない形式となっており、単純に筋が悪い。これは流行らないなぁという事がみんなわかっているのでしょうか。 書籍になるということ 個人的に書籍にするというのは非常に労力がかかることで、お金を取る分の品質が求められると思っています。 の内容の整合性をとるために編集者

    Java EE 7徹底入門を読んだ(jBatch) - 水まんじゅう2
  • Java EE 7徹底入門を読んだ(CDI/EJBまわり) - 水まんじゅう2

    ということで、昨日に引き続き。 CDIは5章、EJBは6章ですね。 作者は何かCDIについて非常に大きな思い違いをしているのではないかという印象でした。 あと、これらの章を書いた人は多分信用が置けない。 CDIとEJBのどちらを使うか? この質問が出てくる時点でCDIの役割について勘違いしているようなきがするのですが、CDIとEJBは排他する機能ではありません。EJBやJSF等でそれぞれInjectionするためのアノテーションが生まれてしまい、それらを統一して使用する側では同じように使用できるように使えるのがCDIです。歴史的経緯によりEJB/JSFでアノテーションが生まれてからCDIが生まれたため、同じ(もしくはサブセットの)機能を持ったアノテーションがあるため、非常に解りにくくなっているのですが、CDIが使用できる環境では基的にCDIのアノテーションを使用して、CDIでInject

    Java EE 7徹底入門を読んだ(CDI/EJBまわり) - 水まんじゅう2
  • Java EE 7徹底入門を読んだ(JPAだけ) - 水まんじゅう2

    一通りは読むのだけれども、たぶんJPAだけは一部の人に期待されている気がするので、先に読んだ感想だけ書いておきます。 JPAについては7章、8章に書いてありました。 とりあえず、JPAについては読まないほうが良いかなと。 いろいろなところで、書いている人がJPAを勘違いしている?のが見えるかつ内容としてもJava EE 7で増えた分はなさそうなので、これを読むぐらいなら金魚がよいかと。 Beginning Java EE 6~GlassFish 3で始めるエンタープライズJava (Programmer's SELECTION) 作者: Antonio Goncalves,日オラクル株式会社,株式会社プロシステムエルオーシー出版社/メーカー: 翔泳社発売日: 2012/03/09メディア: 大型購入: 5人 クリック: 147回この商品を含むブログ (29件) を見る 以下気になった

    Java EE 7徹底入門を読んだ(JPAだけ) - 水まんじゅう2
  • 世界はいろふである #irof_history - 水まんじゅう2

    この記事はいろふ Advent Calendarの三日目の記事です。 一つ前は [twitter:@ayato_p]さんの あなただけの特別ないろふさん です。 一つ後は[twitter:@daiksy] さんの irof文が実装できたよ。そう、Scalaならね! です。 さて、各地で登録してしまったけれども何を書けばいいのかと頭を悩ませている人が多いと噂されるいろふAdvent Calendarも遂に三日目になりました。 いろふさんがJavaの達人ということで、Javaで世界がいろふさんであることを確かめようと思います。 System.out.println("world".equals("irof")); これを実行すると以下のようになりました。 見事に世界といろふさんが等しいと表示されましたね! さすが私が愛用しているJVM。空気を読んでくれている。 これにて終了! どうしてこうなっ

    世界はいろふである #irof_history - 水まんじゅう2
  • JSR 236 Concurrency Utilities for Java EEは何が嬉しいのか - 水まんじゅう2

    これはJava EE Advent Calendar 2015の6日目です。 Java SEの世界では自由にスレッドを生成することができましたが、Java EEの世界ではユーザーが自分たちでスレッドを新しく立ち上げることは大きな制限がありました。 JSR 236 Concurrency Utilities for Java EEではコンテナ管理されたスレッドプールを元から用意しておくことでユーザーが非同期処理を行えるようにしました。 何が嬉しいのでしょうか。 もともとウェブアクセスからの非同期実行を行うために生み出されたJava EE Java EE自体は複数人の同時使用を想定した仕様となっているため、もともと非同期処理を意識した仕様となっています。 サーバーのほうで処理をするためのスレッドを最初から起動させておき、リクエストが来る度にスレッドをリクエストに割り当ててレスポンスを生成します

    JSR 236 Concurrency Utilities for Java EEは何が嬉しいのか - 水まんじゅう2
  • Javaの例外処理について - 水まんじゅう2

    これはJavaアドベントカレンダーの5日目です。 最近例外処理について考えなければいけないことがあったので、こうしたほうが良いよというのをまとめます。 他の言語からJavaに移ってきた場合に微妙なところで変な感じになることがあるので。 ここで扱うJavaの例外というのはThrowableとそのサブクラスのことです。 Javaにはtry〜catch〜finallyという例外を扱うための構文があります。 try { } catch(Throwable t) { } finally { } Java7からはtry-with-resourcesや例外のマルチキャッチという新しい構文も増えました。 そちらについて詳しく知りたい人は[twitter:@skrb]さんの現場で使える[最新]Java SE 7/8 速攻入門をご参照お願いします。 現場で使える[最新]Java SE 7/8 速攻入門 作者:

    Javaの例外処理について - 水まんじゅう2
  • DBエンジニアとアプリエンジニアの間にて #clubdb2 - 水まんじゅう2

    #ClubDB2に行ってきた 7月13日に #ClubDB2でDBエンジニアとして有名な方がお話されるとのことだったので、 最近DBに関してまじめに考えていないなーと思い行って来ました。 普段、業務系アプリケーションエンジニアをやっている人としてはちょっとなぁと思える内容だったのでそちらについて。 DBエンジニアの責任分界点について さて、登壇者の方が物理的なところ(ストレージ)について言及された時にDBエンジニアの責任分界点について、DBエンジニアはストレージについては責任分解が行われるため、触ることが出来ない。チューニングを行う場合はそちらも触れないと限界があるというお話をされていました。 いろいろな会社が入る以上しょうがないのですが、そもそも責任分界点という考え方はどうなんだろうー。 アプリケーションエンジニアDBエンジニアの責任分界点について "責任"から言えば、たぶんアプリケー

    DBエンジニアとアプリエンジニアの間にて #clubdb2 - 水まんじゅう2
  • J2EEレガシーアプリケーションのJavaEEアプリケーションへのマイグレーション(1) - 水まんじゅう2

    何回かに分けてJ2EEレガシーアプリケーションのJavaEEアプリケーションへのマイグレーションについて実際のコードを見ながら解説したいと思います。 変更前のサンプルソースはこちら https://github.com/megascus/oi-webapp-sample/tree/initial こちらのソースは、Tomcat上で動く、ビューがServlet2.5+JSP、O/RマッパーとしてHibernateを直接使用するという、大体2005年ぐらいに作られたシステムのイメージになっています。 また、いくつかの点にてきちんと設計されているとは言えず、MVCに沿って作られたことになっていますが、きちんとViewとModelが分離できていません。 それ以外にも問題をいくつか抱えています。 これをGlassFish4.0上でのJavaEE7仕様で作り直したいと思います。 古いシステムを新しい仕

    J2EEレガシーアプリケーションのJavaEEアプリケーションへのマイグレーション(1) - 水まんじゅう2
  • 1