121. Les plates-formes Java et .Net

Niveau :

Supérieur

Java et .Net sont les deux principales plates-formes de développement d'applications de différents types (standalone, client/serveur, applications web et applications mobiles).

Java est découpée en plusieurs plates-formes :

• Java SE (J2SE) : la plate-forme standard
• Java EE (J2EE) : la plate-forme pour le développement d'applications d'entreprise
• Java ME (J2ME) : la plate-forme pour le développement d'applications mobiles
• Java Card

.Net est découpée en deux plates-formes :

• .Net Framework : pour le développement d'applications standalone et web
• compact .Net Framework : pour le développement d'applications web

.Net semble plus homogène, essentiellement au niveau des API de ses plates-formes car son développement est plus récent et le nombre de systèmes cibles est beaucoup plus restreint (Windows et Windows CE/Mobile).

Le tableau ci-dessous recense les principaux points communs et différences des deux principales plates-formes.

Ce chapitre contient plusieurs sections :

• La présentation des plates-formes Java et .Net
• La compilation
• Les environnements d'exécution
• Le déploiement des modules
• Les version des modules
• L'interopérabilité inter-language
• La décompilation
• Les API des deux plates-formes

121.1. La présentation des plates-formes Java et .Net

En juin 2000, Microsoft lance la plate-forme .Net et un nouveau langage qui lui est dédié : C# (prononcer C Sharp). Cette plate-forme tranche profondément avec les précédentes plates-formes de Microsoft tant au niveau développement qu'exécution.

L'environnement d'exécution des applications .Net est le CLR (Common Language Runtime) qui est l'équivalent de la JVM pour les applications Java.

Le développement d'applications .Net et Java s'appuie sur un ensemble d'API de base fourni respectivement par les deux plates-formes.

Les applications .Net peuvent être écrites dans les différents langages qui proposent un compilateur pour produire du MSIL (MicroSoft Intermediate Language) qui est l'équivalent du bytecode de Java.

L'un des auteurs du langage C# est Anders Heljsberg qui est aussi l'auteur de Delphi.

La documentation de la plate-forme .Net est consultable aux url suivantes :

https://msdn.microsoft.com/fr-fr/netframework/default.aspx

https://msdn.microsoft.com/en-us/netframework/default.aspx

121.1.1. Les plates-formes supportées

Pour .Net, Microsoft ne supporte officiellement que les systèmes d'exploitation Windows et Windows CE/Mobile.

Certaines parties de la bibliothèque de base de .Net sont dépendantes du système d'exploitation Windows notamment la bibliothèque WinForm.

Plusieurs projets open source concernent le portage de .Net sur d'autres systèmes que Windows notamment Mono sous Linux et Rotor sous Free BSD.

La portabilité multiplateformes est un point fort qui a favorisé le succès de Java (Write Once, Run Anywhere). Celle-ci est assurée grâce à la compilation du code source en un langage intermédiaire exécutable par toutes les JVM.

Les plates-formes Windows, Solaris et Linux sont officiellement supportées : d'autres éditeurs proposent le support d'autres systèmes notamment AIX (IBM) et Mac OS (Apple).

121.1.2. Standardisation

Le langage C# est normalisé par l'ECMA (ECMA-334) fin 2001 et par l'ISO/CEI(ISO/CEI 23270) en 2003.

Les évolutions des plates-formes Java sont réalisées par le JCP.

121.2. La compilation

La compilation de code Java et d'un langage supporté par .Net crée une entité qui contient du pseudo code : Bytecode pour Java et MSIL (Microsoft Intermediate Langage) pour .Net.

Le code MSIL est commun à tous les langages de .Net : il est ainsi possible de créer une classe dans un langage, de la compiler et de dériver cette classe dans un autre langage de .Net.

Le SDK de .Net fourni pour chaque langage un compilateur, par exemple csc.exe pour C#

Exemple

csc.exe /out :MonApp.exe fichierSource.cs

121.3. Les environnements d'exécution

Le code Java et .Net est compilé dans un langage intermédiaire respectivement Bytecode et MSIL (Microsoft Intermediate Language) et est exécuté dans un environnement d'exécution respectivement JVM (Java Virtual Machine) et CLR (Common Langage Runtime). La compilation dans un langage indépendant de tous systèmes n'est pas une nouveauté : par exemple, elle était déjà mise en oeuvre dans Smalltalk.

.Net et Java compilent leur code source dans un langage indépendant de tout système et de tout hardware : ce langage intermédiaire (.Net) ou bytecode (Java) est exécuté par interprétation (Java) ou compilation à la volée (compilation JIT : Just In Time) par l'environnement d'exécution de la plate-forme (.Net et Java).

En Java, chaque classe peut implémenter une méthode main avec une signature spécifique qui peut être autant de points d'entrée pour l'application. Il faut préciser à la commande java le nom de la classe qui contient la méthode main à exécuter.

