I think you should probably restrict that to the CDI list for now, on a platform level IMO it feels too noisy. Providing a summary of what was decided in the platform call (or sharing the results again here) sounds better. Werner For me this sounds mostly like a straw men argument because bean-discovery-mode ALL is still perfectly allowed in the spec and even MUST be supported, even in CDI-lite, isn't? See page 3 and 175 of the spec. Thus the code for handling it in the container is still all needed. So what do existing users and container vendors gain exactly? The entire idea was to identify a subset of CDI that 1.
A subset which adds 40% new interfaces and code to the container but is technically purely optional? Doesn't sound like a subset to me, but rather the contrary. I can proof this, because Apache OpenWebBeans does not implement cdi-lite nor has any of the cdi-lite classes in it's spec api jar. Still we pass a major portion of the CDI-4.0 TCK. Apart from that, there have been lots of complaints against how CDI-lite got handled. Both in the EG meetings and in tickets. More likely most EG members speaking up got frustrated because they got totally ignored. Oh, and before this wrong argument gets repeated here as well: no, the criticism isn't just popping up way too late. Much of the criticism got verbalised on EG meetings and written into tickets a long time ago, way before the spec was made final. Only the user-code breaking change of the bean-discovery-mode default was discovered just now.
Am 30.01.2023 um 12:56 schrieb Ladislav Thon <lthon@xxxxxxxxxx>: I don't know where the idea that CDI Lite was intended as a "purely optional build-time add-on to CDI" comes from, because that has never been the point. The entire idea was to identify a subset of CDI that 1. sheds of some baggage that has historically seen little usage (and also high implementation complexity), 2. can be implemented in a build-time architecture. Note the word "subset" -- and while the precise form of subsetting has received plenty of debates (mainly revolving around extensions), not even once was this considered an add-on. Hence, everything affecting CDI Lite by nature affects the entirety of CDI. I have been pretty confident everyone understands that, because this was the most discussed topic since the very beginning, even before the posts I linked in my previous email. Notably: In some build-time architectures, annotated bean discovery is much easier to implement than "all"; in others, it is the only option. To remain a proper subset, changing the default bean discovery mode was one of the options. (Side note: I have myself proposed another option, an alternative bean archive descriptor "beans.properties", with detailed documentation of compatibility impact. It was considered "too complex" by some.) It is true that the poll had a relatively small number of participants, but it is still 2x to 4x more than the number of active participants in the CDI specification. Too many past and present CDI committers willingly chose to remain silent, even if there were plenty of calls for opinions _on this very topic_ (links in my previous email). I don't know what more we could have done to raise awareness and increase activity. Hi Ladislav! True is that it has been discussed for CDI-lite. That was at a time when CDI-lite was still seen as just a purely optional build-time add-on to CDI. A topic with only very little interest for most Jakarta EE users. In practice it really only affects Quarkus. As one can see as there were only 16 votes in a public survey. I don't call this a broad support to break the spec for everything else than CDI-lite. Basically every of those discussions also did emphasis CDI-lite. Digging deep into the archives I could only find ONE very mail not explicitly mentioning CDI-lite. But this mail got no answer, got no VOTE, nothing. I'm totally fine with having 'annotated' in CDI-lite. That's perfect, I do have no objection. But the current TCK assumes this rule also applies for CDI-core and full. Which is the real backward compat problem, got never really discussed, there was no VOTE on, and JakartaEE rules explicitly forbid it.
Hi, first off: wide consensus hasn't always been reached, but that doesn't mean that criticism has been ignored and not taken into account. As far as I can tell, we've always bent over backwards to reply, reply again, and as much as practically possible also satisfy all requests without compromising the end goal. When it comes to the breaking change of empty beans.xml treatment specifically. This has been discussed extensively both on this mailing list: As well as on the CDI meetings: - 2021-01-12 - 2021-03-02 - 2021-04-13 - 2021-04-20 - 2021-04-27 - 2021-05-04 - 2021-05-11 We even had a poll that both CDI committers and users answered: There were multiple options, all explained in decent amount of detail, and the one where empty beans.xml changes meaning from all to annotated discovery has won pretty clearly. Now, I don't know if we broke some arcane process we weren't aware of -- but this certainly hasn't come as a surprise. The discussions about this change occurred 2 years ago -- there has certainly been plenty of time to raise this concern. Good points! CDI- 'lite' (which is actually not lighter but adds 40% classes in addition, creating even bigger and harder to maintain projects) could habe been done as optional 'CDI runtime extensions' feature. Criticism got raised from quite a hand full of current and former EG members, but all got ignored. But then we are also back at the 'optional features' discussion. Those were afaiu officially forbidden only to release specs with optional features a few weeks later. Make the rules, break the rules...
Guess there are several good topics there: 1. Does EE becomes a new kind of project and no more a spec and portable abstraction with backward compat guarantees (which was until now the only value - but it is a key one for enterprise)? 1.bis. Does EE accept discussions and does a group on top of specs guarantees the well behaving and consistency as it was before or is it individual driven? (See 2.b for ex). 2. Does CDI work on its broken and with no common agreement issues 2.a. backward compat breakages (beans.xml, dropped methods like event ones, ...). Most can be restored easily while nobody adopted it. 2.b. lite profile which is mainly done for an impl with *no* real gain in terms of perf (startup or runtime or even mem) and creates a very ambiguous state where it looks build time friendly whereas only runtime is defined by the spec so really exists and in this case means it just duplicates the api it adds so no user help but more a new mess. Also note community didnt agree on that at all and it was forced even if several alternative were proposed. The drop of oracle driven dev mutated the ecosystem and the IT ecosystem changed too but EE does not highlight much benefit anymore for companies now due to the new behaviors and releases content (purely tech) so i guess a lot of efforts have to be done to either fix it or to assume it and explicit the project is no more related to its roots. Both sound ok to me but staying in between is probably to kill itself slowly IMHO. For the record: It seems the whole decision about whether to use semantic versioning is NOT settled yet. The ticket for it is still open and unresolved to this very day: I also found no VOTE about it on any list. So to me it seems that the handling was not really kosher. Good at creating rules, even better at breaking them immediately... But then again, a more important question is: does it make sense for users/consumers of Jakarta EE? Is it worth for them, or does it only benefit one certain implementation (which is not even Jakarta EE but seems to be the origin of this change)? Imo we should raise awareness that backward compatibility in the past used to be one of the key selling arguments pro JavaEE. Do we want to ditch this if there is no really good reason (as in this specific case, see my question list above)?
Looping in the CDI mailing list so that the right folks can provide additional context. My guess is that these decisions were not taken particularly lightly. I think it is easy to see performance is a key value proposition for CDI Lite/Jakarta EE Core runtimes. There is some evidence to suggest that this line of thinking actually is making Jakarta EE more relevant to newer audiences. On 1/28/2023 1:28 PM, Mark Struberg wrote: Sorry, but the whole referenced email threads does NOT cover pruning rules at all! The whole question is about guaranteed stability over a forseeable version range. I have no problem with deprecating features.?? I also have no problem with pruning long time deprecated code. But I DO have a problem with intentionally (or planlessly) breaking backward compatibility from one EE version to the next *WITHOUT* any reason! For swapping the default meaning of empty beans.xml files please ask yourself: * was there really no other way to solve the problem? * was there a groundbreaking new feature which would not have been possible without this change? * was this change thus really technically necessary? * was it worth to break the world just because someone thought it might be funny? PS: failures as such can happen, no problem. But then let's solve/undo those failures and not codify them!
I created an issue to update the page: I don't know that there was ever a formal vote, but the context is found in this issue and platform thread. https://github.com/eclipse-ee4j/jakartaee-platform/issues/449 I would also like to see the discussion or minutes from a meeting where this was decided. I believe that this is a thing that requires a ballot. It??s true that we had to bend the rules for Jakarta EE 9, but it's not a reason to keep bending the rules for all the future releases. It's also true that Jakarta EE 10 dropped some deprecated functionality, which used to be allowed in Java EE but the rules for Jakarta EE in https://eclipse-ee4j.github.io/jakartaee-platform/CompatibilityRequirements don't cover this option. Even if those rules are still valid, they aren't complete, and even state this explicitly in one place: XXX - This section needs to be updated with new rules for the actual removal of APIs and specifications from the Jakarta EE platform as anticipated in Jakarta EE 9, similar to what???s done for the Java SE platform.
I suggest that we update the https://eclipse-ee4j.github.io/jakartaee-platform/CompatibilityRequirements page to be up to date with the current Backwards Compatibility Requirements (Decided by whom? Jakarta EE Steering or Specification Committee??? ). We can't accept that we have an official document that we don't follow, and, on the other hand, have some unwritten non-transparent agreement that some of us follow.
All the best, Director, Jakarta EE expert Omnifish O??, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932 Wow, really. I'm speechless. Do the people who decide such things IN THE DARK (aka undocumented it seems) mean this serious? I mean, really this got nowhere made public, was it? Please point me to the articles covering this! That would imo TOTALLY ditch the whole purpose of JavaEE / JakartaEE in my eyes. If a project wants to use quickly evolving technologies, then they do usually NOT choose JavaEE. JavaEE - in my experience - was previously chosen by companies and governmental organisations whose primary goal is stability over a very long period of time. We are talking in 5 to 10 years of stability. Now when you folks ditch this, then I fear we will loose banks, governments, etc. Those 'slow moving dinosaurs' in my experience used to be the main users of JavaEE. They provide the main money, they have the most code running in JavaEE. There is a good reason why people used to say "JavaEE is these days COBOL". That's because COBOL apps are running till today. Like many JavaEE apps I see at customers. Many of them older than 10 years, but still perfectly maintainable. And for container vendors: why should I pass a TCK if the rules are totally turned around in 2 years anyway? I mean this is a joke, really :( PS: Scott, I understand you are just the messenger, so no personal offense meant.
We have switched to a semantic versioning approach, but I don't see that this was captured in that page or elsewhere. That notion of backwards compatibility was completely violated in the EE 8 to EE 9 release due to the package rename, and in general, maintaining such stringent backwards compatibility was seen as counterproductive to evolving the platform. Hi! I wanted to ask whether the following document is still valid and applies to Jakarta EE10? Or is there a newer version and where can I find it?
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<449.png><449.png>_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ cdi-dev mailing list cdi-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ cdi-dev mailing list cdi-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev |