IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Développons en Java v 2.20   Copyright (C) 1999-2021 Jean-Michel DOUDOUX.   
[ Précédent ] [ Sommaire ] [ Suivant ] [ Télécharger ]      [ Accueil ] [ Commentez ]


 

113. Les plate-formes Java et .Net

 

chapitre 1 1 3

 

Niveau : niveau 4 Supérieur 

 

Java et .Net sont les deux principales plate-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 plate-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 plate-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 plate-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 plate-formes.

 

Java (SE et EE)

.Net

Environnement d'exécution

Java Virtual Machine (JVM)

Common Language Runtime (CLR)

Format de la compilation

Bytecode

Microsoft Intermediate language (MSIL)

Langage

Mono langage : Java uniquement
Quelques solutions open source permettent de générer du bytecode (exemple : JPython, Groovy, ...)

Multi-langage : de nombreux langages dont C#, C++, Visual Basic .Net, C++, JScript, Delphi, Cobol .Net, ...

Mode d'exécution

Mode interprété ou compilateur JIT

Compilateur JIT

Système cible

Support pour tous les systèmes proposant un JVM

Plateforme Windows uniquement
Quelques solutions open source permettent l'exécution sur d'autres plate-formes (exemple Mono sous Linux)

Mode de diffusion

Fournie sous la forme de spécifications avec une implémentation de référence
Chaque spécification peut être implémentée par un tiers

Fournie sous la forme de produit

IDE

Nombreux outils commerciaux et open source (Eclipse, NetBean)

Microsoft Visual Studio

Evolutions

Gérées par le JCP (Java Community Process composé de membres de nombreuses sociétés ou d'individuels)
Chaque évolution est traitée dans une JSR

Uniquement à l'initiative de Microsoft notamment pour les bibliothèques
La version 1.0 de C# et CLI (CLR et bibliothèques de bases) sont normalisées par les organismes ECMA et ISO

gestion de la mémoire

Garbage collector

Garbage collector

Packaging

Archive jar, war ou ear selon le type de projet

Assembly (.dll) ou executable (.exe)

Serveur d'applications

Nombreux serveurs d'applications J2EE (Websphere, Weblogic, OAS, Jboss, Jonas, ...)

IIS uniquement


Ce chapitre contient plusieurs sections :

 

113.1. La présentation des plate-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 plate-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 plate-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 :

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

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

 

113.1.1. Les plate-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 plate-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).

 

113.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 plate-formes Java sont réalisées par le JCP.

 

113.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

 

113.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.

 

113.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.

 

113.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 plate-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.

 

113.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), ...

 

113.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.

 

113.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 plate-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.

 

113.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 plate-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.

 

113.8. Les API des deux plate-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 plate-formes Java et .Net fournissent un ensemble très riche d'API

 

Java

.NET

Développement Web

API de bas niveau : Servlet, JSP
JSTL, Java Server Faces
Nombreux frameworks open source (exemple : Struts, Tapestry, Wicket, Spring MVC, ...)

ASP.Net

GUI

Swing (ou AWT)
SWT est une alternative possible

Win Forms
WPF (Windows Presentation Framework) depuis .Net 3.0

Accès aux données

JDBC

ADO.Net

Appels d'objets distants

RMI

Remoting

Ajax

Partiellement intégré dans JSF 2.0
Nombreux frameworks open source (exemple : DWR, ...)

Atlas proposé indépendamment par Microsoft puis intégré dans ASP .Net

Services Web

JAX-RPX, JAX-WS, JAX-RS
Nombreuses solutions tiers (Axis, ...)

ASP.Net

XML

JAXP (manipulation de document XML)
JAXB (binding document XML/ objets Java)
SAAJ (mise en oeuvre de SOAP)
JAXR (utilisation des registres UDDI et ebXML)

Intégré dans la plate-forme
WCF (Windows Communication Framework) depuis .Net 3.0

Sécurité

JAAS
JCE

Intégré dans la plate-forme

Déploiement d'applications à travers le réseau

Java Web start

One click

Interaction avec du code natif

JNI

la plate-forme est capable de prendre en compte du code managé (MSIL) et non managé (natif) avec des interactions utilisant COM

Objets métiers

EJB

 

Mapping O/R

JDO, JPA
Nombreux frameworks open source (exemple : hibernate, ...)

