タグ別アーカイブ: Java EE/Jakarta EE

Oracle WebLogic Server on Microsoft Azure IaaS

このエントリは以下のエントリを基にしています。
This entry is based on the following one written by Jacob Thomas (Software Development Manager, Oracle).
https://blogs.oracle.com/weblogicserver/oracle-weblogic-server-on-microsoft-azure-iaas

2019年6月初旬にOracleとMicrosoftは両社のクラウドの相互接続のパートナーシップを発表しました。

Microsoft and Oracle to interconnect Microsoft Azure and Oracle Cloud
https://news.microsoft.com/2019/06/05/microsoft-and-oracle-to-interconnect-microsoft-azure-and-oracle-cloud/

このたび、OracleとMicrosoft間のパートナーシップのもう一つの側面として、Oracle WebLogic Server on Microsoft Azure IaaSというもう一つの重要なピースを発表いたします。

WebLogic Kubernetes OperatorやCoherence Kubernetes Operatorへのこれまでの作業に加えて、OracleのWebLogicチームは、WebLogic ServerをMicrosoft AzureのIaaSリソースにデプロイするという最もよくあるニーズをカバーするため、いくつかの相互運用するAzure ARM (Azure Resource Manager) テンプレートとそれに対応するAzure Marketplaceでのアイテムを作成するという作業に現在取り組んでいます。

Portable WebLogic Domains Using Kubernetes Operator Configuration Overrides
https://blogs.oracle.com/weblogicserver/portable-weblogic-domains-using-kubernetes-operator-configuration-overrides
Coherence Operator 1.0 Released! Operate Coherence Clusters with Kubernetes.
https://blogs.oracle.com/oraclecoherence/coherence-operator-1-0-released

Marketplaceで選択できる以下のものは、全てOracle Linux 7.6で稼働するOracle WebLogic Server 12.2.1.3をベースにしています。

  • 事前構成済みのWebLogic管理サーバのみが動作する1個のVMを作成
  • 管理サーバが1個のVMで動作し、クラスタメンバは別のVMで動作する、N個のノードのWebLogicクラスタを作成
    プロビジョニングが完了すると、管理サーバと全ての管理対象サーバがデフォルトで起動している。管理サーバとノードマネージャはsystemdサービスとし起動されており、NodeManagerのCrashRecoveryEnabledプロパティにtrueが設定されているため、VMの再起動後、サーバは自動的に再起動される。Azure CLIを使ってクラスタにノードを追加できる。
  • 前述の通りN個のノードで構成されるWebLogicクラスタを作成すると、クラスタ用にAzure LoadBalancerが自動的に構成される。
  • 1個のVM上の管理サーバと、動的クラスタ内の他のノード上の管理対象サーバを使用して、N個のノードで構成されるWebLogic動的クラスタを作成する。WLS管理者は、管理コンソールまたはWLSTを使ってスケールアップし、利用可能なVMにて追加の管理対象サーバを起動できる。前述の通りサービスは自動開始するように構成されており、Azure CLIでさらにノードを追加できる。

この商品のリリース日などに関する今後のアップデートはこのブログで情報提供していきますので、是非チェックしてください。現時点では、2019年10末までにAzure Marketingpaceでご利用頂けるようにしたいと考えています。Azure Marketplaceの”Contact Me”使って、この機能が利用できるようになったことを通知するように仕込むこともできます。

Oracle WebLogic Server 12.2.1.3 — Azure Marketplace
https://azuremarketplace.microsoft.com/en-us/marketplace/apps/oracle.oraclelinux-wls-cluster

OracleとMicrosoftのパートナーシップに関する詳細情報は以下のURLをご覧ください。

Accelerate your cloud adoption with Microsoft and Oracle®
https://azure.microsoft.com/en-us/solutions/oracle/

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/

Helidon brings MicroProfile 2.2+ support

このエントリは以下のエントリをベースにしています。
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/08/08/helidon-brings-microprofile-2-2-support/
https://medium.com/oracledevs/helidon-brings-microprofile-2-2-support-93d85bb4223e

Helidon 1.2.0では、MicroProfile 2.2をサポートし、さらにバグ修正やパフォーマンス上の問題を改善しています。

Helidon 1.2.0 (Release Notes)
https://github.com/oracle/helidon/releases/tag/1.2.0
Eclipse MicroProfile 2.2 is Now Available
https://microprofile.io/2019/02/12/eclipse-microprofile-2-2-is-now-available/

MicroProfile

Project Helidonの主目的の一つは最新のMicroProfile APIのサポートを提供することにあります。HelidonのMicroProfile実装はHelidon MPと呼ばれ、Helidon SEと呼ばれるリアクティブ、ノンブロッキングフレームワークと並んでHelidonの中核を形成しています。

下図はサポートしているMicroProfileとJava EEのAPIのリストです。

