タグ別アーカイブ: Java

MicroProfile 3.0 Support Comes to Helidon

このエントリは以下のエントリをベースにしています。
This entry is based on the following one written by Dmitry Kornilov (Eclipse EE4J PMC member, Jakarta EE contributor, JCP star spec lead, Helidon Project lead, Oracle).
https://dmitrykornilov.net/2019/09/14/microprofile-3-0-support-comes-to-helidon/
https://medium.com/oracledevs/microprofile-3-0-support-comes-to-helidon-f72ba752b42f

Helidonの新しいバージョン、1.3が出ました。このリリースの主要機能は、MicroProfile 3.0のサポートですが、その他にも機能追加や不具合の修正、パフォーマンス改善などが含まれています。詳しく見ていきましょう。

MicroProfile 3.0

約1ヵ月前にMicroProfile 2.2をサポートしたHelidon 1.2をリリースしました。その後さらに作業を進めて、Helidon 1.3でMicroProfile 3.0のサポートをするようにいたしました。

ご存じない方のために、MicroProfileとはクラウドネイティブJavaのためのAPI群です。

Eclipse MicroProfile
https://microprofile.io/

多くのモダンなJavaベンダー(Oracle、IBM、Red Hat、Payara、Tomitribeなど)がMicroProfileをサポートしており、この領域におけるデファクトスタンダードになっています。Helidon MicroProfile実装はHelidon MPと呼ばれ、リアクティブやノンブロッキングフレームワークのHelidon SEと共にHelidonのコアをなしています。

MicroProfile 3.0はメジャーリリースで、これには以下のアップデートが含まれています。

  • 後方互換性を担保しない変更あり
    • Metrics 2.0
  • 小規模なアップデート
    • HealthCheck 2.0
    • Rest Client 1.3

MicroProfile 3.0はMicroProfile 2.2に対する後方互換性がありませんが、Helidonには後方非互換性を持ち込みたくありませんでした。Helidon 1.3ではMicroProfile 2.2とMicroprofile 3.0の両方をサポートします。Helidon MPアプリケーションは以下のバンドルによってMicroProfileのバージョンを選択できます。

MicroProfile 2.2互換にしたい場合

<dependency>
    <groupId>io.helidon.microprofile.bundles</groupId>    
    <artifactId>helidon-microprofile-2.2</artifactId>
</dependency>

MicroProfile 3.0互換にしたい場合

<dependency>
    <groupId>io.helidon.microprofile.bundles</groupId
    <artifactId>helidon-microprofile-3.0</artifactId>
</dependency>

MicroProfile 2.2への後方互換性はhelidon-microprofile-2.2に依存する既存の全てのHelidonアプリケーションが変更せずに継続して動作することを意図しています。Helidon 1.3の最新のarchetypeを使って作成した新規アプリケーションはhelidon-microprofile-3.0に依存します。

Metrics 2.0 Support

前述の通り、MicroProfile Metrics 2.0では後方非互換の変更だけでなく、数多くの新機能も導入されています。以下はその変更をまとめたものです。

  • 既存のカウンタを常にモノトニック(monotonic)なものに制限
  • concurrent gaugeと呼ばれる新たなメトリックをサポート
  • タグはMetadataではなくMetricIDTagsの一部になった
  • Metadataはイミュータブル
  • JSONフォーマットに小規模な変更
  • PrometheusフォーマットはOpenMetricsフォーマットに(いくつかの小規模なアップデートを含む)

詳細は以下のURLをご覧ください。

MicroProfile Metrics 2.0.1
https://github.com/eclipse/microprofile-metrics/releases/tag/2.0.1

Note: MetricRegistryクラスには、破壊的なシグネチャの変更が入っており、getterメソッドの中には、キーがStringではなくMetricID型であるマップを返すようになったものがあります。MicroProfile Metrics 2.0の最新バージョンにアップグレードするアプリケーションは、これらの使用法を確認して正しいタイプが渡されることを確認し、メトリック検索の失敗を防ぐ必要があります。

Helidon SEアプリケーションでメトリクスを使っている場合も、Helidon 1.3の新機能を活用できます。例えば、MicroProfile 2.0で導入されたconcurrent gaugeの概念はHelidon SEでも利用できます。これらの新機能を使うためには、Helidon SEアプリケーションは以下の依存関係を設定しておく必要があります。

<dependency>
    <groupId>io.helidon.metrics</groupId>
    <artifactId>helidon-metrics2</artifactId>
</dependency>

既存のHelidon SEアプリケーションは引き続き旧来のhelidon-metricsを依存関係として利用できます。

HealthCheck 2.0 Support

