These are the reasons Microsoft would vote -1 on a Jakarta AI/LLM
specification at the current time:
* The entire area is still very much fast moving shifting sands.
It's just not ready for any kind of "one specification to rule
them all" effort. Any such effort is bound to get it wrong -
perhaps completely wrong.
* This is an area that requires extremely deep domain expertise
that most Jakarta EE vendors simply do not have. The people that
have the correct domain expertise are really not ready to come
together in any standards body.
* To the extent that "one API to rule them all" can even work in
this space, LangChain and LangChain4j already have significant
traction. By virtue of being just an open source project in an
emerging space that can move fast, not worry about
quality/stability too much, etc it will always have a competitive
advantage. Any competing Jakarta EE specification is unlikely to
gain relative credibility or adoption against LangChain4j, so such
an effort has a high probability of doing more harm than good.
What Microsoft believes to be a prudent move is for Jakarta EE
vendors to collectively ensure that LangChain4j includes a robust
CDI extension that can work with both Jakarta EE and MicroProfile.
We should all promote this extension. This will also earn Jakarta
EE vendors some badly needed goodwill with open source projects.
Indeed longer term, Jakarta EE should look for ways to officially
promote open source projects that embrace CDI and Jakarta EE.
_______________________________________________