En C#, le point d'entrée de l'application peut être précisé avec l'option /main:maClasse du compilateur.

121.3.1. Les machines virtuelles

Le pseudo code produit à la compilation est exécuté par une machine virtuelle : JVM en Java et CLR en .Net

CLR et JVM mettent en oeuvre un compilateur Just In Time et une gestion de la mémoire grâce à un ramasse-miettes (garbage collector) pour les objets créés dans le tas (heap).

Il est possible en Java de gérer la taille de la mémoire allouée à la JVM. Ceci n'est pas possible avec le CLR.

121.3.2. Le ramasse-miettes

Le CLR et la JVM propose tous les deux un mécanisme de libération automatique de la mémoire des objets inutilisés : le ramasse-miettes (garbage collector).

Les environnements Java et .Net assurent donc leur propre gestion de la mémoire en utilisant un ramasse-miettes. Le ramasse-miettes a pour rôle de rechercher les objets inutilisés et de libérer leur espace mémoire, évitant ainsi aux développeurs d'avoir à le faire explicitement.

Sur les deux plates-formes le ramasse-miettes facilite le travail du développeur. Cependant les fuites de mémoire existent et peuvent être particulièrement difficiles à corriger du fait même que les développeurs se désengagent de la gestion de mémoire ou méconnaissent les mécanismes sous-jacents. Généralement, ces fuites de mémoire sont difficiles à corriger sans l'utilisation d'un profiler qui permet d'inspecter le contenu de la mémoire.

121.4. Le déploiement des modules

Avec .Net, le code est compilé et packagé dans une assembly.

Le SDK de .Net propose l'outil al.exe (Assembly Linker) pour créer des assemblies.

Une assembly peut être physiquement un .exe ou .dll : elle contient le code compilé, des ressources (icônes, images, texte, ...) et des métadonnées.

Ces métadonnées correspondent, entre autres, à un numéro de version qui permet au CLR de charger dynamiquement la bonne version sans avoir à enregistrer l'assembly dans la base de registres. Il est ainsi possible d'avoir deux versions d'une assembly dans un même répertoire.

Le déploiement d'une application .Net peut alors se résumer à une simple copie de fichiers.

Java propose plusieurs formats de packaging des modules selon le type de composants qu'il contient : jar (pour les applications ou les bibliothèques), ear (pour les applications d'entreprises), war (pour les applications web), ...

121.5. Les version des modules

Fort de l'expérience du DLL Hell, Microsoft a réussi à proposer une gestion des modules qui soit un point fort de .Net car elle offre une simplicité d'utilisation tout en étant puissante en permettant, par exemple, d'utiliser plusieurs versions d'une assembly dans un même domaine d'application.

Cette gestion repose sur le stockage dans l'assembly de metadonnées qui contiennent le nom mais aussi le numéro de version de l'assembly.

En Java, la gestion des modules peut rapidement devenir problématique essentiellement à cause des classloaders qui par défaut parcourent de façon linéaire le classpath pour rechercher une classe dans le premier module trouvé.

Pourtant, le mécanisme des classloaders est puissant : il est utilisé par la JVM mais il l'est aussi, par exemple, pour isoler les bibliothèques des applications web exécutées dans un conteneur web ou pour permettre le chargement dynamique de modules par OsGI.

121.6. L'interopérabilité inter-language

Java propose l'API JNI (Java Native Interface) pour permettre l'exécution de code natif dans la JVM.

Le mot clé native est utilisé pour marquer une méthode contenant du code natif.

L'outil javah permet de générer des fichiers header qui devront être exploités pour produire le code qui sera compilé en bibliothèque native.

Historiquement, la plate-forme Java propose aussi un support pour Corba.

En .Net, l'invocation d'objets COM est intégrée dans la plate-forme, ce qui facilite la réexploitation de code existant.

L'invocation de code natif sous la forme d'objets COM est simplifiée grâce à des outils du SDK (tlbimp et tlbexp) qui génèrent des proxys.

En C#, il est possible d'utiliser directement une DLL grâce au mot clé extern et à l'attribut DllImport, ce qui offre un moyen très simple de réutiliser des fonctionnalités existantes tant que celles-ci sont des DLL Windows.

Dans les deux cas, l'exécution de code natif ne permet pas aux machines virtuelles de gérer la mémoire des objets natifs.

L'intéropérabilité des deux plates-formes est possible facilement en utilisant les services web. Un projet commun vise à favoriser l'interopérabilité de ces services entre le framework WCF de .Net et Metro qui est l'implémentation de référence de JAX-WS.

121.7. La décompilation

Comme Java et .Net compilent leur code source dans un langage dédié, il est possible de décompiler ce langage intermédiaire pour obtenir le code source.

Il existe des solutions d'obfuscation proposées par des tiers pour les deux plates-formes.

Le SDK de .Net propose un outil graphique pour réaliser cette décompilation : ildasm (intermediate Langage Desasambler).

Java propose l'outil javap en ligne de commandes pour visualiser le bytecode.

121.8. Les API des deux plates-formes

Un langage est moins utile sans un ensemble de bibliothèques qui fournissent les fonctionnalités de base pour créer des applications. Ces fonctionnalités peuvent couvrir de nombreux sujets : threads, entrées/sorties, réseaux, collections, utilitaires, manipulations XML, accès aux bases de données, composants graphiques, ...

Les plates-formes Java et .Net fournissent un ensemble très riche d'API

En terme d'API, .Net propose une unique API fournie en standard dans la plate-forme ce qui n'oblige à aucun choix majeur. Quelques API open source se développent : ce sont essentiellement des portages d'API Java populaires (Log4net, Spring.Net, Nhibernate, ...)

Java propose généralement une ou plusieurs API qui sont des spécifications. Une implémentation de référence est proposée et ces API sont généralement implémentées par des tiers commerciaux ou open source. Ceci permet d'avoir le choix et ne pas être tributaire d'un seul fournisseur. Mais ce choix est d'autant plus complexe qu'en plus des API standards, de nombreux frameworks, notamment open source, proposent des alternatives particulièrement intéressantes (Struts, Spring, Hibernate, Log4J, ...)

121.8.1. La correspondance des principales classes

Attention : la correspondance entre les classes fournies est rarement parfaite et généralement les classes sont seulement proches ou similaires dans leur fonctionnement. Une consultation des documentations respectives des deux plates-formes est nécessaire lors du portage du code de l'une à l'autre.

121.8.1.1. La correspondance des classes de bases

Chaque type de base possède une représentation sous la forme d'un wrapper objet.

121.8.1.2. La correspondance des classes utilitaires

Java et .Net proposent un ensemble de classes utilitaires de base.

121.8.2. Les collections

Les deux plates-formes offres des fonctionnalités similaires en proposant des interfaces, des classes abstraites et des implémentations concrètes de classes permettant de manipuler des collections.

.Net et Java proposent une bibliothèque facilitant la mise en oeuvre de collections de données sous différentes formes (tableaux, listes chaînées, ensembles, ...)

.Net regroupe les API de gestions de collections dans le namespace System.Collections qui contient notamment :

• Des interfaces et classes abstraites : ICollection, IEnumerable, IDictionary, IList, CollectionBase
• Des implémentations concrètes : ArrayList, SortedList, Stack, Queue

Les éléments des collections .Net peuvent être accédés par des indexeurs dont la syntaxe est similaire à celle utilisée pour accéder à un élément d'un tableau.

.NET 2.0 propose le namespace System.Collections.Generic qui propose des collections mettant en oeuvre les generics.

L'API Collection de Java est incluse dans le package java.util.

Java offre un nombre plus important d'implémentations de collections notamment avec les ensembles (Set) et les listes chaînées (LinkedList). De plus, les fonctionnalités offertes sur ces collections sont plus nombreuses en Java.

Les fonctionnalités de la classe statique Java Collections (Reverse(), Sort(), BinarySearch(), ...) sont utilisables directement dans les classes d'implémentations de .Net.

Attention en .Net, par défaut les collections ne sont pas synchronisées. En Java, certaines collections notamment les plus anciennes (Vector, Hashtable, ...) sont synchronisées par défaut.

L'interface System.Collections.ICollection est similaire à l'interface java.util.Collection. Les interfaces Ilist et IDictionary de .Net sont similaires aux interfaces java.util.List et java.util.Map.

121.8.3. Les entrées/sorties

Les plates-formes Java et C# proposent un ensemble complet de classes pour manipuler des flux de données textuelles ou binaires, entrants ou sortants.

L'exemple ci-dessous copie le contenu d'un fichier texte.

using System;
using System.IO; 
 
public class CopieFichierTexte 
{
    public static void Main(string[] args)
    {
        FileStream inputFile  = new FileStream("source.txt", FileMode.Open);
        FileStream outputFile = new FileStream("copie.txt", FileMode.Open);
        StreamReader sr     = new StreamReader(inputFile);
        StreamWriter sw     = new StreamWriter(outputFile);
        String str;
        while((str = sr.ReadLine())!= null)
            sw.Write(str);
        sr.Close();
        sw.Close();
   }
}

import java.io.*;

public class CopieFichierTexte{
  
  public static void main(String[] args) throws IOException {
    File inputFile  = new File("source.txt");
    File outputFile = new File("copie.txt");
    FileReader in     = new FileReader(inputFile);
    BufferedReader br = new BufferedReader(in);
    FileWriter out    = new FileWriter(outputFile);
    BufferedWriter bw = new BufferedWriter(out);
    String str;
    while((str = br.readLine())!= null)
      bw.write(str);
    br.close();
    bw.close();
  }
}

