Blogounage

Aller au contenu | Aller au menu | Aller à la recherche

Mot clé - java

Fil des billets - Fil des commentaires

mercredi 13 janvier 2010

Comment connaître la provenance d'une classe programmatiquement en Java

Par batmat le mercredi 13 janvier 2010, 18:07 - Technique

Il est possible par programmation de savoir d'où vient une classe : un jar ? un répertoire ? autre ?

Use case classique : vous pensez (et devez) ne plus avoir les commons-logging nulle part dans votre classpath, parce que vous êtes (intelligemment :-)) passés à SLF4J. Malgré cela, il semble que cette fichue classe soit toujours trouvée, mais vous n'arrivez pas à savoir dans quel jar (ou quel répertoire si vous travaillez directement avec les .class). Résultat, ça vous fout un bazar monstre dans la configuration de vos logs. Certains continuent à apparaitre alors que vous avez demandé à ce qu'ils ne soient pas affichés...

Le code est un peu sioux, alors je le mets ici au cas où ça vous servirait :

System.out.println(MaClasse.class.getProtectionDomain().getCodeSource().getLocation());

MAJ du 15/03/2010

Suite à l'incompréhension ci-dessous, voici quelques exemples pour illustrer ce que fait ce code :

Le code :

System.out.println(org.springframework.mail.MailSender.class.getProtectionDomain().getCodeSource().getLocation());

System.out.println(MyJunitTest.class.getProtectionDomain().getCodeSource().getLocation());

Affiche sous Windows :

file:/C:/m2repository/org/springframework/spring-context-support/2.5.6/spring-context-support-2.5.6.jar
file:/C:/tests/myproject-core/target/test-classes/

J'espère que l'utilité est un peu plus claire à présent.

5 commentaires aucun rétrolien

vendredi 29 mai 2009

JSR 330 : Dependency Injection for Java

Par batmat le vendredi 29 mai 2009, 09:57 - Technique

Récemment, SpringSource (Rod Johnson, créateur de Spring) et Google (Bob Lee, coauteur de Guice) lançaient une proposition de JSR visant à standardiser un jeu d'annotations pour gérer l'injection de dépendances.

Cette proposition, « Dependency Injection for Java », est devenue une véritable JSR depuis 3 jours.

Personnellement, j'ai hâte de voir ce qui va ressortir de ce travail. Notamment, je regarderai attentivement en quoi cela complètera ou s'intégrera avec les annotations de common annotations (JSR 250, dont sont notamment issues @PostConstruct, @PreDestroy, @Resource) et éventuellement les annotations de la spécification des EJB3 (@TransactionAttribute, notamment).

Comme la spécification sera développée avec un scm et une liste de diffusion accessibles publiquement, j'essaierai de vous en dire plus à ce sujet dès que possible.

À suivre.

aucun commentaire aucun rétrolien

vendredi 30 janvier 2009

Java User Group Toulouse

Par batmat le vendredi 30 janvier 2009, 10:10 - Technique

Via Sami, j'apprends ce matin que ça y est, le JUG Toulouse est né. Je me suis d'ores et déjà inscrit à liste de diffusion.

J'espère que je trouverai le temps de participer à ce groupe malgré les importants travaux à faire dans la maison que nous venons d'acheter.

PS : Sami, merci encore pour la bétonnière :-).

aucun commentaire aucun rétrolien

dimanche 13 juillet 2008

How to retrieve the Hibernate Session from the EntityManager interface

Par batmat le dimanche 13 juillet 2008, 23:42 - Technique

Well, as I myself fell into this stupid gap, I guess I'll try to help. I was quite pushed in this trap by a fallacious part of the jboss documentation :

@PersistenceContext EntityManager entityManager;

public void someMethod();

{

  org.jboss.ejb3.entity.HibernateSession hs = (HibernateSession)entityManager;

  org.hibernate.Session session = hs.getHibernateSession();

}

Let's be clear : this is totally WRONG! Yes, it will work under JBoss, but as there's a standard way to do this, this is not the right way to do this.

In fact, there's a dedicated method that lets you retrieve the underlying persistence manager : EntityManager.getDelegate(). If you read this method's javadoc, you'll see the following :

/**

 * Return the underlying provider object for the EntityManager,

 * if available. The result of this method is implementation

 * specific.

 * @throws IllegalStateException if this EntityManager has been closed.

 */

public Object getDelegate();

And the "underlying provider", for Hibernate, is obviously the Hibernate Session instance...

So, the right way to retrieve the Session is something like the following instead :

@PersistenceContext EntityManager entityManager;

public void someMethod();

{

  org.hibernate.Session session = (Session)entityManager.getDelegate();

}

Under JBoss, using this code won't make a big difference. But using the standard way will let you run your code under several appservers (namely, it works like a charm[1] under JBoss 4.2.2.ga and Glassfishv2ur1 for example). If you use the bad way above, this will just crash under Glassfish, for example...

I reported the corresponding documentation bug in the JBOSS tracker.

Hope this helps...

Notes

[1] ça, c'est pour Seb

3 commentaires aucun rétrolien

samedi 2 février 2008

Optimisation GWT 1.4

Par batmat le samedi 2 février 2008, 20:47 - Technique

Wouah, je viens de regarder l'interview de Bruce Johnson par InfoQ à propos de GWT.

Bruce explique les nombreuses optimisations qu'ils effectuent au niveau du compilateur GWT. Il explique notamment qu'ils (les développeurs GWT) cherchent sans cesse à optimiser le compilateur, pour cela il comparent par exemple les requêtes qu'une webapp classique effectue vers le serveur et les requêtes que GWT fait.