HealthCheck 2.0には重要な変更が含まれています。Health checkレスポンスのメッセージ本体が変更され、outcomestatestatusに置き換えられました。 また、readiness (/health/ready) と liveness (/health/live) の両エンドポイントがKubernetesとのスムーズな統合のために導入されました。

これまでの /health エンドポイントは削除されていませんので、既存のアプリケーションは変更しなくてもそのまま動作します。

新たな仕様により、2個の注釈(@Liveness@Readiness)が導入されています。Helidon SEで、2個の対応するメソッド(addReadinessaddReadiness)が導入され、これまでのメソッドaddは廃止されました。

JPA and JTA are Production Ready

Helidonの初期バージョンでJPAとJTAとの統合の早期アクセスバージョンを導入しました。ユーザーからのフィードバックを受けて、問題を修正してパフォーマンスを改善しました。Helidon 1.3ではJPAとJTAのサポートを早期アクセスからProduction Readyに移行しました。

この機能を理解するのに有用なガイドも作成しました。

Guides — Using JPA in Helidon MP
https://helidon.io/docs/latest/index.html#/guides/24_jpa

Hibernate Support

Helidon 1.3ではJPAプロバイダとしてHiberneteを利用できるようになりました。引き続きEclipseLinkを利用することもできます。どちらを選択するかはあなた次第です。依存関係の違いは以下の通りです。

EclipseLinkの場合

<dependency>
    <groupId>io.helidon.integrations.cdi</groupId
    <artifactId>helidon-integrations-cdi-eclipselink</artifactId
    <scope>runtime</scope>
</dependency>

Hibernateの場合

<dependency>
    <groupId>io.helidon.integrations.cdi</groupId
    <artifactId>helidon-integrations-cdi-hibernate</artifactId
    <scope>runtime</scope>
</dependency>

EclipseLinkのサポートと同様に、HelidonのHibernate JPA統合は、EJBを使わない拡張された永続コンテキスト、JTAトランザクション、Bean Validationのサポートを含む、Java EEモードとの完全な互換性を備えています。これは、慣れ親しんだアプリケーションサーバーと同じように機能しますが、Helidonの軽量なMicroProfile環境内で機能します。

GraalVM Improvements

GraalVMのサポートは目的の一つです。各リリースでHelidon SEにおけるGraalVMのサポートを継続的に改善しています。このバージョンではGraalVM 19.2.0をサポートしています。また、JerseyクライアントをHelidon SEアプリケーションで利用でき、ネイティブイメージにすることもできます。

以下はサンプルコードです。

private void outbound(ServerRequest request, ServerResponse response) {
    // and reactive jersey client call
    webTarget.request()
        .rx()
        .get(String.class)
        .thenAccept(response::send)
        .exceptionally(throwable -> {
            // process exception
            response.status(Http.Status.INTERNAL_SERVER_ERROR_500);
            response.send("Failed with: " + throwable);
            return null;
    });
}

Helidon SE applicationからGraalVMネイティブイメージを生成する方法を説明するガイドを追加しましたので、是非チェックしてください。

Guides — GraalVM Native Images
https://helidon.io/docs/latest/#/guides/36_graalnative

New Guides

Helidonを使う上で有用な、さまざまなHelidon機能の使用方法を説明する新しいガイドを多数追加しました。

Guides — Overview
https://helidon.io/docs/latest/index.html#/guides/01_overview

Getting Started

Basics

Persistence

Build and Deploy

Tutorial

Other features

このリリースには多数の不具合修正、パフォーマンス改善やマイナーアップデートが含まれています。変更内容の詳細情報はリリースノートをご覧ください。

Release notes
https://github.com/oracle/helidon/releases/tag/1.3.0

Helidon on OOW/CodeOne 2019

来週(2019年9月16日)、Oracle Open World と CodeOne が開催されますが、Helidonもそこでご紹介します。ユーザーからHelidonの様々なユースケースを紹介してもらうだけでなく、まもなく登場するHelidon DBのような新機能をHelidonチームからご紹介するセッションがあります。以下はそのリストです。

  • Non-blocking Database Access in Helidon SE [DEV5365]
    Monday, September 16, 09:00 AM — 09:45 AM
  • Migrating a Single Monolithic Application to Microservices [DEV5112]
    Thursday, September 19, 12:15 PM — 01:00 PM
  • Hands on Lab: Building Microservices with Helidon
    Monday, September 16, 05:00 PM — 07:00 PM
  • Building Cloud Native Applications with Helidon [CON5124]
    Wednesday, September 18, 09:00 AM — 09:45 AM
  • Helidon Flies Faster on GraalVM [DEV5356]
    September 16, 01:30 PM — 02:15 PM
  • Helidon MicroProfile: Managing Persistence with JPA [DEV5376]
    Thursday, September 19, 09:00 AM — 09:45 AM

