Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Java EE 7 : Red Hat soumet une nouvelle spécification de mise en cache des données
Au Java Community Process

Le , par Idelways

5PARTAGES

1  0 
Mise à jour du 18/04/2011 par Idelways

Red Hat vient de soumettre une nouvelle requête au Java Community Process (JCP) dans le but d'intégrer de nouvelles idées aux spécifications de Java EE 7, approuvées à l'unanimité le mois dernier (lire ci-devant)

La nouvelle requête de Red Hat s'intéresse à l'amélioration de la mise en cache des données (Data Caching) en Java, afin de rendre la prochaine édition entreprise du langage encore plus adaptée au Cloud Computing auquel sont destinés nombre des nouveautés notables de Java EE 7.

La proposition de RedHat (de plus en plus impliqué dans l'écosystème Java depuis le départ de la fondation Apache), fait suite à la validation de plusieurs de ses propositions, comme la version 1.1 de « Context Dependency Injection (CDI) », Data Grids et Bean Validation.

La mise en cache des données est prise en charge par Java depuis longtemps, son support ne serait toutefois pas assez répandu, distribuable et élastique d'après un haut responsable de Red Hat dans une déclaration à la presse.

D'où l'idée du projet « Infinispan », développé au sein de la communauté JBoss et chapeauté par Red Hat. Ce projet open source est à la base de la proposition soumise au Java Community Process.

La proposition de Red Hat est destinée à offrir aux entreprises une alternative, standardisée et intégrée au langage, aux solutions tierces pour la gestion avancée du cache en Java, comme Coherence d'Oracle, GemStone de VMware et le projet open source Ehcache.

Red Hat envisage de soumettre d'autres spécifications de technologies, élaborées notamment par la communauté JBoss, pour les mettre à la disposition de l'ensemble la communauté Java.

Dans un autre contexte, Gavin King de Red Hat (le créateur entre autres de l'ORM populaire Hibernate) a dévoilé la semaine passée le projet Ceylon : un nouveau langage pour la JVM fortement inspiré de Java, ayant l’ambition de reprendre les points fort du langage, sans ses défauts.

Source

Et vous ?

Qu'en pensez-vous ?
Java EE 7 a-t-il d'après vous besoin de capacités de mise en cache avancées et intégrées au langage ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 05/09/2012 à 10:09
Citation Envoyé par Traroth2 Voir le message
Ceux qui affirmaient que le rachat de Sun par Oracle allait accélérer l'évolution de Java savent désormais à quoi s'en tenir...
au moins, contrairement à sun, il ne retardent pas tout l'ensemble pour un élément en retard. C'est visiblement la ligne de conduite depuis le rachat: ce qui ne peux pas arriver à temps est reporté, mais les autres n'attendent pas.
3  1 
Avatar de Elendhil
Membre averti https://www.developpez.com
Le 09/09/2012 à 1:04
Pas bien grave le cloud tout le monde s'en fou
1  0 
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 18/04/2011 à 23:07
A faire dès que possible tant que les 2 produits ne divergent pas trop !

Gavin King est dans la boucle... J'imagine que le langage de requête d'Infinispan doit être assez proche du pseudo HQL/JPQL de Coherence ...

Je verrai bien un DSL pour l'accès BDD et/ou cache... est-ce le cas ici ?
0  0 
Avatar de Flaburgan
Modérateur https://www.developpez.com
Le 20/04/2011 à 9:56
J'ai quand même vraiment du mal à comprendre comment marche ce community process.

En gros, les entreprises / fondations qui en font parti bossent sur des améliorations de Java, puis file tout leur travail à Oracle avec comme seule contrepartie sa gratitude... ?! Ouais, dans le monde du libre, ça marche, sauf que c'est pas comme si Oracle jouait le jeu quoi...
0  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 20/04/2011 à 10:13
Il y a aussi des gens d'oracle qui bossent dessus, faut pas croire. Mais quand u soumet une nouvelle spec au community process, elle a quand même beaucoup plus de chance d'être approuvée par les autres membres si une implémentation existe déjà
0  0 
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 20/04/2011 à 12:04
Citation Envoyé par Flaburgan Voir le message
J'ai quand même vraiment du mal à comprendre comment marche ce community process.
Il s'agit de SPECs et non pas d'implémentation !

RedHAt est membre du comité => normal qu'ils proposent de nouvelles propositions.

Même si « Infinispan » est à la base une solution libre, derrière il y a des enjeux financiers pour RedHat... Ici RedHat ne travaille pas pour Oracle mais pour son propre business. RedHat a son propre modèle économique et propose des solutions globales autour de Java: ils ont tout intérêt à se que leurs solutions deviennent des implémentations de référence !
0  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 20/04/2011 à 17:46
Citation Envoyé par Flaburgan Voir le message
J'ai quand même vraiment du mal à comprendre comment marche ce community process.

En gros, les entreprises / fondations qui en font parti bossent sur des améliorations de Java, puis file tout leur travail à Oracle avec comme seule contrepartie sa gratitude... ?! Ouais, dans le monde du libre, ça marche, sauf que c'est pas comme si Oracle jouait le jeu quoi...
Non, en fait les membres votent des standardisations pour défendre leurs propres investissements si tu veux mon avis. Et quand on voit ce qui en sort, franchement ça fait peur.
Enfin, ils sont vraiment pas là pour améliorer java mais pour défendre leurs seuls intérêts.
0  0 
Avatar de Flaburgan
Modérateur https://www.developpez.com
Le 21/04/2011 à 8:48
Mais si ça ne profite qu'à eux et pas à Oracle, pourquoi ce dernier les écouterait-il ?
0  0 
Avatar de Philippe Bastiani
Membre éprouvé https://www.developpez.com
Le 21/04/2011 à 13:30
Citation Envoyé par Flaburgan Voir le message
Mais si ça ne profite qu'à eux et pas à Oracle, pourquoi ce dernier les écouterait-il ?
C'est du donnant donnant... C'est comme celà que fonctionne l'eco-système Java.

JavaEE repose sur des specs qui peuvent être librement implémentées. Les specs constituent ainsi le socle de base de JavaEE: un serveur d'application certifié JavaEE doit impérativement proposer toutes les implémentations (mais le choix de l'implémentation n'est pas imposé par Oracle).
RedHat propose d'enrichir ce socle de specs. C'est donc profitable
- à RedHat puisqu'il dispose d'une implémenation => une solution qui peut-être intégré à Jboss pour certification... RedHat espère ainsi que les utilisareur JBoss se tourne vers une solution globale telle que Linux RedHat Entreprise... Comme tu peux le constater cette proposition n'est pas annodine!
- à l'eco-système Java de manière générale (les JSRs constituent le socle commun pour les impémentations). Pour les contributeurs qui pourront mettre en valeur la conformance JavaEE de leur solution; pour les développeurs qui disposent d'une architecture de base.
- A Oracle propriétaire de Java: tout ce qui peut enrichir Java est bon à prendre...

Le problème ici: c'est que Oracle dispose d'une autre solution pour la mise en cache... Seront-ils se mettre d'accord ?

Conséquence de ce mode de fonctionnement: comme le faisait remarquer _skip, chaque contributeur du JCP regarde avant ses propres intérets. Et l'évolution de JavaEE avance à l'allure d'une tortue !
0  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 21/04/2011 à 13:36
Citation Envoyé par Philippe Bastiani Voir le message


Le problème ici: c'est que Oracle dispose d'une autre solution pour la mise en cache... Seront-ils se mettre d'accord ?
Qu'on soit dans le cadre du JSR ou pas, c'est un problème industriel général dès qu'on veux standardiser quelque chose:
T'as 50 industriels qui ont leur moyen de résoudre le problème, et il faut sortir de là avec une seul spécification standardisée.

Comment croyez vous que les format DIN pour les filtrage, les spécifications ISO pour la gestion d'entreprise, les RFC etc sont négociés? De la même manière. C'est du purement mercantile, mais, au final, dans une grande partie des cas, ça bénéficie au consommateur final (qui peux acheter la pièce mal chez un constructeur et savoir que la pièce femelle de l'uatre constructeur se vissera dessus sans problème )
0  0