Et en exemple, autour de la dixième minute, il explique l'optimisation concernant les images : l'ImageBundle. Dans une application classique, il y a des dizaines d'images, souvent toutes petites (icônes, fonds...). Le problème, c'est que le navigateur, même pour se voir répondre que l'image est à jour ouvre très souvent des connexions, d'autant plus qu'il y a d'image ! Ça peut créer (dixit Bruce) une contention en raison du grand nombre de sockets ouvertes côté serveur.

Et bien si vous utilisez cet objet ImageBundle, GWT construit côté serveur une image composite. Comme ça, le navigateur n'a qu'une seule image à télécharger puis vérifier, et les morceaux sont déconstruits côté client en récupérant les bouts de la grosse image et en les plaçant au bon endroit (cf. 10m40s). C'est quand même génial comme idée.

Bon après, il faut que la machine sur laquelle le navigateur tourne dépote d'autant plus, mais on n'a rien sans rien.

PS : Ce que je viens de dire n'est que le reflet de ce que j'ai compris de l'interview. Je n'ai pas testé cette fonctionnalité.

2 commentaires aucun rétrolien

Ça y est, @Override fonctionne enfin comme je l'ai toujours voulu :-)

Par batmat le samedi 2 février 2008, 15:48 - Technique

Depuis Java 5, les annotations ont été ajoutées. L'une des premières a été @Override, une annotation destinée à informer le compilateur que la méthode ainsi annotée redéfinit une méthode parente.

Le problème, c'est qu'en Java 5, cette annotation ne pouvait être utilisée que sur des méthodes en provenance d'une classe parente, pas d'une interface.

Je l'ignorais jusqu'à hier soir, mais en posant la question de la justification de ce choix d'implémentation sur ma liste de diffusion favorite, c'est mon ancien prof de Java et de Génie Logiciel qui m'a répondu que c'était possible depuis Java 6. Cf. le blog de Peter Ahé.

En clair :

public interface MonInterface

{

        void methode();

}



class MonImpl implements MonInterface

{

        // L'annotation suivante est valide depuis Java6, mais produit à la compilation le 

        // message suivant en Java5 :

        // "The method methode() of type MonImpl must override a superclass method"

        @Override

        public void methode()

        {

        }

}

Ça fait un outil de plus pour augmenter la qualité du code, en l'occurrence en diminuant le risque de se retrouver avec du code mort.

aucun commentaire aucun rétrolien

dimanche 13 janvier 2008

How to load a XML Spring context lazily by default

Par batmat le dimanche 13 janvier 2008, 17:57 - Technique

Say you want to change the default-lazy-init attribute programmatically. The most common use case for this seems to appear with unit-testing. In fact, you probably want to load everything when starting a production server, even if it costs you more time. But when testing, and particularly on your machine, you might want to inverse this behaviour. In fact, you might be interested in not loading every 1000 beans of your context when you just need less than 10 for example...

A (beginning of) solution

If you crawl Google, you might find this entry that links to this other one that explains how to programatically modify the lazy-init attribute of each bean of your context. In fact, before the loading occurs, you can iterate through the bean list and call setLazyInit using the method AbstractBeanDefinition.setLazyInit(true). This will be roughly equivalent to manually put lazy-init="true" on every single bean of your context files.

The problem

The problem with this is that you override everything that was declared in the XML context file. You might want a particular bean be instantiated lazily or eagerly for some reason. But iterating through the whole list like this won't let you keep what was explicitly defined and only redefine the default value. Another problem is that you may have to exclude some bean from this loop, ending up with a condition that really looks like an ugly hack :

for (String beanDefinitionName : context.getBeanDefinitionNames()) {

    AbstractBeanDefinition beanDefinition = (AbstractBeanDefinition)context

            .getBeanDefinition(beanDefinitionName);

    System.err.println(beanDefinitionName);

    // FIXME : ugly hack

    if (!"org.springframework.aop.config.internalAutoProxyCreator".equals(beanDefinitionName)) {

        beanDefinition.setLazyInit(true);

    }

}

Having to exclude the one bean that's (according to its name) responsible for proxying beans that have to be lazy-loaded seems quite reasonable. But the thing is you obviously don't have to do it when you put the default-lazy-init manually...

So I looked for a way to simply replace the default value of this attribute instead. After some time digging into Spring code, I finally found it.

When parsing context definition written in XML (since writing it in XML is no requirement), Spring will use an instance of BeanDefinitionReader that will then call DefaultBeanDefinitionDocumentReader to parse the Document instance. Searching a bit more lets us find where the default values are initialized : BeanDefinitionParserDelegate.initDefaults().

LazyInitByDefaultBeanDefinitionDocumentReader

public class LazyInitByDefaultBeanDefinitionDocumentReader extends DefaultBeanDefinitionDocumentReader

{

        @Override

        protected BeanDefinitionParserDelegate createHelper(XmlReaderContext readerContext, Element root)

        {

                root.setAttribute(BeanDefinitionParserDelegate.DEFAULT_LAZY_INIT_ATTRIBUTE, "true");

                return super.createHelper(readerContext, root);

        }

}

I would have preferred to use the seemingly more dedicated method preprocessXml(Node root)], but this method is called after createHelper(), so the default values are already initialized when calling preprocessXml()... So overriding preprocessXml() is "too late".

I think I'm going to submit a patch into the Spring bug tracker about this problem.

Unit-testing

When you do unit-testing with Spring, you generally inherit the AbstractDependencyInjectionSpringContextTests class. Add this method redefinition to enable the "lazy by default" behaviour :

@Override

protected BeanDefinitionReader createBeanDefinitionReader(GenericApplicationContext context)

{

        XmlBeanDefinitionReader r = new XmlBeanDefinitionReader(context);

        r.setDocumentReaderClass(LazyInitByDefaultBeanDefinitionDocumentReader.class);

        return r;

}

Plain old Java (Spring) code