CodeOneでお会いしましょう。

Announcing Visual Studio Code Extension for MicroProfile Starter

このエントリは以下のエントリをベースにしています。
This entry is based on the following one written by YK Chang.
https://microprofile.io/2019/09/17/announcing-visual-studio-code-extension-for-microprofile-starter/

MicroProfileコミュニティから、MicroProfile StarterのVisual Studio Code extension(拡張機能)が利用可能になったことを発表します。 VS Code extension for Eclipse MicroProfile Starterバージョン0.1が、Visual Studio CodeのMarketplaceからダウンロードして使用できるようになりました。

MicroProfile Starter
https://marketplace.visualstudio.com/items?itemName=MicroShed.mp-starter-vscode-ext

MicroProfile Starterは、MicroProfileを実装するランタイムのコード例を伴うMavenプロジェクトを開発者向けに生成します。開発者は、必要なものを使ってマイクロサービスのコーディングをすばやく開始できます。このたび、VS Code extensionが登場したことで、開発者はエディターを離れずに、VS Code内でMavenスタータープロジェクトを直接生成できるようになりました。

MicroProfile Starter
https://start.microprofile.io/

VS Codeにインストールしたら、コマンドパレットからMicroProfile Starterを選択して実行し、プロンプトに従って必要なものを選択すれば、指定したフォルダーにスタータープロジェクトが生成されます。VS Code extensionは、MicroProfile Starter Webサイトと同じオプションを提供し、プロジェクト生成にあたっては同じAPIを使用します。

MicroProfile Starterと同様に、この拡張機能はMicroProfileコミュニティによる協同作業の成果です。このソースコードはオープンであり、MicroShed(Javaマイクロサービスの開発者ツールに関するコミュニティ・コラボレーション)の下、GitHubに格納されています。

MicroShed — Developer tools for creating Java microservices
https://github.com/MicroShed

Visual Studio Code extension for Eclipse MicroProfile Starter をお試しいただき、フィードバックを頂けると幸甚です、Gitterのmicroprofile-starterやmp-starter-vscode-extリポジトリのIssueでお寄せください。

Gitter — microprofile-starter
https://gitter.im/eclipse/microprofile-starter
Issues — mp-starter-vscode-ext
https://github.com/MicroShed/mp-starter-vscode-ext/issues

VS Code extensionのロードマップには、オフラインモードなどがあがっています。また、これがMicroProfileコミュニティが作成した最初のIDE extensionであり、MicroProfile Starterプロジェクトは、さまざまなIDE向けの拡張機能を近日中に提供する予定です。是非一緒に作り上げましょう。我々はみなさまからのフィードバック、アイデア、貢献を歓迎し、貴重なものとして受け止めます。

Happy coding with MicroProfile!

Oracle JDBC drivers on Maven Central

このエントリは以下のエントリをベースにしています。
This entry is based on the following one written by Kuassi Mensah (Product Management, Oracle DB and Java (JDBC/UCP/OJVM)).
https://medium.com/@kuassimensah/oracle-jdbc-drivers-on-maven-central-64fcf724d8b

At last!

はい、リクエストされていましたものですが、少々遅れて(やらないよりはましですね)、できあがりました。
Maven Centralから、Oracle JDBCドライバを配布します。
現時点では最新のリリース19.3.0.0のみですが、今後すぐにサポート対象の以前のリリースを追加する予定です。

JARs, GAV, etc

Oracle JDBCドライバに付属のjarファイルがあります。MavenアーティファクトとそのIDは何でしょう?

Jars

JARファイル
ojdbc10.jarJDK 10でコンパイルされ、JDK 11で動作保証されているType 4ドライバ
ojdbc8.jarJDK 8でコンパイルされ、JDK 8、JDK 10、JDK 11で動作保証されているType 4ドライバ
ucp.jar: ojdbc8.jarもしくはojdbc10.jarと共に使うためのUCP (Universal Connection Pool) Javaライブラリ
orai18n.jar:NLSもしくは国際化サポートのためのJavaクラス
ons.jarサーバーサイドOracle Notification Services (ONS) デーモンへの自動登録をサポート
simplefan.jarFast Application Notification (FAN) イベントのサブスクライブのためのJava APIをサポート。Oracle Java接続プール (ucp) を使わない場合に必要(ons.jarが必要)。
osdt_core.jar
osdt_cert.jar
oraclepki.jar
Oracle Walletsを使ったOracle DatabaseへのJava接続のために必要
xdb.jar
xmlparserv2.jar
XMLデータ型と標準java.sql.SQLXMLinterfaceをサポート
ojdbc10dms.jarojdbc10.jarと共に使用し、Oracle Dynamic Monitoring Services (DMS) インストルメンテーションのサポートと、java.util.loggingの限定的サポートを提供。
ojdbc8dms.jarojdbc8.jarと共に使用し、Oracle Dynamic Monitoring Services (DMS) インストルメンテーションのサポートと、java.util.loggingの限定的サポートを提供。
ojdbc10_g.jarトレースコード(デバッグモード)付きのojdbc10.jar
ojdbc8_g.jarトレースコード(デバッグモード)付きのojdbc8.jar
ojdbc10dms_g.jarojdbc10_g.jarと共に使い、デバッグモードでDMSインストルメンテーションをサポート
ojdbc8dms_g.jarojdbc8_g.jar.ojdbc8_g.jarと共に使い、デバッグモードでDMSインストルメンテーションをサポート