Entity Framework
Quelques frameworks pour la plupart portés de Java (NHibernate, ...)

Manipulation dynamique des objets

java.lang.reflect

System.Reflection

Gestion des événements

Listener

Delegate, Event

Documentation technique

Javadoc : commentaires particuliers avec des tags dédiés @xyz

Support uniquement en C# avec des tags XML dans des commentaires particuliers


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, ...)

 

113.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 plate-formes est nécessaire lors du portage du code de l'une à l'autre.

 

113.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.

Java

.Net

java.lang.Boolean

System.Boolean

java.lang.Byte

System.Byte

java.lang.Character

System.Char

java.lang.Class

System.Type

java.lang.Double

System.Double

java.lang.Float

System.Single

java.lang.Integer

System.Int32

java.lang.Long

System.Int64

java.lang.Math

System.Math

java.lang.Object

System.Object

java.lang.Process

System.Diagnostics.Process

java.lang.Runtime

System.Diagnostics.Process

java.lang.Short

System.Int16

java.lang.StrictMath

System.Math

java.lang.String

System.String

java.lang.StringBuffer

System.Text.StringBuilder

java.lang.Thread

System.Threading.Thread

java.lang.Throwable

System.Exception

 

113.8.1.2. La correspondance des classes utilitaires

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

Java

.Net

java.util.BitSet

System.Collections.BitArray

java.util.Calendar

System.Globalization.Calendar

java.util.Currency

System.Globalization.RegionInfo

java.util.Date

System.DateTime

java.util.EventObject

System.EventArgs

java.util.GregorianCalendar

System.Globalization.GregorianCalendar

java.util.ListResourceBundle

System.Resources.ResourceManager

java.util.Locale

System.Globalization.CultureInfo

java.util.Random

System.Random

java.util.ResourceBundle

System.Resources.ResourceSet

java.util.SimpleTimeZone

System.DateTime

java.util.Timer

System.Threading.Timer

java.util.TimerTask

System.Threading.TimerCallback

java.util.TimeZone

System.DateTime

 

113.8.2. Les collections

Les deux plate-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.

Java

.Net

java.util.AbstractCollection

System.Collections.CollectionsBase

java.util.ArrayList

System.Collections.ArrayList

java.util.Arrays

System.Array

java.util.Dictionary

System.Collections.DictionaryBase

java.util.HashMap

 

java.util.Hashtable

System.Collections.Hashtable

java.util.Set

 

java.util.Stack

System.Collections.Stack

java.util.TreeSet

System.Collections.SortedList

java.util.Vector

System.Collections.ArrayList

 

113.8.3. Les entrées/sorties

Les plate-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.

Exemple C# :
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();
   }
}

Exemple Java :
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.

 

113.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.

Java

.Net

java.io.BufferedInputStream

System.IO.BufferedStream

java.io.BufferedOutputStream

System.IO.BufferedStream

java.io.BufferedReader

System.IO.StreamReader

java.io.BufferedWriter

System.IO.StreamWriter

java.io.ByteArrayInputStream

System.IO.MemoryStream

java.io.ByteArrayOutputStream

System.IO.MemoryStream

java.io.CharArrayReader

System.IO.StreamReader

java.io.CharArrayWriter

System.IO.StreamWriter

java.io.DataInputStream

System.IO.BinaryReader

java.io.DataOutputStream

System.IO.BinaryWriter

java.io.File

System.IO.File

java.io.FileInputStream

System.IO.FileStream

java.io.FileOutputStream

System.IO.FileStream

java.io.FileReader

System.IO.StreamReader

java.io.FileWriter

System.IO.StreamWriter

java.io.InputStream

System.IO.Stream

java.io.OutputStream

System.IO.Stream

java.io.PrintStream

System.IO.StreamWriter

java.io.PrintWriter

System.IO.StreamWriter

java.io.PushbackInputStream

System.IO.StreamReader

java.io.PushbackOutputStream

System.IO.StreamReader

java.io.RandomAccessFile

System.IO.FileStream

java.io.StringBufferInputStream

System.IO.StringReader

java.io.StringReader

System.IO.StringReader

java.io.StringWriter

System.IO.StringWriter

 

113.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.

 

113.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).

Java

.Net

java.sql.Blob

System.Data.SqlClient.SqlDataReader
System.Data.OleDb.OleDbDataReader