When you want to create an XML context, you generally use a ClassPathXmlApplicationContext instance. If you want to modify the default behaviour like here, you have to use a GenericApplicationContext. Note that this is what is adviced in the javadoc of ClassPathXmlApplicationContext :

This is a simple, one-stop shop convenience ApplicationContext. Consider using the GenericApplicationContext class in combination with an org.springframework.beans.factory.xml.XmlBeanDefinitionReader for more flexible context setup.

Here is the code using this GenericApplicationContext that enables the lazy-loading :

GenericApplicationContext context = new GenericApplicationContext();

XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(context);

reader.setDocumentReaderClass(LazyInitByDefaultBeanDefinitionDocumentReader.class);

reader.loadBeanDefinitions("/yourApplicationContext.xml");

context.refresh();

When is it needed ?

At the moment, I see two reasons for enabling the lazy-loading by default :

  1. When unit-testing, this lets you test a part of the code a bit more quickly, since not every single beans needs to be instantiated.
  2. When using code-coverage tools to evaluate a part of the code, this prevents totally unrelated code to appear with non-null percentage.

Hope this small article will help some other people :-).

2 commentaires aucun rétrolien

samedi 16 juin 2007

Utiliser les objets du domaine directement dans la couche présentation

Par batmat le samedi 16 juin 2007, 23:26 - Technique

Nous utilisons encore Struts 1 actuellement. Ce n'est normalement qu'une question de temps avant de passer à autre chose. Nous sommes sûrs de ne plus l'utiliser à terme. Nous connaissons donc notre source, mais pas encore la cible. Voici les nombreuses solutions qui s'offrent à nous :

  • Struts 2
  • GWT
  • .Net
  • Flex
  • ...

Toutefois, je ne suis pas très chaud pour .Net ou Flex ou toute technologie qui nous contraigne forcément à passer par les WS pour accéder à nos services (développés en Java). Je suis réticent à devoir obligatoirement passer par une couche WS alors que nous pourrions garder du java de bout en bout, et ainsi économiser le marshalling/unmarshalling incessant qui va avec les WS, sans parler du problème de l'identification du graphe d'objets à sérialiser pour le renvoyer. Quoi qu'on en dise, utiliser systématiquement des WS n'est pas neutre et amène de nombreuses questions qu'on ne se pose jamais sinon (hein Séb...).

Donc, pour revenir au sujet, nous ne sommes pas encore fixés sur notre future couche présentation (ou plutôt nos futures couches de présentation). Pour le moment, nous avons donc décidé de continuer à fonctionner tant bien que mal Struts 1.x avec la version 2 du socle technique que nous sortons.

Or, la différence fondamentale entre notre version 1 et notre version 2 est que nous avons supprimé une "transformation" systématique entre deux couches. Auparavant, en effet, nos entités persistantes de couche DAO étaient systématiquement transformés en objet de couche service. Entre les deux couches, nous avions systématisé un bidouillage destiné à régler le problème que nous avons dans la couche Web dans la gestion des multiplicités 0..1.

La gestion du null de Struts 1.x

Avec Struts 1, si vous demandez par exemple le prénom d'un client null, vous n'aurez pas quelque chose de null, mais une exception. La question a été discutée il y a déjà un moment sur la liste de Struts et posée sur le tracker de Struts en février 2001 (quand je vous disais que ça faisait un moment), et Craig Mc Clanahan d'expliquer que le principe était que si vous vouliez afficher le prénom d'un client, eh bien il fallait protéger le code pour n'afficher le prénom que si le client est non null :

<logic:present name="beanname" property="client">

  <bean:write property="client.prenom"/>

</logic:present>

Si dans l'exemple ci-dessus, on met un champ de saisie à la place du <bean:write />, on est dans une impasse : certes, il n'y aura pas de plantage, mais il devient alors impossible de saisir le prénom du client puisque le textfield n'apparaîtra même pas...

Si votre objectif est de créer le client seulement si l'utilisateur a saisi des données (exemple : le formbean en cours gère un objet Facture qui a une multiplicité 0..1 vers un objet client), vous êtes obligé de créer dans votre FormBean un objet destiné à recevoir ces données. Le problème qui survient alors, c'est que si vous voulez conserver des objets "propres"[1], vous devez ensuite vérifier l'instance de Client pour la remettre à null ou l'associer manuellement (si pas encore fait) à la Facture avant de transmettre la Facture à la couche service pour mettre à jour. Ouf...

La longueur de l'explication ci-dessus par rapport à la complexité de ce qu'il faut gérer me paraît parler d'elle-même. Et le code qu'il faut écrire pour gérer ce cas est toujours le même... :

  1. avant affichage de la JSP : instancier les propriétés null pour pouvoir les afficher. Eh oui, rappel comme je l'ai dit plus haut : la demande de la propriété "a.b" déclenche une exception si a est null, il faut donc s'assurer que a est non null et l'instancier le cas échéant.
  2. après soumission du formulaire de la JSP et avant de passer les données à la couche application : supprimer les objets 0..1 non modifiés dans la JSP.

Struts 2

Dans Struts 2, le premier point est géré différemment : la demande de "a.b" si a est null renvoie simplement null. Par contre, le deuxième point est toujours à gérer manuellement et plantera si on cherche à valoriser a.b.

Une étape a déjà été franchie, pourquoi ne pas aller plus loin ?

Une solution

Pourquoi ne pas instancier automatiquement a s'il est null lorsqu'on cherche à valoriser a.b ? La question se pose d'autant que nous ne sommes pas les seuls à nous être posés la question : ce patch apportait déjà les modifications nécessaires aux commons-beanutils (utilisé par Struts, c'est cette bibliothèque qui impose le comportement de lever une exception si une propriété imbriquée est demandée à l'intérieur d'un objet null)...

