FindBugs とは Java のソースコードを静的に解析して、バグとなりそうなコードを見つけるツール。 ビルドプロセスの中に組み込んで自動化させることで、ソースコードレビューの手間を減らしたり、そもそも人目では見つけづらいバグコードを事前に検出したりできるようになる。 環境 OS Windows 10
package sample.intellij; public class Main { public static void main(String... args) { System.out.println("Hello IntelliJ!!"); } } 適当にソースを記述したら、メニューバーの [Run] -> [Run] と選択して 起動する Main クラスを選択する。 コンソールに結果が出力される。 環境設定 テーマ [File] -> [Settings] [Appearance & Behavior] -> [Appearance] [UI Options] の [Theme] を選択。 目に優しい暗色系がいいので、 Darcula を選択。 フォント [File] -> [Settings] [Editor] -> [Colors & Fonts] -> [Font]
これは、 G* Advent Calendarの15日目の記事です。 昨日は @int128 さんの Gradle Slashプラグインをリリースしました #gadvent でした。 明日は @tyama さんです。 はじめに Gradle 便利ですよね。便利すぎて Ant や Maven には戻れないです。 なにが良いって、設定ファイルである build.gradle の記述量が、 Ant の build.xml や Maven の pom.xml と比べると非常に少なくて済むのが良いです。 build.gradle は、設定ファイルと言いつつも、その実体は Groovy で書かれたスクリプトファイルです。 Gradle は、 Groovy の持つメタプログラミング機能や省略記法などを利用して、設定を簡潔に記述できるようになっています。 これはメリットなのですが、一方で Groovy の
JAX-RS の仕様に組み込んで欲しいという意見をちらほら見かける、噂の Jersey MVC を試す。 テンプレートには JSP を使い、とりあえず GlassFish で ver 2.0 を試してから、 Tomcat で 2014/01/26 現在最新の ver 2.5.1 を試してみる。 環境 AP サーバ GlassFish 4.0 Tomcat 7.0.42 GlassFish で ver 2.0 を試す Jersey MVC JSP はバンドルされている GlassFish 4.0 には、 Jersey MVC JSP の 2.0 がバンドルされているので、それを利用する。 glassfish\modules>dir /b jersey-mvc* jersey-mvc-connector.jar jersey-mvc-jsp.jar ← MVC JSP がバンドルされてる je
Java 8 で、 Oracle の JVM を前提とした話です。 Java のメモリ管理 これを知っておかないと、 OOME が起こっても、メモリ内で何が起こっていて、どこを調査すべきで、どのように対処したらいいのかが判断できない。 なので、まずは、そもそも Java がどうやってメモリを管理しているのかを知る。 しかし、実際調べてみたら予想通りというかなんというか、量が多くなってしまった。 なので、個々の用語の説明は末尾の 用語集 に押し込めたので、ここではざっくりとした概要だけ記載する。 メモリの構造 超ざっくりとした、メモリ構造を表した図。 おおきく、ヒープ(Heap)領域とネイティブ(Native)領域の2つの領域がある。 ヒープは Java プログラムが使う領域で、プログラム上で生成したオブジェクトは、このヒープ領域に配置される。 一方、ネイティブ領域は JVM が動くのに必要
環境構築は こちら。 ソースコードは GitHub にあげています。 https://github.com/opengl8080-javaee-samples/ejb EJB とは Enterprise Java Beans の略。 ビジネスロジックを簡潔に実装できるようにしてくれる仕組み・フレームワーク。 ビジネスロジックを持つクラスは POJO で作成でき、エンタープライズアプリケーションで必要になるトランザクション制御やリソース(JNDI, 他の EJB など)の取得、セキュリティ制御、 AOP などなどの機能はコンテナがほとんど自動で提供してくれる。 これにより、プログラマーはビジネスロジックの実装に集中できるようになる。 プロジェクト作成 コンテキストルートが ejb になるように、 NetBeans で Web プロジェクトを作成する。 Hello World package
環境構築 JPA の基本的な話 JPQL の話 Criteria API の話 コード マッピング方法だけを確認しやすいようにした一覧を作成しました。 JPA マッピングカタログ - Qiita はじめに オブジェクト指向で考えられたドメインモデルと、正規化などを考慮して考えられたリレーショナルデータベースのテーブルでは、データの持たせ方に違いが生まれる。 この違いをインピーダンスミスマッチと言う。 インピーダンスミスマッチを解決するには、データベースから取得したレコードをオブジェクトにマッピングする処理が必要になる(さらに、永続化するときは逆変換が必要)。 オブジェクトとテーブルの構造が1対1で対応していれば、この変換はそこまで大変ではない。 しかし、そうでない場合、変換を自力で実装するのは非常に骨が折れる。 O/R マッパーはこの変換を自動でやってくれるフレームワークで、 JPA では
ビルドツールにGradle、IDEにNetBeans、APサーバにGlassFishを使って Web アプリを開発JavaNetBeansgradleglassfish しようと思ったら、しょっぱなで躓いた。 NetBeans には Gradle プロジェクトを取り込むためのプラグインが存在する。 これを使えば、 Gradle のプロジェクトを取り込むことができる。 しかし、そのままプロジェクトを実行すると gradle run というふうにタスクが実行されてしまう。 実際は GlassFish にデプロイして Web アプリケーションとして実行したいわけで、この挙動だと困る。 調べたけど、スマートな方法が見つからず、 Gradle に GlassFish と連携するためのタスクを追加することで対応した。 普通に Gradle のプロジェクトを作る
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く