1.2.0では、JPA (Persistence) と JTA (Transaction) という2個のJava EE APIのサポートを追加しました。現時点ではEarly accessのため、実装や構成は今後変更の可能性があります。

以下はHelidon 1.2.0で追加された新しいAPIの利用例です。

MicroProfile REST Client sample

RESTクライアントインターフェースを登録します(これはJAX-RSリソースが実装するものと同一であってもかまいません)。URIは構成を使ってオーバーライドできる点にご注意ください。

@RegisterRestClient(baseUri = "http://localhost:8081/greet")
public interface GreetResource {
    @GET
    @Produces(MediaType.APPLICATION_JSON)
    JsonObject getDefaultMessage();
     
    @Path("/{name}")
    @GET
    @Produces(MediaType.APPLICATION_JSON)
    JsonObject getMessage(@PathParam("name") String name);
}

(異なるマイクロサービスのJAX-RSリソースなど)利用するクラスでRESTクライアントを宣言します

@Inject
@RestClient
private GreetResource greetService;

あとはフィールドを使ってリモートサービス(この例ではリモートサービスへのリクエストをプロキシしています)を呼び出すだけです。

@GET
@Produces(MediaType.APPLICATION_JSON)
public JsonObject getDefaultMessage() {
    return greetService.getDefaultMessage();
}

Health Check 2.0 sample

Health Check 2.0 にはReadinessとLivenessという2種類のチェック機構があります(以前は1種類だけでした)。

  • Readiness — サービスが起動し利用可能であることを確認するためにクライアントが利用(例えばk8s readiness check)
  • Liveness — サービスが稼働しており実行中であることを確認するためにクライアントが利用(例えば k8s liveness check)

application scopedのbeanに適切な注釈(@Readiness もしくは @Liveness)をつけてヘルスチェックを作成します。

import javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;
import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Liveness;
 
@Liveness
@ApplicationScoped
public class GreetHealthcheck implements HealthCheck {
    private GreetingProvider provider;
   
    @Inject
    public GreetHealthcheck(GreetingProvider provider) 
        this.provider = provider;
    }
 
    @Override
    public HealthCheckResponse call() {
        String message = provider.getMessage();
        return HealthCheckResponse.named("greeting")
            .state("Hello".equals(message))
            .withData("greeting", message)
            .build();
    }
}

Open Tracing Sample

MicroProfileのOpen Tracing では、CDI beansのトレースを追加する目的で @Tracedという1個のアノテーションを追加しています。

Tracing of JAX-RS リソースのトレースは自動化されています( @Tracedで無効化できます)。以下はHealth checkのサンプルで使ったbeanの例で、getMessageメソッドをトレースしています。

@ApplicationScoped
public class GreetingProvider {
    private final AtomicReference<String&gt; message = new AtomicReference<&gt;();
     
    /**
     * Create a new greeting provider, reading the message 
     * from configuration.
     *
     * @param message greeting to use
     */
    @Inject
    public GreetingProvider(
        @ConfigProperty(name = "app.greeting") String message) {
        this.message.set(message);
    }
     
    @Traced(operationName = "GreetingProvider.getMessage")
    String getMessage() {
        return message.get();
    }
     
    ...
}

Other Enhancements

MicroProfile 2.2に加え、Helidon 1.2.0にはいくつかの機能強化が含まれています。

  • Helidon MP と SEでHTTP Access Logをサポート
  • Oracle Universal Connection Pool のサポート(Early access)
    これを使って、Oracle UCP JDBCドライバをHelidon MPアプリケーションのDataSourceとして構成、注入できる。

More to Come

MicroProfile 2.2 のサポートにより、Helidonは他の主要なMicroProfile実装に追いついてきました。現在HelidonのMicroProfile 3.0対応に向けて作業を進めており、すでに最初の一歩を踏み出しています。これがタイトルの2.2の後に+をつけている理由です。すでにHealth Check 2.0をサポートしています(今後後方互換のある形でサポートする予定です)。残るはMetrics 2.0とREST Client 1.3で、来月リリースできるように鋭意取り組んでいます。

Update for Jakarta EE community: July 2019

このエントリは以下のエントリをベースにしています。
This entry is based on the following one, written by Tanja Obradovic (Eclipse Foundation).
https://blogs.eclipse.org/post/tanja-obradovic/update-jakarta-ee-community-july-2019

JakartaOne LiveStream: All eyes on Cloud Native Java

Jakarta EEの現状と将来に関心がある方や、クラウドネイティブJavaアプリケーションのツールを構成する他の関連テクノロジーを探りたい方に、JakartaOne LiveStreamが開催されます。開発者、技術面でのビジネスリーダーのいずれであっても、満足いただけることでしょう。

このバーチャルカンファレンスは2019年9月10日に開催されます。1日のみの開催のため、セッション数には限りがあります。