Une autre solution (sans patch, cette fois) intermédiaire a été proposée pour la partie "get" : mettre en place un handler externe pour gérer le cas des propriétés imbriquées (nested properties) dans un conteneur null. Cette solution est un intermédiaire intéressant parce qu'elle est très courte à implémenter et permet de faciler renvoyer null ou de lancer une autre exception dans le cas en question.

Cette deuxième solution ne gère toutefois que le cas get. Peut-être le même principe serait-il utilisable pour le "set". Cela permettrait de même de positionner une sorte de NestedSetterHandler qui pourrait s'occuper d'instancier les propriétés intermédiaires si besoin. Avec un fonctionnement de ce type, on pourrait même envisager de définir un handler qui serait observable afin de gérer à la fois l'instanciation "dynamique" et de pouvoir suivre les instanciations effectuées. C'est à creuser.

Ce mode de fonctionnement aurait toutefois quelques inconvénients : lorsqu'on instancie manuellement a, on sait qu'on risque de devoir l'enlever s'il n'est pas vraiment saisi avant de l'envoyer à la couche service. Et que faire si on décide de faire gérer ça en standard par le service ? Imaginons par exemple qu'une adresse ait été automatiquement instanciée pour un Client. À quel composant, à quelle couche, incombe le rôle de supprimer l'adresse créée dynamiquement si le fonctionnel indique qu'elle n'est pas correcte ?

Conclusion

Dommage que l'équipe de commons-beanutils soit peu réactive sur cette question à mon avis primordiale de gestion des propriétés. C'est aussi très dommage que l'idée d'avoir derrière la classe statique BeanUtils une instance de BeanUtilsBean ne soit pas poussée à son terme : en l'état, il est en effet impossible d'utiliser de façon transparente une sous-classe BeanUtilsBean qu'on aurait adaptée à ses besoins.

Je nous vois bien maintenir en interne une version patchée de commons-beanutils afin de résoudre le problème tant que nous utiliserons Struts 1, en espérant bien sûr que le patch en question soit finalement appliqué.

En même temps, il reste la question de la gestion de la suppression des propriétés instanciées dynamiquement. Mais je ne suis pas sûr que ce soit un véritable problème, c'est un code qu'il faut de toute façon écrire. Au final, il y a actuellement les deux points suivants à gérer :

  1. instanciation manuelle pour gérer l'affichage ;
  2. vérification des données et suppression des créations incorrectes si les données n'ont par exemple pas été saisies.

C'est à mon sens un point qu'il serait intéressant de creuser. Avec Struts 2 par exemple, écrire un Interceptor chargé de l'instanciation dynamique ferait l'affaire pour enlever le point 1 ci-dessus.

Le tout serait ensuite de définir un emplacement de choix pour faire la validation, puis la suppression des propriétés fonctionnellement "inacceptables". À part ce point, je ne vois aucun frein à cette évolution. Cette question se posant pour n'importe quel formulaire de saisie, le monde de l'informatique aurait à mon sens beaucoup à gagner à trouver un véritable pattern pour gérer ce cas...

Notes

[1] c'est à dire que facture.getClient() renvoie bien null si la facture en question n'a pas de client, et non une instance bâtarde de Client qu'il vous faut ensuite analyser pour savoir si c'est un vrai client ou bien simplement une instance positionnée pour gérer des contraintes de présentation.

un commentaire aucun rétrolien

mercredi 30 mai 2007

Martin Fowler à propos de Microsoft

Par batmat le mercredi 30 mai 2007, 22:43

Martin Fowler a pondu ce soir un long billet sur la politique de Microsoft envers Ruby. Il parle ensuite de sa sensation selon laquelle une certaine désaffection pour la plate-forme .Net serait en cours, et que les AlphaGeeks (tiens, il faudrait un questionnaire, êtes-vous un AlphaGeek ? :-)) seraient en train de quitter l'environnement de développement MS.

Quelques morceaux choisis :

A few years ago my (limited) contacts in Redmond told me that they were seeing a real drift of technical leaders away from the Windows platform. More recently these signs seem to be increasing.

The tools, with their rigid role-separations, actively discourage the blurry boundaries that agilists prefer.

Pour ceux qui ont récemment joué avec WPF, Blend et consorts, on voit très bien ce qu'il entend par là.

The attitude to open-source is a large part of this problem. When Java appeared there were yawning gaps in its portfolio [...] Those gaps and bad ideas were fixed by the open-source community. [...] .NET has also got its gaps, and again the open source community has stepped up to fill them. Yet Microsoft refuses to collaborate with these efforts, [...] Microsoft ended not just bringing out a competitive library, but deliberately making it incompatible. That's not the kind of reaction that encourages people to invest their time in the platform.

Je connais peu .Net, mais est-ce que MS travaille à l'intégration ou en tout cas encourage un projet comme NHibernate ?

Quelques liens (déjà donnés ci-dessus)

MAJ : ajout de liens :

  • L'avis de Sam Gentile, un expert MS consulté par Martin Fowler pour l'écriture de son article. Martin Fowler a ajouté en fin de son billet des liens vers des réactions, dont celle de Sam.

aucun commentaire aucun rétrolien

dimanche 25 mars 2007

Sun Tech Days, mercredi 21

Par batmat le dimanche 25 mars 2007, 16:15 - Technique

Avec un peu de retard, je prends enfin le temps de faire un billet sur mon deuxième jour aux Tech Days. Cette journée a été très chargée, mais j'ai appris pleins de nouvelles choses. Évidemment, ce sont des choses à approfondir, mais je vais essayer de vous donner aussi envie de le faire. En cherchant un logiciel pour faire des vidéos de démo comme on en voit partout fleurir sur le net, je suis tombé sur Wink. C'est simplissime d'utilisation : avec ça, plus aucune excuse pour ne pas faire de vidéo explicative de l'installation ou d'une démo d'un logiciel (et on peut générer du flash ou un .exe pur windows).