Group, Artifacts, and Version

Groupcom.oracle.ojdbc
Version: 19.3.0.0

https://repo1.maven.org/maven2/com/oracle/ojdbc/

Artifacts and Dependencies

Maven Centralとの通信の複数回の往復を避けるため、そしてJDBC jarファイルが付属jarファイルと一緒に使われることが多いことから、アーティファクトの一部にハードおよびオプションの依存関係を追加しました。
以下にIDと依存関係を記載します。

artifactIdPullするJARファイルオプションでPull可能なJARファイル
ojdbc10ojdbc10.jar
ucp.jar
oraclepki.jar
osdt_core.jar
osdt_cert.jar
ons.jar
simplefan.jar
orai18n.jar
xdb.jar
xmlparserv2.jar

(以下のPOMファイルのサンプルを参照)
ojdbc8ojdbc8.jar
ucp.jar
oraclepki.jar
osdt_core.jar
osdt_cert.jar
ons.jar
simplefan.jar
orai18n.jar
xdb.jar
xmlparserv2.jar
ucpucp.jar
orai18norai18n.jar
onsons.jar
simplefansimplefan.jar
ons.jar
osdt_coreosdt_core.jar
osdt_certosdt_cert.jar
oraclepkioraclepki.jar
xdbxdb.jar
xmlparserv2.jar
xmlparserv2xmlparserv2.jar
dmsdms.jar
ojdbc10dmsojdbc10dms.jar
ojdbc8dmsojdbc8dms.jar
ojdbc10_gojdbc10_g.jar
ojdbc10dms.jar
ojdbc10dms_g.jar
dms.jar
ojdbc8_gojdbc8_g.jar
ojdbc8dms.jar
ojdbc8dms_g.jar
dms.jar
ojdbc10dms_gojdbc10dms_g.jar
ojdbc8dms_gojdbc8dms_g.jar

Example

以下はojdbc10.jarファイルと依存関係をPullするためのPOMファイルです。

Watch this space

新機能をドライバや付属JARファイルに追加する際には、Twitter (@kmensah) でお知らせします。

The arrival of Java 13!

このエントリは以下のエントリをベースにしています。
This entry is based on the following one written by Sharat Chander (Director, Java SE Product Management, Oracle).
https://blogs.oracle.com/java-platform-group/the-arrival-of-java-13

2017年のJava 9リリース以後、Javaのリリースサイクルが変わりました。メジャーリリースは3年以上のサイクル、フィーチャーリリースが6ヵ月毎に変わっています。この変更の大きな理由の一つとして、継続的な改善に対して、開発者が予測できるスケジュールでアクセスできるようにすることがあります。フィーチャーリリースは現在3月、9月の年2回確実にリリースされていますが、これは開発者が数年ごとに一度に数百もの変更を管理する必要がなくなったことを意味します。

Update and FAQ on the Java SE Release Cadence
https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence
https://orablogs-jp.blogspot.com/2018/05/update-and-faq-on-java-se-release.html

より詳細かつ迅速な方法で新しい拡張機能にアクセスできるようになったことで、12個の新たな拡張機能を提供したJava 10、17個の新たな拡張機能を提供したJava 11、8個の新しい拡張機能を提供したJava 12で実証された、イノベーションのペースをずっと簡単に開発者は管理できます。

JDK 10
http://openjdk.java.net/projects/jdk/10/
JDK 11
http://openjdk.java.net/projects/jdk/11/
JDK 12
http://openjdk.java.net/projects/jdk/12/

The Arrival of Java 13!