(注意)全てのJakartaOne LiveStreamセッションと基調講演は独立したプログラム委員会が選定します。この委員会はJakarta EEやCloud Native Javaコミュニティからのボランティアで構成されます。メンバーはReza Rahman(委員長)、Adam Bien、Arun Gupta、Ivar Grimstad、Josh Juneau、Tanja Obradovicです。

全ての講演は録画され、後でJakarta EEのWebサイトでご覧いただけるようにしますが、スピーカーと直接対話するためにも、是非オンタイムで参加してください。

Jakarta EE
https://jakarta.ee/


Jakarta EE 8 release and progress

GitHub上でEclipse EE4Jプロジェクトの状況をチェックできるようになっています。

Eclipse EE4J
https://github.com/orgs/eclipse-ee4j/projects
Create Specification Projects
https://github.com/orgs/eclipse-ee4j/projects/13
Specification Document Names
https://github.com/orgs/eclipse-ee4j/projects/12

Jakarta EE 8 TCK jobsやJakarta Specification Project Names、Jakarta Specification Scope Statementsは順調に進捗していますので、GitHubで改善点や解決済みの箇所を是非チェックしてください。

Jakarta EE 8 TCK jobs
https://github.com/orgs/eclipse-ee4j/projects/14
Jakarta Specification Project Names
https://github.com/orgs/eclipse-ee4j/projects/11
Jakarta Specification Scope Statements
https://github.com/orgs/eclipse-ee4j/projects/10

TCKプロセスの作業は、Scott Stark (Vice President of Architecture at Red Hat) がリードして進めています。 TCKプロセスのドキュメント v 1.0 はまもなく完成する予定です。ドキュメントは移植性を提供するのに適していると評価されるためにTCKが備えていなければならないマテリアルや、テストに臨む際のプロセス、解決方法などの側面に焦点を当てています。

Jakarta EE 8はJakartaOne Livestreamのその日、2019年9月10日リリースを予定しています。

Javax package namespace discussions

仕様委員会 (The specification committee) は、コミュニティが考慮すべき、javaxパッケージ名前空間の利用制限について、Big BangとIncrementalの2個のアプローチを提示しました。

Working Group内の議論やコミュニティからの声に基づいて、バイナリ互換性に関する作業がさらに検討されるまで、仕様委員会はまだどのアプローチを取るか決定を留保しています。このことを念頭に置き、Working Groupメンバーはバイナリ互換性に対する技術的なアプローチに時間をかけて取り組み、その後顧客、ベンダー、そして開発者にとってベストな選択しを提示、決定する予定です。

2019年6月12日に開催された、David BlevinsのJakarta EE Update CallにおけるDavid Blevinsのプレゼンテーションをご覧ください。

このトピックを深掘りしたい場合には、David Blevinsがjavaxパッケージの名前空間に関する問題について有用な分析を記載しています。その中で、「javax.servletの名前を変更する場合、他に何を変更する必要があるか?」といった疑問に答えています。

transitive.adoc
https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/namespace/transitive.adoc

JCP Copyright Licensing request: Your assistance in this matter is greatly appreciated

Java EEがJakarta EEという名前でEclipse Foundationへ移管される一環として、仕様を新たなJakarta EE Specification Processの下で発展させるためには、Eclipse Foundationが必要な権利を有していることを確認することが必須です。この目的のため、皆様のお力を必要としています。

JCPの下にある、Java EE仕様に対する過去のコントリビュータ全員からの著作権ライセンスを要求しています。これは過去にJava EEに貢献したすべての企業や個人に協力を求め、その合意を実行し、Eclipse Foundationに返すことを目的としています。仕様や技術の進歩がかかっていますので、早急な対応をお願いします。Oracle、Red Hat、IBM、その他コミュニティの多くの企業は、Java EE仕様への貢献をEclipse Foundationにライセンスする契約をすでに結んでいます。また、JCPコミュニティがこの要請を支持することを期待しています。

本件の詳細は、Tanja Obradovicの以下のエントリをご覧ください。過去のコントリビュータ全員からの著作権ライセンスに対するリクエストに関して疑問がある場合は、Mariateresa Delgadoまでメールでお問い合わせください。

JCP Copyright Licensing request
https://blogs.eclipse.org/post/tanja-obradovic/jcp-copyright-licensing-request

Election results for Jakarta EE working group committees

欠員のあるマーケティング委員会の代表者を除き、ほぼ全ての役職が決まっています。2019年7月1日から始まる2019年~20年までの委員会の代表者は以下の通りです。

  • 参加者代表 (Participant Representative)
    • STEERING COMMITTEE – Martijn Verburg (London Java Community)
    • SPECIFICATIONS COMMITTEE – Alex Theedom (London Java Community)
    • MARKETING COMMITTEE – Theresa Nguyen (Microsoft)
  • コミッター代表 (Committer Representative)
    • STEERING COMMITTEE – Ivar Grimstad
    • SPECIFICATIONS COMMITTEE – Werner Keil
    • MARKETING COMMITTEE – 欠員

 Jakarta EE Community Update: June video call