Sun Technical Keynote

Cette introduction a été l'occasion de nous montrer le langage F3 : Form follows function, censé simplifier le développement d'interfaces graphiques. C'est vrai que la partie de la démo montrant comment mettre un fond en dégradé de rouge vers bleu vers jaune (ou d'autres couleurs) a montré que c'était effectivement très simple.

Speach VMWare

En tant que sponsor Platinium, VMWare a eu droit à un speach devant tout le monde. On nous a présenté ce qu'était VMWare, pour ceux qui l'ignoraient encore. Ça a été l'occasion de parler de Lab Manager, une sorte de dépôt central dans lequel on peut stocker des machines virtuelles et les lancer depuis des postes clients. Ça a l'air intéressant dans le cas des recettes par des équipes de tests. En effet, le syndrôme du Chez moi ça marche est effectivement connu de tout informaticien. Avec ce système qui simplifie le partage d'une configuration complète (du logiciel jusqu'à l'OS et sa configuration précise), il devient possible de débugguer un problème dans les conditions qui garantissent la reproductibilité, ce qui est la première difficulté pour un développeur : trouver les conditions permettant de reproduire le problème (essayez de corriger un problème que vous n'avez pas, pour voir !).

Java Jacket Give away

20 minutes pour un mini-show de 4 d'entre nous. Je n'ai pas osé y aller. J'ai eu une idée un peu tard, mais j'aurais dû la préparer la veille. Peut-être pour l'année prochaine :-).

Le gagnant a chanté une petite chanson sur Java et a donc gagné la veste en cuir avec le logo Java :-).

Java scripting: One VM, Many Languages

Cette session a été très intéressante. La démo de Guillaume Laforge m'a notamment donné envie de me mettre au Groovy, pour les apports en rapidité d'écriture par rapport au Java, l'ajout des fermetures, mais aussi pour sa proximité syntaxique et son intégration avec le Java. Ça peut en effet fonctionner directement avec la JVM, être mis dans un jar..., puisqu'on peut générer du pur bytecode Java. L'idée n'est pas de remplacer le Java, mais d'apporter une alternative plus puissante aux scripts shell et une syntaxe plus habituelle pour le développeur Java qui veut déployer un script de batch sur le serveur, par exemple.

Cette présentation a été l'occasion de découvrir la JSR223, la spécification qui permet d'intégrer n'importe quel langage de script à la plate-forme Java. Javascript l'est déjà (cf. la présentation flash plus bas), JRuby, Groovy, etc. En gros, l'architecture mise en place permet à n'importe qui d'intégrer n'importe quel langage de script en implémentant simplement les interfaces de la spéc (pensez à JDBC si vous ne voyez pas ce que je veux dire).

Code Quality issues: Prevention and Detection

C'est certainement l'une des sessions dans lesquelles je me suis senti le plus à l'aise, parce que j'avais déjà mis en place un grand nombre des outils cités. Ça a toutefois été l'occasion de découvrir de nouveaux outils (Selenium, notamment).

La présentation a commencé en citant Dijkstra : Testing can only show you bug presence, not their absence. Et c'est vrai que c'est bien de rappelant l'intérêt essentiel des outils de qualité de code... Ce n'est pas magique.

