Javaのジェネリクスで，T.class や new T() ができず悩んだ話 （型パラメータのインスタンス化に関し、フレームワーク設計からケーススタディ） - 主に言語とシステム開発に関して
Javaのジェネリクスで，型パラメータ T のインスタンスが欲しくなったことはあるだろうか？ 昨今のオブジェクト指向プログラミングにおいて，ジェネリクスは必須の基本文法だ。 扱う対象のクラスが抽象化されて汎用的になりつつ，なおかつ型安全性が確保される。 そのおかげで，処理の重複や分岐をコーディングする必要が無くなり，コード量が驚異的に削減される。 そういう基本的な原則を踏まえると， 「型パラメータのインスタンスが欲しい」 というシチュエーションは，Javaのジェネリクスの本来の導入目的に真っ向から逆らう。 なぜなら，ジェネリクスは型を抽象化して透過的に扱えるようにするための機構なのだから， せっかく抽象化した物をわざわざ具体化してどうするというお怒りを生む事になるのだ。 頑張って詳細なクラス情報を「T」でパラメータ化して具体性を隠ぺいしたにも関らず， その T に対して .class で具
Javaのジェネリクスとリフレクション応用編 - プログラマーの脳みそ
前回から随分と間が開いてしまった。Javaのジェネリクスはイレイジャ方式だけどもクラスにバインドした型の情報が残る場合があるんだよシリーズの第2弾である。 具体的にどういう場合にバインドした型が残るのかという話だが、端的に列挙すると以下のものである。 フィールドにパラメタライズドタイプ(parameterized-type)を用いた場合 メソッド引数や戻り値型にパラメタライズドタイプを用いた場合 コンストラクタにパラメタライズドタイプを用いた場合 継承によるバインドを行った場合 大きく分ければパラメタライズドタイプを使ったメンバのシグネチャか、継承によるバインドの2種類である。 前回、例に挙げたのはパラメタライズドタイプを引数にとるケースだった。 import java.lang.reflect.*; import java.util.List; public class Reflecti
Javaのジェネリクスとリフレクション - プログラマーの脳みそ
今回のテーマはジェネリクスとリフレクション。Javaのジェネリクスはイレイジャ方式なのでリフレクションでは何も得られないと思ってはいまいか。 public void hoge(List<String> list) {} といったメソッドがあったとして、リフレクションでこのメソッドの情報を得るとしよう。 import java.lang.reflect.*; import java.util.List; public class ReflectionTest { public static void main(String[] args) throws Exception { Method m = ReflectionTest.class.getMethod("hoge", List.class); Type[] types = m.getGenericParameterTypes(); f
new T()したいケースへの対処法 - プログラマーの脳みそ
Javaのジェネリクスの話題のひとつにnew T()したいができないので困る、というテーマがある。 先日のセッションではこの対策についても簡単に述べたが今日はそのまとめ。 まず第一に疑うべきは本当にnew T()する必然性があるか？というのが持論だが、ある種のフレームワークではその必然性がある。 O/RマッピングのフレームワークでPOJOにデータを詰めて返したい WebフレームワークでHTTPリクエストをPOJOに詰めてControllerクラスに渡したい （このあたりの議論はJavaのジェネリクスで，T.class や new T() ができず悩んだ話 （型パラメータのインスタンス化に関し、フレームワーク設計からケーススタディ） - 主に言語とシステム開発に関してによくまとまっている） ここで、これらのPOJO(Plain Old Java Object - 端的に言えばデータを格納する
GitHubに大規模な不正ログイン試行 | 徳丸浩の日記
GitHubのブログおよび国内の報道によると、GitHubに対して大規模な不正ログインが試みられたようです。 GitHubは米国時間の2013年11月19日、ブルートフォース攻撃を受けたことを明らかにした。攻撃の時期や被害を受けたアカウント数は公にしていないが、今回の攻撃を踏まえ、より強固なパスワードや二要素認証などを利用するようユーザーに呼び掛けている。 GitHubにブルートフォース攻撃、一部のパスワードが破られるより引用 私もGitHubアカウントがありますのでSecurity Historyページを確認したところ、不正ログインの試行が確認されました。IPアドレスは、ベネズエラ、タイ、ブラジルのものです。 GitHubアカウントをお持ちの方は、念のためSecurity Historyを確認することを推奨します。 今回の不正ログインの特徴は以下のようなものです。 少数の「弱いパスワード
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