直近のJakarta EE Community Updateミーティングは6月に行われました。Jakarta EE 8の進捗や計画、仕様名の変更や使用範囲の定義の進め方、TCKプロセスのアップデート、著作権仕様許諾契約、PMCおよびプロジェクトのアップデートなどなどのトピックについて会話がありました。ミーティング中で使用したマテリアルはこちらに、Zoomの録画はYouTubeにそれぞれUp済みです。

7月のJakarta EE Community Updateは7月17日に開催されました。

EclipseCon Europe 2019

EclipseCon Europe 2019のCfPは7月15日で締め切られました。コンファレンスは2019年10月21日から24日の期間、ドイツのLudwigsburgで開催されます。

EclipseCon Europe 2019
https://www.eclipsecon.org/europe2019

Jakarta EE presence at events and conferences: June overview

(カンファレンスへの参加有無をJakartaマーケティング委員会のSlackチャネルに問い合わせているところです)

Jakarta EEに関心をお寄せいただきありがとうございます。jakarta.ee-wg@eclipse.orgメーリングリストを購読し、Jakarta EE Working Groupに参加することで、Jakarta EEをわくわくする未来へと導く手助けをしてください。

クラウドのためのこれからのエンタープライズJavaプラットフォームを構築するための共同作業の詳細を知りたい方は、Jakarta Blogsをチェックし、月例のJakarta Tech Talksに参加してください。Eclipseニュースレターの購読もお忘れなく。

Jakarta Blogs
https://jakartablogs.ee/
Jakarta Tech Talks
https://www.meetup.com/jakartatechtalks_/
Eclipse Newsletter
https://www.eclipse.org/community/eclipse_newsletter/

Moving Jakarta Forward: Jakarta NoSQL Approved as an EE4J Project

このエントリは以下のエントリをベースにしています。
This entry is based on the following one written by Otavio Santana (Software Engineer, SouJava/Platform.sh).
https://dzone.com/articles/moving-jakarta-forward-jakarta-nosql-has-approved

Jakarta NoSQLがこれまでの1年のコミュニティによる作業の結果、EE4Jとして承認されました。

Jakarta NoSQL
https://projects.eclipse.org/projects/ee4j.nosql

この仕様に関する主な質問への説明を書いたエントリがいくつか出ています。

The first step in Jakarta NoSQLの技術的な最初の一歩はAPIの作成です。APIにはモジュール性があり、それはEclipse JNoSQLに由来します。したがって、Jakarta NoSQLがAPIとTCKであり、EclipseJNoSQLがそれに対する参照実装です。

Eclipse JNoSQL
http://www.jnosql.org/

最初のスコープのプロジェクトが存在し、Jakarta NoSQLとしてEclipse Foundationに移行するための法的プロセスがあります。基本的にEclipse JNoSQLからの移行に関するものです。新しいパッケージ名は “jakarta.nosql”です。以下のコードは、将来のAPIの使い方の例です。

Eclipse JNoSQL
http://www.jnosql.org/
https://github.com/eclipse-ee4j/nosql

import jakarta.nosql.document.DocumentCollectionManager;
import jakarta.nosql.document.DocumentCollectionManagerFactory;
import jakarta.nosql.document.DocumentConfiguration;
import jakarta.nosql.document.DocumentDeleteQuery;
import jakarta.nosql.document.DocumentEntity;
import jakarta.nosql.document.DocumentQuery;
import java.util.Arrays;
import java.util.List;

public class App {

    public static void main(String[] args) {
        //it loads from Service loader
        DocumentConfiguration configuration = DocumentConfiguration.getConfiguration();
        try (DocumentCollectionManagerFactory managerFactory = configuration.get()) {
            final DocumentCollectionManager manager = managerFactory.get("database");
            DocumentEntity entity = DocumentEntity.of("God");
            entity.add("name", "Diana");
            entity.add("age", 10);
            entity.add("versions", Arrays.asList("0.0.1", "0.0.2", "0.0.3"));
            manager.insert(entity);
            List<DocumentEntity&gt; entities = DocumentQuery.select().from("God")
                    .where("name").eq("Diana").execute(manager);
            DocumentDeleteQuery.delete().from("God")
                    .where("age").gte(10).execute(manager);
        }
    }
}

Jakarta NoSQLはEclipse JNoSQLと同じアプローチを使う予定です。言い換えると、NoSQLタイプ(Key-Value、カラム、ドキュメント、グラフ)ごとに1つのAPIがあります。マッピングでは、Entity、Column、IdなどのMappingアノテーションを含む、すべてのNoSQLデータベースに共有されるクラスを持つ共通APIを伴う同じパスを使用します。

