Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ejb-dev] [cu-dev] Jakarta EE 10 and breaking changes
  • From: Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx>
  • Date: Sun, 23 May 2021 10:15:24 +0000
  • Accept-language: en-GB, sk-SK, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=payara.fish; dmarc=pass action=none header.from=payara.fish; dkim=pass header.d=payara.fish; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tCMPcGGxdaTIl+65oo51NXeNXJ45kI/+LJQbEtqH7w0=; b=j30t2zGfHc8JEv3bNpTD01YloQ+nLyTJsu1aIWTThMjdneL32MD4kH2ll5QbSgzaetaLlU6aBW5Ik2bbh26nDIG429iLJUumIzf07HzGwOvT3JIwBN0YHk8SAp+Qr1VnEXhrS0nD02572VcZaSSAxQzGUmOTOFLCW9ImJt26e5blykr8ZQ57Zv/tUJf3IjGcn4UbKEShtqAm+OEASpQVj0zwAFMO/raPSZCQwO0MhSBlJsly7/zRCUYTsWjhJKTv6wxCghEjj80H06S+ta4Toqm6F1YyfmXksJ3dqnso0IG8zA46YT5jf2Hy0RWx9CFtp7vqIFnCHaZaSdDO+MvgCA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Se4qnJMFDjEIPM4JUkj9uGHHXJyCEyoDbOw65G4IKC6Nbnpv8+rghqwpldeymVhojeyil6ATaeengQACMxe7q030L17mZHP3zmcQRv6tQnX86PyBAeCG+7FsTuKwpGJiChTZ9WatQK4cIK3/5Y2OhN15D/6mfoo/86c3/ogkD5snfoEyNdPw8PRHuDo3alh4yAfzhSiuzdpCPYKRd5ppSt07Y2KyNb2CXRs3qVNzIwvW/bS3Mz/Gmz2va2amrEu4b9WDdjfwC8aXL4goLOjTuuosQeiTiW0iSCVdWpLX3tT+bpdtKHPzPtN/E1WiCJPzfATZZyDR1OM4xHjdUhlTEw==
  • Delivered-to: ejb-dev@xxxxxxxxxxx
  • List-archive: <https://www.eclipse.org/mailman/private/ejb-dev/>
  • List-help: <mailto:ejb-dev-request@eclipse.org?subject=help>
  • List-subscribe: <https://www.eclipse.org/mailman/listinfo/ejb-dev>, <mailto:ejb-dev-request@eclipse.org?subject=subscribe>
  • List-unsubscribe: <https://www.eclipse.org/mailman/options/ejb-dev>, <mailto:ejb-dev-request@eclipse.org?subject=unsubscribe>
  • Thread-index: AQHXT7qhUUxyunJa5U6TlJpJmEhIFQ==
  • Thread-topic: [ejb-dev] [cu-dev] Jakarta EE 10 and breaking changes

Hi,

I agree that the best way to go is to replace EJB features in other specs by a modern approach rather than just copy the existing functionality from EJB. Otherwise there would be 2 competing ways to do the same things, with EJB and without EJB. And we would possibly have 2 sets of annotations with the same names but different package names which has been a pain with Java EE in the past (JSF vs. CDI ViewScoped, EJB vs. DI SIngleton, etc.).

It's better to rethink specific EJB features and implement them in other specs so that they fit those specs and ideally use different names for annotations. It would also allow leaving legacy behind in the EJB spec (e.g. XML config) if it's no longer useful.

On the other hand, EJB spec should be regularly updated to support the new functionality in other specs. E.g., it even now it should add support for specifying the executor service to use for running @Asynchronous methods. If the concurrency spec provides a variant of Asynchronous annotation (hopefully with a different name), the EJB spec should adopt it so that it works seamlessly with EJBs in the same way as the existing @Asynchronous annotation. Users wouldn't need to think about which annotation to use because both the old and the new one would work in the same way.

This could also lead to a subprofile/subspec of EJB that would only build on top of the features in other specs (e.g. Stateless would be just a stereotype on top of CDI annotations in the concurrency spec and all would run in the CDI container). This subprofile could remain in the Jakarta EE Platform spec while the rest would become optional or deprecated.

The key point is to synchronize with other specs to make sure that the essential parts of the EJB spec are provided in some way by other specs (mostly CU, JTA, CDI) and that a simple EJB profile can be defined as an aggregation of those specs plus some glue.

Ondro

+1 Tracy!
would recommend that the EJB specification not be updated.  Developers that are
content with the current version of @Asynchronous, @Schedule, @Timeout, @Lock

can stick with the old EJB versions, but those looking for the newer, simpler, modern,
cloud friendly versions should move to use CDI and concurrency.
I also think CDI + Concurrency should cover most of the useful features offered by EJB. In this case, EJB can fade in the background over the time. We would have less headache with the integrations.

Thanks
Emily

Back to the top