C’est alors que la lourdeur des framework J2EE a donné naissance à une alternative qui s’est voulu plus simple : Spring.

J’aime bien Spring, je pense que vous le savez déjà
C’est pour moi en quelque sorte l’équivalent de l’esprit d’ALT.Net, mais en Java.

Ce fut alors la mode des IOC, et de l’approche orienté POJO. Quand j’ai découvert cela, je me suis rendu compte à quel point le framework d’Eclipse RCP pouvait être compliqué…
La gestion de dépendance et de publication/consommation de service devenaient extrêmement simple.

La ou Spring n’était qu’un framework, « SpringSource DM Server » est, quand à lui, un vrai serveur J2EE mais avec une architecture complètement différente de ses concurrents : il est basé sur le même moteur OSGI qu’Eclipse !

L’installation de nouvelles applications vous semble pénible ? SpringSource DM Server offre un « AppStore » pour installer un nouveau service et ses dépendances en 2 cliques!

Pour ceux qui ont lu mon billet sur WebMatrix, la fonctionnalité n’est pas tout à fait la même que c’elle du produit Microsoft.Vous pouvez ici installer bien d’autres choses que des applications Web: des ESB, des serveurs Web (car oui, en Java, on a le choix entre Tomcat, Jetty et autres), etc.
Vous voulez installer un serveur de Messaging ? Installer ActiveMQ en quelques cliques : http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.activemq&version=5.3.0

Vous trouvez plus d’infos sur http://www.springsource.com/products/dmserver/repository

En plus de tout ces avantages, SpringSource DM Serveur offre un interface d’administration d’un pure merveille, j’en bave quand je vois que Microsoft reste attaché à sa MMC…
Et comme si ça ne suffisait pas, SpringSource ont racheté Hyperic qui est une appli Web de Monitoring applicatif, ce qui rend l’administration de votre serveur  encore plus professionnel.

Petite conclusion:

• l’IOC c’est cool, vive l’approche POJO
• OSGI c’est de la bombe. Cela permet aussi bien de gérer des plugins dans un IDE, que des middleware dans un serveur d’applications
• l’installation d’une plateforme applicative doit être simple et facile, autant que de lancer un Setup de EasyPHP ou de cliquer sur un lien d’un “AppStore”
• vive les interfaces Web d’administration, à mort la MMC

Tout en étudiant J2EE, je suis tombé amoureux de mon IDE Java préféré : Eclipse. Pas seulement pour sont utilisation, mais aussi pour son architecture.

En effet, la réalisation de plugins pour Eclipse se fait de manière ultra puissante. A tel point que le « noyau » d’Eclipse peut être complètement extrait pour faire sa propre application qui n’a rien à voir avec un IDE : c’est le framework RCP (Rich Client Platform).
J’ai d’ailleurs à l’époque réalisé une application RCP pour la gestion de budget d’achat de livres pour les bibliothèques.

Malheureusement, la pauvreté des composants graphique en Java faisait du tors à cette plateforme.
Mais je restais subjugué par le moteur de plugins :

• Les plugins sont isolés afin que si un plugin crash, les autres continuent leur vie
• Les plugins sont aussi isolé coté sécurité : un plugin ne peut pas accéder aux codes d’un autre plugin si ce dernier ne l’a pas explicitement rendu « publique »
• Les plugins peuvent publier et consommer des services, avec un model très élégant
• Il y a une gestion de dépendance entre les plugins, avec la prise en compte des versions
• L’installation et la mise à jour des plugins se fait d’une simplicité déconcertante

En fait, si la gestion des plugins est si balaise c’est car elle provient d’un standard de « développement par composant » : OSGI.

L’alliance OSGI est un organisme de personnes qui se mette d’accord ensemble sur des specs concernant les frameworks OSGI. C’est encore la que Java écrase .Net par sa maturité : il n’y a pas de monopole, il y a bien plusieurs acteurs derrière un « standard » ouvert qui va connaitre de multiples implémentations.

OSGI est donc un framework complexe de gestion de « modules » qui exposent des « services ». N’hésitez pas à lire le WIKI qui explique ça très bien : http://en.wikipedia.org/wiki/OSGi

En conclusion, Eclipse est une plateforme riche en plugins grâce au coté Open-Source de l’IDE, à l’API de plugins très bien faite mais aussi à l’aide du plugins pour développer des plugins

Qu’en est-il du coté .Net? VisualStudio a-t-il le même succès concernant le développement ce plugins? Offre-t-il une architecture de plugin aussi puissante? On verra ça dans un autre épisode

Je remercie Freddy pour sa présentation et Octo pour leur accueil.

En résumé, nous avons évoqué les problèmes avec les langages objets, et ce qui nous fait perdre en productivité.
Pour cela, il faut définir exactement ce qu’est l’Objet: d’après Freddy : Héritage, Composition, Polymorphisme.

D’après lui, l’héritage est un handicap, la composition est une bonne chose, le polymorphisme aussi.
Mais voila, c’est mon blog, alors je parle de ce que je veux
Ceci dit, j’avoue que çette présentation m’a fait réfléchir. A vrai dire, ça m’a presque empêcher de dormir!

