| Re: [jakarta.ee-spec.committee] [Straw poll] namespace policy for existing specifications moving to the Jakarta specification project |
|
TLDR
If we're just sticking to the original poll options: number 1. If we're not, some sort of option that strongly encourages the jakarta namespace.
Expanded Thoughts
Without necessarily wanting to muddy the waters with yet another option, we could combine options 4 and 1.5 (lets call this 4.5):
"We prefer jakarta namespaces and evaluate exceptions on a case-by-case basis.
Existing specification projects are encouraged to move all of their API package namespaces to jakarta at their next major release after they've moved to the Jakarta specification project."
It's similar to option 4 but with a codification of "temporary exceptions" to aid cases where it's appropriate e.g. donating existing specifications.
This would essentially be setting the original javax to jakarta migration process as the precedent for future migrations.
The cynic in me does see a small malicious compliance avenue with the specific wording of 1.5 and 4.5 though: only ever do minor releases to retain your original namespace.
Would we allow a specification that transitioned to jakarta with a "temporary" namespace exception to indefinitely just do minor releases?
If we wanted to stamp that out we'd need some extra wording to prevent gaming the system. That or simply some project oversight.
Even outside of someone going for "malicious compliance", I do worry that this potentially just kicks the proverbial namespace can down the road for a bit though.
If a namespace requirement is a barrier for new specifications being donated or created, it will presumably remain a barrier when it comes time for them to do their next major version.
I'm not sure there is a solution to that though besides one side simply giving in.
Another point which comes to mind: do we also need to come up with some loose criteria for exceptions?
If we allow namespace exceptions for all new specifications, it's no longer an exception. Food for thought.
All that being said, if I was to rank my preferences (favourite first):
This would be a statement of intent that we prefer a unified jakarta namespace, but it would not be a hard rule so as to allow exceptions to be made when necessary.
Thanks,
From: jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Ed Burns via jakarta.ee-spec.committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Sent: Wednesday, July 16, 2025 23:05 To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx> Cc: Ed Burns <Edward.Burns@xxxxxxxxxxxxx> Subject: Re: [jakarta.ee-spec.committee] [Straw poll] namespace policy for existing specifications moving to the Jakarta specification project
Again, I'm not on the spec committee but because this is a straw poll thread, I feel authorized to engage.
I think we should carefully consider the consequences of adopting option 1. If we want to allow more technologies to take advantage of what we've built with Jakarta so they can grow their own usage, and Jakarta's, we want to be more flexible, not less. This
argues for a middle road where we make it clear that there are benefits to using the Jakarta Java package: (brand cohesion, less developer confusion) but we don't insist on it.
It seems a horribly missed opportunity to scuttle the whole idea of MicroProfile coming to Jakarta EE over just the namespace issue. LLMs don't care what namespace you use, we probably shouldn't care either.
Ed
|