RESUME

Ce cours est un cours de développement d’application

avancé sur basé sur JAVA EE. Ce cours est destiné à
toutes personne voulant faire du développement web
avec java. Les notions abordées dans ce cours sont : la
programmation orienté objet (classes, objet,
méthodes), le modèle MVC, serveur d’application et
base de données. A la fin de ce cours, vous devez être

JAVA EE capable d’installer un environne de développement

d’application avec JAVA, Maitriser les syntaxes du lange
JAVA, installer un Serveur d’application, de base de
données, de développer un application web avec JAVA

DEVELOPPEMENT EE et de le déployer.

D'APPLICATIONS
WEB EN JAVA
GLO3 & RSI3 45 H
Organisation du cours 1

● Le chapitre 1 (spécifications de Java EE) présente le langage Java, les règles de nommage ainsi que l’installation
de l’environnement de développement.

● Le chapitre 2 (Le serveur d’applications Apache­Tomcat) est consacré à la mise en place du serveur Java de
référence, Tomcat.

● Le chapitre 3 (Les JavaServer Page) aborde la programmation de Servlets avec les classes, objets et méthodes.

● Le chapitre 4 (Les Servlets) explore en détail le développement de pages Web au travers des pages JSP.

● Le chapitre 5 (Java et les bases de données) présente les bases de données en Java ainsi que les solutions
techniques et les outils adaptés à la persistance des données.

● Le chapitre 6 (Framework Java EE) est consacré à l’étude d’un framework de développement Java nommé

Struts.
Le chapitre 1 2
1. Les conventions de Java, de codage et les règles de nommage
Dans le cycle de vie d’un produit logiciel, la phase de maintenance représente la majeure partie du temps (environ 80
%). De même, un logiciel est rarement développé par une seule et même personne. C’est une équipe entière qui réalise
le projet de développement avec tous les avantages mais aussi toutes les contraintes que cela implique.
La réussite d’un projet dépend beaucoup de l’homogénéité dans le codage. Cette étape essentielle passe par la mise en
œuvre de conventions strictes respectées par toute l’équipe impliquée dans le projet. La plupart des outils de
développement (IDE) proposent des fonctionnalités pour permettre cette homogénéité mais il existe des règles que
seuls les développeurs doivent appliquer. Le fait de vouloir à tout prix avoir un code esthétique et de faible complexité
peut être un frein aux performances. À l’inverse, la course à la performance peut découler sur un code peu lisible. Il
revient donc aux développeurs de trouver le bon équilibre entre les conventions et les contraintes du projet (projet axé
sur la performance, projet OpenSource...).

2. Les conventions de codage

