Skip to content

Instantly share code, notes, and snippets.

View edburns's full-sized avatar

Ed Burns edburns

View GitHub Profile
@edburns
edburns / 20250423-jea-519-to-spec-committee.md
Last active April 25, 2025 17:20
20250423-jea-519-to-spec-committee.md

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 failure is so severe that the tests do not even start.
  • 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.
  • The cause of the failure has been determined to be ClassLoader related. Such failures are beyond the remit of all but the most experienced GlassFish experts on the Platform TCK team.
@edburns
edburns / 20250218-cdi-portable-extension.md
Created February 18, 2025 20:13
20250218-cdi-portable-extension.md

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.

Summary:

@edburns
edburns / 20250109-eb-6431-iJUG-tournee.md
Last active January 15, 2025 20:38
20250109-eb-6431-iJUG-tournee.md

Version 2025-01-10 17:58 EST

Ed Burns iJUG Tournee Rund um JavaLand 2025

Ich habe alle euer JUG Städte aufs eine Google Map inkludiert.

Städte ohne Terminvorschlag

  1. Bonn
@edburns
edburns / 20241118-eb-6419-daniel-van-ross-jug-email.md
Created November 30, 2024 15:43
20241118-eb-6419-daniel-van-ross-jug-email.md

Liebe JUG Leader,

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.
    • KI unterstützte Java Migration
  • Azure
@edburns
edburns / 20241121-jea-480-platform-ballot-proposal-email.md
Last active November 25, 2024 14:30
20241121-jea-480-platform-ballot-proposal-email.md

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.

Details

Greetings programs,

@edburns
edburns / 20241118-eb-6421-jugch-tournee-prospekt.md
Last active November 18, 2024 11:00
20241118-eb-6421-jugch-tournee-prospekt.md

Subject: Ed Burns bittet JUGCH-Mitglieder, bei der Erstellung der JUG-Tour vor oder nach dem JavaLand zu helfen

Wie in vergangenen Jahre werden Ed Burns noch mal nach JavaLand reisen. Er bietet uns die Gelegenheit ihm als JUG Referent an.

Ed stellt die folgendes Themenmenü vor. Er kann natürlich echter Abstrakte schreiben, nach unser Wunsch.

  • KI
    • Java und KI mit LangChain4J -besondersweise mit JakartaEE oder MicroProfile.
  • KI unterstützt Java Migration

Subject: Ed Burns bittet iJUG-Mitglieder, bei der Erstellung der JUG-Tour vor oder nach dem JavaLand zu helfen

Wie in vergangenen Jahre werden Ed Burns noch mal nach JavaLand reisen. Er bietet uns die Gelegenheit ihm als JUG Referent an.

Ed stellt die folgendes Themenmenü vor. Er kann natürlich echter Abstrakte schreiben, nach unser Wunsch.

  • KI
    • Java und KI mit LangChain4J -besondersweise mit JakartaEE oder MicroProfile.
  • KI unterstützt Java Migration
@edburns
edburns / 20241006-coin-tire-tread-depth-technique.md
Last active October 6, 2024 22:19
20241006-coin-tire-tread-depth-technique.md

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:

  1. Grab a penny: Make sure it's clean so you can see the details clearly.
  2. Insert the penny: Place the penny into the tread groove with Lincoln's head pointing down.
  3. 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⁴⁵.
  4. 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?

Source: Conversation

Long version

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

@edburns
edburns / jea-382-responsiveness-to-developer-needs.md
Last active September 23, 2024 23:53
Write draft of blog post

Introduction: I'm humbled and honored

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.

In the spirit of transparency that I was fortunate enough to start over [two decades ago](https://www.ridingthecrest.com/blog/2004/06/28/welcome-javaserver-tm-faces-implemen