Web Application Server を動かす時の Java8 起動オプションのメモ - その手の平は尻もつかめるさ
一般的な Web Application Server *1 を Java8 で動かすにあたって，最近有効にしている起動オプションについてメモ． 何か間違っていたり，あるいは「こっちの方が良い」みたいなのがあれば教えて下さい． -server server mode で起動させる (指定しないと client mode になる可能性がある，マシンスペックによってスイッチする？)． -Djava.net.preferIPv4Stack=true If IPv6 is available on the operating system the underlying native socket will be an IPv6 socket. This allows Java(tm) applications to connect too, and accept connections from,
Java SE 8 best practices
Lambdas and streams are key new features in Java 8. Lambdas allow blocks of code to be passed around as if they were objects. Streams provide an abstraction for processing collections of objects in a declarative way using lambdas. Optional is a new class that represents null-safe references and helps avoid null pointer exceptions. Checked exceptions can cause issues with lambdas, so helper methods
[java] SecureRandom のアルゴリズムの選択について - tokuhirom's blog
[java] SecureRandom のアルゴリズムの選択について 前提 Java SE 8 + Linux 前提です｡ Java で暗号的に安全な乱数をえる Java で暗号的に安全な乱数を得るには SecureRandom クラスを利用します｡ SecureRandom ではいくつかの乱数生成アルゴリズムをサポートしています｡ 各プラットフォームでもっとも安全な SecureRandom の実装は ${JAVA_HOME}/jre/lib/security/java.security の securerandom.strongAlgorithms という項目に書いてあります｡ SecureRandom#getInstanceStrong() で取得できるのはこれです｡ インスタンスの取得方法 new SecureRandom() でデフォルト実装が得られます OSX や linux
Oracle への JDBC 接続に時間がかかる現象の回避方法
まさか、そんな原因だったとは...... いや、あのですね、Oracle への JDBC 接続の話なんですけれども、以前から、なーんか矢鱈と Connect に時間かかるなぁ、とは思ってたんですよ（特に繰り返し接続した時）。 でも、企業の案件で使う場合は、まずコネクションプールを利用しますし、個人的な趣味の場合は Oracle よりもっと軽量な DB を使うことが殆どだったので、あんまり気にしていなかったんですね。 ていうか、Oracle さんはそういうコなんだと、ハナから諦めてたというか（笑） なので、その場でバッチを書いてちょろっと流したりする時だけ、「なんで接続にこんな時間かかんだよ、イライラ」みたいに思っていたのですが、この度、思いがけないことが原因だったことを知りました。 はー、そうだったのかー。 回避方法があることも分かりましたので、追加情報と合わせて記事にしておきます。 読み
Java SE 8のラムダ式はどう実現されたのか？──実装の経緯、内部的な仕組みを理解する - builder by ZDNet Japan
Java SE 8で導入されたラムダ式は、どのような仕組みで実現されているのだろうか？ ラムダ式をより深く理解したいと考える読者にとって、これは気になるテーマの1つだろう。その秘密をお教えしよう。 Java SE 8で導入されたラムダ式は、Javaの言語仕様の歴史において最大級の変更だとされている。ただし、これはあくまでもJava言語の文法レベルの話であり、Javaプログラムを実行するJava仮想マシン（JVM）に新たな仕組みが導入されたわけではない。つまり、言語仕様に関する旧バージョンとの相違はコンパイラとランタイムが吸収し、バイトコードレベルでの互換性は保たれているということだ。 それでは、このような大きな変更を、既存のJVMの仕組みの中でどのように実現したのだろうか。それを知ることは、ラムダ式をより深く理解する手助けとなるかもしれない。Java SE 8のラムダ式実現の経緯と仕組みに
JDK8(Linux 64bit)のデフォルトヒープサイズ - n-agetsumaの日記
Oracleの公式ドキュメントには、-Xmxが未指定であった場合のエルゴノミクスによる最大ヒープサイズは『32GBを上限として、物理メモリの4分の1』書かれている。32GBは-XX:-UseCompressedOopsにより圧縮Oopを明示的に無効にした場合の最大デフォルトヒープサイズで、何もオプションを付けずに起動した場合は29GBが上限。 ヒープサイズの決定はarguments.cppのArguments::set_heap_size()で計算されている。デフォルトの最大および初期ヒープサイズは、物理メモリ量により異なる。 デフォルト最大ヒープサイズ(-Xmx) 物理メモリが248MB以下の場合 物理メモリの2分の1。 248MBは-XX:MaxHeapSize(デフォルト124MB) x -XX:MinRAMFraction(デフォルト2)の値。 物理メモリが248MBより大きい場合
OptionalがSerializableではない話と使い方まとめ - きしだのHatena
Optionalは意図的にSerializableではなくなってますね。 でその意図としては、一旦Serializableにして出力形式を決めてしまうと、今後ずっとその出力形式を維持しないといけないことになるので、そのメンテナンスコストを嫌ったというのがあるようです。 このメンテナンスコストの中には、仕様が変えれなくなる、というコストも含みます。 なので、シリアライズしたい場合には、フィールドはnullを持つようにして、getterでOptionalに変換するということになると思います。 基本的にOptionalは、Optional-returnイディオムをサポートするもの以上ではない、ということをBrian goetzさんも書いています。 Shouldn't Optional be Serializable? そこで、Optionalの使い方としては、基本的にメソッドの戻り値としてだけ、
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
Calendar.Builderとやらを触ってみた - 日々常々
知らなくても生きていけるけど、知ってるとちょっと便利っぽいもの。 みんな知ってるのかもしれないけど、私は今日まで知らなかったから書いておきます。 もともとは今日 @khasunuma さんがされていた一連のツイートからです。その中で紹介されたスライドに乗っかってたので。 Date and Time APIを理解する為には、ISO 8601に踏み込みましょう！ - togetterまとめ 該当スライド Date and Time APIを使わない場合に間違いなく「使える」と思ったので書いておきます。 というかこんなクラス作ったことあるわ……。 なにものか？ FQCNだとjava.util.Calendar.Builderになります。Calendarクラスにネストされたstaticなクラスです。 追加されたのはJavaSE8になってからなので、それ以前には入ってないです。JavaSE7以前の環
Date and Time APIを理解する為には、ISO 8601に踏み込みましょう！
HASUNUMA Kenji (Deprecated) @khasunuma_old Date and Time APIを説明するにISO 8601にまで踏み込むのは蛇足だという方は非常に多く、過去にJava界隈の重鎮から叩かれたことがあります。しかし、過去のセッションやブログを見る限り、ISO 8601には触れずに解説したものは、ほぼ例外なく爆死しています。 2015-05-09 05:11:10 HASUNUMA Kenji (Deprecated) @khasunuma_old Date and Time APIがISO 8601ベースになったのは、先行したJoda-Timeが同様にISO 8601ベースにしてうまくまとまったから。Stephenは暦が無数にあることを承知の上で、ISO 8601という国際規格を「人間向け」の基準と定めたのです。 2015-05-09 05:13:45
Java 8 Streamの挙動を調べたった - mike-neckのブログ
表記の件について、JavaのListから作るStreamは操作中に変更をするとその後の挙動についてなんら結果を保証しないので、ListからStreamを作った場合は、変更をしないか、あるいは不可変なListに変換してから作るのが良いです。 と、書いておいてからなのですが、こんなツイート見かけました。 これは思わぬ結果 ステートフルな中間操作のsorted()かますと 最終的にListは空になるけどforEachで全て出力される。 なんでだろう？ これで今日も眠れないｗ pic.twitter.com/864kLHyK8K— Yucchi (@Yucchi_jp) May 8, 2015 peekでListの要素を削除するというやってはいけないパターンです。 @Test public void intList() { List<Integer> list = IntStream.range(
Optionalの取り扱いかた - 日々常々
JavaSE8で追加されたjava.util.Optionalにはnullとの戦いに終止符を打ってもらいたいと思っているんですが、思ってるだけだと何も起こらないので、使い方とか思ったこととかを一通り書いておきます。 Optionalのファクトリメソッド Optionalのインスタンスメソッド 値を取得するもの 値を使用するもの Optionalのまま扱うもの まとめ なお、一通りと言いつつOptionalIntとかはスルーしています。機会と書くことがあればそのうち書くかもしれません。 Optionalについては諸事情（遅筆とか理解不足とか分量とか）によりJavaエンジニア養成読本では軽い紹介にとどまっておりましたので、補足としてお読みいただけると幸いです。あと、この辺も参考にどうぞ。 OptionalのJavadoc 一通り触って適当にコメント書いたコード(GitHub/sandbox)
Java EEアプリケーションサーバの開発現場で見たJava SEの実際
患者ケアと公衆衛生管理の向上を目的とした、安全でスケーラブルかつアクセスしやすいプラットフォームを構築するためのパートナーシップについてご覧ください。
Spring MVCのOptional<>の使い方がカッコイイ。 - 谷本 心 in せろ部屋
Spring Bootの1.2.0正式版がリリースされ、中で使っているSpringも4.0から4.1になりました。 SpringMVCも4.1になったわけですが、一つ興味深い変更がありました。 それが@RequestParamのOptional対応です。 SprinMVCでは、クエリ文字列の値をメソッドの引数にバインドするための @RequestParamアノテーションは、何も書かないと「必須項目」と見なされてしまいます。 @RestController public class HelloController { @RequestMapping("/") public String hello(@RequestParam("name") String name) { if (name != null) { return "Hello, " + name; } else { return
GitHub - jOOQ/jOOL: jOOλ - The Missing Parts in Java 8 jOOλ improves the JDK libraries in areas where the Expert Group's focus was elsewhere. It adds tuple support, function support, and a lot of additional functionality around sequential Streams. The JDK
// (1, 2, 3, 4, 5, 6) Seq.of(1, 2, 3).concat(Seq.of(4, 5, 6)); // true Seq.of(1, 2, 3, 4).contains(2); // true Seq.of(1, 2, 3, 4).containsAll(2, 3); // true Seq.of(1, 2, 3, 4).containsAny(2, 5); // (tuple(1, "A"), tuple(1, "B"), tuple(2, "A"), tuple(2, "B")) Seq.of(1, 2).crossJoin(Seq.of("A", "B")); // (tuple(1, 1), tuple(1, 2), tuple(2, 1), tuple(2, 2)) Seq.of(1, 2).crossSelfJoin() // (1, 2, 3, 1
Java 8 Date and Time API の実践的なチートシートできたよ~ - tokuhirom's blog
Java8 を使いこなそうとすると､やはり Date and Time API も使いこなす必要がでてくる｡ 我々 Perl 畑出身の人間からすると､Perl の世界では DateTime/Time::Piece というモジュールが一般的に日付の計算に使われており､iandeth.さんのブログエントリがチートシートとしてよく知られている｡このいつも見慣れたエントリの体裁で､一般的な日時の操作を実用的に教えてくれるエントリが欲しくて書いた｡ junit のテストケースとして書いてあるので､適当にコピペして QuickJUnit で動作確認するとよい(assertはしてないけど)｡ なにかあれば教えていただけるとありがたいです｡
OTN Japan マニュアル
互換性は複雑な問題です。このドキュメントでは、このJavaプラットフォームのリリースに関連する次の3種類の潜在的な非互換性について説明します。 ソース：ソース互換性とは、コードのコンパイルが成功するかしないかなどを含む、Javaソース・コードのクラス・ファイルへの変換に関係します。 バイナリ：バイナリ互換性は、Java言語仕様で次のように定義されています。'型への変更が行われた場合に、以前にエラーなしでリンクされた既存のバイナリが引き続きエラーなしでリンクされれば、既存バイナリとのバイナリ互換性があります（つまり、既存バイナリとのバイナリ互換性は損なわれません）。' 動作：動作互換性は、実行時に実行されるコードのセマンティックなどの互換性です。 詳しくは、OpenJDK Developer's GuideのKinds of Compatibilityの項を参照してください。 "バイナリ互換
Jvm internal
사내 공유를 위해 제작한 문서입니다만, 혹시 도움이 되실 분이 있을까 싶어서 공유합니다. 혹여 오류가 있을 수 있습니다. 관대한 마음으로 이해 부탁드리며 글 남겨주시면 참고하여 수정하겠습니다.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OptionalとJavaにおけるsomeスレッディングマクロ的なもの - Qiita
null使ったら負け福岡版