Après de longues réflexions, je ne pense pas que l’objet soit une erreur historique. Freddy souligne bien le fait que l’objet est complexe, et pas facile à maitriser. Vous en connaissez beaucoup qui ne font jamais une erreur d’architecture? Qui maitrise le MVC, l’AOP et l’ORM ? (à part moi? ^^)

Ma définition de l’objet est différente : pour moi, tout est objet, c’est l’unité atomique en programmation.
On peut tout faire avec des objets, les meilleurs choses comme les pires.
Je distingue  plusieurs catégories d’objets suivant leurs responsabilités:

1 – Object domain

L’Object Domain est une représentation d’un composant métier (au sens DDD du terme). Un objet possède un état et un comportement. Une facture par exemple possède un état représenté par son “prix”, et un comportement comme “appliquer une remise”.

2 – Services

Le service est un Objet ayant pour responsabilité de fournir des traitements, c’est-a-dire qu’il n’a pas d’état mais seulement un “comportement”. En DDD, ces services permettent de calculer des choses qui impliquent plusieurs graphes d’objet. Si une facture sait calculer son propre prix, elle n’est pas capable de calculer le profit du mois courant, c’est donc la responsabilité d’un objet de plus haut niveau, c’est à dire le service.

3 – Repository

Un Repository est un service spécial qui a pour objectif de faire l’interface entre le programme et les sources de données, que ce soit des Base de données, fichiers, caches mémoire, WebService ou WMI. Comme le Repository fait référence à une source de données externe (non en mémoire) il n’est pas testable unitairement.
Le Repository fait office de référence des données, on peut dire alors qu’il possède l’instance “de référence” d’un objet.

4 – Factory

Si le Repository est responsable de charger ou modifier les données existantes, la Factory quand a elle est responsable de créer une nouvelle donnée. La Factory est un service, qui a donc connaissance des différents objets du SI pour en construire un nouveau. On peut imaginer que la Factory construise une facture avec un “ReferenceNumber” calculé intelligemment en fonction de la date du jour, et du prochain numéro de factures en fonction de celles déjà existantes: #QUOTE_230110_0002

5- Data Transfert Objects (DTO)

C’est le fameux DataSet de Freddy. Si l’objet du domaine ne possède plus de constructeur (Factory) ne possède plus de procédures/fonctions (Service&Repository), il ne lui reste que l’état, c’est-à-dire une ensemble de données.

On peut alors parler de “structure” ou de “type valeur”. Il ne sert qu’à être “sérializé” à travers un réseau, ou entre 2 programmes, et passer de tier en tier, de l’interface à la source de données. Avoir une unique instance importe peu, ce n’est d’ailleurs pas possible en N-Tier, on l’identifie alors avec son ID.

6 – Message

C’est en quelque sorte la “Command” ou la “Query” de CQRS. C’est un objet qui représente une action à faire: une requête (query) pour récupérer un objet, ou une action (command) à effectuer dans le programme. L’utilisation d’un objet “message” permet de réduire le nombre d’arguments d’une méthode, ou ne donner que ce qui est nécessaire à la méthode: comme le dit Udi, rien ne sert de donner TOUT l’objet métier à la fonction ComputeDiscount(), son ID et le Pourcentage suffisent.

Comment utiliser tout ceci

Pour donner un retour d’expérience, je vais expliquer comment j’utilise ces objets en général.

En réalité, j’utilise très très rarement des méthodes dans des objets. Mes objets du domaine peuvent alors se résumer à des DTO.
Je séparer le comportement dans des services.

J’utilise aussi très peu l’héritage. Je me sert très souvent de la composition, voir de l’AOP.

Je n’ai pas parlé des interfaces, mais c’est un concept important puisque comme dit Freddy:

“tout est boite noire, c’est le principe de composition”.

L’interface au sens “POO” est donc l’intermédiaire entre l’utilisateur (le code appelant) et ce qu’il y a dans la boite noire (implémentation).
Ces interfaces ont aussi un rôle très important dans l’interopérabilité, ou les systèmes distribués: il est donc dommage que ces notions ne soit pas inhérente au langage, quelque soit la technologie de communication.

Procédure ou Fonction?

En ce qui concerne le comportement, on peut distinguer la “procédure” et la “fonction” : La fonction au sens “fonctionnel” du terme, est sensé calculer un résultat sans effet de bord (sans altéré l’état de l’objet ou de ses paramètres). La procédure par contre, ne renvoi aucun résultat et ne sert qu’à altérer l’état de l’objet.
Les langages modernes ne font pourtant pas la distinction entre ces 2 notions, et c’est peut-être une erreur (on avait pourtant le “const” en C++).
Si Freddy suggère que l’objet est un échec, je pense que les “procédures” le sont. Depuis de début de ma formation informatique, on nous met en garde contre les effets de bord, et l’on trouve divers mécanismes pour les éviter, alors qu’on peut simplement “interdire” les procédures. Il faut en tout cas un concept “d’immutabilité” clair pour savoir ce que “la procédure/fonction” fait exactement.

Référence ou Valeur?

On distingue l’identité d’un objet par sa référence, ou son instance en mémoire (c’est à dire son adresse mémoire). Mais ce n’est clairement pas représentatif de la réalité. Dans un contexte distribué comme l’a dit Freddy, ce n’est pas possible: la donné existe dans plusieurs mémoires (plusieurs programmes) et plusieurs machines. Il existe alors plusieurs instances d’une même données : dans l’interface du programme client, sur le serveur de WebService et dans la base de données.

Les références sont donc inutiles, puisque la donnée existe partout, mais on a du coup besoin d’identifier un objet à l’aide d’autre chose, et c’est souvent un “ID” qui sera la clé en BD. Il serait utile aussi de connaitre sa “version”, afin de résoudre mieux résoudre les changements, tout comme dans un gestionnaire de code source.

Donc finalement, les objets du domaine ne sont que des DTOs, tout comme des “Datasets typés”.
Mais parfois nous avons besoin de représenter une même donnée sous différente forme.
Exemple: J’ai besoin de récupérer une liste de “Factures” avec son total calculé, ou parfois j’ai besoin de la même “Facture” mais avec son détail: InvoiceListItemDto & InvoiceDetailDto.

Le problème est le suivant: j’ai une fonction qui calcule le totale avec taxe, qui prend en paramètre un InvoiceDetailDto alors que je manipule un InvoiceListItemDto.

Je me retrouve avec un type incompatible, et pourtant, ma fonction a besoin de champs existant aussi bien dans le premier que le deuxième type: un total hors taxe.

float ComputeWithTaxes(InvoiceDetailDto dto);
var invoice = new InvoiceListItemDto();
ComputeWithTaxes(invoice); // !!! ça marche pas

Faut-il alors de l’héritage pour que la fonction prenne en paramètre un type commun?
Ah NON! Si je commence comme ça, je vais avoir besoin de multiple héritage rapidement, pour de multiples fonctions. Et comme je code en C#, je n’ai pas de multiple héritage.

Alors ai-je besoin d’une interface commune? Mais dans ce cas, vais-je faire une interface pour chaque fonction?? Ors de question.

Une solution existe alors pour convertir un type “presque identique” à un autre: AutoMapper!!
Une solution proposé par Fredy, c’est de ne pas typer tout simplement. Ma fonction va alors “planter” si elle n’a pas les informations attendues, mais fonctionnera le reste du temps.
Mais une autre solution plus simple existe: je peux simplifier la fonction pour ne lui donner QUE CE QUI EST NECESSAIRE:

float ComputeWithTaxes(float totalWithoutTaxes);

Paramètres ou Messages?

Comme je l’ai dit au début, un peut utiliser des objets, qui ont une duré de vie très courte puisqu’ils ne servent qu’a représenter une liste d’argument d’une méthode.
Cela simplifie l’appel de la méthode, et rend la lecture du code plus lisible.

Prenons par exemple l’interface suivante:

public class InvoiceService
{
  Invoice ProcessMessage(ApplyDiscountMessage message)
  {
    // do some stuff
  }

  object ProcessMessage(object unknownMessage)
  {
    // ignore it, unkown message type
  }
}

Grâce au polymorphisme, nous avons un comportement dynamique qui traite le message si son type est connu.
Si tout les services sont capables de prendre une commande, ils peuvent se spécialiser pour traiter certains type de commandes et ignorer les autres.
Un appel à la méthode “ProcessMessage” ne provoquera alors jamais une erreur de compilation, mais peut être ignoré dans le pire des cas.

Et puisque mon programme peut posséder plusieurs services capables de traiter un même type de message, je peux alors le dispatcher à chacun d’eux.
Exemple :

Factory.GetServices().ProcessMessage(new ApplyDiscountMessage {id=1, discount=10.0}) ;

Un nouveau langage!!

En reprenant donc tous ces concepts, je peux TOUT modéliser avec les objets tels qu’on les connaît aujourd’hui.
Mais pour être plus efficace pour la réalisation des différentes briques du SI et modéliser facilement le métier sans rentrer dans la technique, on a peut-être besoin de plusieurs DSL pour chaque aspect du SI, même si ces DSL reposent sur l’objet (tout comme le langage qui s’appuie sur l’assembleur).

Je vais donc essayer de reprendre les concepts cité plus haut, et en faire un NOUVEAU LANGAGE!!

Reprenons le plus important: “Pas d’objet, des données!”.
Soit alors la définition d’une donnée comme ceci:

data Person
{
  key int Id;

  version int Version;

  unique max(20) string SocialSecurityNumber;

  DateTime Birthday;

  string Firstname;

  string Lastname;
}

Il n’y a ici que de la donnée, pas de comportement. Donc inutile de rendre des choses privés, si aucunes méthodes ne peut s’en servir.
Comme je l’ai dis plus tôt, on a besoin d’un identifiant pour cette donnée. Pourquoi ne pas l’inclure au langage?
De même pour la version ou les contraintes sur les données.
Si vous souhaitez calculer l’age de la personne, il suffit alors de demander à un service de le faire:

