• 仕様がそのままテストになる！Javaで始める振る舞い駆動開発

    振る舞い駆動開発（BDD）は、ソフトウェアの振る舞いを軸に仕様を記述し、それをそのまま自動テストとして活用する開発アプローチです。テストコードが仕様書の役割も果たすため、開発者とQAのあいだで認識のズレを防ぎやすくなります。

    本セッションでは、JavaでのBDD導入をテーマに、Cucumber-JVMとJUnit 5を用いた最小限の実装フローをデモを交えて紹介します。
    フィーチャーファイルを仕様書兼テストとして活用する方法、日本語記述のメリット、チームでの取り入れ方を20分でコンパクトに解説します。

    ## 想定対象者
    - BDDって聞いたことはあるけど、よく分からない方
    - テスト自動化に興味があるけど、まだ始められていない方
    - Javaでまずは簡単に試してみたい方

    ## 参加者が得られること
    - BDDの基本的な考え方を理解できる
    - 「仕様を書いたらそのままテストになる」という体験ができる
    - すぐに自分のプロジェクトで試せるヒントを持ち帰れる

    Room A+B
    土 10:00 - 10:20
    • Regular(20m)
    • Basic
    • Tools
    • Design
    • Test
    • Practice

  • 20年もののレガシーJavaプロダクトに自動テストを組み込んできた話

    運用20年を超えるJavaプロダクトに自動テスト（UnitTest、IntegrationTest、E2Eテスト）を組み込んできた経験をもとに、テストサイズごとのCI実行の実装例、実行タイミングの工夫、テストの前提データの管理運用など、テストアーキテクチャの具体的な実装方法と、組織文化醸成のために取り組んだことを話します。

    Room C+D
    土 10:00 - 10:45
    • Regular(45m)
    • Intermediate
    • Architecture
    • Modernization
    • Test

  • JEP 496 と JEP 497 から学ぶ耐量子計算機暗号入門

    耐量子計算機暗号（Post-Quantum Cryptography）とは、将来登場するであろう高性能な量子計算機による解読の脅威に耐えうる、新しい暗号技術の総称です。
    また、2025年3月に公開された Java 24 では追加された機能のうち、JEP 496 と JEP 497 はこの耐量子計算機暗号に関する機能追加です。

    今回のセッションでは、まずはじめに、現在広く使われている暗号技術（共通鍵暗号・公開鍵暗号、RSA暗号、楕円曲線暗号など）がどういったもので、どのように使われているのかといった基本的な話をします。
    そして、この 2 つの JEP を中心に耐量子計算機暗号について、なぜ必要になるのかや NIST の標準化、耐量子計算機暗号の仕組みなどについてエンジニアとして知っておきたい情報を紹介します。

    システム開発において即効性がある話ではないですが、近い将来に必要となるトピックなので、この話をきっかけに興味を持ってもらえると幸いです。

    【想定しているアジェンダ】
    ・現在広く使われている暗号技術のおさらい
    ・共通鍵暗号、公開鍵暗号の仕組みや技術（AES、RSA暗号、楕円曲線暗号など）
    ・JEP 496 と JEP 497 について
    ・それぞれの JEP についての概要や追加された機能について
    ・耐量子計算機暗号入門
    ・なぜ耐量子計算機暗号が必要なのか
    ・NIST の耐量子計算機暗号の標準化について（FIPS 203、FIPS 204）
    ・格子暗号を中心に耐量子計算機暗号の概要や仕組みの解説

    ※また、このトークでは Java 24 で追加された機能について触れますが、Java よりも暗号技術に焦点を当てて話します。

    Room E
    土 10:00 - 10:45
    • Regular(45m)
    • Basic
    • Java SE
    • Security

  • GraalVM Native Image トラブルシューティング機能の最新状況（2025年版）

    GraalVM Native Image は Java アプリケーションを高速スタートアップ＆ウォームアップ、低メモリフットプリントの特徴を持つネイティブイメージへ変換する機能で、コンテナワークロードやサーバーレスに最適な技術です。
    ただしネイティブイメージは OpenJDK の HotSpot VM ではなく独自の軽量な Substrate VM を使用します。
    そのため HotSpot VM では実現できていたことが Substrate VM ではできないということが多々あります。
    私たちは 2023 年にトラブルシューティングの観点で Native Image の解析方法についてご紹介させていただきました。
    この時はまだ GraalVM 21 環境での説明でしたが、今年９月に次の LTS 版である GraalVM 25 がリリースされ、Native Image も前回から多くのアップデートをしています。
    本セッションでは GraalVM 22-25 でアップデートされた Native Image のトラブルシューティング機能の最新状況についてご紹介いたします。

    Room F
    土 10:00 - 10:20
    • Regular(20m)
    • Intermediate
    • JVM
    • Tools
    • Observability

  • イベントストーミングのはじめかた

    近年、ドメイン駆動設計におけるモデリング手法として注目を集めているイベントストーミング。
    この手法は、ビジネスプロセスを可視化し、関係者間の認識を合わせる強力なツールとして、多くの組織で採用が進んでいます。
    しかし、「どこから始めればよいかわからない」「やってみたが期待した効果が得られなかった」という声も少なくありません。

    本セッションでは、これまで10を超える組織でイベントストーミングの導入支援を行ってきた実体験をもとに、ベターといえる「はじめかた」をお伝えします。
    その前提として、なぜイベントストーミングに着目すべきかについて、実利の観点からお話します。
    これはコミュニケーションのトピックから始まり、Java コードへの落とし込みや AI 活用に波及します。

    メインパートでは、小さく始めて成功体験を積む具体的なステップを詳しく解説し、業界や規模の異なる現場での経験を通じて得られた洞察を紹介します。
    また、準備から実施、フォローアップまでの具体的な手順を明日から使える実践Tipsとしてお伝えします。

    このセッションは、イベントストーミングに興味があるが始め方がわからないエンジニアやプロダクトマネージャー、試してみたが期待した効果が得られなかった方、組織にイベントストーミングを導入したいと考えているリーダー層、そしてドメイン駆動設計を実践したいチームの皆さんを対象としています。

    参加者の皆さんには、イベントストーミングを明日から始められる具体的な手順、段階的に拡大していくためのロードマップ、求められるコンピテンシーをお持ち帰りいただきます。
    このセッションを通じて、参加者の皆さんがイベントストーミングを自信を持って始められるようになることを目指します。

    Room G+H
    土 10:00 - 10:45
    • Regular(45m)
    • Basic
    • Design
    • Modeling
    • AI

  • Why not use Kotlin? — Kotlin for Java Developers

    Kotlinは、Javaと同じくJVM上で動作するプログラム言語です。Kotlinという言語はNull Safety、直感的なシンタックス、そのほか実務においても利点のある言語仕様が整っています。また、Javaのさまざまな言語機能と比較しても、有用な点があります。Javaとの相互運用が可能なため、少し注意点はあるものの段階的な移行も可能です。
    また、Kotlinは2024年に言語としてのメジャーバーションが2.0へとアップレードし、2025年5月にはSpringとJetBrainsの戦略的パートナーシップを結び、SpringにおけるKotlinの開発体験の向上が見込まれています。
    本セッションでは、Java開発者へ同じJVM言語であるKotlinの近年のエコシステムの成熟や言語の機能差分を整理し、Kotlinを採用するという選択肢を提供します。

    Room I
    土 10:00 - 10:20
    • Regular(20m)
    • Basic
    • JVM
    • Language
    • Others

  • 生成AI時代における「良いソースコード」の定義とリファクタリング実践

    近年、生成AIや大規模言語モデル（LLM）によるコード生成技術が急速に発展しており、エンジニアの役割は「コードを書く」から「生成されたコードの品質をレビューして改善する」へと変化しつつあります。
    レビューの観点として、仕様通りであることはもちろん、そのコードの品質を確認する必要があります。そのためには、生成されたコードの品質を評価する基準が必要です。
    そこで、本セッションでは、ソフトウェア品質の指標としてマーティン・ファウラー氏の「コードスメル」概念を紹介し、「良いソースコード」の定義を例示します。
    さらに、最新のLLMが生成したコードを対象に調査・分析し、人間が行うべきレビューやリファクタリングの必要性を検証します。

    Room J
    土 10:00 - 10:20
    • Regular(20m)
    • Basic
    • Language

  • 仕様は“書く”より“語る” - 分断を超えたチーム開発の実践

    設計チームと開発チームが分かれ、ドキュメントを通じて仕様を受け渡す。そんな体制は、初期リリースには効果的でした。
    しかし、背景や意図が共有されず、開発チームの自己組織化が進まないという課題に直面します。

    本セッションでは、体制を見直し、設計・仕様検討の段階から開発チームが関わるようになった実践を紹介します。
    リファインメントや仕様共有の取り組みを通じて「システム仕様を語る」文化を育てていったプロセスと、そこから得たチームの変化・学びを共有します。

    ■話すこと
    ・設計→開発の一方向体制とその課題
    ・自己組織化を阻害していた“情報の非対称”
    ・分断を解消するための取り組み（協働による仕様策定）
    ・対話や仕様会議による合意形成
    ・現場で得られた実践的な気づき

    ■話さないこと
    ・ドキュメントの書き方やフォーマットの詳細
    ・特定のツールや設計パターンの技術的な深掘り
    ・契約や組織制度など、業務外の制度的事情

    Room A+B
    土 10:25 - 10:45
    • Regular(20m)
    • Basic
    • DevOps
    • Others

  • Java プロセスのメモリ監視の落とし穴 ～NMT で見抜けない glibc キャッシュ問題～

    昨今のシステムのモダナイズにより Java アプリケーションをクラウドやコンテナ動作させることが増えてきました。
    このような環境ではより厳密なマシンリソース管理が求められるようになるでしょう。
    メモリに関していえば、アプリケーションの消費量を見積もって最適なサイズを割り当て、さらに実行中には OOM Killer を避けるために消費量を継続的に監視する必要があります。
    私たちもその様にしていましたが、ある時不思議なメモリリークらしき事象を確認しました。
    このリークは Java ヒープや非 Java ヒープではなく、Native Memory Tracking でも確認できませんでした。
    つまり JVM としてはリークが確認できないものの、Java プロセスとしてはメモリ消費が増加を続けているというものです。
    実際の所、これは JVM が利用する glibc の malloc のキャッシュが影響していました。
    本セッションではこの事例を観測した経緯、原因、対処方法について紹介いたします。

    Room F
    土 10:25 - 10:45
    • Regular(20m)
    • Intermediate
    • JVM
    • Tools
    • Observability

  • Java Virtual Thread / Kotlin Coroutine / Go Goroutineの比較

    Java, Kotlin, Go には、それぞれ並行処理を簡単に書くための仕組みがあります。

    ･ Java - Virtual Thread
    ･ Kotlin - Coroutine
    ･ Go - Goroutine

    どれも “軽量スレッド” と呼ばれる仕組みですが、動き方に少しずつ違いがあります。

    • Java Virtual Thread
    既存のブロッキング APIをそのまま使っても
    スレッドを自動で切り替えてくれるので、既存のコードをほぼ書き換えずに導入できます。

    • Kotlin Coroutine
    suspend funと付けた関数は、コンパイル時に状態マシンへ書き替えられます。
    実行時は「協調的」（自分で suspend した所だけで切り替え）に動きます。

    • Go Goroutine
    Go ランタイムがプリエンプティブ（強制的）に実行を切り替えるため、
    長い計算をしているコードがあっても他の処理が止まりにくいのが特徴です。

    このセッションでは、３言語でまったく同じ機能の Web サーバーを実装し、

    ・レスポンス速度
    ・CPU 使用率
    ・メモリ使用量

    を負荷テストで測定・比較します。

    結果を通じて

    各軽量スレッドの動く仕組み
    その違いがパフォーマンスにどう影響するか
    を分かりやすく解説します。

    「どの言語／方式を選ぶときに、何を気にしたらいいのか？」を一緒に整理しましょう。

    Room I
    土 10:25 - 10:45
    • Regular(20m)
    • Basic
    • JVM

  • 巨大ロジックをチームでコントロール可能にする ─ モブプロとテストで挑んだリファクタリング

    巨大なロジックが集中したサービスのメイン API。手を付けられず「暗黙知の塊」と化していたこの領域に対して、私たちはモブプロを通じてアプローチしました。まずは integration test を整備し、振る舞いを見える化。さらにテストコードに Why コメントを積み重ね、意思決定の背景を共有知へと変換していきました。その結果、安心してリファクタリングを進められる環境を整備し、トランザクション管理の導入まで実現しました。本セッションでは、その実践過程と学びを共有します。

    Room J
    土 10:25 - 10:45
    • Regular(20m)
    • Basic
    • Java SE
    • Spring
    • Test

  • バッチ性能!!劇的ビフォーアフター

    バッチ処理は、複数のデータや処理を一括で実行する方式であり、その設計では「性能効率性」が特に重要です。
    夜間等、限られた時間で大量データを処理するため、計画時間内の完了が必須です。
    遅延は翌営業日業務に影響し、ビジネスに深刻な打撃を与えかねません。
    バッチ処理の性能を向上する方法として、「処理の多重化」や「N件単位でのデータ出力」など多様な観点がありますが、その具体的な効果は不明瞭です。
    本発表では、特定の業務処理をベースに、方式変更やチューニングが性能に与える影響をについて具体的な数値を交えてお話します。

    Room A+B
    土 11:00 - 11:45
    • Sponsor(45m)
    • Intermediate
    • Spring
    • Others

  • 『次世代RDB劔“Tsurugi”のJDBC（を作った話）』（仮）

    劔"Tsurugi"（以下、Tsurugi）は2023/10/5にOSSとしてリリースされた新しいRDBMSです。
    TsurugiにJavaでアクセスするライブラリーとしてTsubakuro・Iceaxeがありますが、これらはJDBCではありません。
    JDBCを使いたい場合は、PostgreSQLのFDWの機能を利用してPostgreSQLのJDBCドライバーを使う方法があります。

    今回、PostgreSQLを使わずにTsurugiにアクセスするJDBCドライバーを開発しましたので、それを紹介します。

    Room E
    土 11:00 - 11:45
    • Sponsor(45m)
    • Intermediate
    • Java SE
    • Database

  • 開発と運用を楽にするSpring Boot on AWSテクニック集

    Spring BootアプリケーションをAWS上で開発・運用する際に、僕が実際に使っているテクニックをご紹介します。
    ・ログ（JSON化、バージョン情報、ログレベルの基準、通知など）
    ・Spring Sessionでのセッション共有
    ・Microsoft Entra IDとの連携
    ・Secrets ManagerからのJDBC接続情報の取得
    ・AWSサービス利用をローカルでテスト
    ・その他外部サービス利用をローカルでテスト
    ・@SpringBootTest・@WebMvcTest・@JdbcTest
    ・アプリケーションのコンテナ化
    ・リトライの使いどころ
    ・その他

    Room F
    土 11:00 - 11:45
    • Regular(45m)
    • Intermediate
    • Spring
    • Cloud

  • 毎年200人以上のJava初学者を受け入れるため、300ページ以上のテキストを内製している話

    シンプレクスの持株会社であるシンプレクス・ホールディングスでは、毎年200人以上の内定者・新卒社員を対象に、Javaを中心とした技術的基盤を身につけてもらう1年間の研修を実施しています。その中核となるのが、商業誌だけでは補いきれない研修のニーズに応えるために自作している内定者向けのJava学習テキストです。

    私自身は新卒でシンプレクスに入社し、技術者として金融機関向けのシステム開発に従事したのちに退職した後、いくつかの事業会社でエンジニアやエンジニアリングマネジャーを経験してきました。4年前よりシンプレクスに復帰し、内定者および新卒社員向けの研修を企画・運営してきています。この内定者向けJava学習テキストも、組版の仕組みを構築し、テキスト自体のコンセプトを考案して、毎年のバージョンアップを行ってきました。

    200人以上の初学者に読まれるテキストを書くのは、技術ブログなどを書くのとは違った緊張感があり、自分自身も Java の言語仕様や JEP を初めて真面目に読む経験をすることになりました。特に、Java 25 でついにやってきた JEP 512: Compact Source File and Instance Main Methods は、リリースを待たずにテキスト執筆を進める必要があるために読むことになり、実際のリリース後に答え合わせをすることになりました。 本セッションでは、自作テキストを制作するようになった経緯や背景、どのように学習体験を作り込み、コンテンツを設計しているのか、テキストを制作するようになったことで起きたことや自分自身の学びについてお話します。教育自体のみならず、Markdownでの原稿管理、Vivliostyleを活用したCSS組版、誤植対策のための自然言語の静的解析や継続的インテグレーションなど、テキスト制作における技術的な工夫もお話しするので、技術系の同人誌を作り始めようという方の参考にもなるのではないでしょうか。

    Room G+H
    土 11:00 - 11:45
    • Sponsor(45m)
    • Intermediate
    • Language
    • Career
    • Others

  • エラー処理の選択肢を増やす - try-catchから始めて段階的に型安全へ

    エラー処理、try-catchだけに頼っていませんか？
    「ひとまずtry-catchで囲む」「全部ログに出す」「nullが来たら...」こんな対症療法的なエラー処理を続けていると、コードは次第に見通しが悪くなり、バグの温床となっていきます。
    本セッションでは、現場でよく見かける「とりあえずtry-catch」から脱却し、体系的にエラーと向き合う方法を探求します。なぜチーム内でエラー処理の書き方がバラバラになるのか、どうすれば統一された設計ができるのか。実践的なアプローチと明確な判断基準をお伝えします。
    自信を持ってエラー処理を設計できるヒントを持ち帰ってもらえればと思います。

    Room I
    土 11:00 - 11:20
    • Regular(20m)
    • Basic
    • Architecture
    • Design

  • 膨大なデータをどうさばく？Java × MQで作るPub/Subアーキテクチャ

    データは待ってくれない。 広告システムなど膨大なイベントを“止めずに”処理し続けるには、設計×運用の両輪が要です。
    “止まらない”を設計×運用で、Java×MQによるPub/Sub基盤を題材に、ピーク時や障害発生時でも詰まりにくくするキー設計、適切な並列度の設計、再処理と冪等の勘所を整理し、運用の改善サイクル／再発防止策をご紹介します。さらに、Grafanaを用いて指標を相関的に可視化するダッシュボードの設計手法もあわせて解説します。

    Room J
    土 11:00 - 11:20
    • Regular(20m)
    • Intermediate
    • DevOps
    • Architecture
    • Observability

  • 小さくはじめるProperty Based Testing

    プログラマであればだれしもが、テスト時の考慮漏れによりバグを生み出したことがあるはずです。

    Property Based Testing（PBT）は、コードが満たすべき「性質」を検証する手法で、関数に対する入力値を自動生成し多様なケースを検証することで、バグを発見するのに役立つ特徴を持っています。
    また、副次的な効果として、性質を定義する過程で関数の責務や不変条件が明確になるなど、設計改善にも寄与します。

    本セッションでは、そういったPBTの特徴を解説しつつ、KotlinとKotestを使って既存のテストと共存させながら段階的にPBTを導入する方法を具体的なテストコードとともに紹介します。

    以下のようなトピックとなります
    - PBTの概念と特徴について説明
    - Example Based Testingとの比較
    - PBTのユースケースについて解説
    - Kotestを利用したPBTのサンプル提示

    Room I
    土 11:25 - 11:45
    • Regular(20m)
    • Basic
    • Methodology
    • Test

  • DDDとOOPの交差点 ～ エンティティと値オブジェクトから学ぶJava設計の実践知

    オブジェクト指向は長らく使われてきましたが、
    「クラスをどう分けるか」
    「継承かコンポジションか」
    「どこまでクラスを分けるべきか」
    「ビジネスロジックをどこに置くか」などなど
    設計に悩む場面は尽きません。
    マイクロサービスの発展からドメイン駆動設計 (DDD) が注目され、エンティティ／値オブジェクト／ドメインサービスといった概念は、オブジェクト指向設計の１つのトピックと言えます。

    本セッションでは、Javaコードを題材に、DDDの考え方がオブジェクト指向の設計をどうシンプルに、そしてチームで共有可能にするかを紹介します。
    「OOPやDDDを学んだけど、実務でどう活かせばいいかモヤモヤしている人」に、明日から試せるヒントを持ち帰っていただきたいと思います。

    Room J
    土 11:25 - 11:45
    • Regular(20m)
    • Basic
    • Java SE
    • Design
    • Modeling

  • 【ランチ付き】nullの10億ドルの過ちから未来へ：Spring Boot 4とJSpecifyが描くnull安全設計

    ウェルスナビ（WealthNavi）は"働く世代に豊かさを"というミッションのもと、長期運用を前提とした全自動資産運用サービスを提供しています。
    弊社では現在、Spring BootおよびJavaのバージョンアップを進めており、その一環として新たにリリースされるSpring Boot 4系の導入検証も行いました。
    この検証の中で特に注目したのが、nullness annotationにおけるJSpecifyの導入です。
    JSpecifyは、JVM言語における静的解析と言語間の相互運用性を高めることを目的とした、アノテーション仕様の標準化プロジェクトです。Javaにおけるnullの歴史を振り返りながら、Spring Boot 4とJSpecifyが描くこれからのnull安全設計についてご紹介します。

    Room C+D
    土 12:00 - 12:45
    • Sponsor(45m)
    • Basic
    • Spring
    • Tools

  • 【ランチ付き】AI機能実装で直面したパッケージ間のデータ構造の設計

    私達のプロジェクトでは、機能ごとにパッケージを分割して開発を進めています。基本的に各パッケージは独立しており、依存関係はパッケージ内で完結するよう設計されています。

    今回、AI関連の新機能開発において、「既存機能のデータをAI機能で利用する」という要件がありました。このような場合、以下の2つのアプローチが考えられます。

    1. 既存パッケージ内でAI機能が求めるデータ構造に変換する
    2. AI機能パッケージ内で必要なデータ構造に変換する

    本セッションでは、AI新機能の開発プロセスと、その過程で直面したパッケージ間のデータ構造の課題について共有します。実際の判断基準や、選択したアプローチから得られた知見をお話しします。

    Room E
    土 12:00 - 12:45
    • Sponsor(45m)
    • Basic
    • Java SE

  • 乱雑なコードの整理から学ぶ設計の初歩

    ソフトウェア設計の基本を、乱雑なコードの整理整頓を通して学ぶための、設計初学者向けのガイドです。

    ◎コードの整理整頓から設計を学ぶための三原則
    ・目の前の乱雑なコードを整理する
    ・before/afterを実感する
    ・繰り返して身体知にする

    ◎基本の「基」：コードの整頓
    ・使われていないコードの除去
    ・コードの集まりを明示する
    ・説明する
    ・メソッドに切り出す

    ◎基本の「本」：ロジックの整理
    ・値の演算をクラスに抽出する
    ・コレクションの操作をクラスに抽出する
    ・条件分岐をクラスに抽出する
    ・入り組んだ計算判断をクラスに抽出する

    Room A+B
    土 13:15 - 14:00
    • Regular(45m)
    • Basic
    • Methodology
    • Design
    • Modeling

  • Lazy Constant - finalフィールドの遅延初期化

    クラスのfinalフィールドの初期化はフィールドの宣言時もしくはコンストラクターで行います。しかし、初期化に時間がかかる場合、フィールドの初期化のためにオブジェクト生成が遅くなってしまいます。finalでないフィールドであれば、最初にアクセスする時までフィールドの初期化を遅延させることができますが、finalフィールドの場合はそれができませんでした。

    そこで提案されているのが、JEP 526: Lazy Constantsです。Java 25ではStable Valueとして提案されましたが、Java 26でLazy Constantに名称が変更されています。

    このLazy Constantを使用すれば、安全にfinalフィールドを遅延初期化することができます。本セッションではLazy Constantについて例を交えて解説します。また、関連してJEP 513 Flexible Constructor BodiesとJEP draft: Prepare to Make Final Mean Finalについても紹介します。

    Room C+D
    土 13:15 - 14:00
    • Regular(45m)
    • Advanced
    • Java SE
    • JVM
    • Language

  • native のその先へ！System.currentTimeMillis() の実装を見てみよう！

    System.java を見てみると、currentTimeMillis() の実装はこのようになっています。

    @IntrinsicCandidate
    public static native long currentTimeMillis();

    これだけ。native 修飾子がついており、その実装は Java では書かれていません。
    つまり、実装は不明……ではありません！

    このメソッドは native、つまり JVM 内に実装があるのです。
    このセッションでは、JVM 実装を追いかけてどのような実装になっているのかを見ていきます。

    （内容的に C++ のコードが少しでてきますが、簡単な内容にとどめますので、C++ を知らない方でも大丈夫です）

    Room E
    土 13:15 - 13:35
    • Regular(20m)
    • Intermediate
    • Java SE
    • JVM

  • Java OSSの脆弱性とその対策入門

    JavaやSpringなどのオープンソースソフトウェア（OSS）を活用したアプリケーションが影響を受ける脆弱性について、基礎からわかりやすく解説します。実際に公開されているExploitを取り上げ、どのように攻撃が成立するかを具体的に紹介しながら、開発者目線での理解を深めます。さらに、OSSの脆弱性検出ツールの基本的な活用方法、安全な実装のためのベストプラクティスについても取り上げ、日常の開発に役立つセキュリティ対策の第一歩となる内容をお届けします。

    Room F
    土 13:15 - 13:35
    • Regular(20m)
    • Basic
    • Java SE
    • Jakarta EE
    • Spring
    • Security

  • 間も無くリリース Spring Boot 4！

    11/20にリリース予定のSpring Boot 4及び、Spring Framework 7の注目ポイントを紹介します！

    Room G+H
    土 13:15 - 14:00
    • Regular(45m)
    • Intermediate
    • Spring

  • Agentic AIのアーキテクチャ設計とContext Engineering 〜 LangChain4jによるJava実装

    AIコーディングエージェントの盛り上がりを追い風に、視点を「使う」から「作る」へ移していきましょう。本セッションでは、Agenticに振る舞うAIの原理と設計をわかりやすく解説します。
    基本の自律動作である Plan-Act-Reflect、堅実さと自由度のトレードオフがあるワークフロー型／ピュア型の違い、そして最近注目の Context Engineering によるコンテキスト設計の要点を整理します。
    さらに、エージェント対応が強化された LangChain4j（Java向けLLMフレームワーク）を用い、Javaでの実装パターンを具体的に紹介します。
    「作り」の視点を学ぶことは、これからエージェントを「使う」際にもきっと役立ちます。

    対象者：
    ・Javaの設計手法の基礎を理解している方
    ・AIコーディングエージェントの利用経験がある方
    ・Agentic AIに関心があり、これから設計・実装に取り組みたい方

    このセッションで得られること：
    ・Agentic AIの全体像と主要コンポーネント
    ・Context Engineeringに基づく設計の勘所（短期/長期記憶、MCP/RAGによる外部連携、適切なコンテキスト付与 など）
    ・LangChain4jを使ったJava実装パターンと進め方

    Room I
    土 13:15 - 14:00
    • Regular(45m)
    • Intermediate
    • Architecture
    • Design
    • AI

  • ZOZOTOWNカート決済リプレイス ── モジュラモノリスという過渡期戦略

    ZOZOTOWNのカート決済システムを、VBScript/ASP から Java/SpringBoot へリプレイスするにあたり、私たちは「最初からマイクロサービス化」ではなく、「モジュラモノリスという過渡期戦略」を選択しました。
    20年以上蓄積された複雑なビジネスロジック、ドメイン境界の不明確さ、分散システム固有の複雑性。これらの制約を踏まえた上で下した、現実的な判断です。
    本セッションでは、アーキテクチャ選択の意思決定プロセス、モジュラモノリスの実装概要、そして運用して分かったメリット・デメリットを、実例ベースで共有します。

    【対象者】
    - レガシーシステムのJavaリプレイスや段階的なアーキテクチャ移行を検討中の方

    【得られるもの】
    - ZOZOにおける段階的リプレイスの判断プロセス
    - モジュラモノリスの構成概要
    - 運用から得たメリット・デメリット

    【扱わないこと】
    - コード詳細解説
    - マイクロサービス化の完全な達成事例（現在は過渡期）

    【推奨前提知識】
    - マイクロサービスアーキテクチャの概要
    - DDDの基本概念

    Room J
    土 13:15 - 13:35
    • Regular(20m)
    • Intermediate
    • Architecture

  • 【ワークショップ】IntelliJ IDEA予備校

    IntelliJ IDEAは使いこなせていますか？
    JJUG CCC 2025 Spring の調査では、78％のデベロッパ(無償版15.3%、有償版62.7%)が IntelliJ IDEAをメインの開発環境として利用していることが明らかになりました。IntelliJ IDEAを使いこなせるスキルはJavaデベロッパとしてもはや必要不可欠と言えるのではないでしょうか。

    プロジェクト内のあちこちのファイルを開くのにいちいちポインタを動かしていませんか？警告箇所にいちいちカーソルを移動して警告内容を確認していませんか？

    このワークショップではプロジェクト内をマウスカーソルをつかわずに縦横無尽に移動する便利ナーショートカットキーや、AI機能を使いこなすコツなど、IntelliJ IDEAをより効率的かつ快適に使いこなすためのテクニックを凝縮して紹介します。
    IDEをただのエディタとしてではなく「武器」として使いこなしたい方は是非ご参加ください。

    Room L
    土 13:15 - 15:00
    • Workshop(105m)
    • Basic
    • Tools

  • 「O(n log(n))のパフォーマンス」の意味がわかるようになろう

    突然ですが、java.util.ArraysのJavaDocを見てみましょう。sortメソッドの説明として、以下のような説明があります。

    > このアルゴリズムはすべてのデータ・セットに対してO(n log(n))のパフォーマンスを提供

    O(n log(n))ってなんでしょうか？実行速度の話をしているのだろうというのは想像がつきますが、どれくらいの速さなのでしょうか？

    このセッションでは、この一文の意味がわかるようになることを目指します。

    Room E
    土 13:40 - 14:00
    • Regular(20m)
    • Basic
    • Others

  • クラウドネイティブアプリケーションのセキュリティ戦略: Jakarta Security最新動向と実践的適用

    クラウドネイティブ環境やマイクロサービス、さらにはAIを含む分散システムなど、多様な通信が生じる昨今のエンタープライズシステムにおいて、システムセキュリティ確保は極めて重要な要件となっています。
    従来の社内ネットワークに閉じた分散システムではなく、ビジネスを加速するために社外のサービスとも連携したシステムを構築することが当たり前になっているいま、新たなセキュリティアーキテクチャに対応できなければ、ビジネスの機会損失や競争力低下に直面する可能性があります。

    Jakarta Securityは、Jakarta EEアプリケーションの認証・認可を統一した方法で管理するシンプルな手段を提供し、セキュリティ保護されたアプリケーションを効率的に開発することを目指したAPIです。
    最近のJakarta Securityのアップデートで、OpenID Connectが標準でサポートされたり、複数の認証機構を扱うためのAPIが整備されたりしたことで、モダンなセキュリティ対策を実現するための強力なツールとなっています。

    このセッションでは、クラウドネイティブアプリケーションに求められるセキュリティ対策について紹介しつつ、モダンなアプリケーション開発におけるJakarta Securityの実践的な適用方法を解説します。
    また、Jakarta EEのセキュリティに関する最新動向や、MicroProfile JWTとの関係についてもキャッチアップし、これからのクラウドネイティブアプリケーション開発に役立つ視点を提供します。

    Room F
    土 13:40 - 14:00
    • Regular(20m)
    • Intermediate
    • Jakarta EE
    • Micro Profile
    • Cloud
    • Security

  • Axon Frameworkのイベントストアを独自拡張した話

    Axon Framework はJavaにおけるCQRS/ESの主要フレームワークの一つです。
    本セッションでは、Axon Frameworkのイベント永続化層を拡張し、Amazon DynamoDB をイベントストアとして用い、DynamoDBのサービスとしての高い同時実行耐性（水平スケール）とDynamoDB /Kinesis Data StreamsによるCDCでイベントストアとイベントバスとの一貫性を担保する方法を解説します。

    本セッションを通じて持ち帰れること
    - AWS上でDynamoDBをイベントストアとして Axon Framework によりCQRS/ESを実現するアーキテクチャ事例
    - Axon Frameworkのイベント永続化層であるEventStorageEngineを独自拡張してDynamoDBをイベントストアとして扱う事例

    Room J
    土 13:40 - 14:00
    • Regular(20m)
    • Intermediate
    • Spring
    • Cloud
    • Architecture
    • Database

  • Java＋PGPで実現するセキュアなファイル連携

    JavaでPGPによるファイル署名・暗号化を実装するに至った経緯と、具体的な実装方法、ポイントについてご紹介いたします。

    Room A+B
    土 14:15 - 15:00
    • Sponsor(45m)
    • Basic
    • Java SE
    • Spring
    • Security

  • Devinが変えるエンプラ開発 ― 工数50％削減のリアル

    生成AIエージェント「Devin」を導入した結果、
    私たちのエンプラ開発は“半分の時間で終わる”チームに変わりました。
    本セッションでは、Devinをどう開発プロセスに組み込み、
    どこでつまずき、どこで一気に生産性が跳ねたのかをリアルに共有します。
    「AIがコードを書く」だけじゃない――
    “AIと共に開発する”時代の実践ノウハウを、余すところなくお届けします。

    Room C+D
    土 14:15 - 15:00
    • Sponsor(45m)
    • Basic
    • AI

  • 内製化組織の歩みとこれからの課題。-技術アーキテクチャと組織アーキテクチャ-

    本気のエンジニアリングチームを作る、という決意のもと、大企業/金融というフィールドでプログラマー集団として
    自分たちでアーキテクチャを選択し、DXへの貢献を目指して走ってきました。
    これまで構築してきたシステムを概観するとともに、組織の大規模化に伴って、さまざまな課題があり、共通プラットフォームや分業、プロセスなどの必要性も見えてきました。
    一方で、硬直した組織は技術的挑戦を難しくしたり、「インフラのことは知らない」のような官僚主義的な文化が生まれる恐れもあります。
    これらに対して私たちはどのように解決しようとしているのか、現時点での考え方を共有したいと思います。

    Room E
    土 14:15 - 15:00
    • Sponsor(45m)
    • Basic
    • Architecture

  • はじめての OSS コントリビューション 〜小さな PR が世界を変える〜

    オープンソースソフトウェア (OSS) の開発には、専業の開発者から、複数のベンダに所属するエンジニア、そして個人の興味や学習の一環として参加する開発者まで、さまざまな立場の人が関わっています。
    OSS への貢献方法は幅広く、ドキュメントの整備、新機能の追加、バグ修正、開発環境の改善など多岐にわたります。

    このセッションでは OpenJDK と Quarkus を具体例として取り上げ、実際に行った Pull Request の事例を交えながら、OSS 開発に参加するためのプロセスを紹介します。OSS 初心者が一歩を踏み出す際に抱きがちな「準備が大変そう」「どうやって関わればよいのか分からない」といった不安を解消することを狙いとしています。

    Room F
    土 14:15 - 15:00
    • Regular(45m)
    • Basic
    • Community

  • AI駆動開発の最前線：GitHub Copilot Agent Mode と Coding Agent で実現する高速マイクロサービス開発

    AIを活用したアプリケーション開発は、今後ますます重要性を増していくと考えられています。
    本セッションでは、GitHub CopilotのAgent ModeやCoding Agentを用いた実践的な開発手法を、登壇者のリアルな経験をもとに解説します。
    エンタープライズグレードのマイクロサービスを短期間で実装するためのアプローチや、AIツールを最大限に活用するためのベストプラクティスを実践編として一歩踏み込んだ内容をお届けします。

    Room G+H
    土 14:15 - 15:00
    • Sponsor(45m)
    • Intermediate
    • Tools
    • Architecture
    • AI
    • Practice

  • Quarkusで作るInteractive Stream Application

    Kafkaを用いたストリームアプリケーションにWebインターフェースを組み合わせることで、大規模なデータと扱いながら、高いスループットと低レイテンシを両立するマイクロサービスを構築することができます。

    このトークでは、Kafka StreamsフレームワークとQuarkusフレームワークを組み合わせることで、イベント駆動型のマイクロサービスアーキテクチャと親和性の高いインタラクティブなストリームアプリケーションを簡単に構築することができることを解説し、実際の開発現場でどの様に活用しているか、その利点についてご紹介します。

    Room I
    土 14:15 - 14:35
    • Regular(20m)
    • Intermediate
    • Jakarta EE
    • Architecture

  • Spring Boot バリデーション実践入門 - 例外処理からエラーメッセージまで

    Spring Boot で業務アプリを開発する際に欠かせないのが入力値のバリデーションです。
    本セッションでは、 Spring Boot のバリデーション機能の基本的な使い方から、カスタムバリデーション、例外処理、エラーメッセージの取り扱いまで、サンプルコードを交えながら解説します。
    これから Spring Boot を使い始める方、あるいは「バリデーション定義はしたことあるけど、エラーハンドリングの仕組みは有識者に任せていた」という状態から一歩先に進みたい方に役立つ内容をお届けします。

    Room J
    土 14:15 - 14:35
    • Regular(20m)
    • Basic
    • Spring

  • Tomcatが起動しない!? Java SecureRandomと乱数デバイスの罠～LinuxとWindowsで異なる挙動と、Javaでの正しい選択～

    Linux上でJavaアプリケーションを運用していたある日、Tomcatの起動が異常に遅くなりました。
    原因は「乱数生成器」でした。

    JavaのSecureRandomは、OSの乱数デバイスや内部実装を利用して動作します。
    特にLinuxでは、カーネルの/dev/randomと/dev/urandomの扱いによって、エントロピー不足時にブロックが発生し、
    アプリケーションの起動が数分間止まることがあります。
    一方でWindowsでは、OSのCSPRNG APIを利用しているため、この問題は発生しません。

    さらにJavaには複数のSecureRandomプロバイダがあり、選択によって挙動が大きく変わります。
    ・NativePRNGBlocking → /dev/random依存でブロックリスク大
    ・NativePRNGNonBlocking → /dev/urandom利用で安定
    ・DRBG (JDK9+) → NIST準拠でセキュアかつノンブロッキング

    本セッションでは、
    ・JavaとOS乱数生成の違い
    ・実際に遭遇した「Tomcat起動遅延」の事例（Linux）
    ・Windows環境では問題が起きない理由
    ・SecureRandomの実装ごとの違いと選び方
    ・運用者が取るべき具体的な回避策（オプション設定・DRBG活用など）

    を20分でわかりやすく解説します。

    乱数生成と聞くと難しく思われがちですが、
    実務で起こる「Tomcatが起動しない!?」という
    直感的にわかりやすいトラブルを起点に、
    Javaエンジニアが知っておくべき乱数生成の仕組みと運用ノウハウをお持ち帰りいただけます。

    Room I
    土 14:40 - 15:00
    • Regular(20m)
    • Intermediate
    • Java SE
    • JVM
    • Tools
    • Architecture

  • 速習 Spring AI - Gemini CLIを自作しよう -

    今年5月にSpring AIがGAになりました。
    多くのSpringユーザーにってLLMの導入を考えるとき、Spring AIは有効な選択肢のひとつです。既存のSpringプロダクトに簡単にLLMを導入できるからです。
    くわえて、各LLMは日々改善されるため、特定のLLMに特化して実装することには不安がありますが、Spring AIが抽象化レイヤーを提供するためこの問題を解消できます。

    本セッションではSpring AIの一通りの基本機能についてデモを交えて解説を行います。
    サンプルアプリとしてSpring AIを使ってGemini CLIのようなLLM CLIツールを自作しました。複数のLLMを切り替えたり、LLMが特定のメソッドやクラスをツールとして利用しタスクを実行したりする機能を紹介しながら、Spring AIでどういった機能が実現できるのか確認できます。
    また、Spring AIの主なユースケースになるであろう、既存のSpringプロダクトをMCPサーバー化する方法についても紹介します。

    対象者: LLMを使ったアプリケーションの実装に興味がある方、Spring AIをさくっとキャッチアップしたい方

    Room J
    土 14:40 - 15:00
    • Regular(20m)
    • Basic
    • Spring
    • AI

  • レガシーで硬直したテーブル設計から変更容易で柔軟なテーブル設計にする

    データベース設計に日々苦悩されているバックエンドエンジニアに向けて、約10年間の実践で培ったリアクティブで柔軟なテーブル設計手法について紹介します。

    従来の設計では更新日付の管理、カラムの数、複雑な外部キー制約、論理削除による性能劣化などの課題が頻発しています。本セッションでは、これらの問題を根本から解決する「データを追加しやすく、ピボットしやすく、メンテナンス性が高く、性能が劣化しにくい」柔軟で変更容易性に優れたテーブル設計の指針を提示します。

    具体的には、イミュータブルレコードモデル(仮称)の定義とルール、レガシー設計からの段階的移行手順、並行稼働時の注意点、パフォーマンス改善効果を提示します。

    Room A+B
    土 15:30 - 16:15
    • Regular(45m)
    • Intermediate
    • Spring
    • Architecture
    • Database
    • Modeling
    • Modernization

  • 実践AI駆動開発～プロンプトエンジニアからAIアーキテクトへ～

    社会実装という意味では、LLMがどれだけのポテンシャルを持っているのかはまだ分かりません。
    しかし、ソフトウェア開発においては、現時点で私たちが利用可能な生成AIが、このまま一切進歩しなかったとしても既に無視できないだけの能力を持っています。

    このセッションでは、生成AIをブラックボックスとして扱いながら、ソースコードを一切手書きすることなくRustで実装したJDKのバージョンマネージャであるkopiを紹介します。

    私たちソフトウェアエンジニアが蓄積してきた開発手法の多くを高度に適用することで、生成AIからの不安定な出力を安定的で高品質なものだけに絞り込めるという事を、kopiの事例を元に皆さんに共有します。

    Room C+D
    土 15:30 - 16:15
    • Regular(45m)
    • Advanced
    • Tools
    • Methodology
    • AI

  • FFMの実装から学ぶJavaのインテグリティ

    AI利用の高まりからJavaにおけるネイティブコードラッパーの位置づけ見直しの期待もあり、FFM(JEP454:Foreign Function & Memory API)は、メモリ破壊の危険性など問題のあったJNI(や類似機能)の代替技術としてJava SE 22で正式リリースされました。
    FFMはネイティブコードを用いずpure JavaでJava外部の世界を記述したり操作でき、一見、安全性が高まったように見えます。
    本セッションでは、FFMの特徴の中でも特にその安全性についてJDKコアライブラリやHotSpotの実装を参照し実現方法を解説し、
    はたしてどこまで安全なのか、その安全性を担保するためにユーザはFFMを使う上で何をしなければならないのかを考察します。
    また、最近のJavaでは、JEP472(Prepare to Restrict the Use of JNI)やJEP451(Prepare to Disallow the Dynamic Loading of Agents)などの危険機能の制約がすすめられています。
    その背景には、インテグリティという考え方があり、これによりJavaがC言語などに比べて言語的に安全性を高められていますが、
    Javaにおけるインテグリティとは何か、なぜ今着目されるているのか、FFMやその他のJava機能はどのようにインテグリティを実現するのかJDK実装をベースに解説し、現代の複雑なJavaエコシステムでの安全性について考察します。

    Room E
    土 15:30 - 16:15
    • Regular(45m)
    • Advanced
    • Java SE
    • JVM
    • Language
    • Security

  • GraalVM Update - 2025 edition

    GraalVMは、JVM上で動作するアプリケーションのパフォーマンスを向上させるための新しいJITコンパイラ（Graalコンパイラ）を開発する研究プロジェクトとして、2011年にOracle Lasでスタートしました。オープンソースとして開発が進められています。

    このセッションでは、2025年10月に開催されたGraalVM Community Summitでの発表を基に、以下の内容でお届けします。
    - GraalVMの現在地
    - 今後の進化の方向性、現在研究・開発中の機能
    - GraalVMコミュニティの最新動向

    GraalVMの現在および未来に関する発表は国内ではほとんどないので、最新情報を把握する良い機会になるかと思います。

    Room F
    土 15:30 - 16:15
    • Regular(45m)
    • Basic
    • JVM
    • Language
    • Community

  • アーキテクチャと考える迷子にならない開発者テスト

    Javaを使った開発で「どのようにテストしたらいいか」「どんな道具を使えばよいか」で迷うことは少なくありません。
    本セッションではよくあるWebアプリケーションを題材に、アプリケーションアーキテクチャを切り口として「どこで何をテストできるか」を整理し、どのような性質があればどんなテストが合っているかのパターンを提示します。そのまま踏襲すれば完璧！というものではありませんが、日々の開発でテストを考える指針となる経験則をお伝えします。
    対象はアプリケーション開発者で、主にローカル開発環境で実施する機能テストをスコープとしています。
    具体例にはSpringBootを採用します。馴染みのある人にはよりわかりやすいかと思いますが、SpringBootでしか通用しないような話でもないのでご安心ください。

    Room G+H
    土 15:30 - 16:15
    • Regular(45m)
    • Intermediate
    • Spring
    • Architecture
    • Design
    • Modeling
    • Test

  • "おまじない"はもう卒業！デバッガで探るSpring Bootの裏側と「学び方」の学び方

    Spring Bootを使い始めて数年、「次に何を学べばいいんだろう？」と感じていませんか？便利なアノテーションの裏側で何が起きているか分からず、まるで"おまじない"のように感じてしまう...。このセッションは、そんな「中級者の壁」を感じている、あなたのためのものです。

    本セッションでは、「ググっても答えが出ない」問題に直面した実体験を元に、IDEのデバッガを武器にフレームワークの内部を探り、解決の糸口を見つけ出す、一連の学習プロセスをお届けします。

    セッション後、あなたはSpring Bootが決して魔法の箱ではないことを知るでしょう。明日からあなたの「学び方」が変わる、具体的なヒントを持ち帰ってください。

    Room I
    土 15:30 - 15:50
    • Regular(20m)
    • Intermediate
    • Spring
    • Tools
    • Methodology

  • ユニットテストが難しいプロダクトコードになぜなるか？と工夫例

    テストコードを書こうとはよくいうものの、いざ書こうとするとモックをいっぱい使ったりして、テストを書くのもメンテも難しいプロダクトコードになってしまってることありませんか？
    ウォーターフォールにありがちなネストが深い模擬設計書とそのプロダクトコードを元にどうしてテストが難しくなってしてしまうのか？を解説します。その後、これらを踏まえて、仕様書が同じでも、テストしやすくする実装の工夫をご紹介します。

    Room J
    土 15:30 - 15:50
    • Regular(20m)
    • Basic
    • Test
    • Practice

  • 【ワークショップ】手を動かしながら学ぶデータモデリング - 論理設計から物理設計まで

    ソフトウェア開発にデータモデリングは欠かせません。
    しかし、意外とちゃんと学ぶ機会がないまま来てませんか？

    実際の現場では過去に見てきたテーブル設計を参考にしてとりあえず作る。ということが多いのではないでしょうか？
    そんな人たちに一度ちゃんと0からデータモデリングを経験してみませんか？
    今回の『駐車場』をテーマにデータモデリングを行っていきます。

    Room L
    土 15:30 - 17:15
    • Workshop(105m)
    • Basic
    • Database

  • Spring Boot利用を前提としたJavaライブラリの開発方法の提案

    昨今のJavaアプリケーションにおけるWebフレームワークのデファクトスタンダードはSpring Bootと考えています。複数のプロジェクトで開発を進める際、各チームが業務領域の実装に集中できるよう、DBへのI/O、認証・認可、HTTPクライアントなどの横断的関心事をライブラリjarとして切り出すことで、管理の効率化と品質向上を実現できます。
    Spring Boot上で動作するライブラリを開発する際は、Auto Configurationなどの仕組みを効果的に活用することが重要です。また、技術的な実装だけでなく、継続的にエンハンスするための体制づくりも欠かせません。ドメイン（業務ロジック）に関わらず、技術的難易度が高く再利用性がある機能に限定してライブラリ化すべきと考えています。
    本セッションでは、機能選定、ドキュメント整理、マイルストーン策定、テストスコープ整理、サンプルアプリケーション作成の観点から、ライブラリ開発のTIPSを提供します。複数プロジェクトの生産性向上を目指すエンジニアの皆様に実践的なヒントをお伝えします。
    ◾️このセッションで学べること:
    ・複数プロジェクトで共通利用するライブラリの設計手法
    ・Spring Boot AutoConfigurationを活用したライブラリ開発
    ・PostgreSQL unnestによる高速バルクインサート実装
    ・ライブラリ化すべき機能の見極め方
    ・ライブラリ開発におけるテスト戦略の考え方

    ◾️想定するオーディエンス:
    ・複数のSpring Bootプロジェクトを運営している方
    ・チーム間の技術的な重複を解消したい方
    ・Spring Bootを使ったことがある方

    Room I
    土 15:55 - 16:15
    • Regular(20m)
    • Intermediate
    • Java SE
    • Spring
    • Cloud
    • Database
    • Practice

  • Testcontainers の Reusable Containers を使った、リポジトリテストの高速化

    DB 使用したリポジトリの単体テスト (UT) では、テストで DB をどのように扱うかが課題となります。現在では、組み込みの H2 Database を利用した UT、あるいは Testcontainers を利用したUT が有力なアプローチと言えますが、それぞれにメリット、デメリットがあります。H2 Database を利用したアプローチでは、テストの実行時間は非常に高速であるものの、DB 製品の再現性に懸念
    があり、UT では問題なかったが、実際に DB を使用した結合テスト、あるいはシステムテスト時に問題が発生するケースがあります。一方で、Testcontainers を利用したアプローチでは、実際に
    DB 製品のコンテナを利用するため、DB 製品の再現性は非常に高い一方で、コンテナの起動、停止の処理が加わるため、テストの実行時間に課題があります。

    本セッションでは、Experimental な機能ではありますが、Testcontainers の Reusable Containers の機能について紹介します。サンプルコードを元に利用方法について解説し、コンテナを使い回すことによって、テストの実行時間と DB 製品の再現性を両立する方法について紹介します。

    Room J
    土 15:55 - 16:15
    • Regular(20m)
    • Basic
    • Database
    • Test

  • ニューレガシー徹底抗戦ガイド

    レガシーシステムをモダナイズするも、EOLなdependenciesを置き換えるだけで、テスタビリティも保守性も別に向上していないプロジェクトが多くあります。開発環境やコードの雰囲気は現代的になっても、実際に現場でメンテする人にとっては明確なメリットがなく、リリース直後から難解なコードに悩まされ影響調査にかかる時間も以前と変わらぬまま。なんてプロジェクトをこれ以上生まないために、私はこれを"ニューレガシー"と呼び、設計・開発プランを練り込まない限りニューレガシーの重力に負けてしまうことを、広く伝えていきたいと考えました。

    ニューレガシーに陥るメカニズムを分析するとともに、ニューレガシーを作らないための設計および開発プロセスをご紹介します。抽象的な話にとどまらず、できる限りJavaのコードレベルでニューレガシーあるあるパターンと回避方法をお話しします。

    レガシーマイグレーションを予定している方だけでなく、リアーキテクチャや新規開発案件にたずさわる方でも、費用対効果を最大化したいと考えている方は是非ご参加ください。

    Room A+B
    土 16:30 - 17:15
    • Regular(45m)
    • Intermediate
    • Architecture
    • Modernization

  • AIエージェントでのJava開発がはかどるMCPをAIを使って開発してみた

    AIエージェントなどと連携する仕組みとしてMCPが話題です。
    AIコーディングエージェントでも、MCPで言語情報を与えると効率化することが知られています。
    このセッションでは、Javaのimport補完やMaven Dependencyの操作などJavaの開発をサポートするMCPを作ってみた過程で気付いた、どのようにAIコーディングを使うか、どのようにAIアプリをテストするか、開発時にどのモデルを使うかといった気付きを共有します。

    Room C+D
    土 16:30 - 17:15
    • Regular(45m)
    • Intermediate
    • Java SE
    • Tools
    • AI

  • しっかり学ぶ java.lang.*

    中級へのステップアップとして java.lang パッケージにある基礎的なクラスをもとに言語機能や言語仕様について学びます。
    java.lang パッケージは importなしで参照できるJava言語のもっとも基本的なクラス群で、Javaのプログラムを書いている人は意識せずとも利用しているはずです。例えば System.out.println() といったように。
    これらのクラス群の機能を基礎からしっかり学びましょう。

    ・基本データ型、ラッパークラス類
    ・Classやリフレクション関連、ClassLoader
    ・AutoCloseable, Iterable など言語機能に関わるもの
    ・System, Runtime, Process
    ・例外関連
    ・Thread関連
    ・アノテーション
    ・java.langのサブパッケージについて

    Room G+H
    土 16:30 - 17:15
    • Regular(45m)
    • Intermediate
    • Java SE
    • Language

  • バーチャルスレッドは実アプリでどこまで使えるか〜コンテナ環境での効果検証でわかった注意事項〜

    Java 21 で導入されたバーチャルスレッドは、IO バウンドな処理の多い Web アプリケーションでのパフォーマンス向上が期待されています。しかし、単純に有効化するだけで本当にメリットが得られるのでしょうか？

    本セッションでは、同一のアプリケーションを、プラットフォームスレッド、バーチャルスレッド、WebFlux の 3 パターンで実装し、コンテナ環境での負荷テストの結果を詳しく比較します。

    「バーチャルスレッドを使えば万事解決」という単純な話ではなく、バーチャルスレッド化による新たに顕在化するボトルネック、エラーの増加といった注意点、WebFlux との性能差など、実導入で直面する現実的な課題について、具体的な検証データとともにお話しします。

    バーチャルスレッドの導入を検討している方に、実践的な判断材料を提供します。

    Room J
    土 16:30 - 16:50
    • Regular(20m)
    • Intermediate
    • Java SE
    • Spring
    • JVM

  • Virtual Thread Deep Dive

    Java 21で正式導入されたVirtual Threadは、大量の並行処理を効率的に扱う強力な仕組みです。本セッションでは、Virtual Threadの基本的な仕組みから、従来のPlatform Threadとの違い、アンマウントとスケジューリングの仕組みを解説します。さらに、synchronizedを利用した際に発生していたPinning問題と、その解決を目的としてJDK 24 で導入されたJEP 491における改善点を取り上げます。改善点だけでなく、依然として残る制約や課題についても触れ、Virtual Threadを現場で安全に使うための実践的な知識を提供します。

    Room J
    土 16:55 - 17:15
    • Regular(20m)
    • Intermediate
    • JVM
    • Language
    • Modernization
    • Practice
Session and Speaker Management powered by Sessionize.com