Des conventions de codage sont utilisées tout au long de ce document. Par défaut, les conventions de codage pour la
plupart des projets OpenSource suivent ces instructions. Par exemple, si la parenthèse { est après la condition if, le
code n’est pas correct.
Tous les blocs de code doivent commencer par une nouvelle ligne.

public class MaClasse

{ public void
maMethode()
{
if(xxx)
{
}
}
}

Chaque conditionnelle contient les parenthèses ouvrantes et fermantes.

//Correct if
(expression)
{
//le code
}
//Incorrect if
(expression)
//le code

Une indentation se trouve après chaque instruction. Les noms des fonctions et des paramètres, ne doivent pas avoir de
préfixe, commencent par une minuscule et chaque partie de mot est en majuscule.

public class MaClasse

{ private String maChaine; public
void maMethode(String monParametre)
{

}
}

La version de l’application (du code) est précisée dans chaque fichier d’extension .java.

@version 2.8

Le nom de l’auteur est précisé.

@author jeromelafosse
Chaque importation de paquetage (paquet) Java est pleinement qualifiée.
3
//Correct import java.util.Date;
import
java.net.HttpURLConnection;

//Incorrect import
java.util.*;
import java.net.*;

3. Les conventions Java

Pour utiliser efficacement le langage de programmation Java, il existe plusieurs conventions à connaître et à
appliquer. Les instructions Java se terminent par un point­virgule. Les instructions Java utilisent des accolades
{ } pour indiquer le début et la fin du corps. Un corps peut contenir plusieurs instructions.
La présentation avec les accolades alignées sur la même colonne que le premier caractère de l’instruction Java
sera utilisée. Cette présentation ajoute des lignes de code, mais elle est plus facile à lire. Il est important de
mettre en retrait (espace ou tabulation) les instructions Java qui comportent un corps. Il est également
nécessaire de toujours utiliser la même mise en retrait du code.
Java recourt comme tout langage à plusieurs mots­clés, c’est­à­dire des mots réservés exclusivement au
langage. Il ne sera donc pas possible d’utiliser ces mots­clés comme noms ou valeurs de variables.
Voici une liste non exhaustive de ces mots­clés : abstract, boolean, break, case, catch, char, class, continue,
do, double, else, extends, false, final, finally, float, for, if, import, instanceof, int, interface, new, null, package,
private, protected, public, return, static, super, switch, this, true, try, void, while...
Le code doit être succinct, cela facilite la maintenance et la lisibilité de l’ensemble. Il vaut mieux découper
parfois des méthodes et ajouter des commentaires. Les recommandations doivent être appliquées sur
l’intégralité du projet et non avec parcimonie. Si les règles sont plus ou moins appliquées, si le code change
d’un fichier à l’autre, la compréhension sera difficile. L’application uniforme des règles est un gage de
maintenabilité.

Fichiers

Les noms des fichiers sources portent l’extension .java et le code (bytecode) généré porte l’extension .class.
Les fichiers de propriétés portent l’extension .properties (langues, traductions...) et les fichiers de configuration
l’extension .xml. Le fichier de construction du projet porte le nom build.xml (Ant) et le fichier de description du
projet est appelé README.
Un projet de développement utilise plusieurs répertoires. Il est généralement composé du répertoire /src qui
contient les sources, du répertoire /build qui contient les classes compilées, /docs qui contient la documentation
du projet et /log qui contient les traces d’exécutions et d’erreurs du projet.
Souvent, pour un projet minime, seuls les répertoires /src, /build et /docs sont utilisés.
Les classes doivent être regroupées en packages (paquetages ou paquets).

Sources

Il est recommandé de ne pas dépasser 2000 lignes de code par fichier. Si tel est le cas, il est important
d’optimiser le code, de vérifier s’il n’existe pas de redondance et de découper les fonctionnalités en plusieurs
classes (boîte à outils par exemple).

Formatage

Il faut configurer l’éditeur pour que la tabulation écrive huit caractères espace (configuration par défaut).
L’entrée dans un bloc impose l’ajout d’une indentation. Des blocs de même niveau doivent débuter sur la même
colonne, c’està­dire avoir la même indentation. Les lignes blanches doivent être utilisées pour séparer des
portions de code et les méthodes. Les espaces peuvent être utilisés en quantité mais sous certaines conditions.
Le caractère espace est proscrit avant les points­virgules, avant les crochets des tableaux et entre une variable
et les opérateurs de pré/post incrément. Par contre, l’espace est autorisé après les virgules, avant et après les
accolades, avant et après chaque opérateur, après les mots réservés du langage et entre le nom d’une méthode
et la parenthèse de ses paramètres.
//Correct 4
maMethode(a,b,c, d);
for (i = 0; i < 100;i++)
{
++count;
(MaClasse)maVariable.get(i);

//Incorrect
MaMethode (a,b,c,d);
++ count;
(MaClasse) maVariable.get(i);

Nommage

Les noms utilisés doivent être explicites, c’est­à­dire que le nom doit expliquer le contenu de l’objet, le rôle de
la méthode... Les acronymes qui apparaissent dans les noms doivent être passés en minuscules (sauf la
première lettre du premier mot). Il est conseillé de mettre les identifiants en langue anglaise pour des projets
internationaux.

Package/Paquetage

Les noms des paquetages doivent être en minuscules. Ces noms doivent être pleinement qualifiés (comme une
URL) et reprennent le nom du projet, l’URL du site... En général, la technique consiste à retourner l’URL du
projet. Exemple : monprojet.com devient : com.monprojet.monpaquet

//Correct package
com.monprojet.monpaquet;

//Incorrect package
Com.MonProjet.MonPaquet;

Classes et interfaces

Les noms des classes doivent être en minuscules, hormis les initiales des mots qui les composent.

//Correct class
MaClasseFavorite;

//Incorrect class
maclassefavorite;

class maClassefavorite;

Méthodes

Les noms des méthodes doivent être en minuscules hormis les initiales des mots qui composent les mots (sauf
la première lettre).

//Correct public void maMethodeFavorite() {

//Incorrect
public void mamethodefavorite() {

Les accesseurs directs (getters et setters) des attributs d’une classe doivent être préfixés d’un get pour la
lecture de l’attribut et d’un set pour l’écriture. Le préfixe is doit être utilisé pour les méthodes qui retournent
un booléen.

//Correct public int getNiveau() {

public void setNiveau(int niveau)
{ public boolean isVisible() {
//Incorrect public int recupererLeNiveau() {
public void ecrireLeNiveau(int niveau)
{ public boolean estIlVisible() {
Nous pouvons également utiliser d’autres mots pour les recherches, les suppressions, les ajouts, la fermeture
de connexions... (find, delete, add, close...). 5

Attributs, variables et paramètres

Les attributs des classes , les variables ainsi que les paramètres des méthodes doivent être en minuscules hormis
les initiales des mots qui les composent (sauf le premier). Les variables de boucle doivent porter une seule lettre
: i, j, k... Les signes dollars ($) et soulignement (_) sont proscrits.

//Correct
Voiture prochaineVoiture = voitures.get(this.id + 1);
float laTaille = 145.5;
//Incorrect
Voiture a = voitures.get(this.id + 1);
float la_Taille = 145.5;

Les collections doivent être nommées au pluriel.

//Correct
Vector comptes;
Collection banques;
Object[] mesObjets;
//Incorrect
Vector compte;
Collection banque;
Object[] monObjet;

Constantes

Les noms des constantes doivent être écrits entièrement en majuscules. Le séparateur de mot est le caractère
de soulignement (underscore).

//Correct static final

int LOG_CONSOLE = 1;
//Incorrect static
final int LOGCONSOLE
= 1; static final int
console_Log = 1;
static final int
Console_LOG = 1;

Commentaires

Les commentaires sont essentiels dans un code source. Ils permettent de documenter le projet à l’intérieur
même du code source en vue de la génération de la documentation via l’outil JavaDoc. Il existe en Java deux
types de commentaires :

● les commentaires mono­ligne qui permettent de désactiver tout ce qui apparaît sur la même ligne // ;

● les commentaires multilignes qui permettent de désactiver tout le code qui se trouve entre les deux
délimiteurs /* */.

Il est important de réserver les commentaires multilignes aux blocs utiles à la JavaDoc et à l’inactivation de
portions de code. Les commentaires mono­ligne permettent de commenter le reste, à savoir, toute information
de documentation interne aux lignes de code.

/*
* La classe MaClasse permet telles fonctionnalités…
*/ public class
MaClasse() {
// Recuperer un objet de la collection monFichier = (Fichier)fichiers.get((int)item.getIdFichier());
Déclarations
6
Les variables doivent être déclarées ligne par ligne. L’initialisation doit se faire lors de la déclaration lorsque
cela est possible. Les variables doivent être déclarées au plus tôt dans un bloc de code. Les noms des méthodes
sont accolés à la parenthèse ouvrante listant leurs paramètres. Aucun espace ne doit y être inséré.

//Correct int niveau= 10;

void maMethode() {

//Incorrect int niveau; niveau = 10;

void maMethode () {

Ordre

L’ordre de déclaration des entités du code source doit être le suivant (qui est plus ou moins naturel) :

● Les attributs de la classe (1­> statiques, 2­>publiques, 3­>protégés, 4­> privés).

● Les méthodes de la classe (1­>statiques, 2­>publiques, 3­>protégées, 4­>privées).

Instructions

Une ligne de code ne peut contenir qu’une seule instruction.

//Correct
count++; i--;
println("Bonj
our");
//Incorrect count++; i--;
println("Bonjour");
Définitions de J2EE/Java EE 7
De nombreuses possibilités existent pour réaliser des applications Internet depuis plusieurs années. Des langages ont été
créés, des architectures et des environnements de travail ont été conçus pour répondre aux besoins et faciliter la tâche des
développeurs. Sun (le concepteur de Java) a donc mis en place un ensemble de technologies pour réaliser des applications
Web. Ces technologies sont regroupées sous le nom J2EE (Java 2 Entreprise Edition), désormais Java
EE.

Depuis la version 5, le chiffre 2 a disparu pour faciliter la compréhension de la version et ne pas mélanger le
chiffre 2 avec le numéro de version.

La plate­forme Java EE s’appuie entièrement sur le langage Java. Java EE est donc une norme, qui permet à des
développeurs, entreprises et SSII de développer leur propre application qui implémente en totalité ou partiellement les
spécifications de SUN. En simplifiant, il est possible de représenter Java EE comme un ensemble de spécifications d’API, une
architecture, une méthode de packaging et de déploiement d’applications et la gestion d’applications déployées sur un
serveur compatible Java.

Une API est un ensemble de librairies ou bibliothèques de fonctions destinées à être utilisées par les
programmeurs dans leurs applications.

Java Entreprise Edition est destiné aux gros (très gros) systèmes d’entreprises. Les librairies utilisées fonctionnent
difficilement sur un simple PC et requièrent une puissance beaucoup plus importante (notamment au niveau de la mémoire).
Java Entreprise Edition est apparue à la fin des années 90. Cette évolution apporte au langage Java une plate­forme logicielle
robuste et complète pour le développement. La plate­forme Java EE a souvent été remise en cause, mal utilisée et mal
comprise. Des outils OpenSource sont venus la concurrencer. Ces remarques et la concurrence ont permis à Sun d’améliorer
son produit et d’éditer des versions de plus en plus abouties. Java EE ne remplace en aucun cas J2SE. Au contraire, J2SE
est la base de Java EE qui est plus complet et qui est axé sur le Web. La plate­forme J2SE offre des outils de développement
d’applications client/serveur, applications graphiques fenêtrées et Applets.
La plate­forme J2SE est composée des éléments suivants :

● La machine virtuelle Java (JVM) : permet d’exécuter des applications Java. Elle constitue une passerelle et
permet une portabilité entre les architectures (Windows, Linux, Mac...).

● La bibliothèque de classes Java : un ensemble de composants logiciels prêt à l’emploi.

● Les outils de développement : le compilateur javac , un interpréteur Java nommé java, le générateur de
documentation javadoc, la console de supervisation Jconsole... La plate­forme Java EE est une extension de la
plate­forme J2SE. Elle permet un développement d’applications qui vont s’exécuter sur un serveur d’applications.
Les applications seront utilisées par des clients légers (comme des navigateurs Web) ou bien des applications lourdes
(IHM). La dernière version stable de Java EE est la version Java EE 8.0 et fonctionne avec le JDK 8.0

1. Pourquoi choisir Java EE

Il existe actuellement beaucoup d’autres plateformes de développement qui sont basées sur d’autres langages (C#, PHP5,
.NET...). Les principaux avantages d’utiliser Java EE (et donc Java) sont la portabilité, l’indépendance, la sécurité et la
multitude de librairies proposées.
Le développement d’applications d’entreprise nécessite la mise en œuvre d’une infrastructure importante. Beaucoup de
fonctionnalités sont utilisées et développées, le but étant de produire des applications sûres, robustes et faciles à maintenir.
Certains services sont d’ailleurs récurrents comme : l’accès aux bases de données, l’envoi de mails, les transactions, la
gestion de fichiers, la gestion d’images, le téléchargement, le chargement ou upload, la supervision du système...
C’est pour cela que l’architecture Java EE est intéressante car tous les éléments fondamentaux sont déjà en place. Pas
besoin de concevoir une architecture, des librairies et des outils spécialement adaptés. Cela nécessiterait un temps et un
investissement considérables.
Enfin, la plate­forme Java EE est basée sur des spécifications, ce qui signifie que les projets sont portables sur n’importe
quel serveur d’applications conforme (Tomcat, JBoss, WebSphere...) à ces spécifications. Cette implémentation est gratuite
et permet de bénéficier de la totalité de l’API sans investissement. La plate­forme Java EE est la plus riche des plateformes
Java et offre un environnement standard de développement et d’exécution d’applications d’entreprise multi­tiers.
Le fait que Java EE soit standardisé a contribué à son adoption par de très nombreux éditeurs de logiciels/outils
informatique. Ces éditeurs associés à Sun Microsystems font partie du JCP (Java Community Process). Le Java Community
Process regroupe les entreprises suivantes : Sun, IBM, Oracle, Borland, Nokia, Sony, la fondation Apache, ObjectWeb...
L’objectif du JCP est de définir les spécifications des technologies basées sur Java.

Programmation avancée
 Chaque demande de modification est appelée une JSR (Java Specification Request).
8

2. L’API Java EE (JDBC, Servlets, JSP)

La plate­forme Java EE est composée de plusieurs API (ensemble de libraires et services). Java EE fait intervenir trois
types de composants logiciels (Servlets, JSP, EJB).

a. Les Servlets

L’API Servlet fournit les éléments nécessaires à la conception de composants Web dynamiques avec le langage Java. Les
Servlets sont des composants logiciels entièrement écrits en Java. Les Servlets effectuent des traitements côté serveur
en réponse aux requêtes des clients distants. Une Servlet est chargée en mémoire lors de son premier appel. De même,
il n’existe qu’une seule instance d’une Servlet en mémoire, le serveur utilise alors un thread global pour traiter les
demandes émises par les clients.

Cycle de vie d’une Servlet

Une Servlet est une classe Java. Cette classe doit être chargée puis interprétée par une machine virtuelle Java (celle du
serveur d’applications). La Servlet est alors prête à recevoir des requêtes et à renvoyer des réponses. Lorsque
l’application ou le serveur s’arrête, la Servlet est détruite, puis son instance est nettoyée par le ramasse­miettes de la
machine virtuelle.

Les Servlets permettent de développer des pages dynamiques, dont le contenu est créé à la volée sur demande. C’est le
cas par exemple, lorsqu’un client souhaite obtenir la liste des articles d’une boutique pour une plage de prix. Les pages
HTML sont alors générées dynamiquement en fonction de critères spécifiques (prix, dates, recherches...).

Une Servlet est un composant Java qui implémente l’interface javax.servlet.Servlet. Cette interface permet de gérer les
requêtes du client, dirigées vers la Servlet en question. Le serveur reçoit une demande adressée à une Servlet sous la
forme d’une requête HTTP. Il transmet alors la requête à la Servlet concernée par le traitement puis renvoie la réponse
fournie par celle­ci au client. La Servlet est gérée par le conteneur de Servlets Java EE. Lorsque le serveur Web reçoit la
requête du client, il charge la Servlet (si elle n’est pas encore chargée) et invoque l’interface javax.servlet.Servlet afin
de satisfaire la requête.
Ce type de programmation est très proche du développement CGI mais offre les outils pour gérer les cookies, sessions,
accès aux bases de données et autres avec une excellente portabilité.

Programmation avancée
 Exemple de Servlet simple :
9
public class PremiereServlet extends HttpServlet
{
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, java.io.IOException
{
}
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws ServletException, java.io.IOException
{ doGet(request,
response);
}
}

b. Les JSP (Java Server Page)

L’API JSP permet de développer des pages Web dynamiques rapidement à partir d’un squelette HTML et de données
incluses directement dans chaque page. Les JSP permettent d’insérer des bouts de code Java (scriptlets) directement
dans le code HTML.
Du point de vue de la structure, une JSP est très proche d’une page PHP ou bien ASP. Une page JSP est un fichier qui
porte l’extension .jsp ou .jspf (pour les fragments de code).
Lors de la création de Servlets, le but est de construire des composants capables de produire un service (essentiellement
du code HTML). Toutefois, ce principe est parfois complexe pour des personnes qui ne sont pas habituées à la
programmation objet et au code 100% Java. C’est pour ces raisons que les développeurs de chez
SUN ont inventé JSP.
La page JSP est transformée en classe Java puis compilée en Servlet par le serveur d’applications. Ce traitement est
réalisé par le serveur d’applications au premier appel de la page et à chaque fois que cette page est modifiée par un
programmeur.

C’est cette étape qui nécessite un serveur d’applications Java EE, un compilateur Java et qui par conséquent nécessite
pour la majorité l’installation de Java avec un JDK plutôt qu’un JRE.

Programmation avancée
 Cycle de vie d’une JSP
10

Programmation avancée
 Le résultat de la compilation (essentiellement du code HTML) est renvoyé au client. Cette technologie est simple, légère
et rapide. Les développeurs de pages JSP peuvent ainsi mélanger du contenu statique et du contenu dynamique. 11
<%
System.out.println("Ma première Servlet");
out.println("<h1>Ma première Servlet<h1>");
%>

Il est donc possible d’avoir des équipes de développement séparées avec une personne spécialiste de HTML/XHTML et du
design et un programmeur Java qui réalise les scriptlets. Les JSP sont exécutées sous la forme de Servlets, elles disposent
donc des mêmes fonctionnalités que celles­ci et peuvent ainsi manipuler les sessions, les bases de données, les mails...

c. LES EJB (Entreprise Java Bean)

Les EJB sont des composants métier distribués, c’est­à­dire qu’ils sont invocables par le réseau. Un composant EJB est
une classe qui possède des attributs et méthodes pour mettre en application la logique métier. L’API EJB fournit un
ensemble de services (persistance, transaction...) de gestion de composants. Il existe plusieurs (trois) types d’EJB : les
beans sessions, les beans entités et les beans contrôlés par message.

● EJB session : il permet de maintenir des informations sur les clients et les traitements qu’ils réalisent.

● EJB entité : c’est un composant persistant, son état est sauvegardé dans une base de données.

● EJB piloté par message : les EJB message sont semblables aux EJB session mais sont invoqués différemment
(par le biais de Java Message Service).

La mise en place d’EJB nécessite l’utilisation d’un serveur d’applications capable de gérer ces EJB.
Actuellement, les serveurs GlassFish, JBoss et Jonas existent dans le domaine du libre. Le serveur Tomcat ne
permet pas d’utiliser les EJB.

Il existe ensuite au sein de Java EE, la plate­forme de Services avec JDBC, JNI, JavaMail, JTA, RMI, JAAS et XML.

JDBC (Java DataBase Connectivity)

L’API JDBC permet de faciliter l’obtention de connexions JDBC vers des sources de données (essentiellement des bases
de données, mais également annuaire...). L’API fournit les librairies pour se connecter aux bases de données et pour la
gestion des transactions.

JNDI (Java Naming and Directory Interface)

L’API JNDI permet d’accéder à des services de nommage ou d’annuaire (LDAP par exemple). Cette API est par exemple
utilisée pour se connecter à une source de données pour des accès à la base de données ou la gestion des accès (associée
aux Realms). JNDI permet d’implémenter un service de nommage. L’ensemble des ressources que le serveur
d’applications met à disposition via ces API de services, doit être enregistré avec un nom logique unique, permettant aux
applications de rechercher cette ressource dans le serveur.

JavaMail

L’API JavaMail fournit des fonctionnalités de gestion de courrier électronique (transfert, type de contenu, pièces jointes...).
JavaMail permet la création et l’envoi de messages électroniques via Java. Cette API permet de manipuler les protocoles
de messagerie Internet comme POP, IMAP, SMTP. JavaMail n’est pas un serveur de courrier mais plutôt un outil qui
permet d’interagir avec ce type de serveur.

JPA (Java Persistance API)

Les entités Beans ont été développées pour le modèle de persistance en Java EE. Ce modèle de composants avait de
nombreux détracteurs. Pour apporter des solutions à ce problème, de nouvelles spécifications, des outils de mapping
objet/relationnel comme TopLink et Hibernate ont été développés. Java EE apporte donc un nouveau modèle de
persistance nommé JPA. JPA s’appuie sur JDBC pour communiquer avec la base de données mais permet d’éviter de
manipuler directement les fonctionnalités de JDBC et le langage SQL.

Programmation avancée
 3. Les autres API
12
Parmi les autres API Java EE, il faut citer :
JMS (Java Message Service) permet d’accéder à un service de messages pour une gestion asynchrone des composants.
Le composant appelant poste un message (en arrière­plan) à destination d’une file d’attente de messages hébergés par le
serveur d’applications puis continue son traitement sans attendre.
RMI (Remote Method Invocation) permet de concevoir des applications distribuées en Java. RMI permet l’appel de
fonctionnalités à distance par le biais de la communication réseau.
JTA (Java Transaction API) permet de mettre en place une gestion des transactions dans des applications distribuées
(commit, rollback...). Le principe des transactions est de considérer un ensemble d’opérations comme une seule. Ce type
de service est obligatoire pour des traitements bancaire. Par exemple, une application bancaire qui permet de réaliser des
virements entre deux comptes va d’abord débiter le premier compte et ensuite créditer le second compte. Si le débit puis
le crédit aboutissent sans problème, alors la transaction est validée. JDBC permet de gérer les transactions sur une base
de données locale mais si les données sont réparties, il faudra alors utiliser les transactions
JTA. JTA permet en effet de gérer les transactions distribuées qui font intervenir différentes bases de données.
JCA (J2EE Connector Architecture) : ce connecteur permet à Java EE d’utiliser des gros systèmes tels que les mainframes.
JAAS (Java Authentication and Autorisation Service) est un mécanisme de sécurité géré par le serveur d’applications.
XML n’est pas véritablement une API Java mais il est très utilisé pour la mise en place et la configuration des applications.
De même, XML est la base d’un nouveau mode de communication entre les applications qui est appelé Web Service. Par
exemple, JAXP (Java API for XML Parsing) analyse des fichiers ou données XML, JAX­RPC (Java API for XML based RPC)
utilise des Web Services et JAXB (Java API for XML Binding) permet de générer des classes Java à partir de schémas XML
ou inversement.
Actuellement, la version de Java EE est 8.0 associée à l’API Servlet 3 , et à l’API JSP 2.2 (et à Apache­Tomcat 9).

Encodage des applications Java

Présentation
Les ordinateurs travaillent avec des bits ou suites d’octets (un octet=8 bits). Les chaînes de caractères, entiers, réels
sont donc codées sous forme d’octets. Les ordinateurs utilisent donc un procédé qui consiste à transformer les chaînes
de caractères en octets, associé à une technique afin de relire les chaînes d’origine. C’est ce procédé qui est appelé
encodage.

Il existe plusieurs encodages qui utilisent plus ou moins le même nombre d’octets, donc de caractères disponibles comme
ISO­8859­1, ASCII, UTF­8... L’encodage UTF­8 est le plus pratique pour échanger des textes constitués de caractères
UNICODE (standard du consortium Unicode). Ce consortium a pour but de répertorier tous les caractères utilisés dans
les différentes langues et d’associer à chacun un code noté sous forme hexadécimal. L’encodage UTF­8 est compatible
avec l’encodage ASCII ce qui est très pratique lors des développements informatiques.

Lors des développements d’applications Java et/ou Java EE, il n’est pas rare de constater de nombreux problèmes
d’encodage des applications tant au niveau des messages présents dans un navigateur, que des fichiers de propriétés
d’une application ou encore de l’encodage des caractères saisis au clavier. La mise en œuvre d’une application Java
nécessite donc la gestion de plusieurs paramètres. La difficulté est qu’il ne faut pas en oublier un seul sous peine de
constater l’affichage de ’’hiéroglyphes’’ à la place du caractère souhaité.

Les fichiers
La première contrainte à vérifier est que tous les fichiers (HTML, JSP, JSPF, XML, XSLT...) de l’application développée
soient dans l’encodage souhaité. Pour cela, la plupart des IDE peuvent se paramétrer afin de sélectionner l’encodage.
Avec Eclipse, nous pouvons sélectionner l’encodage dans le menu Fenêtre ­ Préférences ­ Editeurs ­ Codage du fichier
texte et Types de contenu. Le plus utilisé est UTF­8

Programmation avancée
 Les pages JSP et JSPF 13
Il est nécessaire de déclarer dans chaque page JSP ou JSPF d’en­tête l’encodage utilisé. Pour cela, il faut utiliser la
directive JSP adaptée.

<jsp:directive.page
contentType="text/html;charset=UTF-8" /> ou

<%@ page contentType="text/html;charset=UTF-8" %>

Il est possible également de centraliser l’encodage dans le fichier de configuration et de déploiement de

l’application web.xml du serveur Tomcat.

<jsp-config>
<jsp-property-group>
<description>Config. de l’encodage des pages
JSP</description>
<url-pattern>*.jsp</url-pattern>
<page-encoding>UTF-8</page-encoding>
</jsp-property-group>
</jsp-config>

Les pages HTML/XHTML

Il est également important de prévenir le navigateur client de l’encodage qu’il doit utiliser pour afficher la page
HTML/XHTML. Cette directive est précisée avec la balise meta et le paramètre content.

<head>
<meta equiv="Content-Type"
content="text/html;charset=UTF-8"> ...
</head>

Il est également possible de préciser l’encodage d’une feuille de style externe à l’aide de la directive placée en tout début
de fichier.

@charset "UTF­8";

Les feuilles de style XSL

Si des transformations XSLT sont utilisées dans notre application, il est nécessaire de déclarer également explicitement
l’encodage dans ces pages.

<xsl:output method="xml" omit­xml­declaration="yes" encoding="UTF­8" indent="yes" />

Code Java
Du point de vue du code Java, il est possible d’utiliser un filtre qui va forcer le serveur d’applications Java à lire les
paramètres de la requête dans l’encodage souhaité et qui va renvoyer les réponses avec le même encodage.

Programmation avancée
 package application.filters;
import java.io.IOException; 14
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class EncodingFilter implements Filter {

public static final String ENCODING = "encoding";
private String encoding;
public void init(FilterConfig filterConfig) throws ServletException
{ this.encoding = filterConfig.getInitParameter(ENCODING);
}
public void doFilter(ServletRequest req, ServletResponse resp,
FilterChain filterChain)throws IOException, ServletException
{ req.setCharacterEncoding(encoding);
resp.setContentType("text/html;charset="+encoding);
filterChain.doFilter(req, resp);
} public void
destroy() {}

Il est alors possible de déclarer ce filtre au sein du fichier de configuration de l’application web.xml. Les filtres étant
exécutés dans l’ordre de déclaration, ce mapping doit être le premier déclaré dans le fichier de configuration.

<filter>
<filter-name>encodingfilter</filter-name>
<filter-class>application.filters.EncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>encodingfilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

L’encodage peut aussi être géré au sein d’une Servlet générique. Chaque Servlet du projet devra alors ensuite hériter
de cette Servlet.

Programmation avancée
 package application.servlets; 15
import java.io.IOException;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import avax.servlet.http.HttpServletResponse;
public abstract class EncodingServlet extends HttpServlet { public
static final String ENCODING = "encoding";
private String encoding;
public void init(ServletConfig servletConfig)throws ServletException
{ this.encoding = servletConfig.getInitParameter(ENCODING);
}
public void doGet(HttpServletRequest req, HttpServletResponse resp) throws
IOException, ServletException
{ req.setCharacterEncoding(encoding);
resp.setContentType("text/html;charset="+encoding);
}
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws IOException, ServletException
{ request.setCharacterEncoding(encoding);
response.setContentType("text/html;charset="+encoding);
}
}

Encodage de la JVM
Il est important d’exécuter la JVM dans l’encodage voulu. Le traitement des chaînes de caractères doit être le même
que le reste de l’application. C’est au lancement de la JVM, donc au lancement du serveur Java EE, que l’encodage est
spécifié à l’aide de l’argument : ­Dfile.encoding=UTF­8

Avec Tomcat, cet argument est spécifié dans le fichier de lancement du serveur, catalina.sh.

JAVA_OPTS="$JAVA_OPTS "­Dfile.encoding=utf­8"

Il est parfois également nécessaire de vérifier l’encodage des URL de l’application. Avec Tomcat, cet encodage est
déclaré explicitement via l’attribut URIEncoding sur le connecteur Coyote. Voici la ligne du fichier server.xml concerné
: <Connector port="8080" maxHttpHeaderSize="8192"... URIEncoding="UTF­8" />

Le code suivant est très utile car il permet la transformation d’une chaîne de caractères dans un encodage précis.

public static String

transformStringEncoding(String init,String
encodingBefore, String encodingAfter)
{
try
{
return new String(init.getBytes(encodingBefore),encodingAfter);
}catch(UnsupportedEncodingException uee)
{
return null;
}
}

Programmation avancée
 16
Gestion de l’encodage
Il est tout à fait possible en Java de gérer l’encodage à utiliser. Pour les flots d’entrée par exemple, la connexion est
réalisée à l’aide de la classe InputStreamReader. Le jeu de caractères à utiliser peut être alors précisé. Par défaut, le
jeu de caractères est fonction du système d’exploitation utilisé et de la localisation (ex : fr_FR UTF­8).

Avec un flot, il est possible de préciser l’encodage utilisé :

InputStreamReader i=new InputStreamReader(is,"UTF­8");

Le nom du jeu de caractères utilisé par défaut est obtenu en programmation avec la méthode System.getProperty()
et le paramètre file.encoding.

package com.betaboutique.classes;
public class
Programmation {
public static void main(String[] args) {
System.out.println("Encodage : "+System.getProperty("file.encoding"));
}
}

Lors des développements Web, il est assez courant que les paramètres reçus par les méthodes HTTP GET et POST ne
soient pas dans un format correct. Les problèmes portent alors sur les accents, les caractères spéciaux... Pour cela, la
transformation d’un encodage peut être forcé en utilisant les octets. Le code ci­dessous permet de transformer un
paramètre reçu en caractères UTF­8.

String
parametre=(String)request.getParameter("parame
tre");
String parametreUTF8=new
String(parametre.getBytes(),"UTF-8");

De même pour les envois d’informations en programmation Java à travers des flux, l’encodage et les transformations
de jeux de caractères sont utilisés.

package
com.betaboutique.classes;
import java.io.InputStream;
import java.net.URL;
import java.net.URLEncoder;
public class Programmation {
public static void
main(String[] args) {

Programmation avancée
 try
{ 17
//paramètre à envoyer en direction du flux
String parametreaenvoyer="mon paramètre";
String unautreparametreaenvoyer="un autre
paramètre"; String
unautreparametreeniso="un paramètre en iso";
URL url=new URL("http://www.essai.com"+"?parametre1="
+URLEncoder.encode (parametreaenvoyer,"UTF-8")
+"&parametre2="+URLEncoder.encode(new String
(unautreparametreaenvoyer.getBytes(), "UTF-8"),"UTF-8")

+"&parametre3="+URLEncoder.encode(unautreparametreenis
o,"ISO-8859-1"));
//poster les informations dans le flux
InputStream fluxLecture=url.openStream();
//fermer le flux
fluxLecture.close();
}
catch(Exceptio
n e)
{
System.out.println("Erreur de connexion");
}

}
}

Programmation avancée