Twitterでこれ↓が流れてきて、あれーあのクラスは無いんだー、まぁ最低限と言われると違うかもなー。と思うのがあったので便乗。 nowokay.hatenablog.com java.util.Objects recordの導入で不要になってきたメソッドも多いが、引数の検証などでまだ出番がある。防御的な書き方を簡単にしてくれるのでおすすめ。 java.util.Scanner 標準入力を受け取ってゴニョゴニョするツールを書くのに便利。競技プログラミング御用達。 java.util.concurrent.Executors スケジュール実行とか、スレッドを立ち上げてなんかするとか、そういうときに役立つ。 java.util.concurrent.CompletableFuture JavaにPromiseって無いんですか、と言われたらCompletableFuture があるよ！と返してま
2年前のブログが未だにブクマされるので、念のため掲題の件について書いておきます。 端的に書くと、あのブログで挙げた懸念事項が解消されたのでどんどん使うと良いと思います。 SLF4J v2の安定版がリリースされた 良かったですね。ちなみにv2.0.9から slf4j.provider プロパティでproviderを指定できるようになったので、Service Loaderによるprovider探索をガツッとスキップできます。多くのユースケースでは利用したほうがログの単純化や起動の高速化に有効のはずです。 SLF4Jの活動は最近活発 JIRAのデータを見れば一目瞭然。私もGitHub Issueで回答に回ったりしますが、著者の方も頻繁にコメントしてくれてます。最近のLogbackの脆弱性への対応も充分に早かったのではないでしょうか。 図1 2023年の活動状況。緑の線が6ヶ月近く右肩上がりなのに
こんにちは、SREの戸田です。本日はJVM勉強会（運用編）に続けて開催したJVM勉強会（開発編）の一部を公開します。 図1 勉強会はやっぱりGoogle Meetでオンライン開催しました システムプロパティ システムプロパティは環境変数のように、プログラムの挙動を変えるために利用することが多いです。例えばOpenJDKそのものでも Integer.valueOf() で値をどの程度キャッシュするか*1を設定するためにシステムプロパティを使っています。 他にも user.language あたりはよく知られていますし、標準で提供されるシステムプロパティも多数あります。しかし製品コードから直接参照することは基本ないと思っていて、 File.pathSeparator などの提供されたAPIを使うことが望ましいでしょう。またシステムプロパティは動的に変更することも可能ですが、システムプロパティを
こんにちは、SREの戸田です。本日は社内で開催したJVM勉強会（運用編）の一部を公開します。 JVM、使っていますか？弊社ではサーバサイドKotlinが活躍しているので、もちろん日常的にJVMが稼働しています。このためサービス運用の一貫で必要になる知識や関連ツールなどをSREないしプロダクトチームに共有することを目的として、この勉強会を開催しました。 図1 勉強会はGoogle Meetでオンライン開催しました パフォーマンス・チューニング サービスを開発していると、この処理をもっと高速化したい！ランニングコストを抑えてユーザ体験の向上に投資したい！というというシーンには多く遭遇しますよね。こうしたユーザが増えてサービスに負荷がかかるようになったことで生じた課題に対して迅速に打ち手が取れることは、とても重要です。 しかし焦ってはいけません。「このコードはめっちゃループしてるし遅そう！」「あ
Gradle v7.5の時点ではまだIncubating段階の機能ではあるのですが、Gradleの新しいプラグイン jvm-test-suite がいい感じなので紹介します。 docs.gradle.org 解きたい課題：サブモジュールや統合テストが出てくるととたんに面倒になるビルドスクリプト Gradleは設定をDSLで記述するので基本的には何でもありなのですが、やはり定形コード（boilerplate）は少ないほうがビルドスクリプトの見通しも良くなります。もちろんGradleは「設定より規約（Convention over Configuration）」の考えを持っているため、ある程度は空気を読んでSourceSetやTaskを自動的に生成してくれます。しかしテスト周りにおいてはこうした自動生成は十分ではなく、次に挙げるような課題がありました： サブプロジェクト全てに対して実行したタス
正解は int ＠NonNull [] です。な、なんだってー！ 本当です。Java言語仕様書にも記載がありますが、配列を修飾する場合は [] の手前にアノテーションを書く必要があります。JVM仕様書に記載の例のほうがわかりやすいかもしれません： @Foo String[][] // Annotates the class type String String @Foo [][] // Annotates the array type String[][] String[] @Foo [] // Annotates the array type String[] 組み合わせて考えると、「要素も配列自体も非nullのString配列」は @NonNull String @NonNull [] になります。コレクションは @NonNull List<@NonNull String> みたいにわ
![「非nullのint配列」をアノテーションで表すのは `＠NonNull int[]` ではない - Kengo's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/4530a42a4de1c2d600eff4812598c18b575a0d4e/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fogimage.blog.st-hatena.com%2F13208692334729908800%2F13574176438081076007%2F1649457525)
SLF4JとLogbackの中の人はここ数年活発ではないのでLog4j2などを代わりに使いましょう。 SLF4Jの活動は最近活発ではない SLF4JはVCSとしてGitHubを利用しています。最後の変更が2020年2月、最後のリリースが2019年12月となっていることからも、あまり活発ではないことが伺えます。 またBTSとしてJIRAを使っていますが、こちらもメンテナンスされていません。昨夏SLF4J-209が既にクローズ可能な状態であることやSLF4J-186が修正可能であることなどをコメントしましたが、1年近く経った今もすべて返信がない状態です。 2020年12月にイシューを閉じていたりするので全く動きがないわけではないのですが、年間で22つ作成されたのに対して2つしか閉じられていないので、充分にメンテされているとは言い難い状況です。 2021年5月31日時点での過去360日のイシュー
JJUG CCCで聞きたい内容を募集👇🏻— ｺﾞｰﾙﾄﾞｼｯﾌﾟと同誕の方のトダ (@Kengo_TODA) 2021年3月2日 ということでJava8〜16におけるバイトコード生成の変化について、先日開催されたJJUG CCCで喋ってきました。 動画をYoutubeにて配信していただいているので、よろしければご覧ください： youtu.be 資料はSpeakerdeckにあります。ハイパーリンクを埋めているところは、PDFを落としてもらえれば追えるはずです： speakerdeck.com マイクロベンチマークはGitHubに置いてあります。みんなも手元でレッツJMHだ： github.com なお最後の方に触れたJEP396については、掘り下げたセッションがあったようです： youtu.be 運営の皆様、いつも素敵なイベントを開催いただきありがとうございます！ 昔は息子氏見てもらう
配列使うとmutableになるから使うべきではない、というのに加えて。生成される hashCode() と equals(Object), toString() が配列を考慮しない実装になっているため、JavaのRecordでは配列を使わないほうが良いようです。 検証コード 生成される hashCode() と equals(Object) の挙動を検証するコードです。 gist.github.com なぜこうなるのか ObjectMethods クラスによって生成されるコードを見ると、 Arrays.hashCode(int[]) ではなくint[].hashCode()が、Arrays.equals(int[], int[]) ではなく int[].equals(Object) が使われているようです。これは考慮漏れというわけではなく、ObjectMethodsクラスのjavadocに
ITエンジニア本大賞2021で紹介されていた「ドメイン駆動設計入門」（以下、本書と呼ぶ）が、DDDを学ぶ上でわかりやすかったです。一応他のDDD本も数冊読んではいたのですが、どうしてもユビキタス言語や境界づけられたコンテキストなど”場合による”ものが頻出してしまい、結局どうすればいいんだ……となって手が動きにくかったのです。よくわからない概念の上にさらにわからない概念を積み重ねるので、どんどん混乱する感覚がありました。 定期的にDDD勉強しなきゃ……ってなるんだけどやらない（やれ）— 正月と正月のあいだ (@Kengo_TODA) September 5, 2019 反面、本書では副題の通りボトムアップ形式を採っているため、実際にどう手を動かせば良いのか細かく確認できました。また不明点を最小化しながら進むだけでなく、その概念を導入することでどんな問題が解決されるのかが実例をもって明示されて
4年前の下書きが出てきたので、供養のために置いておきます。 SpringOne Platform 2016のKeynoteとSessionを、特にProject Reactor周りについて確認した。 https://www.youtube.com/watch?v=Xm-KjMY_Z_w http://www.slideshare.net/SpringCentral/going-reactive-building-better-microservices-rob-harrop http://www.slideshare.net/SpringCentral/data-microservices-in-the-cloud http://www.slideshare.net/SpringCentral/designing-implementing-and-using-reactive-apis h
この記事は、2013年に書いた記事を現状に合わせてアップデートするものです。結論から言うと、当時から id:miyakawa_taku さんがおっしゃっていた「APIは依存に含めて良い」を支持するものです。あるいは無難にバージョン 1.7.30 を使っておきましょう。 blog.kengo-toda.jp slf4j-apiに1.7, 1.8, 2.0の3バージョンが生まれた 現在slf4j-apiには3つのバージョンが存在します。現在のSLF4Jエコシステムを考える上では、これらの違いを抑える必要があります： 1.7.x Java 1.5から利用できるバージョンです。安定版にこだわるなら未だこのバージョンを使う必要があります。 1.8.x JPMS（a.k.a. jigsaw）を採用しServiceLoaderを使ってBindingを呼び出すようになったバージョンです。Java 1.6が
考慮する点 成果物のデプロイ ビルドの成果物（artifct）をアップロードすること。アップロードと公開は分けて考えることに注意。デプロイ先にはいくつか候補がある： GitHub Packages (旧GitHub Package Registry) Maven Central Repository Docker HubなどのDocker Registry GitHub Packagesはコンテナも.jarもまとめて置けるが、コミュニティ標準の場所ではないので利用する際にひと手間必要になる。プライベートプロジェクトの場合は積極利用することになりそう。FOSSなら基本的にMaven Centralに置くことになる*1。プロジェクトによっては.jarファイルとしてではなくコンテナとしてデプロイすることもあるだろう。 リリースノートの作成 CHANGELOG.mdやsrc/site以下のファイル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