import jakarta.nosql.mapping.Column;
import jakarta.nosql.mapping.Entity;
import jakarta.nosql.mapping.Id;
import java.util.List;

@Entity
public class Person {
    @Id
    private Long id;
    @Column
    private String name;
    @Column
    private List<String&gt; phones;
    //getter and setter
}

import jakarta.nosql.document.DocumentQuery;
import jakarta.nosql.mapping.document.DocumentTemplate;
import javax.enterprise.inject.se.SeContainer;
import javax.enterprise.inject.se.SeContainerInitializer;
import java.util.Arrays;
import java.util.Optional;
import java.util.concurrent.ThreadLocalRandom;
import static jakarta.nosql.document.DocumentQuery.select;

public class App2 {

    public static void main(String[] args) {
        ThreadLocalRandom random = ThreadLocalRandom.current();
        Long id = random.nextLong();
        try (SeContainer container = SeContainerInitializer.newInstance().initialize()) {
            Person person = new Person();
            person.setPhones(Arrays.asList("234", "432"));
            person.setName("Name");
            person.setId(id);
            DocumentTemplate template = container.select(DocumentTemplate.class).get();
            Person saved = template.insert(person);
            System.out.println("Person saved" + saved);
            DocumentQuery query = select().from("Person")
                    .where("_id").eq(id).build();
            Optional<Person&gt; personOptional = template.singleResult(query);
            System.out.println("Entity found: " + personOptional);
        }
    }
}

Jakarta EEには明るい未来があります。オープンソースであり、重要な統合の機能が含まれており、そして最も重要なのはコミュニティです。結局のところ、透明性を高めることがJakartaの最も強力な側面です。つまりテクノロジ自体ではなく、コミュニティの中心の透明性です。したがって、成功は各開発者の手に委ねられています。 この最初のJakarta EEの仕様で両方を提供したいと思っています。

Update for Jakarta EE community: June 2019

このエントリは以下のエントリをベースにしています。
This entry is based on the following one written by Tanja Obradovic (Jakarta EE Program Manager at Eclipse Foundation).
https://blogs.eclipse.org/post/tanja-obradovic/update-jakarta-ee-community-june-2019

先月、Jakarta EEコミュニティ向けに毎月のEメールでのアップデートを開始したのとともに、これらの最新情報をブログとして公開し情報を共有することにしました。以後で、先月の出来事を確認まとめます。

Jakarta EE 8 release and progress

Jakarta EE 8は、javax名前空間の使用も含めて、Java EE 8と完全に互換性があります。 Jakarta EE 8仕様、Jakarta EE 8 TCKのデリバリ、およびJakarta EE 8互換のインプリメンテーションの作成プロセスでは、透明性を担保します。

Mike MilinkovichがJakarta EE 8に関するFAQを公開しました。

  • Jakarta EE 8は、javax APIに依存する既存のJava EEアプリケーションを壊すのか?
  • Jakarta EE 8の構成要素
  • Jakarta EE 8の互換実装
  • Jakarta EE 8のデリバリプロセス
  • Jakarta EE 8のリリース時期

Mikeのエントリをぜひご一読ください。

Frequently Asked Questions About Jakarta EE 8
https://eclipse-foundation.blog/2019/05/08/jakarta-ee-8-faq/
https://logico-jp.io/2019/05/14/faq-about-jakarta-ee-8/

Jakarta EE 8リリースの作業に皆様のご支援が必要です。プロジェクトチームはEclipse EE4Jプロジェクトに参加して、 Jakarta Specification Project NamesとJakarta Specification Scope Statementsの支援をお願いします。

EE4J Projects (Eclipse Enterprise for Java)
https://github.com/orgs/eclipse-ee4j/projects
Jakarta Specification Project Names
https://github.com/orgs/eclipse-ee4j/projects/11
Jakarta Specification Scope Statements
https://github.com/orgs/eclipse-ee4j/projects/10

Jakarta EE Platformの作業に参加したい場合、以下の3プロジェクトに対して注意しておくべきでしょう。現時点では、Jakarta EE 9の計画や準備について発言するのであれば、Jakarta EE.Next Roadmap Planningに参加するのがよいでしょう。

プロジェクト名プロジェクトの目的
Jakarta EE 8 Platform SpecificationJakarta EE 8のプラットフォーム仕様作成に関連する作業をトラックすること
Jakarta EE 9 Platform SpecificationJakarta EE 9のプラットフォーム仕様の作成に関連する作業をトラックすること
Jakarta EE.Next Roadmap PlanningJakarta EE 9リリースのロードマップおよび計画を定めること

jakartaee-platform
https://github.com/eclipse-ee4j/jakartaee-platform/projects
Jakarta EE.Next Roadmap Planning
https://github.com/eclipse-ee4j/jakartaee-platform/projects/1