Pour résumer :

  • Test unitaire : Junit, TestNg
  • Couverture de code : Emma (+ pleins d'autres), ce type d'outil permet de savoir quelles parties de votre code ont été testées par les tests unitaires. En gros, vous lancez tous les tests de votre projet et l'outil monitore par où ça passe. Ensuite, vous pouvez généralement savoir quelles parties ont été testées, voire même lesquelles l'ont été plusieurs fois et d'autres une seule. La plupart de ces outils possèdent des plugins pour les principaux IDE qui permettent de voir graphiquement la couverture. Bien sûr, il existe aussi des plugins pour des outils comme Maven, permettant de sortir des statistiques.
  • Montée en charge : JMeter, LoadRunner (j'ajouterais OpenSTA)
  • Mock objects : EasyMock, JMock
  • Qualité du code : PMD, Checstyle
  • Test fonctionnel d'une webapp : Selenium
  • P6Spy pour voir la valeur des "?" dans les requêtes SQL paramétrées.

TP : Les nouveautés de Java 6

Comme j'en ai parlé plus haut, il est possible d'interfacer la JVM avec d'autres langages. Avec Java 6, vous disposez de jrunscript, un interpréteur Ecmascript (javascript normalisé).

En voici une petite démo :(cliquez sur l'image pour voir la démo flash) : jrunscript-presentation.jpg

JMX, Performance et concurrence

JMX

J'ai appris au cours de cette session que l'équipe de développement de JMX était située à Grenoble.

L'objet de cette session a été principalement de développer un MBean et de l'exposer via le MBeanServer. Ceux qui, comme moi, ont déjà développé un MBean et joué avec JConsole juste pour voir n'auront pas été surpris.

Par contre, j'en ai appris sur les différentes espaces mémoires de la JVM :

  • Eden : c'est l'espace mémoire où les objets à courte durée durée de vie sont stockés (la plupart en général) ;
  • Survivor : pour les objets qui ont une durée de vie un peu plus grande ;
  • Tenured : ben euu, encore plus :-).

Autre chose que les conférenciers ont dit, je n'ai pas vérifié, mais à propos des options -client et -server :

  • -client est toujours utilisé sous Windows, quelle que soit la machine
  • -server est utilisé automatiquement sous Linux ou sous Solaris si la machine possède plus de 2Go de mémoire vive.

Truc génial : la possibilité de repérer des deadlocks avec un simple bouton ! (je crois que c'est un ajout dans le JConsole embarqué dans Mustang, parce que je ne me souviens pas de l'avoir dans Tiger).

JSR 262

La façon dont on accède à JMX, JMX Remote, n'est pas liée fortement à JMX. En effet, l'implémentation par défaut dans Java 5 est effectivement en RMI, mais il reste très faisable de permettre l'accès aux fonctionnalités d'un serveur JMX par n'importe quelle autre implémentation.

C'est justement l'objet de la JSR 262 : implémenter une couche WebServices d'accès à JMX. Comme il existe une norme appelée WS-Man qui n'est pas liée au Java. Cette implémentation permettra donc l'accès au management de la JVM d'une façon normalisée. WiseMan est ainsi l'implémentation Java de WS-Man.

Lors de la séance de Q/R, j'ai posé la seule question de ces deux jours à Paris : pourquoi n'y a-t-il pas pour les MBeans, de la même façon qu'il y a l'annotation @WebService pour les Webservices, une annotation @MBean qui indiquerait automatiquement aux MBeanServer quels sont les MBeans à exposer ? Éamonn McMannus a répondu que c'était une question qu'on leur posait souvent, et que c'était justement prévu.

Performance

Bon, ils ont parlé du classique StringBuffer à la place de concaténer des String. Attention : depuis la version 5 de Java, la classe StringBuilder est à privilégier : de la même manière qu'il est recommandé d'utiliser HashMap à la place de Hashtable, il faut utiliser StringBuilder dans un contexte qui ne nécessite pas de synchronisation. En effet, la synchro n'est pas gratuite, donc l'utiliser de façon systématique est une grave erreur.

Concurrence

Ils ont présenté la nouvelle API de gestion de la concurrence ajoutée au JDK5, encore peu connue.

Java Puzzle

Pour finir, on a eu droit à un Java Puzzle (en anglais, puzzled correspond à surpris, étonné), c'est un bout de code qui surprend ou pour lequel on n'a généralement pas une réponse évidente pour tout le monde :

public class PingPong {

    public static synchronized void main(String[] a) {

        Thread t = new Thread() {

            public void run() { pong(); }

        };

        t.run();

        System.out.print("Ping");

    }



    static synchronized void pong() {

        System.out.print("Pong");

    }

}

Qu'affiche ce bout de code ?

  1. PingPong
  2. PongPing
  3. Ça varie

J'avoue sans honte que j'ai répondu correctement à cette question :-). Je mettrai la réponse dans les commentaires un peu plus tard (si personne d'autre ne le fait avant, d'ailleurs).

5 commentaires aucun rétrolien

mercredi 21 mars 2007

Sun Tech Days de l'intérieur, mardi 20

Par batmat le mercredi 21 mars 2007, 01:11

J'étais donc aux Tech Days aujourd'hui. Encouragé par des "moins scrupuleux" que moi, je me suis aussi levé pour dire bonjour à Alexis Moussine-Pouchkine, que je n'osais pas déranger parce qu'il avait l'air à bloc pour préparer/peaufiner sûrement sa session de cet après-midi :-) (ce qu'il m'a confirmé ensuite, la session avec Stéphane Goudeau sur WSIT, plus précisément :p).

De façon très inégale, j'ai pris quelques notes au cours de chacune des sessions. Je vais essayer de vous faire un rapide topo de ce à quoi j'ai assisté et ce que ça m'évoque. Après, je vais dormir pour réussir à me réveiller tout à l'heure :-).

Keynote session : James Gosling

Ça faisait longtemps que je ne n'avais pas entendu quelqu'un parler anglais, j'ai donc mis quelques minutes à m'habituer à son accent, que je qualifierais d'américain malgré le fait qu'il soit Canadien il me semble :-). Une fois lancé, j'ai ensuite pu comprendre facilement Rags ou Rima Patel (soit dit en passant, j'ai été amusé de remarquer qu'ils avaient tous les deux un portable Ferrari, vous savez celui tout en rouge).

Pour rester dans l'anecdotique, ça ne va pas intéresser grand monde, mais comme j'avais déjà joué avec, j'ai pu remarquer que James Gosling utilisait toujours Huckster pour faire sa présentation. J'ai trouvé ça propre et joli. J'avoue que ça m'a donné envie de l'utiliser à nouveau :-).

Sinon, au niveau du contenu, James a survolé un peu tout ce qui fait Java aujourd'hui. Du client léger au mobile, en passant par les tests de l'A380 et le temps réel. Une phrase qui m'a amusé, mais finalement pas tant surpris que ça. Il a dit : For me, the java language is almost uninteresting.. Sorti du contexte, ça pourrait faire une bonne news à troll sur TSS. En fait, ce qu'il a évidemment précisé, c'est que c'est surtout la JVM et sa portabilité sur des plates-formes potentiellement très hétérogènes qui l'intéresse :-).

Sun Technical Demo(s)

En l'espace de quelques dizaines de minutes, nous avons eu droits à 6 démos. Je le dis, les deux les plus impressionnantes ont été pour moi celle de Romain Guy montrant Aerith en fonctionnement et celle d'un certain Peter (pas entendu/noté le nom, désolé) qui m'a bluffé sur du dév sur téléphone portable. De mémoire :

Développement client léger

Pas trop bien compris. Ça ressemblait plus à du flash qu'à du Java sur une page Web (ou alors, c'était sûrement une Applet). L'objectif était de montrer qu'on pouvait faire une jolie page web avec Java EE. Pourquoi pas.

Aerith : Romain Guy

Aerith montre qu'on peut faire en Swing des applis avec un design de fou furieux. Si vous voulez tester, vous pouvez lancer assez facilement aerith directement depuis le lien Java Web Start (jnlp).

Aerith est un Mashup. Il utilise les WS de Flickr, de Google Maps et la localisation Yahoo si j'ai bien compris... Époustouflant.

Développement JSF avec Netbeans : Doris Chen

