Built by EngineeringX - an independent collective of hundreds of CTOs and VPs of Engineering
Welcome to the third part of my tutorial series about multi-threaded programming in Java 8. This tutorial covers two important parts of the Concurrency API: Atomic Variables and Concurrent Maps. Both have been greatly improved with the introduction of lambda expressions and functional programming in the latest Java 8 release. All those new features are described with a bunch of easily understood c
Palomino Labs unlocks the potential of software to change people and industries. Our team of experienced software developers, designers, and product strategists can help turn any idea into reality. Palomino Labs Website → Java 8 is on its way, bringing a host of new features to the most widely-used language on the JVM. Likely the most oft-noted feature will be lambdas, to which Scala and JRuby af
Monads are central to Functional programming. They are generally totally ignored in imperative programming. They are even often feared by imperative programmers. Most Java programmers either do not know what a monad is, or would raise strong protest if monads were to be introduced in Java. But, although this has not been much advertised, Java 8 brings monads. In a recent post, (http://java.dzone.c
we write about the things we build and the things we consume I finally got to play with Java 8 streams and lambdas in more than a “Hello, World” way a couple of weeks ago. It was all pretty basic stuff—a map here, a few filters there, a sprinkling of counts—but it’s lovely to finally have first-class support for things we’ve been using in Guava for years, and lambdas make the syntax much more ters
このエントリーでは、これまでに紹介した機能以外の、新しいAPIと改良されたAPIについてまとめています。 (2014-03-21追記)APIドキュメントのリンクを差し替えました。 目次 ラムダに伴うコアライブラリーの拡張 内部イテレーターとIterable#forEach Comparatorの拡張 プリミティブラッパークラスの二項演算子的メソッド 新しい日付・時刻API Base64エンコード・デコード 並行処理APIの改良 JDBC 4.2 配列の並列ソート RFC 4647 (BCP 47) 言語タグマッチング Unicode 6.2 サポート その他の拡張 ラムダに伴うコアライブラリーの拡張 ラムダ式の導入に伴い、コアライブラリーにもラムダ式を使ったメソッドが多数、追加されました。 ここでは、次の3つに絞ってご紹介します*1。 内部イテレーターとIterable#forEach C
java.util.Optional<T> in Java 8 is a poor cousin of scala.Option[T] and Data.Maybe in Haskell. But this doesn’t mean it’s not useful. If this concept is new to you, imagine Optional as a container that may or may not contain some value. Just like all references in Java can point to some object or be null, Option may enclose some (non-null!) reference or be empty. Turns out that the analogy between
※ サンプルがJDK7までとJDK8までで意味が変わっていてわかりにくいという指摘があったので、少し直しました。 ※ boxedを使う書き方だと無駄なAutoboxingが走るとの指摘を頂きましたのでmapToObjを利用するように変えました。 Java8の目玉機能の一つにStream APIがあります。 目玉機能だけあって、先日のJava Day Tokyo 2014を含めて色んな所で発表やブログの記事が公開されているので、どんなものかを知ってる人は多いと思います。 Stream APIといえば「".parallel()"と書くだけで並列化してスピードアップ出来る!」という魅惑的なキーワードで紹介されることが多いので、並列化のための仕様だと勘違いされそうですが、そうではありません。 ※ もちろんそういった記事の中をちゃんと読めばそう単純な話じゃないことも分かります。 むしろ、並列化に関し
本日、Java Day Tokyo 2014に来ています。 で、ついさっきのセッションで「JDK8ではInvokeDynamic(以下、indy)の実装を一新したのですごく速くなったよ」という話を聞いたので、Groovyのindyモードで試してみました。 Groovyは2.0(現在は2.3)でindy対応されています。 それ以前はGroovy独自機構による性能改善が行われていました。 しかし、JDK7からのホヤホヤなindyを前提にしてしまうと、JDK6で動かなくなってしまいます。 Groovyは下位互換性が重視されているので、これは問題です。 というわけで、indyが使えないJDK上でも使えるように既存の独自機構もそのまま残っているし、indy不要バージョンが標準になっていて、indyオプションを利用可能にするには$GROOVY_HOME/lib配下を$GROOVY_HOME/indy配
1.8.0 Collection removeIf(Predicate<? super E> filter) package java8; import java.util.Arrays; import java.util.List; public class Main { public static void main(String[] args) { List<String> list = Arrays.asList("hoge", "fuga", "piyo"); System.out.println("before : " + list); list.removeIf(str -> str.contains("g")); System.out.println("after : " + list); } } before : [hoge, fuga, piyo] Exception
結論 Java8のOptionalは超すっきり扱えるよ、そう、Groovyならね。 Optionalって何? Java 8で導入される新規クラスの一つ、java.util.Optionalは、メソッドの実行結果で成功する場合と失敗する場合があるときに、その返り値で成功と失敗を表現するためのものです。 Opitonalは単一要素を保持するコンテナ型。成功した場合は返り値をコンテナで保持させたものを返す。(成功時の返り値をラッピングする) 「失敗」は固定のシングルトン(Optional.empty())として扱う まあ、それだけの話といえばそれだけなのですが、効果は、 失敗のある可能性のあるメソッドと無いメソッドをコメントではなくプログラムの一部として明示し、両者の違いをコーディング上も区別する 失敗のある可能性のあるメソッドと無い混在・混同することのないようにコンパイル時チェックをできるよう
※ 5/29 3:23 追記:なんかモナドになったかも。最下部参照 さて、Java8での拡張をいろいろ見てきたわけですが、ではアプリケーションプログラムでFunctionを受け取るメソッドをがんがん定義するかというとそういうことはあまりなく、フレームワーク的な部分で数個定義する感じになると思います。もちろん数個でも効果はでかいのですが。 また、おそらくStreamを受け取ったり返したりするメソッドを定義することは、めったにないのではないかと思います。 Mapでの拡張も、メソッド内部での処理記述がかわる話で、メソッドの引数や戻り値はMapのまま変わりありません。 Javaでのプログラムの構造というのは、メソッドの引数や戻り値の型がなんであるかで決まると言うことができます。その意味では、lambdaやStreamというのは処理の記述は変わるけどプログラムの構造は変わらないとなります。 けれども
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く