OracleはJava 13をエンタープライズならびに開発者向けにJava 13を提供します。JDK 13は、2020年3月に予定されているOracle JDK 14の登場までに、OracleのCPU (Critical Patch Update) のスケジュールごとに最小2個のアップデートがリリースされる予定です。なお、JDK 14の早期アクセスビルドはすでにご利用いただけるようになっています。

Oracle Keeps Driving Developer Productivity with New Java Release
https://www.oracle.com/corporate/pressrelease/oow19-new-java-release-091619.html
Critical Patch Updates, Security Alerts and Bulletins
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
JDK 14 Early-Access Builds
http://jdk.java.net/14/

再度、OracleはJava 13をオープンソースのクラスパス例外付きのGNU General Public Licence v2 (GPLv2+CPE) に基づいてOracle OpenJDKリリースとしてリリースします。また、Oracle製品やサービスの一部としてOracle JDKリリースを使用する方々や、オープンソースソフトウェアを使いたくない方々向けに商用ライセンスの下でもOracle JDKをリリースします。

OpenJDK 13
https://jdk.java.net/13/

Java 13, Together

Java 11やJava 12と同様に、OpenJDKコミュニティの多くの個人や組織からJava 13に寄せられた貢献を称え続けています。私たちが全員一緒になってJavaをつくっています!

Building JDK 11 Together
https://blogs.oracle.com/java-platform-group/building-jdk-11-together
https://orablogs-jp.blogspot.com/2018/10/building-jdk-11-together.html
The arrival of Java 12!
https://blogs.oracle.com/java-platform-group/the-arrival-of-java-12

JDK 13 Fix Ratio

長期にわたるJDKの全体的な変化率は基本的に長年一定でしたが、6か月サイクルになったことで、開発者に提供されるイノベーションのペースが大幅に改善されました。数年ごとに大規模なメジャーリリースで数万個の修正と約100個のJEPを利用できるようにする代わりに、管理しやすく予測可能な6か月のスケジュールで小規模な機能リリースで機能拡張を利用できます。この変更は、重要な機能から、定期的なメンテナンス、バグ修正、ドキュメントの改善といった小さな拡張にまで及びます。こうした変更の各々は、JDK Bug Systemの単一の問題に対する単一のコミットで表現されています。

JDK Bug System
https://bugs.openjdk.java.net/secure/Dashboard.jspa

JDK 13での修正対象としてマークされているJIRA上の2,126個のIssueのうち、1,454個がOracleで働く人々が、671個は個人開発者や他の企業に属する開発者が、それぞれ対応しました。Issueと担当者の組織データを照合すると、以下のようなJDK 13での修正開発を後援する組織のグラフができました。

Oracle所属の開発者はJIRAのIssueの70%弱をJDK 13開発期間中に解決したのに対し、30%弱を他の企業に所属の開発者が修正しました。OracleはGoogleやRed Hat、SAPといった企業に属する開発者の多大な貢献に感謝すると共に、Bellsoftのような小規模な組織や、JDK 13の修正の5%に貢献してくださった個人開発者のみなさまにも感謝申し上げます。

このリリースで注目すべきは、ARMサポートに関心のある組織からの貢献です。 Ampere Computing、ARM、Huawei、Linaroの方々がこの点で貢献してくださいました。このリリースでは、MIPSベースのCPUに取り組んでいるLoongsonからの貢献もありました。

Oracleは、提案された変更をレビューしてくださった多くの経験豊富な開発者、早期アクセスビルドを試して問題を報告してくださったアーリーアダプター、OpenJDKメーリングリストに関するフィードバックを提供した専門家に感謝しています。また、Nicolai Parlogの”Definitive Guide To Switch Expressions In Java 13″のような、新機能を紹介する高品質のコンテンツを提供してくれた人たちにも感謝申し上げます。

Definitive Guide To Switch Expressions In Java 13
https://blog.codefx.org/java/switch-expressions/

New Enhancements in Java 13

Java 13では、2つのプレビュー機能を含む5つの拡張機能が提供されます。

JDK 13
http://openjdk.java.net/projects/jdk/13/

JEP 350 – Dynamic CDS Archives

アプリケーションクラスデータ共有 (JEP 310) を拡張して、Javaアプリケーション実行の最後にクラスの動的アーカイブを可能にします。アーカイブされたクラスには、デフォルトのベースレイヤーCDSアーカイブに存在しない、ロードされたすべてのアプリケーションクラスとライブラリクラスが含まれます。

JEP 310: Application Class-Data Sharing
https://openjdk.java.net/jeps/310

JEP 351 – ZGC: Uncommit Unused Memory

ZGCを拡張し、利用されていないヒープメモリをOSに返すようにしました。

JEP 353 – Reimplement the Legacy Socket API