NetBeans semble effectivement bluffant de simplicité pour du dév Web. Quand je vois comment on rame pour nos JSP avec Eclipse, je m'interroge...

Par contre, JSF, JSF, JSF, JSF, ou alors JSF si j'ai bien compris

Java DB

Dans un client Web (Firefox :)), Francois Orsini nous montre qu'il peut saisir des données et tuer Firefox. Lorsqu'il rouvre l'application, il retrouve ses données telle qu'il les avaient saisies sans avoir pourtant cliqué sur un bouton de soumission. En fait, par Ajax, à chaque modification de champs, le client envoie les données au serveur qui les stocke.

Certes, la fonctionnalité est intéressante pour éviter le syndrôme de la perte des données dans un formulaire en cours de saisie. Mais, je ne vois pas bien le rapport direct avec Derby : la partie la plus grosse du code me semble résider dans l'Ajax qui stocke les données au fur et à mesure, non ? N'importe quelle base côté serveur ferait ensuite l'affaire il me semble.

jMaki : Ludovic Champenois

Sorte de wrapper à framework Javascript, jMaki a été mis à contribution pour développer rapidement quelques pages Web et montrer l'intégration simple et rapide de code Java directement dans le code Javascript. Ceci a notamment permis par exemple d'utiliser java.util.Date en plein milieu d'un code js. À creuser, à mon avis, mais très intéressant.

Développement Mobile

Si j'ai bien suivi, Peter a ensuite fait en live du remote debugging, posant en effet un point d'arrêt sur le code en cours d'exécution sur la JVM du téléphone ! Après avoir pris Doris Chen en photo avec l'appareil, il a imprimé sa photo sur l'imprimante, mais je n'ai pas bien compris ce qu'il voulait montrer. En tout cas, c'était sympa.

Glassfish : Alexis Moussine-Pouchkine et Ludovic Champenois

L'une des principales choses que j'ai retenue, ça tombe bien parce que j'ai le sentiment que c'est l'une des choses sur lesquelles Alexis a voulu insister : Glassfish n'est pas seulement une implémentation de référence dans le sens où on pouvait l'entendre habituellement[1]. Glassfish est parfaitement utilisable en production.

L'interface d'administration est agréable et l'outil asadmin permet de gérer des choses comme l'ajout de Datasources, etc.. (euu, là, chui pas sûr du tout). Glassfish intégre JAX-WS, beaucoup plus rapide qu'Axis 2, qu'y disaient.

Quelques notes en vrac :

  • Intégration de Comet : permet de créer des connexions persistantes HTTP, et donc de permettre au serveur de faire du callback.
  • Shoal : implémentation de clustering dynamique avec JXTA.
  • L'admin se fait avec JMX
  • Des extensions à JMX, des Application Servers Management eXtensions donc ? :-), des AMX sont aussi présentes.

Extreme Gui Makeover : Romain Guy

Là, j'ai un peu merdé. Comme je n'avais pas re-regardé le planning. Je me suis retrouvé à assister aux quelques premières minutes de la session VMWare. J'ai donc changé de salle pour aller suivre une "Track" a priori plus développement, plus code. J'ai pu voir quelques trucs bien agréables pour améliorer la tronche des composants Swing ou en simplifier le développement :

  • un peu de code maison, pas forcément difficile mais qu'il faut tout de même trouver :-),
  • SwingX
  • Timing Framework

WSIT : Tangoing with .Net

Cette session a permis de rappeler les normes existantes ou en cours de développement liées à WS. C'est Rags qui s'est occupé de la partie "magistrale" :-). Alexis et Stéphane Goudeau (de MS), nous ont quant à eux fait une jolie démo de l'interopérabilité Java/.Net, projet sur lequel ils ont travaillé pour la DGME. Il a notamment été question d'optimisation du transport des pièces jointes avec les WS en utilisant deux protocoles/principes (?) :

  • W3C SOAP Message Transfert Optimization Mechanism : MTOM
  • W3C XML-binary Optimized Packaging : XOP

La session s'est ainsi terminée par l'envoi depuis le code .Net d'une image affichée ensuite sur le portable d'Alexis.

SOA, WS, BPEL : Rima Patel

Après la session WSIT, j'ai quitté la grande salle pour rejoindre Rima Patel afin de découvrir un peu ce qu'était BPEL, dont j'entends tant parler mais dont je ne savais toujours pas ce qu'elle permettait de faire concrètement.

Cette session a été intéressante pour rappeler une fois de plus ce que doit être une Architecture Orientée Services. Un peu en vrac :

  • Un WS est une boite noire avec une interface bien définie (elle n'a pas utilisé le mot contrat, je trouve pourtant qu'il convient parfaitement bien).
  • SOA apporte de la valeur ajoutée sur le métier, pas sur la technique. Elle a même dit : c'est pour ça que ce sera votre CEO qui vous parlera peut-être de SOA, en raison de la valeur ajoutée métier qu'elle apporte (Nota de moi : et qui donc est remontée dans les articles de 01 Informatique :-)).

On a eu droit en fin de session à une démo de BPEL dans NetBeans. Comme je voulais en savoir plus sur BPEL, je suis ensuite allé au TP pour faire les exercices moi-même. J'avoue que le plugin BPEL, notamment le debugger, de netbeans est impressionnant de simplicité. Le problème, c'est que je n'ai pas eu le temps de faire le troisième exercice où on rentrait un peu plus dans le code. Les deux premiers n'étant presque que du clic-clic-bouton sur l'interface de netbeans sans forcément prendre le temps de comprendre un peu plus BPEL. Comme j'ai le support, j'essaierai de finir l'exercice pour voir s'il y a des choses intéressantes à dire.