Election schedule for Jakarta EE working group committees

3つの主要委員会(Committee、Steering Committee、Specification Committee、Marketing and Brand Committee)がJakarta EE Working Groupのさまざまな役割を推進していきますが、そのメンバーは選挙で選ばれます。選出された人は、Enterprise Members、Participant Members、Committer Membersのそれぞれを代表します。Strategic Membersにはそれぞれこれらの委員会に任命された代表がいます。

Eclipse FoundationはJakarta EE Working Groupに代わり、以下のタイムテーブルで選挙を実施しました。

  • 推薦期間:5月24日 – 6月4日(自己推薦は大歓迎)
  • 選挙期間:6月11日 – 6月25日
  • 当選者発表:6月27日

すべてのメンバーは、誰かを推薦するよう検討することが奨励されており、自薦も歓迎します。推薦期間は6月4日までです。推薦者がいる場合はelections@eclipse.orgに送ってください。

推薦期間が終了すると、全Working Groupメンバーに対し、候補者と投票のお知らせをメールで選挙権のあるメンバーに通知する旨の知らせが届きます。選挙プロセスは、Eclipse細則で定義されているように、Eclipseの “Single Transferable Vote”方式に従います。

Eclipse Foundation Governance Documents
https://www.eclipse.org/org/documents/

選挙終了後すみやかにこのメーリングリストで当選者を発表します。

以下のポジションがこの選挙で決まる予定です(訳注:Enterprise Member以外は決まったため、以下に追記してあります)。

Steering Committee
  • Enterprise Membersで2席
  • Martijn Verburg (London Java Community)
  • Ivar Grimstad
Specification Committee
  • Enterprise Membersで2席
  • Alex Theedom (London Java Community)
  • Werner Keil
Marketing and Brand Committee
  • Enterprise Membersで2席
  • Theresa Nguyen (Microsoft)
  • 空席
Transitioning Jakarta EE to the jakarta namespace

Java EEからEclipse Foundationへの移行プロセスはEclipse Foundationのスタッフや参加している多くのコントリビュータ、コミッター、メンバー、ステークホルダーが共同作業してきたものです。先月、javaxパッケージの名前空間はJakarta EEコミュニティが今後進化させることはないこと、そして既存の仕様名のようなJavaの商標をJakarta EEの仕様が利用してはいけないことが明らかになりました。これらの制限は当初想定されていたものではありませんが、javaxの変更には常に長期的な法的および商標の制限が含まれているため、Jakarta EEの最大の関心事になる可能性があります。

Jakarta EEを進化させるためには、新しい名前空間に移行する必要があります。会話をはじめるために、Jakarta EE仕様委員会はスムーズな移行を進めるため、新しい名前空間への移行方法に関する2つの提案(Jakarta EE 9でのビッグバン的な変更、Jakarta EE 10の新機能とJakarta EE 9以後の変更の都度の段階的な変更)を準備しました。これらの提案は出発点にすぎず、コミュニティからのより多くの提案を期待しています。

jakarta名前空間への移行方法に関するコミュニティでの議論は2019年6月9日に終了しました。

このトピックに関する以下のエントリを是非ご覧ください。

2019 Jakarta EE Developer Survey Results

Eclipse Foundationは最近、2019年のJakarta EE開発者調査の結果を発表しました。これは、エンタープライズJavaプログラミングのトレンドとクラウドネイティブテクノロジの採用についての調査で、1,800人近くのJava開発者を対象としたものです。 London Java CommunityやJava User Groupsを含むメンバー企業やパートナーと協力して2019年3月にEclipse Foundationが実施したこの調査の目的は、JavaエコシステムのステークホルダーがエンタープライズJava開発者コミュニティのもつ要件、優先順位、認識の理解を進めるためです。 結果は以下からご覧頂けます。

2019 Jakarta EE developer survey
https://jakarta.ee/documents/insights/2019-jakarta-ee-developer-survey.pdf

調査対象の1/3の開発者が現在クラウドネイティブアーキテクチャを開発しており、別の30%の人たちが翌年までには携わる予定があると答えています。さらに、クラウドで稼働するJavaアプリケーションの個数は来る2年で激増することが想定されており、32%の回答者が、この2年の間に自身が携わったJavaアプリケーションの2/3はクラウドで稼働すると考えています。また、回答者の40%以上が、Javaをクラウドで実装するためにマイクロサービスアーキテクチャを使用しています。

Community engagement

Jakarta EEコミュニティは非常に活発なものになるでしょう。特に、最新かつ最高のもので常に最新の状態に保つために使われるさまざまなチャネルではそうでしょう。Tanja Obradovicのブログでは、コミュニティエンゲージメントプランをチラ見せしています。

Jakarta EE Community Engagement
https://blogs.eclipse.org/post/tanja-obradovic/jakarta-ee-community-engagement

