Journal du Net : contributions sur l'utilisation de Spring
Le Journal du Net vient de lancer un appel à contribution sur l'utilisation du framework Spring :
Au moment où ce post est écrit, il y a 5 contributions, globalement très positives, sur l'utilisation de Spring : nous vous invitons à venir y participer vous aussi.
En lisant ces contributions, plusieurs points nous ont parus particulièrement intéressants :
- De manière générale, tout le monde semble très satisfait de la manière dont Spring permet de structurer des applications Java : qualité et productivité sont là les maîtres mots.
- Un contributeur parle de "prise en main parfois difficile", un autre d'"apprentissage aisé"... Au niveau de SpringSource, nous faisons tout notre possible pour que Spring soit simple d'accès, avec un succès certain si on regarde la courbe d'apprentissage de Spring par rapport à des technologies comme les EJBs. Cependant, il est vrai que Spring représente aujourd'hui une large palette de solutions, et que savoir correctement utiliser le framework et les projets associés demande un certain investissement : c'est d'ailleurs pour cela que nos formations sont si populaires.
- L'un des inconvénients remontés concerne la verbosité de la configuration d'Acegi Security : à juste titre, le contributeur précise que cela va être corrigé avec Spring Security. Ajoutons que c'est en effet là la principale nouveauté de Spring Security, qui est déjà disponible en version finale depuis 7 mois, et utilisé chez de nombreux clients.
- L'autre inconvénient remonté, et que nous entendons parfois, concerne l'utilisation mémoire de Spring : c'est là un point qui mérite que nous nous y attardons.
En termes d'utilisation "classique", un test simple (réalisé par SpringSource France, et que nous espérons bientôt publier plus en détail) montre que pour créer une application Spring simple (10 beans Spring, de l'injection de dépendances, 2 aspects, du log et quelques services de base), vous allez :
- Utiliser 11 Mo en RAM (taille du process Java, sans aucun tuning particulier)
- Avoir besoin de 5 Mo de librairies (les librairies Spring de base ainsi que quelques commons-*)
- Le toute démarrant en 150 millisecondes sur un ordinateur portable
Cependant, il s'agit là de faire une tourner une application Java SE simple : sur un PC fixe, cela ne devrait donc vous poser strictement aucun problème. Reste donc deux modes d'utilisation pour lesquelles ces contraintes peuvent devenir problèmatiques :
- Dans du Java embarqué : il est vrai que Spring est très orienté Java EE, et que nous ciblons aujourd'hui très peu le monde embarqué.
- Dans des applications d'entreprise complexes, pour lesquelles sont utilisées un grand nombre de librairies supplémentaires. L'utilisation d'outils comme Maven font que nous voyions chez des clients des WARs qui font parfois plusieurs centaines de Mo, et même des EARs frôlant le demi-gigaoctet. Pour ce type de problème, nous mettons en avant trois points :
- Tout d'abord, ce problème ne provient pas de Spring, mais des autres librairies qui sont ajoutées de manière automatique via les dépendances transitives que propose Maven. Un nettoyage de ces dépendances est alors généralement très bénéfique.
- Spring lui-même est aujourd'hui découpé en de nombreux modules : n'utilisez que ceux qui vous sont utiles. Il s'agit là encore d'un nettoyage utile de votre système de build, et en cas de forte contrainte mémoire, c'est un travail nécessaire.
- SpringSource dm Server permet justement de résoudre ce type de problème. Grâce à son noyau OSGi, notre nouveau serveur d'applications vous permet de ne lancer qu'une seule fois une librairie, et de la partager entre toutes vos applications. De plus, cette librairie ne sera démarrée qu'en cas de besoin, ce qui vous fera certainement gagner en mémoire dans le cas de dépendances transitives abusives. De même que Maven peut vous aider à gérer ce problème lors de votre de "build", SpringSource dm Server va vous permettre de le gérer lors de votre "run".