メンバーのスキルアップ、どうしてる？ − Java 100本ノックで新加入メンバーを鍛えてみた −JJUG CCC Fall 2016 での発表資料です。 Java 100本ノックを用いたトレーニングの実例と、アンチパターンについてご紹介しています。
ScalaとKotlin（と昔のJava）のジェネリクスが壊れている理由 - kmizuの日記
表題の通りです。とりあえず、Kotlin版とScala版のコード貼ります。 gist.github.com gist.github.com これらのコードでは、両方とも明示的なダウンキャストやその他の抜け穴を使っていないので、実行しても決してClassCastExceptionが起きてはいけないのですが、実際に実行するとClassCastExceptionが起きてしまいます。 さて、これはコンパイラの実装のバグでもあり、言語仕様のバグでもあるのですが、ちょっと理由を説明してみたいと思います。 class B extends A with Comparable[B] { def compareTo(b: B): Int = 0 } 上記のコードをコンパイルすると、下記のコードが生成されます。ここで、int compareTo(java.lang.Object)というメソッドが 定義されている
Java 8u60で、Mapの初期化とかがすごい楽になってる件 - mike-neckのブログ
夜中に8/15頃のツイートが回ってきた。 Java 8u60 adds reflection on lambda param names DSLs https://t.co/cflxFK468e Hash-Literals https://t.co/5rOCrrckcB pic.twitter.com/NEzj4X3Bt1— Benjamin Weber (@benjiweber) 2015, 8月 16 曰く Java8u60でラムダのパラメーターの名前に対してリフレクションができるようになってるよ というわけで 早速、件のツイートにあったレポジトリーをダウンロードして(mavenレポジトリーにはない…(´・ω・｀))、プロジェクトに追加して、試してみた。 コード import com.benjiweber.typeref.NamedValue; import java.util.Col
JavaのテストにはAssertJがオススメ - Qiita
JavaでのテストはJUnit4が使われていると思いますが、自分としては、それに加えてAssertJをオススメします。 AssertJ AssertJが使いやすい理由 JUnit4のassertThatと比べてAssertJが使いやすい理由は2つあります。 流れるようなインターフェース AssertJは「Fluent assertions for java」とトップページに大きく書かれているように、流れるようなインターフェースが最大の特徴です。いちいちドキュメントを調べなくても、IDEの補完機能で適切なメソッドを調べられるので、JUnit4のassertThatに比べて書きやすいです。 拡張がMatcherに比べて遥かに楽 Matcherの拡張対象は「比較方法」で、AssertJの拡張対象は「クラス」なので比較するのは適切ではないかもしれませんが、Matcherの拡張が靴の上から足を掻く感
Java の throws 節では型変数が使える - 映画は中劇
つい先だって知ったのですが、 Java のメソッドの throws 節では型変数が使えます。 8.4.6 Method throws / Java Language Specification これによって、投げる可能性のある例外の型が使い手側で変えられるようなメソッドを書くことができます。たとえば次のプログラムのように、例外の型と例外オブジェクトの生成を使い手にまかせる汎用の表明メソッドが書けます。 *1 class Checker { static <T extends Throwable> void check(boolean condition, Supplier<T> supplier) throws T { if (! condition) { throw supplier.get(); } } } class SomeException extends Exception {
[Android Tips] バージョン毎に読み込むクラスを変える | DevelopersIO
バージョン毎に異なる処理を吸収する 最近では Android 4.x 系の端末もかなり普及し、4.x 系のみサポートするようなアプリ開発も増えてきているように感じています。しかしながら、 2.x 系をサポートして欲しいとう要件もゼロではありません。 各バージョンの対応でよくある問題がバージョン毎にアクセスする API が異なるという点です。4.0 以降で追加された API を 2.x 系では呼ばないようにする (または独自で実装する) などといった対応が必要です。こういった場合によく使うのがバージョン毎に読み込むクラスを変えるという方法です。ということで、今回はその手順を解説したいと思います。ちなみにこの方法は Google I/O 2012 で発表されており、 Lazy Loading というデザインパターンをベースに生み出された手法です。Support Package も同じ手法を採用
![[Android Tips] バージョン毎に読み込むクラスを変える | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/c5e8311b4c7b634b9485765308f30289f0d33842/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2013%2F09%2Fandroid.png)
Fluent HTTP Client – jcabi-http
2.1.0 $dateFormat.applyPattern("yyyy-MM-dd'T'hh:mm:ss'Z'") $dateFormat.applyPattern('dd-MMM-yyyy') ${dateFormat.format($currentDate)} menu For example: import com.jcabi.http.Request; import com.jcabi.http.request.ApacheRequest; public class Main { public static void main(String[] args) { String html = new ApacheRequest("https://www.google.com") .uri().path("/users").queryParam("id", 333).back() .m
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Logback 使い方メモ - Qiita