コミュニティエンゲージメントについては、Tanja Obradovicのエントリをご覧ください。

Jakarta EE Wiki

もうJakarta EE Wikiをチェックされましたか?このWikiには重要な情報が記載されています。例えばプロセスガイドラインやドキュメント、Eclipseガイドやメーリングリスト、Jakarta EE Workling Groupの重要事項などなどです。

Jakarta EE Wiki
https://wiki.eclipse.org/Jakarta_EE

このページはまだ作成途中であり、来る数週間、数ヶ月で進化していく予定です。コミュニティからのインプットやご提案を承っております。

Jakarta EE Community Update: May video call

直近のJakarta EE Community Updateミーティングは5月に開催されました。この中では以下のことが取り上げられました。

  • Jakarta EEの進捗状況
  • Java商標に対するJakarta EEの権利
  • javax名前空間からjakarta名前空間への移行(javaxからjakartaへのマッピング、再パッケージ化が必要な場合と名前空間への移行が不要な場合について)
  • 技術革新を妨げずに将来のバージョンでJava EE 8およびJakarta EEとの互換性を最大限に高める方法
  • Jakarta EE 8のリリース
  • PMC/Projectsアップデート、など。

Jakarta EEコミュニティアップグレードミーティングの議事録、ならびに動画がありますのでご利用ください。

Jakarta EE presence at conferences: May overview

5月はクラウドネイティブが街の話題になっていました。JAX 2019、Red Hat Summit 2019、KubeCon + CloudNativeCon Europe 2019などのコンファレンスの内容はクラウドネイティブとITモダナイゼーション成功のためのこの重要なアプローチの活用方法で埋め尽くされていました。Eclipse Foundationはクラウドネイティブテクノロジーの採用をより理解するため、コミュニティの意向を探るべくそこにいました。

JAX 2019
https://jax.de/en/
Red Hat Summit 2019
https://www.redhat.com/en/summit/2019
KubeCon + CloudNativeCon Europe 2019
https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019/

JAX 2019におけるJakarta EEの将来に関するTanja Obradovicの動画インタビューもチェックしてください。

EclipseCon Europe 2019: Call for Papers open until July 15

またこの時期がやってきました。EclipseCon Europe 2019のスピーカーの一員となるべくCfPを出してください。コンファレンスはドイツのLudwigsburgで2019年10月21日から24日に開催されます。CfPのEarly Bird submissionは7月1日まで、最終締め切りは7月15日です。Jamekaのブログエントリをご覧になって、すぐにCfPを出してください!

EclipseCon Europe 2019: Call for Papers open until July 15 – Submit a talk today!
https://blogs.eclipse.org/post/jameka-woodberry/eclipsecon-europe-2019-call-papers-open-until-july-15-submit-talk-today
Call for Papers
https://www.eclipsecon.org/europe2019/cfp

9月10日に予定しているJakartaOneライブストリーミングコンファレンスに向けて鋭意作業中です。Call for Paperの締め切りは、7月15日13時07分(UTC、JSTでは同日22時07分)までです(訳注:本文では7月1日でしたが、延長されています)。

JakartaOne
http://jakartaone.org/

Jakarta EEに興味を持っていただきありがとうございます。  jakarta.ee-wg@eclipse.org  メーリングリストをサブスクライブし、Jakarta EE Working Groupに参加して、わくわくする未来に向けてJakarta EEを導く支援をお願いします。

これからのクラウド向けエンタープライズJavaプラットフォームを一緒に作っていくことに興味がある方は、ブログをご覧になって、月例のJakarta Tech Talksにご参加ください。Eclipse newsletterのサブスクライブもお忘れなく。

Jakarta EE Blogs
https://jakartablogs.ee/
Jakarta EE Tech Talks
https://www.meetup.com/ja-JP/jakartatechtalks_/
Eclipse Newsletter
https://www.eclipse.org/community/eclipse_newsletter/

Jakarta EE 8に関するFAQ

このエントリは以下のエントリをベースにしています。
This entry is based on the following one written by Mike Milinkovich.
Frequently Asked Questions About Jakarta EE 8
https://eclipse-foundation.blog/2019/05/08/jakarta-ee-8-faq/

Mike Milinkovichは先週の自身のエントリに対する反応に対して、再度 Jakarta EE Steering Committeeの一致した見解を表すとともに、Jakarta EEの最初のリリースであるJakarta EE 8(Java EE 8完全互換、javaxパッケージ名前空間を使用)に関する質問に答えることを目的として、上記エントリを発表しました。

Update on Jakarta EE Rights to Java Trademarks
https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/

なお、このエントリに記載している内容は、名前空間が変わる将来のJakarta EEのリリースに関するものではありません。現在jakarta-platform-devメーリングリストで活発な議論が行われていますので、興味がある方はご参加ください。現時点では、Jakarta EE Spec CommitteeがJakarta EEロードマップの次のステップを決定するまでに約1ヶ月かかると見込んでいます。