java.sql.CallableStatement

System.Data.SqlClient.SqlCommand
System.Data.OleDb.OleDbCommand

java.sql.Clob

System.Data.SqlClient.SqlDataReader
System.Data.OleDb.OleDbDataReader

java.sql.Connection

System.Data.SqlClient.Sql
System.Data.OleDb.OleDb

java.sql.Date

System.Data.SqlTypes.SqlDateTime

java.sql.ParameterMetaData

System.Data.SqlClient.SqlParameter
System.Data.OleDb.OleDbParameter

java.sql.PreparedStatement

System.Data.SqlClient.SqlCommand
System.Data.OleDb.OleDbCommand

java.sql.ResultSet

System.Data.SqlClient.SqlDataReader
System.Data.OleDb.OleDbDataReader

java.sql.ResultSetMetaData

System.Data.SqlClient.SqlDataReader
System.Data.OleDb.OleDbDataReader

java.sql.Savepoint

System.Data.SqlClient.SqlTransaction

java.sql.Statement

System.Data.SqlClient.SqlCommand
System.Data.OleDb.OleDbCommand

java.sql.Time

System.Data.SqlTypes.SqlDateTime

javax.sql.RowSet

System.Data.DataSet

 

113.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.

 

113.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.

Java

.Net

javax.swing.AbstractButton

System.Windows.Forms.ButtonBase

javax.swing.AbstractListModel

System.Windows.Forms.ListControl

javax.swing.AbstractSpinnerModel

System.Windows.Forms.UpDownBase

javax.swing.ImageIcon

System.Windows.Forms.Image

javax.swing.JButton

System.Windows.Forms.Button

javax.swing.JCheckBox

System.Windows.Forms.CheckBox

javax.swing.JColorChooser

System.Windows.Forms.ColorDialog

javax.swing.JComboBox

System.Windows.Forms.ComboBox

javax.swing.JComponent

System.Windows.Forms.UserControl

javax.swing.JDialog

System.Windows.Forms.CommonDialog

javax.swing.JEditorPane

System.Windows.Forms.TextBoxBase

javax.swing.JFileChooser

System.Windows.Forms.OpenFileDialog

javax.swing.JFormattedTextField

System.Windows.Forms.RichTextBox

javax.swing.JFrame

System.Windows.Forms.Form

javax.swing.JLabel

System.Windows.Forms.Label

javax.swing.JList

System.Windows.Forms.ListBox

javax.swing.JMenuBar

System.Windows.Forms.MainMenu

javax.swing.JMenuItem

System.Windows.Forms.MenuItem

javax.swing.JPanel

System.Windows.Forms.Panel

javax.swing.JPasswordField

System.Windows.Forms.TextBox

javax.swing.JPopupMenu

System.Windows.Forms.ContextMenu

javax.swing.JProgressBar

System.Windows.Forms.StatusBar

javax.swing.JRadioButton

System.Windows.Forms.RadioButton

javax.swing.JScrollBar

System.Windows.Forms.HScrollBar
System.Windows.Forms.VScrollBar

javax.swing.JScrollPane

System.Windows.Forms.Panel

javax.swing.JSlider

System.Windows.Forms.TrackBar

javax.swing.JSpinner

System.Windows.Forms.DomainUpDown

javax.swing.JSplitPane

System.Windows.Forms.Splitter

javax.swing.JTabbedPane

System.Windows.Forms.TabControl

javax.swing.JTable

System.Windows.Forms.ListView

javax.swing.JTextArea

System.Windows.Forms.TextBox

javax.swing.JTextField

System.Windows.Forms.TextBox

javax.swing.JTextPane

System.Windows.Forms.RichTextBox

javax.swing.JToggleButton

System.Windows.Forms.ButtonBase

javax.swing.JToolBar

System.Windows.Forms.ToolBar

javax.swing.JToolTip

System.Windows.Forms.ToolTip

javax.swing.JTree

System.Windows.Forms.ListView


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

 

113.8.6. Le développement d'applications web

 

113.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.

 

113.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, ...)

 

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

 

113.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.

 

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

 


Développons en Java v 2.20   Copyright (C) 1999-2021 Jean-Michel DOUDOUX.   
[ Précédent ] [ Sommaire ] [ Suivant ] [ Télécharger ]      [ Accueil ] [ Commentez ]