jjugccc2018 app review postmortemIntroduction to JShell: the Java REPL Tool #jjug_ccc #ccc_ab4
Javaの超低レイテンシなGCアルゴリズム、ZGCをコンパイルして動作を試す - くろの雑記帳
The Z Garbage Collector 以下の資料を見てZGCのことを知りました。 The Z Garbage Collector ZGCは、 "A Scalable Low Latency Garbage Collector" というものだそうで、まだ開発中でリリースはされていないです。 数TBまでのヒープメモリのサイズを想定していて、なおかつGCの最大停止時間が10msというのがゴール。既にヒープサイズが128GBのベンチマークにおいて、パラレルGCやG1GCより圧倒的に停止時間が短い。ベンチマーク上では最大停止時間も10msを切っています。 アルゴリズムについては別途まとめてみようかと思っています。Colored Pointerという概念が特徴です。 ZGCを試す 開発版のZGCは既に試すことができるようです。ですが、自分でビルドする必要があります。紹介したスライドで書かれて
Kotlinの隠れたコストについてのベンチマーク | POSTD
@BladeCoder が書いた Kotlinの隠れたコストの調査 という一連のブログ記事は、ある Kotlin 構文にどのように隠れたコストがあるのかを説明しました。 実際の隠れたコストは、普通、不可視オブジェクトのインスタンス化やプリミティブ値のボクシング／アンボクシングに起因します。これらのコストは、Kotlinコンパイラがどのように上記の構文をJVMのバイトコードに変換するのかを理解していない開発者には特に見えづらいのです。 しかし、何らかの数字を示さずに隠れたコストの話をするだけでは、実際にどのくらいコストのことを心配すべきなのかという疑問が湧いてきます。コードベースのいたるところで、これらのコストを考慮すべきでしょうか？あるKotlin構文は単に全面的に禁止されるべきでしょうか？あるいは、最も範囲の狭い内部ループの中でだけ考慮されるべきでしょうか？ さらに挑発的な言い方をすれば
タイムゾーン呪いの書 - Qiita
コメント欄で「Software Design 誌 (2018/12) に寄稿した内容や修正などをこちらの記事にも適用したい」と言ったあと、やるやる詐欺でずっと放置していましたが、三年近く経ってようやく 2021年 7月に大幅に改訂し、同時に Zenn に引っ越すことにしました。 タイムゾーン呪いの書 (知識編) タイムゾーン呪いの書 (実装編) タイムゾーン呪いの書 (Java 編) なにやら長くなりすぎたので三部構成になっています。 この Qiita 版は、しばらく (最低一年は) 改訂前のまま残しておきます。 タイムゾーンの存在はほぼ全ての人が知っていると思います。ソフトウェア・エンジニアなら多くの方が、自分の得意な言語で、タイムゾーンが関わるなにかしらのコードを書いたことがあるでしょう。ですが、日本に住んで日本の仕事をしていると国内時差もなく1 夏時間もない2 日本標準時 (Japa
再帰的ジェネリクスの代入互換性 - プログラマーの脳みそ
Javaのややこしいジェネリクスの話をしよう。*1 再帰的ジェネリクス クラスHogeがあったとして、型変数Tを取る。 public class Hoge<T> {} このHogeの型変数Tがextends Hogeとすると public class Hoge<T extends Hoge> {} すると、T extends Hoge の Hoge が raw型だと警告される。Hogeの<>の部分にHoge型を継承した型を指定しなければならない。ここで型変数T が extends Hogeだったので、丁度いいからT型をおさめよう。 public class Hoge<T extends Hoge<T>> {} これは再帰的ジェネリクス(recursive generics)と呼ばれているようだ。 追記：僕は勝手に自己言及型ジェネリクスなどと呼んでいた。情報サンクス！併せてタイトルなども表現
Java 10でラムダが強化される可能性あり
新しいJEPには、より明確な曖昧さ回避、未使用パラメータのアンダースコアの使用、外部変数のシャドウイングなど、ラムダ機能を強化するための変更提案が提出されている。これらの変更によって、Javaのラムダが他の言語のラムダに近づくことになるが、最初の議論では支持するレベルも様々であった。このJEPは、Java言語を改善するための、他の一連の提案を補完しており、ローカル変数型の推論と拡張された列挙型を含む。これらは全てJava 10に含まれる可能性がある。 3つの変更はすべてラムダに関連しているが、それらは独立しており、フィードバックに応じて、一部が不採用となり、他のものが採用される可能性がある。そのため、この記事では個別に説明する。 より明確な曖昧性回避 ラムダがバージョン8でJavaに追加されたとき、それらをサポートするために型推論を修正しなければならなかった。しかし、過去に行われた変更は、
Kotlin vs Java: Compilation speed
If you convert an app from Java to Kotlin, will it take longer to compile? This is part 3 in a series of articles on Kotlin. Part 1 discussed converting an Android app from Java to Kotlin, and part 2 contains my thoughts on the Kotlin language. In an earlier article, I discussed converting an Android app from Java to 100% Kotlin. The Kotlin codebase was smaller and more maintainable than it’s Java
Google対OracleのJava API訴訟。歴史的経緯とIT業界への影響を考える（その１）。JJUGナイトセミナー
Google対OracleのJava API訴訟。歴史的経緯とIT業界への影響を考える（その１）。JJUGナイトセミナー 2016年5月、GoogleとOracleがJava APIを巡って争っていた裁判に最初の陪審員による評決がくだりました。結果は、GoogleがJava APIをAndroidに流用したことはフェアユースにあたる、というものです。 この評決にはどのような背景があり、IT業界にどんな影響を与えるものなのか。このことをテーマに2016年7月に行われた日本Javaユーザーグループ主催の「JJUGセミナー」の内容を紹介しましょう。 記事は全部で4本（その1、その2、その3、その4）。いまお読みの記事は「その1」です。 日本マイクロソフトで開催したJJUGナイトセミナー 日本Javaユーザーグループ会長 鈴木雄介氏。 今日の前半では私から、JavaとAndroidとOSS（Ope
ORMは不快なアンチパターン | To Be Decided
このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM
PHPのround関数とは一体なんだったのか - hnwの日記
（7/3 14:05追記）Javaに関する記述について誤認があったので盛大に書き換えました。Java 6、Java 7、Java 8それぞれで実装が変わっていたようです。 （7/13 23:55追記）本記事中ではroundを四捨五入と言い切ってしまっています。これは筆者がC99のroundを基準に考えているためですが、言語によっては偶数丸めになっているround関数も珍しくありません。ご注意ください。 PHPのround関数について、ネット上で次のような記述を見つけました。 PHP 四捨五入の計算を間違える唯一の言語として畏れられていましたが、そのバグは治っているかもしれません（治ってないかもしれません） 主要なプログラミング言語8種をぐったり解説 - 鍋あり谷あり 各言語を面白おかしく紹介する内容とはいえ、ずいぶん雑な理解だなーという印象です。ゆるふわな話だけでPHPがdisられ続けるの
GlassFish から Payara 移行のススメ
GlassFish から Payara 移行のススメ 2016年5月30日 at 5:43 午後 1件のコメント 先日 decode:2016 が開催され、山本裕介さんと一緒にセッションを行いました。ご参加いただいた皆様、誠にありがとうございました。 今回の de:code 2016 では、私が今できること、私ならではの内容が何かないかを考え構成を検討しました。本ブログではその経緯をご紹介します。そして次のエントリでは技術的な内容に触れる予定です。 結論から申し上げると、今回ご紹介した内容は、 Payara という Java EE アプリケーション・サーバを利用した、マルチリージョン間のレプリケーション方法（冗長構成）についてです。かんたんにいうならば、Azure の東日本リージョンと西日本リージョンに、それぞれクラスタ環境を構築し、その東日本と西日本のリージョンをさらに冗長化させるという
Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます！ 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C
Kotlinに対する雑感 | さにあらず
1.0.0 がリリースされました。やりましたね。 僕の観測範囲内に見えることが増えてきたので、興味本位で少しずつ触っています。 まず、ブラウザだけで試せるチュートリアルが大変素晴らしいので、Kotlin が肌に合うかどうか確認するといいですよ。 Kotlin Koansjs で実装されたエディタなのにシンタックスハイライトだけでなく、入力補完がガンガン効くので凄く良い。 僕の理解#大体 3 日くらいかけて言語仕様やマニュアルの類を読みながらチュートリアルをこなした結果、 Kotlin は 安全な次世代の Groovy であるという理解に到達しました。 僕が Groovy に対して持っていた不満は、大体以下の通り。 ランタイムがデカ過ぎるgroovy-all-2.4.6-indy.jar が 6.5Mバイトコードエンハンス等の危険な黒魔術がカジュアルに動く型がありそうで、実は殆どない型があま
JUnit5はどこに向かうのか？ | DevelopersIO
この表から解るように、一部の機能を除けばJUnit4の機能は継承されています。 したがって、JUnit4を理解していれば継承された機能をJUnit5に移行することは難しくないでしょう。 最初は多少の混乱はあるかと思いますが、すぐに慣れるレベルかと思います。 逆に、新しくJUnit5からJavaのユニットテストに入るのであれば、JUnit4の制約がないことは良い材料です。 特に、構造化テスト（ネストクラス）の時、JUnit4ではネストクラスをstaticクラスにすることを強いられていました。 これは、テストクラスをテスト毎に作成するという制約があったためです。 この制約がある以上、テストクラスからアウタークラスのインスタンス変数にアクセスできませんでした。 ユニットテストではテスト毎にテストインスタンスを作成することが原則なので、この制約は仕方ないと考えても良いでしょう。 しかし、テストがネ
OpenJDKは使い物になるか？OpenJDKの実際と今後 （NTTデータ オープンソースDAY 2015 Autumn 講演資料）
OpenJDKは使い物になるか？OpenJDKの実際と今後 （NTTデータ オープンソースDAY 2015 Autumn 講演資料）
InfoQ の記事に対する私のコメントのまとめ
2015年9月16日 at 11:48 午前 「オラクルがJavaエヴァンジェリストを追放」 という記事が、2015年9月14日 InfoQ 様から掲載されました。 ( 9月16日 該当記事の日本語翻訳の指摘箇所は翻訳者様によって修正されました。) 当初、Twitter や FaceBook で自分の見解を書いていましたが、私のツイートがリツィートなどで拡散されるに従い、記事の全てがウソというような内容に変わっていたりしました。それはそれで違いますので、該当記事に対する私のコメントを改めて下記にまとめます。下記意見はすでに InforQ の該当ページでも伝えています。 また、ご理解いただきたいのは、本記事の内容は、InfoQ 様、執筆者様、翻訳者様を叩くとか否定したいわけでは決してなく、事実は事実として正しく伝えていただき、事実とは異なる箇所は正しく修正していただきたいと思い記載しました。
Spring in Summer ~ 夏なのにSpring で発表してきました #jsug_sis - yukungのブログ
こういう大きいイベントでセッション発表するのは初めてだったのでかなり緊張しましたが、無事発表を終えることができました。やればできるもんですねｗ*1 Report to Spring Developer from CyberAgent from Yusuke Ikeda www.slideshare.net 時間が多少オーバーしてしまい、質疑応答の時間が取れなかったのは申し訳なかったです。ただセッション終了後には数人の方に質問しにきていただいたりもして、多少なりとも興味持って聞いていただけたのかなぁと勝手ながら思っています。 発表の機会を下さった @making さんはじめ、 JSUG スタッフの方々、その他関係者の方々、本当にありがとうございました。 補遺 私と同僚の山田の2人でのセッションで、前半が私のレガシーシステムへの導入事例、後半が山田の Spring Boot を使った運用 Ti
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PipelineDBとは？
Java 8を可能にしたJava 7の機能
オラクルがJavaエヴァンジェリストを削減
