 |
 |
|
 |
| Niveau : |  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 :
.Net est découpée en deux plate-formes :
.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 |
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 |
|
Mode de diffusion |
Fournie sous la forme de spécifications avec une implémentation de référence |
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) |
Uniquement à l'initiative de Microsoft notamment pour les bibliothèques |
|
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 :
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
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).
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.
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
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.
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.
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.
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), ...
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.
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.
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.
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 |
ASP.Net |
|
GUI |
Swing (ou AWT) |
Win Forms |
|
Accès aux données |
JDBC |
ADO.Net |
|
Appels d'objets distants |
RMI |
Remoting |
|
Ajax |
Partiellement intégré dans JSF 2.0 |
Atlas proposé indépendamment par Microsoft puis intégré dans ASP .Net |
|
Services Web |
JAX-RPX, JAX-WS, JAX-RS |
ASP.Net |
|
XML |
JAXP (manipulation de document XML) |
Intégré dans la plate-forme |
|
Sécurité |
JAAS |
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 |
Entity Framework |
|
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, ...)
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.
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 |
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 |
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 :
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 |
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.
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 |
Java et .Net propose en standard des API pour l'accès aux bases de données de bas niveau ou de type ORM.
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 |
|
java.sql.CallableStatement |
System.Data.SqlClient.SqlCommand |
|
java.sql.Clob |
System.Data.SqlClient.SqlDataReader |
|
java.sql.Connection |
System.Data.SqlClient.Sql |
|
java.sql.Date |
System.Data.SqlTypes.SqlDateTime |
|
java.sql.ParameterMetaData |
System.Data.SqlClient.SqlParameter |
|
java.sql.PreparedStatement |
System.Data.SqlClient.SqlCommand |
|
java.sql.ResultSet |
System.Data.SqlClient.SqlDataReader |
|
java.sql.ResultSetMetaData |
System.Data.SqlClient.SqlDataReader |
|
java.sql.Savepoint |
System.Data.SqlClient.SqlTransaction |
|
java.sql.Statement |
System.Data.SqlClient.SqlCommand |
|
java.sql.Time |
System.Data.SqlTypes.SqlDateTime |
|
javax.sql.RowSet |
System.Data.DataSet |
Java propose deux solutions standards pour l'accès aux données au travers d'une API de type ORM :
.Net propose le framework Entity.
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 |
|
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.
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.
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
|
.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.
|
|
|
La suite de cette section sera développée dans une version future de ce document
|