You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
Ed Burns
edburns
Ed Burns is a Principal Architect for Java on Azure at Microsoft and has worked on a wide variety of client and server side web technologies since 1994.
At the 2025-04-29 Platform call, this proposal was declared dead-on-arrival.
Background for making the request
An important set of EE 11 TCK tests are currently failing: the subset of the Connectors specification relating to the use of Servlet and JSP with Connectors. For discussion: ConnectorServletJsp [tck-2183]
The cause of the failure has been determined to not be in the EE 11 TCK.
The same set of tests when run with GlassFish 7 do not fail.
Therefore, we assert the failure is an implementation bug in GlassFish 8.0-JDK17.
A CDI (Contexts and Dependency Injection) Portable Extension is a feature in CDI that allows developers to extend the CDI container's functionality in a portable, container-independent way. Portable extensions can leverage the CDI SPI (Service Provider Interface) to interact with the CDI container at various lifecycle events such as initialization, shutdown, and during the processing of beans.
Key characteristics of CDI Portable Extensions:
Portability: They are designed to work across different CDI implementations and containers.
Integration: They can interact with the CDI container lifecycle and modify the behavior of the CDI environment.
Customization: They allow adding custom behavior, such as registering new beans, interceptors, decorators, and observers.
In contrast, a non-portable CDI extension would typically be specific to a particular CDI implementation or container and may use non-standard APIs, making it less portable and reusable across different environments.
Ed Burns hat mich gebeten euch auf seine JUG-Tour im Frühjahr aufmerksam zu machen.
Wie in den vergangenen Jahren wird er an der JavaLand teilnehmen, d.h. er ist von Mitte März bis Mitte April in Deutschland und würde sich über zahlreiche Besuche bei unseren User Groups freuen.
Er hat folgende Themen im Repertoire:
KI
Java und KI mit LangChain4J - insbesondere mit JakartaEE oder MicroProfile.
To: platform-dev
Subject: [BALLOT] Proposal for bringing EE 11 Web and Platform specs to ballot by end of CY 2024
Executive summary
A +1 vote means you, as a Platform Project committer, agree we, as the Platform Project, will submit the ballots for EE 11 Web and Platform profiles with a TCK exclusion list containing all the non-passing appclient tests as of 2024-12-15.
Measuring tire tread depth with a coin is a simple and effective way to check if your tires are still safe to use. Here's how you can do it using a penny:
Grab a penny: Make sure it's clean so you can see the details clearly.
Insert the penny: Place the penny into the tread groove with Lincoln's head pointing down.
Check the tread: If you can see the top of Lincoln's head, your tread is less than 2/32 of an inch deep, and it's time to replace your tires. If part of his head is covered, your tread is still above 2/32 of an inch and your tires are in better shape⁴⁵.
For a more proactive approach, you can use a quarter instead. Insert the quarter with Washington's head down. If the tread covers part of Washington's head, your tread depth is above 4/32 of an inch, which is better for wet conditions⁴.
Regularly checking your tire tread can help you maintain better traction and safety on the road. Do you have any other questions about car maintenance or anything else?
Jakarta EE means IT investment stability. The pillars of this stability are time and compatibility.
Let's take time. Enterprises need stability measured in many years, in the face of a highly volatile product marketplace. But if you continually evolve a product over many years, it is extremely important to manage technical debt. Technical debt is what happens when you must decide between doing "the right thing" and "the quick thing" and you choose the latter. On a huge product like Jakarta EE, there are hundreds of such decisions in all parts of the product, taken over the multiple decades development. For the specifications, we skew heavily towards doing the right thing. For other aspects of the product, the skew is more balanced. This is where compatibility testing enters the discussion. Jakarta EE asserts compatibility across vendor implementations using the Test and Compatibility Kit (TCK). The TCK is a very complicated software tool that itself is subject to accruing technical debt. How
I am humbled and honored to find myself in a position of helping to deliver the next iteration of Jakarta EE. I've held many roles in J2EE/Java EE/Jakarta EE over the decades: implementer, spec lead, advocate, author, tester, and more. My current role, however, is a new one for me release co-coordinator.
In this role, I co-lead (along with Arjan Tijms) the Jakarta Platform project, which is responsible for delivering the finished Jakarta EE specification (and component specifications), the corresponding TCK, and at least on ratifying compatible implementation for all of the specifications. Importantly, there need not be one single monolithic implementation that satisfies all the component TCKs at the same time, but there must be one single monolithic implementation that passes the Platform TCK.