java.net.Socket と java.net.ServerSocket APIが利用する配下の実装をよりシンプルかつモダンな実装に置き換え、メンテナンスとデバッグを容易にしました。この新たな実装により、現在Project Loomで調査中の、fiberとしても知られるユーザーモードスレッドへの対応が簡単になると考えています。

Loom – Fibers, Continuations and Tail-Calls for the JVM
https://openjdk.java.net/projects/loom

JEP 354 – Switch Expressions (Preview)

switchを拡張して、ステートメントまたは式として使用できるようにします。これにより、日常のコーディングが簡素化され、スイッチでのパターンマッチング(JEP 305)の利用に対応できるようにしています。

JEP 305: Pattern Matching for instanceof (Preview)
https://openjdk.java.net/jeps/305

JEP 355 – Text Blocks (Preview)

Java言語にテキストブロックを追加しました。これにより、よくあるエスケープシーケンスを避けながら、ソースコードの複数行にわたる文字列を簡単に表現できるようになり、Javaプログラムの作成タスクを簡素化でき、Javaプログラム内のJava以外の言語で表現されたコードを示す文字列の可読性を高めます。同様に、新しいコンストラクトが同じ文字列セットを文字列リテラルとして表現し、同じエスケープシーケンスを解釈し、文字列リテラルのように操作できることを規定することにより、文字列リテラルからの移行をサポートします。

Javaは、ソフトウェアプログラマーが選択するプログラミング言語の第1位であり続けています。また、Java 13での改善のオンタイムデリバリが示すように、継続的かつよく考えられた計画とエコシステムの関与を通じて、Javaプラットフォームはクラウドでの最新の開発と成長のためによい状況にあります。

Azure Service Busでカスタムプロパティをやりとりする (1)

このエントリは2019/09/12現在の情報に基づくものです。今後の機能追加や変更に伴い、記述内容との乖離が発生する可能性があります。

Azure Service Busはメッセージブローカーで、様々なメッセージをやりとりできるが、メッセージとともにカスタムプロパティを送受信することもできる。

今回はTopicを使って動作確認した。Queueでも基本的には同じである。例によって利用言語はJavaである。

SDKを使う場合

事前準備

pom.xmlに以下の依存関係を追加しておく。

<dependency>
  <groupId>com.microsoft.azure</groupId>
  <artifactId>azure-servicebus</artifactId>
  <version>3.0.0</version>
</dependency>

送信側

通常通りメッセージを作成するが、カスタムプロパティはMapに詰め込んでおき、Message#setProperties()でカスタムプロパティをメッセージに設定する。

Message message = new Message();
message.setMessageBody(MessageBody.fromValueData(messageString));
Map<String, Object> properties = new HashMap<>();
properties.put("account-id", "common");
properties.put("data-partition-id", "common");
properties.put("correlation-id", "12345-67890-abcde-fghij-klmno");
message.setContentType("application/json");
message.setCorrelationId("12345-67890-abcde-fghij");
message.setProperties(properties); // <---- Here!
topicClient.sendAsync(message).thenRunAsync(() -> topicClient.closeAsync());

受信側

messageインスタンスを取得後、Message#getProperties()を呼び出せば、カスタムプロパティを取得できる。

IMessageHandler messageHandler = new IMessageHandler() {
    @Override
    public CompletableFuture<Void> onMessageAsync(IMessage message) {
        if(message.getContentType().contentEquals("application/json")) {
            Map<String, Object> properties = message.getProperties(); // <---- !! Here !!
            String messageString = (String) message.getMessageBody().getValueData();
        }
        return subscriptionClient.completeAsync(message.getLockToken());
    }
    @Override
    public void notifyException(Throwable throwable, ExceptionPhase exceptionPhase) {
        System.out.println(exceptionPhase + "---" + throwable.getMessage());
    }
};

Functionsの場合

事前準備

pom.xmlに以下の依存関係を追加しておく。なお、Functionsのバージョンは2を使う。

<dependency>
  <groupId>com.microsoft.azure</groupId>
  <artifactId>azure-servicebus</artifactId>
  <version>3.0.0</version>
</dependency>

送信側(Output)

OutputBindingにMessageを指定すれば、 あとはSDKの場合と同様のお作法でカスタムプロパティを付加して送信できる。

@FunctionName("sboutput")
public HttpResponseMessage send2ServiceBus(
    @HttpTrigger(
            name = "req",
            methods = {HttpMethod.POST},
            authLevel = AuthorizationLevel.ANONYMOUS
    ) HttpRequestMessage<Optional<String>> request,
    @ServiceBusTopicOutput(
            name = "message",
            topicName = "%TOPIC_NAME%",
            subscriptionName = "%SUBSCRIPTION_NAME%",
            connection = "AzureServiceBusConnectionString"
    ) OutputBinding<Message> message,
    final ExecutionContext context) {
    Map<String, Object> properties = new HashMap<>();
    properties.put("account-id", "common");
    properties.put("data-partition-id", "common");
    properties.put("correlation-id", "12345-67890-abcde-fghij-klmno");
    String body = request.getBody().get();
    MessageBody.fromValueData(body);
    Message sendMessage = new Message();
    sendMessage.setMessageBody(MessageBody.fromValueData(body));
    sendMessage.setContentType("application/json");
    sendMessage.setCorrelationId("12345-67890-abcde-fghij");
    sendMessage.setProperties(properties);
    message.setValue(sendMessage);
    return request.createResponseBuilder(HttpStatus.ACCEPTED)
        .header("Content-Type","application/json")
        .body(body)
        .build();
}

受信側(Trigger)

FunctionsはデフォルトでReceiveMode.PEEKLOCKを使っており、成功すると自動的にSubscriptionClient#complete()、失敗するとSubscriptionClient#abandon()が呼ばれることに注意。Functions v2では、com.microsoft.azure.servicebus.Message をBinding変数に指定しておけば、SDKの場合と同じお作法で取得できる。もちろん通常のPOJOも可能。以下はContextTypeとしてapplication/jsonが指定されているメッセージのみ受け取る例。

@FunctionName("sbtrigger")
public void triggerFromServiceBus(
        @ServiceBusTopicTrigger(
                name = "message",
                topicName = "%TOPIC_NAME%",
                subscriptionName = "%SUBSCRIPTION_NAME%",
                connection = "AzureServiceBusConnectionString"
        ) Message message,
        final ExecutionContext context) {
    if (message.getContentType().contentEquals("application/json")) {
        context.getLogger().info(message.getMessageBody().getValueData().toString());
        Map<String, Object> properties = message.getProperties();
        context.getLogger().info(properties.toString());
    }
}

SDKとFunctionsを混在させる(例えば送信側がFunctions、受信側がSDK)というのは通常の方法ではできない。詳細は別のエントリに記載する予定。

Welcome to the Future of Cloud Native Java

このエントリは以下のエントリを基にしています。
This entry is based on the following written by Mike Milinkovich (Executive Director of the Eclipse Foundation).
https://eclipse-foundation.blog/2019/09/10/welcome-to-the-future-of-cloud-native-java/

今日、Jakarta EE 8がリリースされ、Javaのイノベーションの新しい時代に入りました。

Jakarta EE 8 Software
https://jakarta.ee/release/

ベンダーに依存しないオープンなプロセスのもと、世界有数のJavaの組織、数百人の専任開発者、Eclipse Foundationスタッフといった多様なコミュニティがJakarta EE 8 Full Platform、Web Profiles、関連するTCK、そしてJakarta EE 8互換の実装として認定されているEclipse GlassFish 5.1をリリースしました。

これは月並みに言ってもすごいことです。18個の異なるメンバー組織、160名を超える新しいコミッター、43個のプロジェクト、129個のGitリポジトリにある6100万行を超えるコードベースという、Eclipseコミュニティの標準からみても本当に大規模な取り組みでした。個々人の方々に感謝の意を述べるにはあまりにも多数の方がいらっしゃるので、この業界のマイルストーンを達成するのに役割を果たしたジャカルタEEコミュニティの皆さんにこの場を借りて感謝申し上げます。

Our members
https://jakarta.ee/membership/members/
EE4J
https://projects.eclipse.org/projects/ee4j

以下にこのリリースにこれほどまでにわくわくしているか述べていきます。

Java EEはエンタープライズアプリケーションの開発と実行のためのプラ​​ットフォームで、20年以上にわたって業界全体で選択されています。 IDCによると、Fortune 500企業の90%は、ミッションクリティカルなワークロードはJavaに依存しています。Jakarta EE 8は、ソフトウェアベンダー、1,000万人以上のJava開発者、および数多の企業に、Java EEアプリケーションとワークロードを標準ベースのベンダーに依存しないオープンソースのエンタープライズJavaスタックに移行するために必要な基盤を提供します。

Jakarta EE Working GroupのSpecification Committeeのたゆまぬ努力の結果、仕様開発はJakarta EE仕様プロセスとEclipse開発プロセスに従っています。これらは、Java EEのJava Community Process(JCP)に対するコミュニティ主導のオープンな後継者です。これにより、仕様を生成するための完全にオープンな共同アプローチが可能になり、コミュニティがすべての決定を共同で行います。オープンソースのTCKおよび自己申告のオープンプロセスと組み合わせることで、Jakarta EEは、独立した実装への参加と参加の障壁を大幅に低下させます。

