SpringSource -rachete- Groovy et Grails
Par dgirard le mardi, novembre 11 2008, 09:58 - Lien permanent
SpringSource rachète G2One, la société qui édite les projets opensource Groovy et Grails. Ceci devrait donner un bon coup de projecteur sur ces technologies très utiles pour faire du développement rapide d'applications. SpringSource se positionne de plus en plus comme un acteur proposant une alternative à J2EE.
Les choses étant bien faites, les personnes venant aux Rencontres Spring 2008 auront l'occasion de discuter avec Guillaume Laforge, co-créateur de G2one.
SpringSource buys Groovy and Grails specialist
Update :
Guillaume Laforge confirme : SpringSource acquires G2One
Graeme Rocher fait de même : Groovy and Grails join the Spring family
SpringSource aussi : SpringSource Acquires G2One Inc.
Commentaires
je ne comprends toujours pas pourquoi veut concurrencer JEE plutôt que de le faire évoluer.
Au final ce seront les développeurs et les entreprises qui vont payer la note.
Java et JEE sont des normes ouvertes via le JCP, pourquoi Johnson n'adopte pas la démarche de Gavin King ? Je pense que Johnson va faire évoluer spring vers un modèle propriétaire ...
Je suis peut être parano...mais je pense que Spring Source à de très grosses ambitions. Et Spring IoC( core) n'était que le cheval de Troie pour entamer ce schisme dans le monde Java.
Je pense que Spring Source est entrain de construire toute une stack de framework/outils/Serveurs d'applis/ et la, elle se paie carrément un langage pour se mettre en concurrence directe avec JEE voir Java tout court.
Je ne possède pas de boule de cristal, mais je vois venir une nouvelle plateforme de dev distincte SPRING en plus de JEE et .NET .
D'un autre coté...vu l'excellente qualité des produits SPRING, on ne peut que s'en réjouir... Une bonne concurrence, ça n'a jamais fait de mal.
Ben si justement ....
Le JCP permet une approche collective et rationnelle des évolutions technologiques.
Lorsque JEE évolue il y a des specs que l'on peut consulter : différentes sensibilités sont représentées au sein des groupes d'expert pour chaque JSR. Tout ça dans un seul but : offrir le meilleur aux utilisateurs.
Ou sont les specs des futures fonctionnalités de Spring ?
La stack JEE a des défauts mais elle a certains mérites que Spring et .Net n'offre en aucun cas :
- proposer une API commune documentée et spécifiée clairement validée par des acteurs différents
- les éditeurs se différentient sur les implémentations afin de ne pas pénaliser les utilisateurs avec l'apprentissage d'API différéntes et de garantir un niveau élevé d'interopérabilité.
Depuis par rapport à certaines normes sprind redéveloppe des choses existantes.
Spring Source annonce le support de Java EE 6 (au moins une partie, mais à priori y compris EJB 3.1 lite!). Tout n'est pas si noir! ;)
Enfin certains diront qu'ils attendent de voir pour y croire...
Le soucis avec JEE c'est quand même que ca évolue très lentement, il suffit de voir le retard que prend le langage java par rapport à c# (proriétés, type generic manipulables au runtime, méthodes anonymes et lamba, bientôt les dynamics...).
Sur la richesse du framework c'est moins flagrant et java a clairement de l'avance sur certains points (persistence notamment) mais la logique du 'plus petit dénominateur commun' du JCP ouvre souvent la porte à des solutions propriétaires (un peu de spring, un peu d'axis, un peu de gwt...). Je viens de finir un projet en wcf, en deux endpoints j'expose un service en nettcp et en ws (avec gestion des types abstraits et des références circulaires dans les graphs d'objets) là ou en java je dois jongler les @Remote pour les ejb et avec axis ou jaxws pour les webservices.
Une fois les annotations intégrées, l'évolution du langage Java n'a que peu d'incidence sur Java EE. Les implémentations (serveurs d'applications) n'ont pas besoin d'attendre les prochaines version du standard pour innover (modularisation, extensibilité, démarrage rapide, redéploiement à chaud et incrémental). Et puis AXIS implémente désormais JAX-WS et Spring va vers Java EE. GWT c'est l'exception qui confirme la règle.
Quant à WCF vs. JAXWS, je ne suis pas convaincu d'une quelconque différence fondamentale.