Ces exemples de code sont similaires hormis le fait que Java ne travaille pas avec des tampons par défaut.

121.8.3.1. La correspondance des classes pour gérer les entrées/sorties

Le tableau ci-dessous propose une correspondances entre les classes des deux plate-formes relatives aux entrées/sorties.

121.8.4. L'accès aux bases de données

Java et .Net propose en standard des API pour l'accès aux bases de données de bas niveau ou de type ORM.

121.8.4.1. Les API de bas niveau

Java propose l'API JDBC qui est une abstraction de l'accès aux bases de données grâce aux spécifications de l'API et à leur implémentation au travers de pilotes (Driver) fournis par des tiers. Ces pilotes peuvent être de 4 types dont un fourni en standard qui permet une utilisation d'ODBC.

.Net propose l'accès aux bases de données aux travers de l'API ADO.Net qui est le résultat des évolutions des API d'accès aux données proposées par Microsoft :

ADO.Net est une spécification qui nécessite une implémentation sous la forme de Providers. La plate-forme propose en standard deux Providers : un pour SQL Server (System.Data.SqlClient) ou un pour OLE-DB (System.Data.OleDb). Il est possible d'utiliser d'autres Providers fournis par des tiers.

Ce mode de fonctionnement impose d'avoir un code dépendant du Provider utilisé : pour une utilisation de plusieurs bases de données, il est nécessaire de développer sa propre abstraction sous la forme d'un DAL (Data Acces Layer) en utilisant notamment le design pattern factory.

Les informations de connexions et leurs paramètres de configuration en ADO.Net sont fournis par une chaîne de caractères contenant ces informations sous la forme clé=valeur. JDBC utilise une url dépendante du pilote pour préciser les informations de connexion.

Les deux API proposent les modes de fonctionnement connecté (ResultSet pour JDBC et DataReader pour ADO.Net) et déconnecté (depuis JDBC 3, RowSet avec une implémentation offrant cette fonctionnalité comme CachedRowSet et DataSet pour ADO.Net).

Depuis la version 2 de JDBC, il est possible de parcourir un ResultSet dans les deux sens (si le pilote le permet) ; ceci est aussi possible avec un RowSet.

Les Providers ADO.NET fournis en standard mettent automatiquement en oeuvre un pool de connexions. En Java, l'utilisation d'un pool de connexions doit être explicite et mise en oeuvre avec la classe DataSource, généralement stockée dans un annuaire et accédée avec JNDI.

Depuis sa version 2, JDBC permet de regrouper plusieurs opérations de mises à jour (batchUpdate).

121.8.4.2. Les frameworks de type ORM

Java propose deux solutions standards pour l'accès aux données au travers d'une API de type ORM :

• JDO (Java Data Object)
• JPA (Java Persistence API)

.Net propose le framework Entity.

121.8.5. Les interfaces graphiques

Tous les composants graphiques de base ont une correspondance dans les deux plate-formes.

.Net ne propose pas d'équivalence au look and feel de Swing puisque seule la plate-forme Windows est supportée nativement.

Java propose deux frameworks pour le développement d'interfaces graphiques : AWT et Swing. Historiquement, AWT est le plus ancien et repose sur des composants natifs de l'environnement d'exécution ce qui limite le nombre de composants disponibles. Swing utilise des composants légers écrits en Java qui possèdent une toute petite partie native. Swing propose donc des composants plus nombreux et plus riches.

La gestion des événements en Java se fait avec des listeners. En .Net, elle se fait avec des events et des delegates.

121.8.6. Le développement d'applications web

121.8.6.1. Les APIs de bas niveau

En Java, les développements web reposent sur les servlets. Les JSP sont une abstraction de plus haut niveau permettant la réalisation de la partie graphique d'une application web. Les JSP sont compilées de façon transparente en servlets.

121.8.6.2. Les frameworks

En .Net, les développements d'applications web se font avec le framework ASP.Net.

En standard, les applications web en Java utilisent les JSF (Java Server Faces).

Il existe de nombreux frameworks open source (Struts, Spring MVC, Tapestry, Wicket, ...)

La suite de cette section sera développée dans une version future de ce document

121.8.7. Le développement d'applications de type RIA

.Net propose Silverlight

Historiquement, Java a proposé les applets qui sont des applications Java s'exécutant dans une page web du navigateur. Par défaut, l'utilisation d'une applet présente de nombreuses restrictions notamment pour garantir la sécurité (exécution dans une sandbox, pas d'accès au système, communication uniquement avec le serveur depuis lequel la servlet est téléchargée, ...)

Java propose aussi JavaFX.