J'aurais aimé terminer la journée en allant au "FOSSDAY" sur "Langages Libres, machines virtuelles et Web 2.0", mais j'ai préféré ne pas arriver chez moi à 21h. J'ai pu voir un peu plus la famille pour une fois que je passe dans la région parisienne (en coup de vent, en plus :p).

Voilà pour aujourd'hui, bonne nuit :-).

Notes

[1] Lorsqu'une spécification est publiée, Sun développe toujours une implémentation de référence pour montrer la faisabilité du principe. Ces implémentations sont donc souvent basiques et impropres à un usage en production. Ce n'est donc pas le cas de Glassfish.

aucun commentaire aucun rétrolien

mardi 13 mars 2007

Sun Tech Days à Paris, les 19, 20 et 21 mars 2007

Par batmat le mardi 13 mars 2007, 20:41

J'y serai le mardi 20 et le mercredi 21. Et vous ? :-)

un commentaire aucun rétrolien

dimanche 18 février 2007

JSR 310 : Date and Time API

Par batmat le dimanche 18 février 2007, 23:11

Génial.

L'API standard de Java manque encore aujourd'hui cruellement d'une API de traitement des dates, de calcul des durées entre deux dates et tout ce qui peut avoir un rapport avec le traitement du temps dans un programme. L'une des bibliothèques les plus connues qui comble cette lacune est Joda-Time.

Une JSR est donc en marche pour répondre à ce besoin de façon standard. Ceux qui ont déjà utilisé les classes Calendar et Date savent à quel point elles sont incomplètes et parfois même bugguées. Vivement que ce groupe de travail produise la base de ce javax.time.*, base sur laquelle nous pourrons jeter un oeil afin de commenter. Ça va sûrement être très intéressant. Nous découvrirons alors notamment s'il est entrevu un chemin de migration entre la classe Date actuelle et celle qui sera conçue. A priori, les deux classes devraient en effet être rendues obsolètes :

It is intended that this JSR will produce classes that effectively replace the need for the existing Date and Calendar APIs. Over time we look forward to other specifications being updated to us the new date and time API.

Mais le groupe de travail tentera évidemment si possible de réintégrer ces classes dans le nouveau modèle :

In terms of design, it is intended that immutable classes will form the core. It is also intended to use interfaces, if possible, to bring the old Date and Calendar classes into the new model. The expert group will also examine if Calendar can be reimplemented internally using the new date and time classes.

Vu la base de code dans la nature qui dépend de Date/Calendar, j'espère qu'on trouvera un moyen de fusionner l'ancien et le nouveau modèle...

aucun commentaire aucun rétrolien

mardi 30 janvier 2007

Comment fusionner plusieurs listes en une seule avec Spring [Test de coloration syntaxique :-)]

Par batmat le mardi 30 janvier 2007, 10:05

Attention, fonctionnalité en test :-). Merci GeShi

C'est pas mal du tout, mais il faut encore améliorer le rendu. Notamment les espaces inter-lignes. Il faut aussi que je passe en mode "class" et que j'écrive le code CSS associé au rendu que je veux donner à mon code.

package fr.mipih.foundation.spring;



import java.util.ArrayList;

import java.util.List;



import org.springframework.beans.factory.config.AbstractFactoryBean;



/**

 * Classe Spring permettant de fusionner plusieurs tableaux ou listes en une seule.

 * 

 * @author Baptiste Mathus

 */

public class ListMergerFactoryBean extends AbstractFactoryBean

{

        List<String> mergedSourceList;



        public Class getObjectType()

        {

                return List.class;

        }



        public void setSourceLists(List[] sourceLists)

        {

                mergedSourceList = new ArrayList<String>();

                for(List<String> l : sourceLists)

                {

                        mergedSourceList.addAll(l);

                }

        }



        @Override

        protected Object createInstance() throws Exception

        {

                logger.debug(mergedSourceList);

                return mergedSourceList;

        }

}

2 commentaires aucun rétrolien

mardi 2 janvier 2007

Différence entre Session.save() et Session.persist()

Par batmat le mardi 2 janvier 2007, 15:28 - Technique

Dans la version 3 d'Hibernate, d'un point de vue strictement utilitaire, il y a deux méthodes qui ont le même objectif : sauvegarder un objet en base (ou le rendre persistant, comme on dit).

Le problème est donc de savoir laquelle il faudrait plutôt utiliser. Et bien la réponse est simple, euuuu...

Traduction de ce qu'on peut lire dans la FAQ :

Je ne sais pas si je dois utiliser save() ou persist().

Ces deux méthodes rendent persistante une instance éphémère (NdT : transient). Toutefois, la méthode persist() ne garantit pas que la valeur de l'identifiant sera assignée immédiatement, l'assignement pourrait arriver au moment du flush.

La méthode persist() garantit aussi qu'aucun INSERT ne sera exécuté si elle est appelée en dehors d'un contexte transactionnel. Ceci est utile pour les conversations longues avec un contexte de persistance/session étendu.

La méthode save() ne garantit pas la même chose. Elle retourne un identifiant, et si un INSERT doit être exécuté pour obtenir l'identifiant it returns an identifier (e.g. générateur "identity", pas "sequence"), cet INSERT arrive immédiatement, peu importe que vous soyez à l'intérieur ou à l'extérieur d'une transaction. Ce n'est pas bon pour les conversations longues avec un contexte de persistance/session étendu

En résumé, si vous faites des conversations longues, utilisez plutôt persist(). Sinon il y a peu de différence, mis à part toutefois le cascading. Celui-ci n'est propagé dans le cas de save() que si la relation est mappée cascade="save-update", alors que c'est cascade="persist" pour persist().

Notez que si vous mappez cascade="all", cela inclue à la fois save-update et persist. Donc pour les relations mappées "all", la sémantique de persist() et de save() sont à mon avis extrêmement proches.

aucun commentaire aucun rétrolien

- page 1 de 2