Jakarta EE Specification Process
https://jakarta.ee/about/jesp/
Eclipse Development Process
https://www.eclipse.org/projects/dev_process/

Jakarta EE 8仕様はJava EE 8仕様と完全に互換性があり、開発者が長年使用してきた同じプログラミングモデルを使う、同じAPIとJavadocが含まれています。Jakarta EE 8 TCKは、Java EE 8 TCKに基づいており、完全に互換性があります。つまり、エンタープライズのお客様は、Java EE 8アプリケーションを変更せずにJakarta EE 8に移行できます。

GlassFish 5.1に加えて、IBMのOpen LibertyサーバーランタイムもJakarta EE 8互換の実装として認定されています。Jakarta EE Working Groupのすべてのベンダーは、各ベンダーのJava EE 8実装がJakarta EE 8と互換性があることを保証する予定です。

Eclipse GlassFish
https://projects.eclipse.org/projects/ee4j.glassfish/downloads
Open Liberty
https://openliberty.io/

これはすべて、JavaのステークホルダーがJakarta EEの前進に参加して、重要なビジネス上の課題を解決するクラウドベースのアプリケーションに対する最近のエンタープライズの要求を満たす前例のない機会を示しています。コミュニティには現在、オープンソースのベースラインを手にしており、これを使うことで、実績のあるJavaテクノロジーを、コンテナ、マイクロサービス、Kubernetes、サービスメッシュ、および過去数年にわたって企業に採用されているその他のクラウドネイティブテクノロジーの世界に移行できます。

行動の呼びかけの一環として、Jakarta EE Working Groupの新しいメンバーを積極的に募集しています。メンバーシップの便益と利点をよく調べていただければと思います。Javaがビジネスにとって重要であり、すべての人に利益をもたらす、よく管理された、ベンダーに中立なエコシステムの中でJakarta EEの革新、成長、および持続可能性を確保したい場合は、今すぐ参加しましょう。

Membership
https://jakarta.ee/membership/

また、クラウドネイティブJavaとは何か、多くの企業にとってクラウドネイティブJavaが重要である理由、およびJakarta EEテクノロジーがどこに向かっているのかについてのコミュニティの視点について詳しく知りたい場合は、Fulfilling the Vision for Open Source, Cloud Native Javaという新しい無料の電子ブックをダウンロードしてください。クラウドネイティブJava。 Adam Bien、Sebastian Daschner、Josh Juneau、Mark Little、Reza Rahmanが自身のインサイトと専門知識をこのeBookにつぎ込んでくれたことに感謝いたします。

Cloud Native Java eBook – Charting a Course for Cloud Native Java
https://jakarta-4753786.hs-sites.com/cloud-native-java-eBook

最後に、来週サンフランシスコのMoscone Centerで開催されるOracle Code Oneに参加されるのであれば、ブース#3228にお立ち寄りください。Eclipseコミュニティでは、Jakarta EE 8、GlassFish 5.1、Eclipse MicroProfile、Eclipse Che、その他クラウドネイティブJavaオープンソースプロジェクトのポートフォリオの多くをご紹介する予定です。

Oracle Code One 2019
https://www.oracle.com/code-one/
Eclipse MicroProfile
https://microprofile.io/
Eclipse Che
https://www.eclipse.org/che/

JVM Language Summit 2019 feedback

例年7月下旬にサンタクララで開催されるJVM Language Summitの報告会を東京(2019/08/09)、大阪(2019/08/23)、福岡(2019/08/30)の3か所で開催しました。

Tapestry of “Project Loom”

これは今年初の試みで、当初はちょっと違う内容を考えていました。ところがきしださんから、以下のようなコメントをもらい、開催した、という背景があります(そのくせ筆者のスライドは全て英語だったわけですが)。

ともかく、3会場で開催し、予想以上の多くの方に参加いただきましてありがとうございました。JVMLSに参加し、スピーカーをやってくださったさくらばさん (@skrb) 、きしださん (@kis) 、さかたさん (@jyukutyo) 、あじさかさん (@ajis_ka) 、そして会場を提供くださったLINE株式会社、LINE Fukuoka株式会社、Yahoo! Japan株式会社のご協力をもって開催できました。厚く御礼申し上げます(ロジ子のオフィスでやらなかった理由は、DevRelチームの手を借りることができなかったからです)。

この3回の報告会で使用したスライドは以下です。

JVMLSはいわゆるお祭り的なカンファレンスではありませんが、狭く深くJVMの一部分に興味をお持ちであれば、結構はまる可能性があります。ご興味ある方は是非来年参加してみてください。