| Re: [jakarta.ee-spec] [jakarta.ee-community] Defining Jakarta EE 12 Scope in Program Plan |
_______________________________________________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.
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community