contract PersonContract
{
  float ComputeAge(Person this);

  string SayHelloTo(Person this, Person otherPerson);

  string Talk(Person this, Person to, string message);

  Person HappyBirthDay(Person this);

  Person BuildNew();
}

// on parle beaucoup "d'injection de dépendance", c'est même maintenant une JSR en Java,
// ou un mot clé dans le langage NOOP. Un contrat peut donc dépendre d'un autre contrat
service PersonService : PersonContract<Person>
   depends MathContract,optional DateContract, PersonRepository
{
  float ComputeAge() =>
    this.Birthday-DateTime.Now;

  string SayHelloTo(Person otherPerson) =>
     "Hello {otherPerson.FirstName} {otherPerson.LastName.ToUpper()}";   
  
  string Talk(Person to, string message) =>
     var m = message??"Hello";
     "Hey {to.FirstName}, {m}!";

  Person HappyBirthDay(Person this) =>
     this.Birthday = this.Birthday.AddDays(1);
     this;

  Person BuildNew()=>
     var id = PersonRepository.GetNextId();
     new Person{ Id = id }; 
}

On peut alors imaginer une utilisation de ce service comme ceci:

// constructeur? pas besoin avec des types valeur...
Person moi;

// ... mais on peut imaginer une initialisation "à la C#3", ou dirais-je,
// comme un tableau puisque chaque structure est comme un tableau typé
Person freddy = { Firstname = "Freddy", Lastname = "" };

// ... ou demander à une Factory de le construire
Person other = Person.BuildNew();

// la données n'ont pas de méthode, mais rien n'empêche d'utiliser les services comme les méthodes d'extensions?
moi.SayHelloTo(Freddy);

// imaginons aussi que les paramètres sont nommé comme en C#4
// l'ordre n'a donc pas d'importance...
moi.Talk(message = "Salut", to = Freddy)

// ... et les paramètres ont des valeurs par défaut
moi.Talk(to = Freddy);

Conclusion (enfin)…

Après ce petit essaie, il ne me reste plus qu’à maitriser http://www.antlr.org/works/index.html et réaliser mon propre langage

Cette proposition de langage ne résout pas un dernier problèmes évoqué par Freddy concernant l’objet: le typage fort.
Je ne suis pas sûr que le Javascript soit le meilleur langage du monde ça me fait perdre trop de cheveux lors des “debugging-party”.
Je ne suis pas fan d’écrire du code qui “peut être marche”, je préfère éviter de longue journée de débuguage devant le client.

C’est parfois utile, c’est pourquoi C#4 offre maintenant le mot clé “dynamic”. Mais dans certain cas on souhaite s’assurer que le programme est viable, et pour cela il existe la programmation par “contrat” comme le propose Spec#.

Bref, rien de bien nouveau donc. La plupart des propositions proviennent de langages déjà existant. On en revient toujours au même problème: est-ce l’outil qui est mal adapté? Ou est-ce qu’on l’utilise pas comme il le faut? Je ne suis donc pas sectaire, et apprendre de nouveau langage, objet, fonctionnel ou autre, ne me dérange absolument pas. C’est pour moi un métier passionnant que d’apprendre toutes ces choses et utiliser le langage adapté situation.

La particularité et le défi de MonoTouch, c’est que le processeur de l’iPhone ne supporte pas une opération nécessaire à la compilation à chaud (JIT), qui est la base des langages sur une VirtualMachine (.Net et Java). L’application Mono est alors compilée nativement, avec une suppression des bibliothèques du framework inutilisées.

Et Java alors, est-ce que la communauté compte faire quelque chose?
Et bien une startup, Flexycore, l’a déjà fait: iSpectrum! Et le produit est gratuit pour les projets Open-Source!!! Ce qui n’est pas le cas pour MonoTouch.

Voici un aperçu de ce qui est possible:

Certes, la démo n’est pas “bandante”, mais derrière, il y a le support de J2ME, du JavaScript, les API de l’iPhone (comme le GPS) et bientôt l’API OpenGL ES.
Est-ce le retour de Java pour les jeux mobiles?

Ce matin, aux alentours de 5h30, vous vous levez pour allumer votre portable qui démarre sous…

- Windows bien sûre
– Google chrome OS, c’est très tendance et vous avez  juste besoin de surfer

Tiens, on dirait que vous n’êtes pas le seul debout à cette heure! Vous commencez à chatter sur…

– GTalk
– MSN
– une client multi-protocole… ah si vos amis pouvez switcher de MSN vers GTalk…

On vous a parlé de “keyboard cat” sur le net, vous ouvrez alors pour surfer…

– Internet Explorer, c’est le meilleur
– Google Chrome, c’est plus rapide

Vous recherchez l’info grâce à…

– Google évidement
– Yahoo forever
– Bing ça déchire

On vous parle d’un coin de paradis sur terre. Vous allez chercher l’adresse sur…

– Google Map
– Bing Maps

