• JJUG総会

    日本Javaユーザーグループの定期総会です。
    誰でも参加自由です。

    ◆主な内容
    ・活動報告
    ・会計報告
    ・会則の改訂について
    ・新幹事の承認
    ・etc

    コンファレンスB
    日 9:30 - 9:50
    • Regular(20m)
    • Beginner
    • Community

  • 知名度は高くないけど便利なJavaライブラリ集

    知名度は高くないけど便利なJavaライブラリ集を紹介したいと思います。
    * Jilt https://github.com/skinny85/jilt
    * YAVI https://github.com/making/yavi
    * Logbook https://github.com/zalando/logbook
    * NullAway https://github.com/uber/NullAway

    紹介するライブラリは基本的にはSpring以外でも利用できますが、サンプルコードにはSpring Bootを使用します。

    コンファレンスA-1
    日 10:00 - 10:45
    • Regular(45m)
    • Intermediate
    • Java SE
    • Spring
    • Tools

  • Virtual Threadsで実現する性能改善

    Java21で追加されたVirtual Threadsについて、初心者向けに解説します。
    「Virtual Threadsとはなにか？」からスタートし、従来のPlatform Threadsとの違い、SpringBootでの適用方法、速度検証を行った結果をお伝えします。
    速度検証にはJMeterを利用し、スループット・レイテンシが従来と比べてどう改善されたかを紹介します。

    コンファレンスA-2
    日 10:00 - 10:20
    • Regular(20m)
    • Beginner
    • Java SE
    • Jakarta EE

  • InvokeDynamic Under the Hood

    InvokeDynamic、略して “Indy” をご存じですか。
    ラムダ式や、最近では Record の解説で目にしたことがあるかもしれません。InvokeDynamic はバイトコードの1つで、どのメソッドを呼び出すかを実行時に動的に決定できるというのが特徴の命令です。Java のバイトコードはいろいろありますが、あとから追加されたのは現時点ではこの InvokeDynamic だけです。

    もともと、InvokeDynamicはJRubyなどのJVM言語のために導入されました。それが今ではJavaでも欠かせないバイトコードになっています。
    そこで、本セッションではInvokeDynamicの導入背景から、その動作、そしてなぜ他の用途で使用されるようになったのかを解説します。またInvokeDynamicの Java での適用例についても紹介していきます。

    コンファレンスB
    日 10:00 - 10:45
    • Regular(45m)
    • Advanced
    • Java SE
    • JVM

  • リファクタリングとデザインパターンの基礎

    初級から中級の開発者を対象に、リファクタリングの基本的な技術とオブジェクト指向プログラミングのデザインパターンについて、
    実際のプログラミングの問題を通じて理解を深めていくセッションです。

    プログラミングは常に進化しています。
    しかし、その進化を支える基盤はコードの品質です。
    このセッションでは初級者のためのリファクタリング技術とオブジェクト指向プログラミングのデザインパターンを学んでいきます。
    これらのスキルはコード品質を改善し、ビジネスの変化に柔軟に対応するソフトウェアの開発を容易にするのに役立ちます。

    セッションの中で、リファクタリングの基本的な手法と最も一般的なデザインパターンを明らかにします。
    実際のプログラミングの問題に取り組む具体的な例を使って、これらのコンセプトの適用方法を示します。

    1. リファクタリングとは何か、なぜ重要か
    2. リファクタリングの基本的な手法
    3. デザインパターンとは何か、なぜ重要か
    4. 典型的なパターンの概要と実装例
    5. 現実的な問題によるデモンストレーション

    デモンストレーションでは、頻繁に発生する典型的なコードの問題を取り上げ、リファクタリングとデザインパターンを用いた効率的な解決策を体系的に示します。
    具体的には、無駄に複雑になった関数の分解、重複した記述の排除、難解な条件分岐の整理等について考えます。

    私たちの目標は、あなたがこのセッションで得た知識を使って、自分自身のコーディングスキルを向上させ、チーム全体の生産性の向上に貢献できることです。

    コンファレンスC
    日 10:00 - 10:20
    • Regular(20m)
    • StepUp
    • Java SE
    • Tools
    • Architecture

  • Javaで学ぶ SSL/TLS

    「httpは安全じゃないけど、httpsなら安全だよ」ということを言われたことはありませんか？
    この「https」の通信に使われているセキュリティ技術が「SSL/TLS」です。
    「普通の通信とSSL/TLS通信は何が違うの？」
    「証明書ってなあに？」
    を、Javaのソースコードを実際に動かしながら解説します！

    ミーティングルーム
    日 10:00 - 10:20
    • Regular(20m)
    • Beginner
    • Java SE
    • Tools

  • チームの成長を促すためのスプリントレトロスペクティブの活用法

    開発組織がアジャイルな状態になるためで利用される開発プラクティスにスクラムや エクストリームプログラミング (XP) などが挙げられます。そして、これらのプラクティスはソフトウェア開発の現場におけるスタンダードになってきました。その一方で、プラクティスを取り入れてもなかなかうまくいかないという話も耳にします。

    私たちの組織では、スクラムイベントである「スプリントレトロスペクティブ」に対して課題感がありました。具体的には、イベントの形骸化が起こり、単なる報告会や反省会となっていたことでした。
    そこで、「スプリントレトロスペクティブ」を再度捉え直し、その改善を考え、実践していきました。

    このセッションでは、スクラムにおけるプラクティス、特に「スプリントレトロスペクティブ」に焦点をあて、効果的な実践ができるように私たちが考えたこと・やったことをお話します。

    セッションの中で主に取り上げる内容（予定）は以下です。
    ・ 前提について（チームや体制、その中での役割など）
    ・ スクラムガイドにおける「スプリントレトロスペクティブ」について
    ・ いいふりかえりになるためにやったこと・考えたこと・気をつけたこと
    ・ やっていく中での学びと課題

    このセッションの目標は以下を考えています。
    ・ スクラムガイドにおける「スプリントレトロスペクティブ」の理解
    ・ 「スプリントレトロスペクティブ」を実践するうえでの Tips
    ・ 私たちのチームにおける「スプリントレトロスペクティブ」の実践例の共有

    逆に、以下は目標としません。
    ・ アジャイルとウォーターフォールのどちらがいいかのような比較は行いません
    ・ Java や Spring Framework などの言語やツールの技術仕様などは話しません

    コンファレンスA-2
    日 10:25 - 10:45
    • Regular(20m)
    • Beginner
    • Others

  • 物理削除 vs 論理削除 レコード消滅作戦

    # 概要
    たびたびSNS等でも話題になる物理削除と論理削除について、深掘りして設計指針を示します。

    # 詳細
    物理削除と論理削除は意見の分かれるところですが、トレードオフ関係があり、常にどちらかを選択すればうまくいくというものではありません。
    ほとんどのシステムでは考慮が必要な点であり、設計時に選択を迫られます。
    本セッションではプロジェクトや保存されるデータの特性からどんな削除ポリシーが良いか示していきます。

    ## アジェンダ
    - 物理削除とは
    - 論理削除とは
    -- 削除フラグ/削除日時/削除ステータス
    -- 削除レコード
    -- マスキング
    - 各陣営の主張
    -- 物理削除のメリット
    -- 論理削除のメリット
    - 削除の目的整理
    - 大まかな選定基準

    # スピーカー
    SIerでtoB向けの基幹システム開発(Java)に従事した後、転職し、ECサイト(Java)開発やtoC向けのクリエイター支援プラットフォーム(Ruby on Rails)の開発を行っています。
    幅広い開発経験からプロジェクト特性に合わせた事例の紹介を行います。

    タイトルは『ゴジラ×メガギラス G消滅作戦』のパロディです。

    コンファレンスC
    日 10:25 - 10:45
    • Regular(20m)
    • Beginner
    • Architecture
    • Database
    • Others

  • JVM言語でもできる、競技プログラミング

    競技プログラミング（競プロ）って知っていますか？聞いたことはあるけどよく知らないという方もいらっしゃるかと思います。

    このセッションでは、実際にJVM言語（Kotlin）で競プロに取り組んでいる経験をもとに以下の内容について話します。

    ・競プロってどんなもの？
    ・競プロでJVM言語を使うのって実際のところどうなのか？
    ・自己研鑽として役に立つのか？

    競プロのコンテストサイトは多くありますが、日本で最も人気のあるAtCoderというサイトをもとに話をします。

    ※AtCoderの過去問のネタバレを含む可能性があります

    ミーティングルーム
    日 10:25 - 10:45
    • Regular(20m)
    • Beginner
    • Others

  • 次世代RDB劔"Tsurugi"にアクセスするJavaライブラリー・ツール

    Tsurugiは2023/10/5にOSSとしてリリースされた新しいRDBMSです。
    Tsurugi本体はC++で書かれていますが、Tsurugiにアクセスするライブラリーは今のところJavaのものだけ提供されており、ツールもほとんどがJavaで書かれています。
    今回は、Tsurugiの特徴を説明した後で、TsurugiでSQLを実行するライブラリーであるIceaxe（JDBCではない）や、対話形式でSQLを実行するツールであるtgsql（JShellでも使われているJLineを利用）等を紹介します。

    コンファレンスA-1
    日 11:00 - 11:45
    • Regular(45m)
    • Intermediate
    • Java SE
    • Tools
    • Database

  • フレームワークを10年以上開発する中で培ってきた単体テストのプラクティス

    これまで 20年以上 Java での開発を行い、10年以上前から社内向けWebアプリケーションフレームワークの開発を行ってきました。
    開発している社内向けフレームワークは色々な種類のシステムで利用されており、（特に決済系のシステムでは）高い品質を求められるケースもあります。そのため、プロダクトコードのみでなく、単体テスト基盤・ユーティリティー、単体テストの観点・ルール等も提供しています。

    このセッションでは、これまでの開発で培ってきた単体テストのプラクティスを共有したいと考えています。
    （ここでベストプラクティスとしていないのは、色々な制約から単体テストの理想からは離れたプラクティスもあるためです。）

    現実的な制約として、
    ・フレームワーク初見のメンバーもいるので、フレームワーク自体の教育も必要なケースもあり、単体テストの教育まで十分に時間をかけられない。
    ・メンバーの開発スキルにばらつきがある。
    ・開発チームがリリース後の保守や追加開発を行うとは限らない。
    といった制約がある中で、
    ・いかに品質を担保するか
    ・いかに効率的に単体テスト記述できるようにするか
    を考え、単体テストのアーキテクチャやルールを構築してきました。

    具体的には以下のような内容等について、メリット・デメリット、なぜそうしているか等について発表します。
    ・レイヤー毎の単体テストの観点
    ・期待値との文字列ベースのアサート（故 石井勝 氏のアイデアを発展させたものです）
    ・データベースの初期化、アサート、暗号化・復号化
    ・基本的にスタブは使用しない
    ・コントローラ層の単体テストの仕組み

    これらのプラクティスは、システム規模、求められる品質レベル、開発体制、メンバーのスキルレベル等によって、何がベターかは変わると思っていますが、少しでも参考になれば幸いです。

    コンファレンスA-2
    日 11:00 - 11:45
    • Regular(45m)
    • Intermediate
    • Java SE
    • Others

  • FIFOキューで実現するSpring Bootの非同期処理とその性能評価方法

    リクルートのHuman Resource (HR) 領域では従来、サービスごとに異なる職務経歴書を作成する必要があった。求職者の書類作成負荷を低減するため、各サービスの職務経歴書を「レジュメ」という共通のプラットフォームに順次移行している。この移行の一環で、あるサービスにレジュメPDFを連携する非同期処理をSpring Bootとメッセージキューを用いて実現したが、設定していた性能目標を下回ってしまうという問題がリリース直後に発生した。これを受けて我々は、メッセージキューのタイプを標準キューからFIFOキューに変更したうえで、コンシューマーのスペックとオートスケーリングの発動ロジックを見直す性能試験を行った。結果として、現在まで性能目標を下回らない状態を維持できている。本セッションでは、非同期処理におけるSprgng BootとFIFOキューの扱い、及び性能評価方法の知見を共有する。

    コンファレンスB
    日 11:00 - 11:45
    • Sponsor(45m)
    • Intermediate
    • Spring
    • Cloud

  • Spring for GraphQL の実践

    株式会社エス・エム・エスでは介護事業者向け経営支援サービス「カイポケ」のリニューアルプロジェクトに着手しています。
    本セッションではSpring for GraphQL を利用した開発における実践的な内容について紹介します。

    プロダクトの全体構成
    モノレポの構成
    バックエンド構成
    ・Spring for GraphQL
    ・GraphQL Federation
    フロントエンド構成
    ・Next.js
    ・Apollo Client
    スキーマ管理
    ・GraphQL Code Generator
    Spring for GraphQLの構成方法
    ・Schma定義
    ・Controller実装
    ・graphql.config.yml
    コード生成
    ・DGS Codegen
    ・Apollo code generation
    Schema validation
    Error レスポンス管理
    ・Resolver に到達する前のエラー
    ・graphql-java-extended-validation で発生したエラー
    ・Resolver 以降で発生したエラー
    認可処理
    ・認可アノテーション
    テスト
    ・GraphQL Document
    ・認可のテスト

    コンファレンスC
    日 11:00 - 11:45
    • Sponsor(45m)
    • Intermediate
    • Spring
    • Architecture

  • Kubernetes でも Java アプリで TLS 接続を終端したい

    企業は顧客データの安全な処理と転送の確保に対するプレッシャーが増大しています。通信の暗号化は、顧客の信頼を維持する上で不可欠です。

    PCIDSS や HIPAA などの規制においても、内部ネットワークにおいても通信の暗号化を実装することが望ましいとされていることがあります。

    このセッションでは、 Kubernetes にデプロイされる Java アプリケーションにおいて TLS 通信を終端するための手法、パターンなどを紹介します。

    Java アプリケーションにおいては Keystore (JKS) に証明書をインポートする必要がある場合があります。どのようにコンテナ上で動作する JKS に証明書をインポートするとよいか、証明書をどのように管理するとよいかなどの考察もできれば良いと考えています。

    コンファレンスB
    日 12:00 - 12:45
    • Sponsor(45m)
    • Intermediate
    • JVM
    • Tools
    • Architecture

  • PCI DSSの観点から見たセキュアなJavaアプリケーション

    私たちが開発している STORES 決済は、PCI DSS(Payment Card Industry Data Security Standard)に準拠しています。
    PCI DSS とは、クレジットカード情報のセキュリティを確保するための国際的な基準であり、決済サービスを継続する上では準拠することが必須となります。

    準拠に際して求められる要件は、クレジットカードを扱うならではのものが存在する一方で、一般的なアプリケーション開発にも役立つものもあります。

    このセッションでは、PCI DSS準拠を通じて得られた、セキュアなJavaアプリケーション開発に関する知見を説明していきます。

    コンファレンスA-1
    日 13:00 - 13:20
    • Regular(20m)
    • Beginner
    • Others

  • 自動アップグレードを夢見て、Amazon Q Developer使ってみた

    昨年のAWSのre:Inventにおいて、Java8のコードをJava17に変換するAmazon Q Code Translationが発表されて、AWSの社内テストの事例としても、2日で1,000の本番アプリケーションを変換したとして発表がありました。 JJUGのセッションエントリを行った時点ではプレビュー版でしたが、現在はAmazon Q Developerとして公開され、、既存のコードを自動的に分析し、変換プランを生成し、プランによって提案された変換タスクを完了してくれるものです。コード自動性生成は競争の激しい分野ではあり、多数の製品が各社から発表されていますが、コテコテのエンタープライズJavaユーザにとっては非常に注目せざるを得ないサービスです。 今回のセッションでは、プレビュー版の利用方法を紹介すると共に、果たして、コテコテのレガシーJavaアプリケーションを見事に書き換えてくれたのか？、いくつか試したコードを基に、将来の自動アップグレードの夢を紹介させて頂きます。

    コンファレンスA-2
    日 13:00 - 13:20
    • Regular(20m)
    • Beginner
    • Tools

  • JJUGキーノート: Java First. Java Always.

    As the world of modern application development rapidly evolves, Java continues to adapt to keep pace. This affords enterprises the ability to accelerate mission-critical application development reliant on Java and provide developers a programming language and platform that efficiently and effectively address app development from on-premises to the cloud. In this keynote, Java luminaries from Oracle explore modern Java features that enable next-gen applications, as well as cover how Oracle’s ongoing Java technology leadership and ecosystem stewardship are creating a contemporary language and platform that help advance developer productivity and Java community participation.

    コンファレンスB
    日 13:00 - 13:45
    • Regular(45m)
    • Beginner
    • Java SE
    • Community

  • Webアプリケーションセキュリティの基礎とSpring Bootでの実装

    Webアプリケーションをクラッカーの攻撃から守るために様々な対策が求められます。例えばSQLインジェクション対策、CSRF対策、XSS対策、セッションID固定化対策などです。
    このセッションでは、これらの対策について基礎から解説したあと、Spring Bootでどのように実装するかを解説します。

    コンファレンスC
    日 13:00 - 13:45
    • Regular(45m)
    • Beginner
    • Spring
    • Others

  • 条件分岐の多さと紛らわしい命名、先にリファクタリングするなら？ - Java ソースコードをみんなで読んで比べた結果

    リファクタリングの対象であるコードスメル(code smells: コードの臭い)を一括して解消することは難しいことが多いので、解消するコードスメル(code smells)に優先順位をつけて、段階的に解消する必要があります。その際、解消すると読みやすくなるコードスメルからリファクタリングしていくほうがリファクタリングの効果が出やすいです。

    Githubで公開されているJavaソースコードを含むリポジトリから少数のコミットを取り出して分析した研究では、可読性の向上を目的としたリファクタリングのうち、約30%が構造的な問題を修正するためのメソッド分割作業であり、約60%が命名的な問題を修正するためのリネーム作業であると報告しています。

    そこで、構造の問題と命名の問題のどちらを優先すべきかを確かめることを目的として、同じ仕様を満たす小規模なJavaソースコードを2種類準備しました。片方は構造の問題、もう片方は命名の問題を含みます。

    2023年のJJUG CCC 2023 Fallの懇親会のLTにてご協力をお願いし、拡散いただきました。本セッションでは、ご協力いただいた皆さまにお礼をお伝えします。
    その後、50名超のエンジニアの方にこれらのコードを読んでいただいて、コードに関する質問の正解率に統計的に有意な差があった点をはじめ、どちらが読みやすかったか比べた結果を報告します。また、ご協力いただいたエンジニアの方とのディスカッションの内容を報告します。

    コンファレンスA-1
    日 13:25 - 13:45
    • Regular(20m)
    • Intermediate
    • Java SE
    • Community
    • DevOps
    • Methodology

  • ビルドツールとはなにか?からはじめるGradle超入門

    本セッションでは、Javaプロジェクトで利用されるビルドツールであるGradleについて初心者の視点から解説します。そもそもビルドツールとは?という基本からスタートし、なぜ難しく感じてしまうのかを、実例を交えて発表します。Gradleがビルドツールとしてどのようにプロジェクトの効率化に貢献するのか、基本的な概念と使い方から、実際のプロジェクトでの使い方・既存のコードの読み解き方まで幅広くカバーします。

    発表のモチベーション:

    発表者は約1年前にJava/Spring Bootを使ったサービス開発に初めて参加しました。プロジェクトではGradleというビルドツールが使われていたものの、ながらく理解があやふやなまま使っており、気持ち悪さを感じていました。
    違和感を解消するためにGradleに向き合ってみたところ、Gradleで使われる概念の理解が誤っていることに気づき、（きっと開発参加直後よりは）正しく認識することができました。その結果、スッキリとした気持ちでサービス開発ができています。この体験を共有し、少しでも皆さんの開発体験の向上に寄与したいと考えています。

    発表を聞いて得られること:

    - ビルドツールの役割とJavaプロジェクトにおけるビルドツールの位置づけ
    - Gradleが扱う基本概念と主要なファイル構成についての理解
    - 既存プロジェクトにおけるGradleの利用の読み解き方

    セッション内容（予定）:

    【背景】
    - Gradleに初めて触れる方向けの概要の説明。ビルドツールの必要性とGradleの位置づけについて解説
    - ビルドツールとは： ビルドツールが何をするものか、Dependency Hellの問題などビルドの難しさについて説明
    - Javaにおけるビルドツール： Java世界でのビルドツールのシェアとGradleの特徴について
    【メイントピック】
    - Gradleの基本概念：ProjectとTaskについて
    - 主要なファイル：settings.gradle, build.gradle, Gradle Wrapperについて
    - Mavenリポジトリとの連携方法
    - Gradleバージョンでの変更を踏まえた、実際のプロジェクト上での利用や改善点について
    【まとめ】
    - 他のビルドツールやタスクランナー（Maven、Makeなど）との比較
    - Gradleの強力なドキュメントとチュートリアルの紹介

    対象者:

    - Gradleの概要をつかみ、使えるようになる準備をしたい方
    - ビルドツールについて学びたい方
    - ビルドツールに一家言ある方

    注意点:

    - 発表者のWebアプリケーション開発の経験をベースに話すため、非Webアプリ開発の事情が考慮できてない可能性があります
    - 時間の都合上、基本を理解する・既存のコードベースを理解・修正できるようになる、が中心となり、自身で作っていくこと（例えばpluginの開発）までは話せない気がします

    コンファレンスA-2
    日 13:25 - 13:45
    • Regular(20m)
    • Beginner
    • Tools

  • Javaエコシステムの最新動向

    本番環境に最も使用されているJavaのバージョンは？
    最もポピュラーなJDKのベンダーって今はどこなんだろう？
    今最も一般的なヒープサイズって？
    日々みなさんが開発される中で最新トレンドが気になることはありませんか。
    当セッションでは、最新のJavaエコシステムレポートを公開します。Javaの開発・運用に関わるエンジニアの皆様、そしてこれから関わる予定の皆様にも役立つ情報をお届けします。
    合わせてNew RelicのJavaモニタリング機能もご紹介します。

    コンファレンスA-1
    日 14:00 - 14:45
    • Sponsor(45m)
    • Beginner
    • DevOps

  • Spring Bootと行レベルセキュリティではじめるマルチテナントアーキテクチャ

    複数のテナント間でデータベースを共有するマルチテナントアーキテクチャ。構築・運用のコストに優れる一方で、アプリケーション側の不具合によって他のテナントのデータが見れてしまう、という重大なインシデントを起こしかねません。

    マルチテナントアーキテクチャを採用する際に、どうやってセキュリティと開発者体験を両立すればよいのでしょうか。その一つの解として、行レベルセキュリティ (Row-Level Security : RLS)があります。

    本セッションではSpring Boot + PostgreSQLでRLSを用いたマルチテナントアーキテクチャを構築するノウハウとテスト、Tipsについてお話します。

    コンファレンスA-2
    日 14:00 - 14:45
    • Regular(45m)
    • Intermediate
    • Spring
    • Architecture
    • Database

  • Adopting ZGC in HBase for LINE Messaging

    発表は日本語でします。

    The LINE Messaging Platform, renowned for managing a vast amount of requests and messages,
    relies on HBase as its underlying storage/database. The performance of HBase, particularly its latency characteristics,
    is crucial for ensuring the platform's responsiveness, reliability, stability, and scalability.

    HBase, a Java-based middleware operating on the JVM, demands careful selection of garbage collection (GC) strategies
    to balance throughput with responsiveness. Initially, our HBase deployment utilized G1GC with a targeted pause time of
    approximately 100ms. Despite this, we encountered a limitation that prevented heap sizes from exceeding 31GB without
    sacrificing our pause time goals. This limitation was particularly challenging given our deployment on high-specification
    baremetal servers equipped with 256GB of RAM or more, effectively underutilizing the available hardware resources due to GC constraints.

    To address these issues, we upgraded our production environment to HBase 2, alongside Java 17, and subsequently to Java 21.
    ZGC, which debuted as an experimental feature in Java 11 and was promoted to a production-ready feature by Java 15, presented
    an opportunity for optimization. Our initial experiments with ZGC in Java 11 and 15 revealed application latency issues.
    However, the advancements in ZGC within Java 17 and 21 have been significant, enabling us to integrate ZGC into our production HBase cluster successfully.

    In this session, we will explore the mechanism of ZGC, its impact on our systems, and our journey towards its adoption.
    We will delve into the ZGC algorithm, its operational behavior, and provide guidance on enabling ZGC in server environments.
    Additionally, we will discuss the pitfalls encountered with ZGC in Java 17 and share insights into the real-world performance improvements observed post-adoption.

    Join us to learn how ZGC can revolutionize the performance of Java applications like HBase, allowing full utilization of
    high-spec hardware and ensuring that your platform remains responsive and scalable under heavy load.

    LINE Messaging Platformは、膨大な数のリクエストやメッセージを処理することで知られており、その基盤となるデータベースとしてHBaseを使用しています。
    特にレイテンシの特性を含むHBaseのパフォーマンスは、プラットフォームの応答性、信頼性、安定性、およびスケーラビリティを保証する上で重要です。

    JVM上で動作するJavaベースのミドルウェアであるHBaseは、スループットと応答性のバランスを取るために、ガベージコレクション選択が重要です。
    我々のHBaseでは、目標一時停止時間が100ミリ秒のG1GCを適用していました。
    しかし、一時停止時間の目標を犠牲にすることなくヒープサイズを31GBを超えることができないという制限に直面しました。
    この制限は、HBaseが256GB以上のRAMを備えた高性能ベアメタルサーバーにデプロイされていることを考えると、GCの制約により利用可能なハードウェアリソースを効果的に活用できないという特に大きな課題でした。

    これらの問題に対処するため、私たちはプロダクション環境をHBase 2にアップグレードし、同時にJava 17に、その後Java 21にアップグレードしました。
    Java 11で実験的機能として登場し、Java 15で本番環境に適した機能に昇格したZGCは、最適化の機会を提供しました。
    Java 11と15でのZGCの初期実験ではレイテンシの問題が明らかになりました。
    しかし、Java 17と21でのZGCの進歩は顕著であり、私たちは成功裏にZGCを本番のHBaseクラスタに適用できました。

    このセッションでは、ZGCの仕組み、HBaseへの影響、そしてその採用に至るまでの経緯を探求します。
    ZGCのアルゴリズムと運用方法について詳しく説明し、サーバー環境でZGCを有効にするためのガイダンスを提供します。
    さらに、Java 17で遭遇したZGCの落とし穴について議論し、採用後に観察された実際のパフォーマンスの改善についての洞察を共有します。

    ZGCがHBaseのようなJavaアプリケーションのパフォーマンスをいかに革命的に変えることができるか、
    高性能ハードウェアを完全に活用し、大量の負荷がかかってもプラットフォームが応答性とスケーラビリティを維持できるようにする方法を学びに参加してください。

    コンファレンスB
    日 14:00 - 14:45
    • Sponsor(45m)
    • Intermediate
    • Java SE
    • JVM

  • テストコードが根付くチームを立ち上げるために考えたいこと

    シンプレクスは、お客様のビジネスを成功に導くテクノロジーパートナーです。戦略から設計、開発、運用保守までのすべてに責任を持ち、一気通貫でソリューションを提供しています。このセッションでは、とあるチームにテストコードが根付いた経験を元に、テストコードが根付くチームになるために考えたいことをさまざまな観点からお伝えできればと思います。テストコードに悩む方に明日から実践できるかもしれない何かを持ち帰っていただけるセッションを目指します。

    コンファレンスC
    日 14:00 - 14:45
    • Sponsor(45m)
    • Beginner
    • Others

  • FFMでJITコンパイラを作ってみた

    Java 22でいよいよ正式機能となったForeign Function & Memory API（FFM）。ネット上でも紹介記事を目にすることが多くなりましたが、そのほとんどはネイティブライブラリの呼び出しやメモリ操作に関するものです。しかし、FFMの魅力はそれだけではありません。動的に機械語を生成し、Javaから呼び出すことまでできてしまうのです。

    Javaでアセンブラを書き、それを実行するffmasm ( https://github.com/YaSuenag/ffmasm ) というライブラリの仕組みを例にとり、FFMでJITコンパイラを実現する方法や関連するHotSpot VMの実装など、Javaからネイティブレイヤを積極的に使っていく方法や注意点をご紹介します。

    コンファレンスA-1
    日 15:15 - 16:00
    • Regular(45m)
    • Advanced
    • Java SE
    • JVM
    • Others

  • ソートできるUUID v7をJavaで使うときの話

    IDを採番するときにUUID（v4）を使おうと思ったとき、「順番性がなくソートしにくい」という理由で使いにくかったりしました。
    それを解決するために「タイムスタンプ情報をつかってソートできるUUIDを」という感じで提案されているのがv6, v7, v8です。

    そんなソートできるUUIDの簡単な説明と v7 をJavaで使う方法、ちょっとした落とし穴の話をしようと思います。

    コンファレンスA-2
    日 15:15 - 15:35
    • Regular(20m)
    • Beginner
    • Java SE
    • Others

  • Javaプロファイラの信頼性とバイアスへの付合い方

    性能トラブル調査や性能チューニングの際には、プロファイラを使うことになりますが、Java VM技術の変化にともない、現在では多種多様なプロファイラが存在します。
    しかし、プロファイラは一般的にその動作にバイアスがかかるため、同じプログラムでもプロファイラによって性能分析結果が異なることがあり、何を信用すればよいのか悩むことが多々あります。
    特にJavaではセーフポイントバイアスが有名ですが、最近ではこのようなバイアスを解消する技術を使ったプロファイラもでてきました。しかし、これ以外にもさまざまなバイアスがあり、
    どのプロファイラも完全にバイアスを取り去ることは難しいのが実状です。現実にはいろいろなプロファイラのバイアスを理解しつつ、用途に合ったものをいくつか選択・組合わせすることが必要になってきます。
    本セッションでは、なぜバイアスが生じるのかをJava VMのアーキテクチャをベースに紐解き、いくつかのプロファイラ(JFR、AsyncProfiler、VisualVM、perfなど)を例に、バイアスに対してどのように対処していけばよいのか、プロファイラの信頼性とは何か、を考察します。

    コンファレンスB
    日 15:15 - 16:00
    • Regular(45m)
    • Intermediate
    • Java SE
    • JVM

  • Spring Boot vs MicroProfile - クラウドネイティブにおけるフレームワークの比較と選択

    ページ生成をサーバーサイドで行う従来型のWebアプリケーションをJavaで作る場合、現実的なフレームワークの選択はSpring Boot(+Thymeleaf)の一択ですが、それがRESTを中心としたクラウドネイティブなアプリケーションである場合はどうでしょうか？Spring Bootも依然として有力な選択肢ですが、もう一つの有力な選択肢として現在ではMicroProfileがあります。

    スピーカーはここ数年、Jakarta EE+MicroProfileを使った開発を行ってきましたが、昨年度からはSpring Bootを使った共通機能の開発も行っています。その日々の開発を通してコレはMicroProfileの方がいいな、よくできているなと思ったり、反対にSpringでよかったなと思うところは結構あったりします。

    今回のセッションでは、そんなSpring BootとMircoProfileの両方の開発者の視点から、まずは土台となるDIとAOPに対する双方の違いを簡単に説明した後、RESTリソース(@RestController vs JAX-RS)、RESTクライアント(RestClient+HttpInterface vs MicroProfile Rest Client)、コンフィグ(Environment & @ConfigurationProperties vs MicroProfile Config)といったクラウドネイティブでは必須かつ重要となる機能を中心に双方の違いを見ていくことで、それぞれに向くアプリや開発組織を筆者なりに考察したいと思います。

    なお、説明はSpring Bootを使っている人には、MicroProfileにもそんな機能があるのねと思っていただけるレベルを、反対にMicroProfileを使っている人にはSpring Bootも同じ感じなのねと思っていただけるレベル感を目指します。

    また、今回のセッションはテーマが発散しないよう以下の前提で説明を行います。
    ・AWSやAzure、Google Cloudなどクラウドサービスそのものや固有なテーマは扱いません
    ・MicroProfileの実装はQuarkusやHelidonなどアプリケーションサーバが不要なものを前提にしています
    ・Micronautも選択肢になるんじゃないの？というご意見はごもっともで、そのとおりかと思いますが、ｽﾐﾏｾﾝ、今回は割愛させてください
    ・そもそもJavaでクラウドネイティブってどうよ？という話はある気はしますが、怖いのでそういうことは言いません

    コンファレンスC
    日 15:15 - 16:00
    • Regular(45m)
    • Intermediate
    • Spring
    • Micro Profile
    • Cloud

  • Contributing to the Java Community

    Java has one of the largest developer communities in the world, and it offers many interesting ways for developers to participate and contribute. Getting involved in this way is not only enjoyable personally but also results in serious value for your career. And it helps move Java forward too! We're all in this together, and the more we all contribute the more we all benefit! Remember, when you get involved and contribute directly, you make Java better.

    In this session you'll learn about the current state of the Java community globally and how to get engaged. We'll talk about contributing code, writing documentation, translating content, starting user groups, participating at conferences, and more. You'll also hear stories about Java developers who have successfully contributed something of value to the community and how that gift has changed their lives forever!

    コンファレンスA-2
    日 15:40 - 16:00
    • Regular(20m)
    • Beginner
    • Community

  • WealthNaviにおけるObservability実践と、サービス改善への活用

    ウェルスナビではサービスをお客様に安心してご利用いただく為にシステム監視を自動化し安定運用に努めています。
    AWS環境にてjavaを中心とした多くのアプリケーション群に対する継続的な監視を通じて得たデータとインサイトを活用し、事後保全や予知・予防保全に取り組むことでObservabilityの実現を進めております。
    今セッションでは、これまでの取り組みについて、ウェルスナビでの実例から以下を中心にお話する予定です。
    ・Javaアプリケーションの監視方法（ログ、メトリクス等）
    ・Observability基盤の構成
    ・Observabilityの実現とサービス改善サイクルへの影響

    コンファレンスA-1
    日 16:15 - 17:00
    • Sponsor(45m)
    • Intermediate
    • Java SE
    • Spring
    • Cloud
    • Others

  • Spring Boot 2.7 から 3.1 へのアップグレードに苦労したことと学んだこと

    皆さんは Spring Boot のアップグレードにどれぐらいかかりましたか？
    私は繁忙期を挟むなどして約半年間もの時間を費やしました。

    Spring Boot 2.7 の OSS サポート終了を前に社内でもシステムの Spring Boot 2.7 から Spring Boot 3.1 へのアップグレードの話が持ち上がりました。
    私はその主担当として、そして、初めての大きなアップグレードで苦労したこと、そして学んだこと、どうしてここまで時間がかかったのかをまとめました。
    また、アップグレードによる影響を小さくする為に行った段階的なリリースについてもその概要を紹介します。

    【要点】
    アップグレードでの理想とギャップ
    アップグレードでのつまづきポイント
    上記のつまづきポイントに対して工夫したこと
    アップグレードの影響を小さくする為の段階的なリリースの概要

    【目標】
    アップグレードのプロセスにおけるヒントの共有

    【扱わないこと】
    コードレベルでの詳細な説明

    コンファレンスA-2
    日 16:15 - 16:35
    • Regular(20m)
    • Beginner
    • Spring
    • Others

  • 2024年 AI を利用した Java 開発の最新情報

    昨年から、AI の活用は多岐に渡り利用されるようになりました。GitHub Copilot を利用した開発生産性の向上や、企業環境における AI サービスの導入など多くの企業が AI の活用に対して興味を持ち採用をし始めています。本セッションでは AI サービスの開発において利用可能な Java の SDK やライブラリをデモを交えてわかりやすく紹介する他最新のアップデートをお届けします。
    本セッションを通じて、去年から今年にかけての Java における AI サービス開発の最新情報を学ぶことができます。

    コンファレンスB
    日 16:15 - 17:00
    • Sponsor(45m)
    • Intermediate
    • Java SE
    • Cloud
    • Tools
    • Methodology
    • Others

  • 新卒エンジニアが 0から Non-Blocking な gRPCサーバーを作った話

    出前館では現在レガシーシステムから新システムへのリプレイスを進めています。
    本セッションでは、その一環として新卒エンジニアが0からNon-BlockingなgRPCサーバーを構築する際に使った技術を紹介します。
    また、その技術を使ってどのようにgRPCサーバーを構築するのか、実際のコードを用いたデモンストレーションを通じてgRPCの入門を行います。

    デモンストレーションで使うコードはこちらになります。
    https://github.com/sato9818/jjug-sample

    発表する予定の内容は以下の通りです。
    ・gPRCとNon-Blocking通信の基礎
    ・技術選定 + デモンストレーション
    ・開発時に苦労した点

    コンファレンスC
    日 16:15 - 17:00
    • Regular(45m)
    • Intermediate
    • Spring
    • Tools

  • Spring Bootで作成したAPIテストのコスパを高めよう！

    APIのテストはどのようにやっていますか？
    ユニットテストは書いても、E2Eまでは書かないという方も多いのではないかと思います。

    私はAPIを作った際、curlコマンドやgrpcurlコマンドを使って動作確認をしていました。しかし、OpenAPIやgRPCを利用してAPIを作っている場合においてシナリオテストを導入すると、とても素早くしかもコマンドで確認するより正確なテストができました。

    このセッションでは、OpenAPIまたはProtocol BuffersをつかったgRPCをSpring Bootで実装されたAPIに対してどのようにシナリオテストを行うのか、シナリオテストによって得られるメリット・デメリットについてお話しします。

    * 期待するゴール
    APIをrunnコマンドでシナリオテストする方法が理解できる
    APIのテストカバレッジや型チェックを行うことで、APIとシナリオを継続的に比較的簡単に改善できることが理解できる

    * 話さないこと
    OpenAPIやgRPCの詳細について
    細かなテスト手法について

    コンファレンスA-2
    日 16:40 - 17:00
    • Regular(20m)
    • Intermediate
    • Spring
    • Tools

  • いまどきの分析設計パターン おすすめ１０選

    Javaの主戦場であるエンタープライズアプリケーション分野でのソフトウェア開発にすぐに役に立つ、業務活動の分析設計パターンを精選して紹介します。

    内容は、実務でよく見かける題材と、そのコード例の抜粋です。

    以下を予定しています。

    【初級編】
    事業活動で起きていることを観測し、観測結果を元にした計算判断の業務ルールを表現するための基本パターン。
    関連：境界値テスト

    ・基本的な測定値（金額、数量、日付）
    ・範囲演算（範囲の境界と判定）
    ・階段状の判定ルール

    【中級編】
    時間軸（状態の変化）を表現するための分析設計パターン
    関連：状態遷移テスト

    ・状態遷移モデルの分析設計
    ・入出金履歴と残高
    ・未来在庫と出荷可能判定

    【上級編】
    より複雑な業務ロジックの分析設計パターン。
    関連：デシジョンテーブルテスト

    ・集合演算（スキルセットのマッチング）
    ・複合条件の判定（決定表）
    ・比率配分（シェアパイ演算）
    ・経路選択（グラフ構造の表現）

    コンファレンスA-1
    日 17:15 - 18:00
    • Regular(45m)
    • Intermediate
    • Java SE
    • Database
    • Methodology

  • JJUGセッション: Javaコミュニティのススメ

    Java は、現在もソフトウェア業界で最も広く利用されているプログラミング言語の 1 つです。
    言語を常に進化させるという点で、Java コミュニティは重要な役割を果たしています。

    このセッションでは、Java のイノベーションがコミュニティによってどのように活発化されてきたかを、Java の歴史を振り返りながら解説します。
    そして、どのようにしてコミュニティ活動に参加すればいいのかを、JJUG 幹事の経験談を交えて紹介します。

    コンファレンスA-2
    日 17:15 - 18:00
    • Regular(45m)
    • Beginner
    • Community

  • イベント駆動アーキテクチャ導入の手引と共通の落とし穴

    イベント駆動アーキテクチャを導入するために必要な取り組みと、共通の落とし穴の避け方についてお話します。

    システムの大規模化が進むと、システムのスケーラビリティを担保するための多くの努力が必要になります。
    システム上の出来事をイベントとしてとらえ、関連システムがイベントをベースに連携するイベント駆動アーキテクチャはその解法のひとつです。

    たとえば、スケーラビリティを左右する要素として、システムの結合方法や度合いが挙げられます。
    イベント駆動アーキテクチャはそれをうまく疎結合に処理します。
    その性能は拡大傾向にある開発組織にとって有益なものです。

    ただし、イベント駆動アーキテクチャを採用することは、それに携わってきていなかった開発者にとって、これまで経験したことがない観点の考慮事項を生み出します。

    そこで、本トークではアプリケーション刷新に伴い Spring Framework と Axon Framework を主軸としたイベント駆動アーキテクチャの導入を主導してきた経験を元に、イベント駆動アーキテクチャを採用する際に考慮すべき技術的課題やフレームワークに囚われない共通の落とし穴の避け方について解説します。
    また、そのうちフレームワークが解決してくれるものについてもお話します。

    なお、セッション中のサンプルは Spring Framework と Axon Framework を主体とします（もちろん、トークで触れる内容はそれ以外のフレームワークでも共通ですし、何かしらの回避手段はあるものです）。

    ◆お話すること
    ・イベント駆動アーキテクチャの基本
    ・イベント駆動アーキテクチャが解決する課題
    ・イベント駆動アーキテクチャの共通の落とし穴
    ・落とし穴に対する Spring Framework と Axon Framework による解法
    ・その他フレームワークにおける回避方法

    コンファレンスB
    日 17:15 - 18:00
    • Regular(45m)
    • Advanced
    • Java SE
    • Spring
    • Architecture

  • バッチを作らなきゃとなったときに考えること

    バッチを作るときに考えることを話します。
    「バッチ」と言っても案外認識が合わなかったりしますので、そのあたりから入り、WebAPIとバッチをならべてどのように棲み分けたり連携するかや、バッチを作るときに気をつけること、難しいところを整理してみます。
    なおこのセッションでは大規模なジョブネットのような話には踏み込みません。

    コンファレンスC
    日 17:15 - 18:00
    • Regular(45m)
    • Intermediate
    • Java SE
    • Architecture
Session and Speaker Management powered by Sessionize.com