La question, c'est quelle est la part utile de j2ee qui vient réellement d'oracle?
Je suis pas l'actualité de super près, mais pour autant que je sache, ces derniers temps les évolutions viennent vachement de la communauté qui finit par pousser ses secs dans le standard.
Genre jsr-330 et tout le di/ioc vient de spring et/ou guice, ou des trucs genre jaxrs qui vient en grande partie des nombreux appservers de la communauté.
C'est clair que la standardisation est très appréciable, mais en pratique, tu dépends toujours plus ou moins d'un jar spécifique à l'implementation, donc c'est pas non plus la fin du monde. Genre sur jsr-330, la spec est pas assez complète et manque de features certaines (genre @value), et chez jaxrs, ton code finit toujours par tirer des classes vendor specific. Idem sur jpa, où il va toujours manquer un bout, et tu finit par tirer du hibernate specific de toutes façons.
Du coup, est ce que c'est réellement un problème?
[^] # Re: Alternatives
Posté par groumly . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 8.
La question, c'est quelle est la part utile de j2ee qui vient réellement d'oracle?
Je suis pas l'actualité de super près, mais pour autant que je sache, ces derniers temps les évolutions viennent vachement de la communauté qui finit par pousser ses secs dans le standard.
Genre jsr-330 et tout le di/ioc vient de spring et/ou guice, ou des trucs genre jaxrs qui vient en grande partie des nombreux appservers de la communauté.
C'est clair que la standardisation est très appréciable, mais en pratique, tu dépends toujours plus ou moins d'un jar spécifique à l'implementation, donc c'est pas non plus la fin du monde. Genre sur jsr-330, la spec est pas assez complète et manque de features certaines (genre @value), et chez jaxrs, ton code finit toujours par tirer des classes vendor specific. Idem sur jpa, où il va toujours manquer un bout, et tu finit par tirer du hibernate specific de toutes façons.
Du coup, est ce que c'est réellement un problème?