A votre tour, vous voulez publier vos photos de vos dernières vacances. Vous les publiez sur…

– Flickr
– Windows Live
– Picasa Web Album

C’est le moment de vérifier vos Emails, vous allez donc sur…

– Windows Live (Hotmail)
– GMail
– Tout ça c’est “Has been”, vous êtes déjà sur Google Waves

Un mail vous parle de votre prochaine réunion ALT.Net. Vous vérifiez votre disponibilité sur…

– Toujours Windows Live
– Google Calendar

Ouf, quelle mâtiné ! Il est temps d’aller bosser. D’ailleurs, vous aimeriez bien changer de boulot, et vous rêvez secrètement d’être employé chez…

– Microsoft rules the World!
– Google c’est trop Hype!

A force de surfer le matin, vous allez être en retard au boulot. Votre boss vous le rappelle sur votre téléphone qui est un…

– HTC Hero/Dream ou Nexus… n’importe du moment qu’il y a Android dessus
– HTC Touch/Diamond ou autre avec Windows Phone, c’est une valeur sûre

Vous voila à la fin de la journée, vous pouvez enfin rentrer chez vous et bosser sur votre projet perso OpenSource qui est hébergé sur…

– Codeplex
– Google Code

Vous êtes tendance, et vous faites du Cloud Computing. Pour vous, la meilleure plateforme c’est…

– ASP.Net sur Windows Azure, le C# est le meilleur langage du monde
– GWT sur GoogleApp Engine, Java reste une valeur sûre, mais vous attendez avec impatience la sortie de Noop

Vous en profitez pour mettre à jour votre CV. Vous utilisez pour cela…

– Un bon vieux Microsoft Office, Word il n’y a que ça de vrai
– L’avenir est sur le net, vous préférez Google Doc
–  Word c’est bien, mais Office Live c’est mieux!

Il est déjà 1h du mat’, il faut vous coucher. Vous commencez à faire des rêves…

– Noir et Blanc, en costume/cravate
– Tout en couleur, avec votre T-shirt de Hippie “Geek inside”

Comptabilisez vos réponses, et grâce à nos algorithmes mathématiques très complexes, la science et la psychologie vont déterminer de quel côté vous vous situez!

Vous avez plus de : c’est que Microsoft est pour vous  l’entreprise idéale. C’est pour vous synonyme de stabilité, une garantie de fiabilité mais c’est aussi une technologie toujours à la pointe.

Vous avez plus de : c’est que Google est votre idole. Jeune et dynamique, Google va selon vous révolutionner le monde informatique.

Ce qui est sûr, c’est que Google investi pas mal dans Java: GWT, la JVM d’Android, et maintenant Noop: http://code.google.com/p/noop/

