| Re: [jakarta.ee-community] A Composable Platform Over Profiles |
|
I believe that we mean the same thing but your term "supported" is better than my "optional".
Very often there are just a few mandatory dependencies for Java EE specs but a lot of supported ones. However, most of the time the supported dependencies aren't clear as they are thrown into a single "supported in Java EE container" basket. It would be better specify individual supported dependencies and the functionality they enable.
Another example for JAX-RS - if it dropped support for its own DI then injection would work only when in a CDI container (it wouldn't have to be Full/Web Jakarta EE container). Otherwise, plain Java SE API would be used
to retrieve values that would be injected with CDI.
There's no sense to drop JAX-RS specific DI now, but for new specs, functionality from other specs should be reused as much as possible but Java SE API should be available as a fallback if the dependency isn't present.
Cheers, Ondrej Mihályi Senior Payara Service EngineerPayara Server – Robust. Reliable. Supported. E: ondrej.mihalyi@xxxxxxxxxxx | T: +1 415 523 0175 | M: +421 902 079 891 ---------------------------------------------------------------------------------------------------------------------- Payara Services Limited, Registered office: Unit 11, Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZRegistered in England and Wales: 09998946 | www.payara.fish | info@xxxxxxxxxxx | @Payara_Fish From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of reza_rahman <reza_rahman@xxxxxxxxx>
Sent: 02 May 2018 15:35:11 To: Jakarta EE community discussions Subject: Re: [jakarta.ee-community] A Composable Platform Over Profiles I am nitpicking here, but there is a distinction between what dependency is required vs. what is merely supported. For example, I think JAX-RS could require only Java SE but support CDI, Bean Validation, JSON-P, JSON-B, Security,
etc when present in the environment.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx>
Date: 5/2/18 9:28 AM (GMT-05:00)
To: Michael Remijan <mjremijan@xxxxxxxxx>, Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] A Composable Platform Over Profiles
All Jakarta EE specs supporting bare metal Java SE as a baseline is appealing and I would go that direction. But it should be a recommendation not mandatory because some specs may make sense only in the CDI container or build on another spec (like JSON-B which depends on JSON-P).
What's more important and is missing in the specs is clear documentation of dependencies. Many specs are already usable in plain Java SE (CDI, JPA, etc.) and provide additional features under certain conditions. But it's easy to find out the conditional features provided.
I would really like to have all mandatory and optional dependencies stated for each spec. For some, it will be plain Java SE. For some, there will be some optional dependencies. And for others, there will be additional mandatory dependencies on top of Java SE.
An example for a future version of JAX-RS: - mandatory: Java 8, supports java 8-11 - optional: CDI, EJB, Interceptors, ... (with a reference to a chapter in the spec which describes the additional behavior)
Then it would be easy to create multiple profiles by selecting a useful subtree of dependencies. Right now, many specs can be used individually in Java SE but it's not defined how they could be combined with other specs except combining them all together in Full/Web profile. At the current state, I find it hard to create another profile with only some selected specs because the dependencies aren't clear.
Ondro
Cheers, Ondrej Mihályi Senior Payara Service EngineerPayara Server – Robust. Reliable. Supported. E: ondrej.mihalyi@xxxxxxxxxxx | T: +1 415 523 0175 | M: +421 902 079 891 ---------------------------------------------------------------------------------------------------------------------- Payara Services Limited, Registered office: Unit 11, Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZRegistered in England and Wales: 09998946 | www.payara.fish | info@xxxxxxxxxxx | @Payara_Fish From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of reza_rahman <reza_rahman@xxxxxxxxx>
Sent: 02 May 2018 14:14:07 To: Michael Remijan; Jakarta EE community discussions Subject: Re: [jakarta.ee-community] A Composable Platform Over Profiles I think you are basically saying all Jakarta EE specifications should support bare metal Java SE (or make minimal assumptions about a profile), ship standalone and have a standalone TCK.
I do think this is essential going forward.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Michael Remijan <mjremijan@xxxxxxxxx>
Date: 5/1/18 3:02 PM (GMT-05:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] A Composable Platform Over Profiles
> I
argue
that a better approach would be to define the platform as a palette of composable standards[1]
I
completely support this but I don't think it takes it far enough. For an "enterprise" standard to survive in the coming years, I think it must become more "Spring like" meaning the standard must become a framework of libraries which development teams can
import into their application in any combination they see fit. I truly believe if JakartaEE continues to develop specifications for a *server*, then it won't survive the coming years. Organizations just don't move their servers fast enough. They are slow
to upgrade existing servers and forget about moving to a different EE server. Organizations typically are OK with updating libraries and frameworks - they don't care what's running inside the server - just as long as they don't need to update the server itself.
It's
not uncommon for me to see the latest and greatest frameworks and libraries shoehorned into 10+ year old EE servers because organizations can't move on their server technology. Granted, this is not all organizations. But, it is a huge appeal of Spring being
able to bring in new features without server updates.
On Tuesday, May 1, 2018 01:11:23 PM CDT, Jason Greene <jason.greene@xxxxxxxxxx> wrote:
Over the years there has been vigorous debate about what makes the perfect profile. “Should spec X be included or not?” “Should we create a “plus” variant of the web profile?" “How many profiles is too many?" “How many is too few?" Recent threads
you can see the topic rising again with Stable and Legacy profile proposals, and debate about whether or not JAX-WS should be part of the platform.
A related issue is that EE compliance is overly strict. An implementor must ship exactly what a profile defines, with limited exceptions on variation. As an example, a certified web or full implementation can’t ship a newer version of the Servlet
API, even though it’s fully backwards compatible. The default run mode / config of the implementation is also not allowed to enable a subset of the profile, even though the implementor’s primary audience may not need all of the specified technologies.
The idea behind a rigid platform certainly had merit, and it arguably led to the very strong level of portability across containers we enjoy today. However, this one-size-fits-all approach just no longer fits the current state of software, with
developers expecting a high degree of application specific tailoring.
I argue that a better approach would be to define the platform as a palette of composable standards[1], where profiles define only what must be available for a developer to choose from, and only limit the version of a given standard to the minimum
that must be provided[2]. Under this model there is less of a need to define a perfect profile, since it can be freely adjusted by the developer to fit his or her needs. Instead, all that matters is that we have a sensible array of choice.
[1] It’s worth noting that this would require the TCK to be split up, as discussed previously, to facilitate the flexibility required in testing a near arbitrary combination of standards.
[2] For clarity, the full and web profiles would still be versioned (8.0 etc) as today, this is just a rule softening to support variation.
--
Jason T. Greene
Chief Architect, JBoss EAP
Red Hat
_______________________________________________
jakarta.ee-community mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
|