Mailing list: jakartaee-platform-dev
https://accounts.eclipse.org/mailing-list/jakartaee-platform-dev
アーカイブ
https://www.eclipse.org/lists/jakartaee-platform-dev/

Will Jakarta EE 8 break existing Java EE applications that rely upon javax APIs? (Jakarta EE 8はjavax APIを使う既存のJava EEアプリケーションを壊そうとしている?)

いいえ、Jakarta EE 8は、javaxパッケージ名前空間のAPIに依拠している既存のJava EEアプリケーションを壊すことはありません。Jakarta EE 8はJava EE 8の完全互換を目指してします。Jakarta EE 8はJava EE8で指定されているのと同じjavax名前空間、同じjavax API、同じ動作が指定されるはずです。Java EE 8のTCKをパスした実装は、Jakarta EE 8のTCKにもパスするでしょう。なぜならJakarta EE 8のTCKはJava EE 8のTCKと同じソースを基にしているからです。Jakarta EE 8はJava EE 8アプリケーションやjavax APIの利用に対して変更を加える必要はありません。

What will Jakarta EE 8 consist of? (Jakarta EE 8の構成要素)

Jakarta EE 8仕様は以下のようなもので構成されるでしょう。

  • Java EE 8仕様完全互換
  • 同じjavaxパッケージ名前空間を使う、同じAPIそしてJavadocを含む
  • オープンソースのライセンス下でJakarta EE 8 TCKを提供。このTCKはJava EE 8 TCKをベースにしており、完全な互換性がある
  • Jakarta EE 8 Platform仕様を含む。これにはJava EE 8 Platformと同じプラットフォーム統合要件が記載されている。
  • Jakarta EE 8仕様がリリースされたタイミングで、Jakarta EE 8 Platformの複数の互換実装(Compatible Implementations) に言及
  • 実装がJakarta EE 8互換であることを説明するための互換性ならびにブランディングプロセスを提供

Will there be Jakarta EE 8 compatible implementations? (Jakarta EE 8互換実装はあるか?)

はい。Jakarta EE 8仕様がリリースされるタイミングで、Jakarta EE 8 Platformの複数の互換実装が利用可能になる予定です。すべてのJava EE 8互換実装もまたJakarta EE 8互換実装であり、Jakarta EE 8 Working Groupに属するベンダーは自社のJava EE 8互換実装をJakarta EE 8互換として認定する予定です。さらに、Jakarta EE TCKはオープンソースのライセンス下で入手できるので、他のテクノロジーベンダーが自身の実装をJakarta EE互換と実証するためのハードルを下げる予定です。より低コストかつより自由なJakarta EEの商標ライセンスにより、 多くのテクノロジープロバイダーがEnterprise JavaコミュニティにおけるJakarta EEブランドを活用し強化できます。Jakarta EE 8はオープンでベンダーニュートラルなコミュニティ主導のプロセスの下、Jakarta EEテクノロジーの進化のための新たなベースラインを提供します。

What is the process for delivery of Jakarta EE 8 (Jakarta EE 8のデリバリに関するプロセス)

Jakarta EE 8仕様のデリバリプロセスは完全に透明性があり、Jakarta EE Specification Processに完全に従います。 Java EE8コンポーネント仕様に対応した最初のJakarta EE8コンポーネント仕様のドラフトが、数週間以内に提供される予定で、これらには、関連するAPIを定義するJavadocと、互換性テスト用のTCKが含まれます。仕様文書を公開するには、この文書の著作権ライセンスを取得する必要がありますが、Eclipse Foundationでは、OracleとIBMからの貢献により、両社の著作権ライセンスを取得しています。できるだけ多くのコンポーネント仕様を公開するため、Jakarta EE 8 Platform仕様文書と、必要な残りの著作権ライセンスも取得するつもりです。過去にJCPでJava EE仕様に貢献したことがあれば、今後Jakarta EEでその貢献を利用するためのライセンスを提供をお願いするためにEclipse Foundationからご連絡することになるでしょう。このようなライセンス提供は、新しい仕様プロセスとJakarta EEコミュニティをサポートする上で重要なステップとなるでしょう。これらのドラフト仕様は、オープン・コミュニティ・プロセスにて最終仕様に発展します。ぜひ仕様プロジェクトに参加してください。

When will Jakarta EE 8 be delivered? (Jakarta EE 8のリリース時期)

Jakarta EE Working Groupは2019年秋までにJakarta EE 8仕様の最終版をリリースしたいと考えています。これはオープンなコミュニティ主導の取り組みであるため、Jakarta EE仕様の推進、Jakarta EE 8 TCKのデリバリ、Jakarta EE 8互換実装というプロセスには透明性があります。