Noop est une proposition d’un nouveau langage pour la JVM.
Certains prétendent que le langage Java va mourir, qu’il est coincé et n’évoluera plus, et que son successeur peut être Scala.
Moi qui suit fan de Groovy, je suis heureux de voir que SpringSource prennent en charge son évolution ( http://www.springsource.com/products/grails )
Bref, la JVM n’est pas prête de mourir! Les alternatives à Java se font sérieuses, et Google est maintenant de la partie!!

Noop se veut aussi un langage offrant le meilleur de Java, dont évidement l’API GoogleCollections: http://code.google.com/p/noop/wiki/Features#Good_stdlib

Comme je l’avais dit dans nos discutions Alt .Net, les langages ne se contentent plus d’offrir des mot-clés pour raccourcir le code, ils offrent maintenant des mot-clés pour faciliter l’utilisation de Framework:
- les mot-clés de Linq facilite l’utilisation du framework du même nom
- des mot-clés permettent d’utiliser aisément le framework de parallélisation PFX: http://prismwiki.codegear.com/en/Asynchronous_Statements
- d’autres mot-clés permettent de faire du “TDD”: http://en.wikipedia.org/wiki/Spec_Sharp

Google propose avec Noop des facilités de langages pour exploiter les frameworks de tests unitaires, le mocking, l’IOC, etc..

Alors je dis et je re-dis: Vive la JVM, vive les polyglottes et vive Google!

(J’en profite pour faire découvrir aussi le langage http://fandev.org/ qui est très orienté multilangages et Web)

Mais cette technique est très largement contestée :

• nécessite un éditeur XML “intelligent” (ce qui est le cas grâce à SpringIDE) pour la complétion de la structure mais aussi des types.
• interprétation au Runtime, et donc erreurs potentielles découvertes qu’au dernier moment.
• verbeux
• mauvaises performance (lecture du XML…)

Ça a aussi ses avantages, c’est pour ça que je reste adorateur de Spring, mais ce n’est pas le sujet…

J’ai déjà souvent eu ce débat avec Romain dans le monde .Net (voir http://ninject.org).
Je connais très mal les alternatives à Spring dans le monde Java, mais je connais celle de Google : Guice.

Voici un tuto/introduction très convaincante.

Pour ceux qui ne connaissent pas Ninject ou Guice, voici un peu le principe :
Au lieu de rédiger un XML, on utilise massivement les annotations (attributs en .Net) pour spécifier les injections. Ceci est aussi possible en Spring (technique dite Autowire) mais l’utilisation du XML reste nécessaire pour personnaliser plus finement les dépendances entre instances.
Dans le cas de Guice, au lieu de rédiger un XML, on créer une classe Module qui réalise le mapping entre une interface et la classe concrète à instancier/injecter.
On peut spécifier bien plus de chose que cela, mais je vous laisse lire l’article pour découvrir par vous même.

Pour ceux qui veulent suivre le débat “Spring vs Guice” ou “XML vs Code”, voici le point de vue de la documentation officielle de Guice.

+  = FAN ?

Mais le petit nouveau, FAN, cible aussi bien la JVM que la CLR.Net. Certes, les 2 mondes possèdent des concepts similaires, mais aussi très différents et qui risque de ne pas être possible d’exposé dans ce langage.
Ceci dit, la plupart des concepts sont haut-niveaux, et peuvent donc générer un bytecode en utilisant des concepts plus simples et bas niveau, comme un foreach peut être écrit sous la forme d’un for…

En l’occurrence, FAN introduit un concept déjà existant en C# mais absent en Java : les Nullables.
C’est l’objet de cet article.

De nombreuses autres sucreries du langages C# sont introduites dans le JVM à l’aide de FAN comme les Closures. Je vous laisse découvrir tout ça sur la documentation officielle.
Je vous invites aussi à lire cet autre article d’introduction qui expose beaucoup d’avantages.

Pour ma part, j’adore :

• gestion des nullable
• valeur par défaut des arguments des méthodes (ce qui évite plein de surcharge inutile)
• property implicite à la C#, pour toujours moins de code à écrire
• closure en Java
• pas de ; superflux en fin de ligne
• l’équivalent du mot clé dynamic du C#4 avec object->variable !
• mot clé once qui évite de gérer manuellement le caching du résultat (genre : if(truc == null) truc = new Truc(); return truc;")
• l’écriture des listes/maps et l’écriture des instanciations “à la JSON”

A noter aussi une gestion de “package” propre au langage, et qui n’expose pas toute l’API Java (JDK). Je n’ai pas trouvé d’infos concernant .Net à ce sujet, mais ce langage se veut vraiment comme une union des 2 mondes.

En attendant un pluggin Eclipse ou un addin VisualStudio Shell, ils livrent un mini IDE fort sympathique.

Et vous? Qu’en pensez-vous?

Rentrons dans le vif du sujet: qu’est-ce que ça donne du coté de mon application C#:

// on démarre la JVM avec mes bons arguments
MathiasJniCpp.JVMWrapper.InitJvm(new String[] { "-Djava.class.path=Mathias.Jni.Java.jar" });

// on créer un objet .Net qui wrappe l'objet Java
// en C++/CLI, le destructeur des classes CLI sert de méthode "Dispose"
using (MathiasJniCpp.MyJavaWrapper javaObject = new MathiasJniCpp.MyJavaWrapper())
{
// faire mumuse avec...
javaObject.People = "Mathias";
Console.WriteLine(javaObject.SayHello());
}

// on libère la JVM
JVMWrapper.ReleaseJvm();

MathiasJniCpp c’est le namespace de mon assembly c++/cli, j’en reparlerai plus tard.
On voit que je manipule une classe JVMWrapper qui me permet de charger une JVM (et de la libérer). J’utilise aussi une classe .Net codé en C++/CLI. En fait, je l’utilise comme un classe C#, ou VB.net etc. C’est une classe “classique” .Net avec des méthodes et des propriétés.

Point intéressant à souligner: pourquoi utiliser using?
Pour rappelle, il y a des mots-clefs en C# très lié au Framework (comme foreach) et using en fait partie. Il prend les objets qui implémente IDisposable et fait appelle à la méthode Dispose() à la fin du bloque. Comme ça, je suis sûr de libérer la classe du coté JVM quand j’en ai plus besoin.

Je ne vais pas montrer tout le code, car trop long et disponible ici.
Mais voici un aperçu de la classe C++:

#include "jni.h"
public ref class MyJavaWrapper
{
private:
  static jmethodID initMethodId;
  static jclass clazz;
  jobject obj;
public:
  /* initialisation des métadata Java/JNI, à voir plus tard */
  static void initJavaMetadata()
  { ... }

  /* une méthode de notre classe Java que l'on wrappe, expliqué aussi plus tard */
  String^ SayHello(String^ people)
  { ... }

  /* constructeur */
  MyJavaWrapper(void)
  {
    // histoire de récupérer toutes les métadatas nécessaires du coté Java
    MyJavaWrapper::initJavaMetadata();

    // construction d'une instance avec le constructeur par défaut
    this->obj = JVMWrapper::env->NewObject(MyJavaWrapper::clazz, MyJavaWrapper::initMethodId);
  }

  /* "destructeur" */
  virtual ~MyJavaWrapper(void)
  {
    JVMWrapper::env->DeleteLocalRef(this->obj);
  }
};

Je manipule le membre this->obj qui est tout simplement un “pointeur” sur notre objet java. En fait, c’est un jobject qui est un type définie dans "jni.h".
J’utilise la classe JVMWrapper qui me permet de communiquer avec la JVM, et je lui demande de créer un nouvel objet d’une certaine classe jclass avec un certain constructeur jmethodID et j’obtiens ainsi mon jobject.
Étant donnée que la classe et la méthode ne change pas, j’ai rendu ces données static.

Voyons maintenant ce que fait MyJavaWrapper::initJavaMetadata();:

/* initialise les metadata du coté Java */
static void initJavaMetadata()
{
  // si les métadata ne sont pas déjà récupérées...
  if(MyJavaWrapper::clazz == NULL)
  {
    MyJavaWrapper::clazz = JVMWrapper::env->FindClass("mathias/jni/java/MyJavaClass");
    MyJavaWrapper::initMethodId = JVMWrapper::env->GetMethodID(MyJavaWrapper::clazz, "<init>", "()V");
  }
}

C’est la dedans que j’obtiens une fois pour toute la représentation de la classe Java mathias.jni.java.MyJavaClass et la représentation de la méthode <init> avec en paramètre ()V.
Pour comprend le lien avec la classe, il n’y a pas trop de problème: c’est le fully qualified name avec des ‘/’ au lieu des ‘.’.
Mais en ce qui concerne la recherche d’une méthode, ça devient du charabia!!
En fait, <init> est une méthode un peu spéciale: c’est un constructeur.
Ensuite, on spécifie les arguments du constructeur que l’on cherche, et la on tombe sur une syntaxe barbare. Dans notre cas, on cherche le constructeur par défaut c’est à dire qui ne prend pas d’argument.
Mais pour mieux comprendre la syntaxe barbare, voyons d’autres exemples de méthodes:

JVMWrapper::env->GetMethodID(MyJavaWrapper::clazz, "setPeople", "(Ljava/lang/String;)V");

JVMWrapper::env->GetMethodID(MyJavaWrapper::clazz, "sayHello", "([Ljava/lang/String;Z;)I");

On retrouve cette syntaxe à beaucoup d’endroits, comme sous Eclipse par exemple. Pour plus d’explication voir la documentation officielle.

Si l’on veut maintenant appeler une méthode Java, on récupère sa représentation tout comme on le fait avec le constructeur, puis on l’invoque sur notre instance:

public ref class MyJavaWrapper
{
private:
  static jmethodID initMethodId;
  static jclass clazz;

  // notre représentation JNI de la méthode "sayHello"
  static jmethodID sayHelloMethodId;

  jobject obj;
public:
  /* initialisation des métadata Java/JNI */
  static void initJavaMetadata()
  { 
    /* initialisation de la classe et du constructeur, comme vu précédemment 
    [...]  */

    // on récupère la représentation de "sayHello"
    JVMWrapper::env->GetMethodID(MyJavaWrapper::clazz, "sayHello", "(Ljava/lang/String;)Ljava/lang/String");
  }

  /* sur l'appelle de cette méthode .Net, on fait appelle à la méthode Java */
  String^ SayHello(String^ people)
  {
    // j'utilise une classe spéciale pour convertir ma String^ .net en natif ou Java
    StringConverter peopleStringConverter(people);
    jstring jPeople = peopleStringConvert.toJava();

    // appelle de la méthode Java, j'ai le droit de caster en jstring car c'est un sous-type de jobject
    jstring jResult = (jstring)JVMWrapper::env->CallObjectMethod(this->obj, sayHelloMethodId, jPeople);

    // conversion du type Java en .Net
    StringConverter resultStringConvert(jResult);
    return resultStringConvert.toDotnet();
  }
};

Voila, maintenant vous savez:

• obtenir la représentation d’une classe Java
• obtenir la représentation d’une méthode d’une classe
• créer une instance d’une classe Java
• invoker des méthodes sur une instance

En conclusion:
l’API JNI c’est un peux comme utiliser la réflection. Ça a donc des conséquences en termes de performance. Pour information, créer 10000 objet en java prend 625ms, en pure .net ça donne 46ms et en .Net->JNI->Java ça donne 2.687s.
L’API JNI peut sembler barbare au début, mais on s’y fait et puis il y a la doc, alors RTFM .

C++/CLI c’est de la bombe en termes d’interop. C’est le pont parfait entre le monde .Net et le natif.
L’inconvénient c’est que la syntaxe C++ est lourde. Et elle l’est d’autant plus en C++/CLI car il faut y ajouter les spécificités .Net, et il faut aussi distinguer une instance managée et non-managée, et tout ça passe par de nouveau symboles/mots-clefs.
Les conversions de types entre les deux mondes ne sont pas faites implicitement, et il faut souvent jongler pour avoir le bon type. J’ai par exemple eu des problèmes lors des conversions de String avec JNI: il faut convertir la String^ .net en char* natif pour enfin construire une jstring. Les conversions ont été le plus pénible dans l’histoire.

Enfin, voici le projet complet: Mathias.Jni.CSharp.zip
Un petit rappel des liens utiles:

• http://dotnet.developpez.com/faq/cppcli/
• http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/jniTOC.html

Au début, il y avait le néant… puis l’informaticien inventa la page HTML! Dans sa foulé il inventa le Javascript… puis les applets Java… pas de chance, l’informaticien était en avance sur son temps…

Puis le Web s’est vu enrichir de nouveau média (Youtube, Deezer, etc.) Toute cette magie est possible grâce aux génies de Macromédia inventeurs du Flash! (racheté par la suite par Adobe)
Le web est devenu plus beau, plus fun… et plus lourd tout de même.
Flash est aujourd’hui la techno incontesté pour les médias riches. Elle était aussi en avance sur son temps: les sites entièrement Flash était encore trop lourd pour les débits de l’époque. Ce n’est aujourd’hui plus un problème, mais si tous les sites ne sont pas en Flash, je l’explique pour plusieurs raisons:
Premièrement, cette technologie était boudé par le monde Linux qui se retrouvé avec un produit propriétaire, des versions en retard par rapport à celles sur Windows, et même souvent bugguées.
Les adeptes des standards W3C ne voient pas non plus Flash d’un très bon œil et préfère se concentrer sur la norme HTML+ECMASCRIPT (autrement dit: Javascript).

C’est la que le Web 2.0 atteint son paroxysme: les sites Web d’aujourd’hui exploitent à fond le Javascript (Ajax, GWT, Scriptaculous, etc.). Cela donne des pages Web plus riches, plus interactives, plus animées, et plus légères!
Car oui, le bon vieux HTML avec un peu de Javascript c’est plus léger que du Flash. Certains dénonceront simplement les mauvais codeurs ActionScript qui sont souvent des graphistes reconvertis et qui font des choses non-optimisés…
Ceci dit, cette performance n’est possible que grâce aux effort fournis par les navigateurs Web qui supportent de mieux en mieux le Javascript.
Mais voila, les vidéos ou encore d’autres choses ne sont pas possibles en HTML+Javascript aujourd’hui, et c’est pourquoi que Flash est encore très utilisé (surtout concernant la vidéo).

C’est la que Microsoft riposte avec Silverlight et ça va faire mal.
Imaginez: un plugin similaire à Flash, mais plus performant (WPF utilisant gracieusement DirectX) avec des langages plus faciles à coder (C#, XAML, etc.) et des outils de développement/design très soignés (la série des Expression).

Mais la communauté pro-libre/pro-standard n’en reste pas la: HTML5 est censé combler les lacunes vis-à-vis de Flash ou Silverlight.

Sun veut aussi être de la partie, après l’échec des applets, il tente nous proposer JavaFX.
Les principales raisons de l’échec des applets sont:
- Java c’est gros et lourd à télécharger… imaginez un JRE de 30mo à l’époque des 56k!
- Ce n’est n’était pas non plus très performant, surtout en matière d’affichage.
- Il n’existe aucun outil pour graphiste pour faire des applets! C’est la que Macromédia avec Flash avait marqué un point.
- Ce n’est n’était pas libre… donc difficile à faire adopter par la communauté des développeurs.

Mais Sun propose des solutions:

• Java Kernel: le principe est simple, il faut que le téléchargement d’une JRE soit négligeable (tout comme Flash). Pour ce faire, l’utilisateur télécharge une version “minimale” de la JRE, qui téléchargera des paquets supplémentaires seulement s’il y en a besoin.
• Java2D/Swing plus performant, ainsi que l’accélération avec DirectX (elle existait depuis peux de temps, mais désactivé par défaut car trop buggué). Cela permet aussi des effets comme la transparence etc.
• JavaFX: ou comment créer un langage de description d’interface, pour créer plus simplement des animations etc.
• Java est open-source: à quand Java installé par défaut sous Linux? (Même si c’est maintenant un paquet officiel d’Ubuntu)

Le seul hick qui va faire très très mal: toujours pas d’outil puissant pour les graphistes.
On peut aussi se demander pourquoi avoir inventer un n-ième langage de script, là où tout le monde optent pour le XML comme descripteur d’interface.

On remarque que “Open-source” est maintenant synonyme de “standard”, et ça Adobe l’a compris. Fort se sa popularité, l’ouverture forcement va booster son engouement.
Microsoft n’est pas en reste dans ce domaine: depuis son alliance avec Novell, ils travaillent tous deux pour promouvoir .Net sous Linux même si l’équivalent à Silverlight en libre, Moonlight, est encore loin de voir le jour…
On pouvait pointer du doigt le manque de sérieux en matière de développement avec ActionScript, mais avec Flex ce n’est plus vrai.

Avec toutes ces technos, on se demande si le navigateur ne servira plus qu’a charger un plugin Flash/Java/Silverlight, et déléguera le travail de rendu à ceux la. Mozilla sonne l’alarme et explique l’importance de HTML5.

Les paries sont lancés:
Les prochains sites-web, en Flash? HTML5+Javascript? Silverlight/Moonlight? JavaFX?