Atelier Developpement Java

Projet :

L’atelier de develop-

pement JAVA

Client :

Sun Service Forma-

tion

Réf. Sun :

LJ300

Révision : D

Date : 20/7/98

SunMicrosystems

Projet :


pement JAVA

Client :

Sun Service Forma-

tion

Réf. Sun :

LJ300

Révision : D

Date : 20/7/98

SunMicrosystems

Projet :


pement JAVA

Client :

Sun Service Forma-

tion

Réf. Sun :

LJ300

Révision : D

Date : 20/7/98

SunMicrosystems

Projet :


pement JAVA

Client :

Sun Service Forma-

tion

Réf. Sun :

LJ300

Révision : D

Date : 20/7/98

SunMicrosystems

Projet :


pement JAVA

Client :

Sun Service Forma-

tion

Réf. Sun :

LJ300

Révision : D

Date : 20/7/98

SunMicrosystems

L’at

elie

r de

dév

elop

pem

ent J

AVA

L’at

elie

r de

dév

elop

pem

ent J

AVA

L’at

elie

r de

dév

elop

pem

ent J

AVA

L’at

elie

r de

dév

elop

pem

ent J

AVA

L’at

elie

r de

dév

elop

pem

ent J

AVA

Projet : L’atelier de develop-

pement JAVA

Client : Sun Service Formation

Réf. Sun : LJ300

Révision : D

Date : 20/7/98

Sun Microsystems France


pement JAVA


Réf. Sun : LJ300

Révision : D

Date : 20/7/98



pement JAVA


Réf. Sun : LJ300

Révision : D

Date : 20/7/98


L’at

elie

r de

dév

elop

pem

ent J

AVA

L’at

elie

r de

dév

elop

pem

ent J

AVA

L’at

elie

r de

dév

elop

pem

ent J

AVA

Intitulé Cours : L’atelier de developpement JAVA


Réf. Sun : LJ300

Révision : D

Date : 20/7/98


Sun Microsystems France S.A.Service Formation143 bis, avenue de Verdun92442 ISSY LES MOULINEAUX CedexTel 01 41 33 17 17Fax 01 41 33 17 20

L’atelier de développement JAVA

7Intutilé Cours : L’atelier de developpement JAVA

Client : Sun Service Formation Révision : D

Réf. Sun : LJ300 Date : 20/7/98

Protections Juridiques

Protections Juridiques

1998 Sun Microsystems, Inc.

2550 Garcia Avenue, Mountain View, California 94043-1100 U.S.A.

AVERTISSEMENTCe produit ou document est protégé par un copyright et distribué avec des licences qui en restreignent l’utilisation, la

copie, la distribution, et la décompilation. Aucune partie de ce produit ou de sa documentation associée ne peut être

reproduite sous aucune forme, par quelque moyen que ce soit, sans l’autorisation préalable et écrite de Sun et de ses

bailleurs de licence, s’il y en a.

Des parties de ce produit pourront être dérivées du système UNIX® licencié par Novell, Inc. et du système Berkeley 4.3

BSD licencié par l’Université de Californie. UNIX est une marque enregistrée aux Etats-Unis et dans d’autres pays et

licenciée exclusivement par X/Open Company Ltd. Le logiciel détenu par des tiers, et qui comprend la technologie

relative aux polices de caractères, est protégé par un copyright et licencié par des fournisseurs de Sun.

Sun, Sun Microsystems, le logo Sun, sont des marques déposées ou enregistrées de Sun Microsystems, Inc. aux Etats-Unis et

dans d’autres pays. Toutes les marques SPARC, utilisées sous licence, sont des marques déposées ou enregistrées de SPARC

International, Inc. aux Etats-Unis et dans d’autres pays. Les produits portant les marques SPARC sont basés sur une

architecture développée par Sun Microsystems, Inc.

Les interfaces d’utilisation graphique OPEN LOOK® et Sun™ ont été développées par Sun Microsystems, Inc. pour ses

utilisateurs et licenciés. Sun reconnaît les efforts de pionniers de Xerox pour la recherche et le développement du concept

des interfaces d’utilisation visuelle ou graphique pour l’industrie de l’informatique. Sun détient une licence non exclusive

de Xerox sur l’interface d’utilisation graphique Xerox, cette licence couvrant aussi les licenciés de Sun qui mettent en

place l’interface d’utilisation graphique OPEN LOOK et qui en outre se conforment aux licences écrites de Sun.

Le système X Window est un produit de X Consortium, Inc.

CETTE PUBLICATION EST FOURNIE “EN L’ETAT” SANS GARANTIE D’AUCUNE SORTE, NI EXPRESSE NI

IMPLICITE, Y COMPRIS, ET SANS QUE CETTE LISTE NE SOIT LIMITATIVE, DES GARANTIES CONCERNANT LA

VALEUR MARCHANDE, L’APTITUDE DES PRODUITS A RÉPONDRE A UNE UTILISATION PARTICULIERE, OU LE

FAIT QU’ILS NE SOIENT PAS CONTREFAISANTS DE PRODUITS DE TIERS.

viii

Copyright 1998 Sun Microsystems, Inc. Tous droits réservés. SunService Avril 98

Table des matières

Prérequis............................................................................................... iiObjectifs du cours............................................................................... iiiProjet : Le poste de travail d’un courtier en bourse ....................... 2

Généralités ................................................................................... 2Exposé du problème ................................................................... 2Le système existant ..................................................................... 2Le système existant (suite) ......................................................... 3Spécifications (suite) ................................................................... 4

Configuration de la base : ................................................. 4Spécifications générales ............................................................. 5

Fonctionnalités principales : ............................................. 5Limitations ................................................................................... 6

PHASE 1 : l’architecture générale..................................................... 7PHASE 2 : l’accès à la base................................................................. 9PHASE 3 : l’interaction utilisateur.................................................. 11PHASE 4 : assemblage d’un produit complet............................... 13PHASE 5 : consolidations, extensions............................................ 15

Objectifs ...................................................................................... 17Références .................................................................................. 17

Introduction à mSQL....................................................................... 18Généralités ................................................................................. 18la réalisation de mSQL ............................................................ 19Les outils de mSQL................................................................... 19

............................................................................................ 19

............................................................................................ 19msqld – le moteur mSQL.......................................... 19

les outils mSQL (suite) ............................................................ 20relshow - Visualiseur de schéma mSQL ....................... 20msqladmin – administration de la base (pour mémoire)

20msqldump – image de la base (pour mémoire) ......... 20

Contrôle d’accès mSQL (pour mémoire) ....................................... 21les outils mSQL (suite) ............................................................ 23

ix L’atelier de développement JAVA


Commandes mSQL........................................................................... 24Généralités ................................................................................. 24La requête SELECT ................................................................. 25La requête SELECT (suite) ...................................................... 26

Exemples ........................................................................... 26La requête SELECT (suite) ...................................................... 27

Jointures............................................................................. 27La commande INSERT............................................................. 28La commande DELETE ........................................................... 28La commande UPDATE........................................................... 29La commande CREATE (pour mémoire) .............................. 30La commande DROP (pour mémoire) ................................... 30

Exercices ............................................................................................. 31Introduction ....................................................................................... 34“Pilote” JDBC..................................................................................... 35Organigramme JDBC........................................................................ 37

L’enchainement des appels ..................................................... 37Package java.sql ................................................................... 37

Organigramme JDBC........................................................................ 38Exemple JDBC ................................................................................... 39Création de pilotes JDBC ................................................................. 41

Création explicite d’une instance de pilote JDBC ................ 41Pilotes JDBC....................................................................................... 43

Désignation d’une base de données....................................... 43Connexion à une base de données.......................................... 44Interrogation d’une base de données..................................... 45

Instructions JDBC.............................................................................. 46Soumission d’une requête........................................................ 46requête préparée (non disponible sous mSQL) .................... 47Exemple ...................................................................................... 47Les méthodes setXXX ............................................................... 47

Méthodes set XXX ........................................................................... 48procédure stockée (non disponible sous mSQL).................. 49Exemple ...................................................................................... 50Appel de procédure.................................................................. 50Récupération de résultats ........................................................ 51

Méthodes get XXX ........................................................................... 53Correspondance des types de données SQL en Java ................... 54Utilisation de l’API JDBC................................................................. 55

Types de conception des pilotes JDBC .................................. 55Types d’architecture d’accès aux bases de données .................... 56

Conceptions en deux niveaux ................................................. 56Conceptions en trois niveaux .................................................. 57

Applets................................................................................................ 58Applets et applications de bases de données traditionnelles .

58

table des matières x


Performances ............................................................................. 58Contraintes de sécurité............................................................. 59

Accès au manipulations graphiques .............................................. 62Le package AWT ....................................................................... 62

Les gestionnaires de Disposition (LayoutManager) .................... 63Les événements ................................................................................. 65

Evénements sources.................................................................. 65Traitements d’événements....................................................... 65Modèle de délégation (JDK 1.1) .............................................. 66

Comportement de l’interface graphique utilisateur Java............ 70Catégories d’événements ......................................................... 70

Tableaux ............................................................................................. 71Comportement de l’interface graphique utilisateur Java............ 72

Evénements générés par composants AWT.......................... 72Obtention d’informations sur un événement ....................... 73Récepteurs multiples ................................................................ 73

Adaptateurs d’événements.............................................................. 74Button.......................................................................................... 76

List ....................................................................................................... 80TextArea ............................................................................................. 83

TextComponent......................................................................... 84Frame .................................................................................................. 85Panel.................................................................................................... 86Dialog.................................................................................................. 87FileDialog ........................................................................................... 89ScrollPane........................................................................................... 90Menus ................................................................................................. 91

Menu Aide ................................................................................. 91MenuBar ............................................................................................. 92Menu ................................................................................................... 93MenuItem........................................................................................... 94CheckboxMenuItem ......................................................................... 95PopupMenu ....................................................................................... 96Contrôle des aspects visuels............................................................ 98

Couleurs ..................................................................................... 98Polices ......................................................................................... 99Polices ....................................................................................... 100

Impression........................................................................................ 101E/S JAVA : concepts fondamentaux............................................ 104

flots d’E/S (Streams)............................................................... 104I/O Streams et Reader/Writer.............................................. 105catégories de flots.................................................................... 105filtres ......................................................................................... 106

Fichiers.............................................................................................. 107Noms de fichiers ............................................................ 107 Tests de fichiers ............................................................. 107

xi L’atelier de développement JAVA


Information générale axée sur les fichiers et utilitaires.107

Utilitaires en rapport avec les répertoires .................. 107Linéarisation .................................................................................... 108

Classes DataInputStream et DataOutputStream ..... 108Méthodes DataInputStream ......................................... 108

Object Input/Output .............................................................. 109Architecture de linéarisation ......................................................... 110

Package java.io ........................................................................ 110Interface Serializable ....................................................... 111Eléments sérialisables............................................................. 111

Ecriture et lecture d’un flot d’objets ............................................. 112Lecture ...................................................................................... 112qu’est ce qui est transferré? ................................................... 113personnalisation de la lecture/écriture d’objet .................. 114Externalisable........................................................................... 115

Programmation réseau sous Java ................................................. 118Sockets ...................................................................................... 118

Le modèle réseau de Java............................................................... 119Principe d’un Serveur TCP/IP...................................................... 120

Exemple de code de mise en oeuvre d’un serveur TCP/IP120

Principe d’un Client TCP/IP......................................................... 121échanges UDP................................................................................. 122Exemple de Serveur UDP ............................................................. 123Exemple de client UDP ................................................................ 124 UDP en diffusion (Multicast) ..................................................... 125Exemple de Serveur Multicast ..................................................... 126Exemple de client Multicast .......................................................... 127Fonction de l’architecture RMI en Java........................................ 131Packages et hiérarchies RMI.......................................................... 132

Package java.rmi ................................................................. 132Création d’une application RMI ................................................... 135

Exemple bancaire .................................................................... 135Création d’une application RMI ................................................... 136

Interfaces bancaires................................................................. 136Procédure ................................................................................. 138Interface Account .................................................................. 139Interface AccountManager ................................................... 140réalisation de l’interface Account — AccountImpl .......... 141AccountManagerImpl ............................................................ 143

Classe de conteneurs ..................................................... 145Compilation du code .............................................................. 146Utilisation de la commande rmic ......................................... 147Application BankServer ...................................................... 148Application rmiregistry .................................................... 150

table des matières xii


Application BankClient ...................................................... 151Exécution de l’application BankClient .............................. 154

Syntaxe............................................................................. 155Exemples ......................................................................... 155

Sécurité RMI..................................................................................... 156Chargement de classe ............................................................. 156

Côté serveur RMI ........................................................... 156Côté client RMI............................................................... 157

Invocation RMI au travers d’un coupe-feu ......................... 157Pourquoi réaliser du code natif?................................................... 160un exemple : "Hello World" en C.................................................. 161

résumé des phases : ................................................................ 161Ecriture du code JAVA :................................................ 161Création des binaires JAVA de référence : ................ 161Génération du fichier d’inclusion C/C++ : ................ 161Ecriture du code natif : ................................................ 161Création d’une librairie dynamique:.......................... 161Exécution: ........................................................................ 161

Ecriture du code JAVA........................................................... 162Création des binaires JAVA de référence ............................ 163Génération du fichier d’inclusion C/C++........................... 164Ecriture du code natif ............................................................. 165Création d’une librairie dynamique..................................... 166Exécution.................................................................................. 167

présentation de JNI ......................................................................... 168JNI: types, accès aux membres, création d’objets....................... 169références sur des objets JAVA: .................................................... 172exceptions......................................................................................... 173invocation de JAVA dans du C..................................................... 174Organisation des packages et des répertoires............................. 176convention de codage..................................................................... 177

Identificateurs (conventions standard)................................ 177Identificateurs (conseils complémentaires)......................... 177Nommage (conseils complémentaires)................................ 178Mise en page ............................................................................ 179

portabilité ......................................................................................... 180performances ................................................................................... 181 traces, exceptions ........................................................................... 182le "bon " et le "beau" code ?............................................................ 183les interactions graphiques ............................................................ 187répartition......................................................................................... 188

les protocoles ........................................................................... 189internationalisation......................................................................... 190intégration des méthodes natives ................................................. 191introduction : R.A.D et/ou maîtrise du code de base?.............. 194L’intégration des outils, les ateliers .............................................. 196

xiii L’atelier de développement JAVA


analyse et conception...................................................................... 197L’éditeur ........................................................................................... 198Outils annexes à l’éditeur .............................................................. 199L’aide à la conception d’interaction ............................................. 200Gestion des sources......................................................................... 201

principes ................................................................................... 201outils.......................................................................................... 201points ........................................................................................ 202

Gestionnaires de maintenance ...................................................... 203Documentation de code, aide en ligne........................................ 204Debug................................................................................................ 205

outils.......................................................................................... 205génération (make) ........................................................................... 206tests.................................................................................................... 207

principes ................................................................................... 207produits .................................................................................... 207points ........................................................................................ 208

analyse de couverture .................................................................... 209analyses de performances.............................................................. 210

principes ................................................................................... 210outils.......................................................................................... 210points ........................................................................................ 210

Analyses statiques du code ........................................................... 211principes ................................................................................... 211outils.......................................................................................... 211points ........................................................................................ 211

préparation à la livraison............................................................... 212livraison/déploiement ................................................................... 213autres outils...................................................................................... 214

décompilateurs/brouilleurs .................................................. 214outils syntaxiques.................................................................... 214

JavaWorkshop: Gestionnaire de projets ...................................... 216Mise en oeuvre du “Project Manager”................................. 216créer ou importer un portefeuille ......................................... 217créer ou importer un projet ................................................... 217fixer les attributs d’un projet ................................................. 218

JavaWorkshop: édition, compilation, tests.................................. 219édition ....................................................................................... 219personnalisation de l’édition................................................. 219contrôle d’accès et version ..................................................... 219compilation .............................................................................. 220test ............................................................................................. 220

iCopyright 1998 Sun Microsystems, Inc. All Rights Reserved. SunService 1998

Introduction

Durant ce stage vous aurez la possibilité de mener à bien un projet

JAVA complet.

L’accent est mis sur la pratique et vous êtes vivement encouragé à

confronter vos reflexions à celles des autres stagaires (ou à celles de

l’animateur).

Ce stage contient peu de cours théoriques mais, selon vos besoins,

l’animateur peut-être amené à faire quelques rappels rapides -en règle

générale vous vous appuierez plutôt sur les aide-mémoires du

support-

Vous trouverez dans le présent support:

● La description générale du projet à réaliser.

● Une série d’aide-mémoires concernant l’utilisation de SQL, JDBC,

AWT, les entrées-sorties, la programmation réseau et RMI. Un

cours sur l’intégration de méthodes natives complète ces rappels.

● Deux chapitres constituant une introduction à la pratique

professionnelle du développement en JAVA : les savoir-faires et la

filière des outils.

Introduction Revision D -iiCopyright 1998 Sun Microsystems, Inc. Tous droits réservés.

Prérequis

Pour participer à ce cours il est vivement conseillé de maitriser:

● Le contenu des cours LJ20 (introduction à Java) et LJ21

(programmation Java avancée) et en particulier:

● Les Api Java standard

● La création d’interface graphiques réalisées avec AWT.

● La programmation des sockets TCP/IP avec Java

● La programmation parallèle (Threads)

● Les techniques de programmation Objet

Introduction Revision D -iiiCopyright 1998 Sun Microsystems, Inc. Tous droits réservés.

Objectifs du cours

A la suite de ce cours vous serez capable de:

● d’initier un projet JAVA depuis la conception jusqu’à la réalisation

et aux tests.

● organiser les développements JAVA dans le cadre d’une filière

professionnelle.

● mettre en place une filière de maintenance

● enrichir en permanence vos savoir-faires en JAVA moyennant des

investissements modiques dans la veille technologique.

Introduction Revision D -ivCopyright 1998 Sun Microsystems, Inc. Tous droits réservés.

Intitulé Cours: L’atelier de developpement JAVA


Réf. Sun : LJ300 Date : 20/7/98

Le Projet 1

Objectifs

Ce chapitre décrit:

• Les spécifications générales du projet à réaliser durant le stage

• Les différentes phases de réalisation du code.

1

1/2Intitulé Cours: L’atelier de developpement JAVA


Réf. Sun : LJ300 Date : 20/7/98

Le Projet

Projet : Le poste de travail d’un courtier en bourse

Généralités

L’exposé du problème ne définit pas toutes les spécifications (on retrouve

ici une situation courante dans la vie réelle!). Quelques précisions

supplémentaires seront données par l’animateur dans les présentations

de phases . Il faudra donc réfléchir à des spécifications plus détaillées, en

discuter en équipe et prendre des décisions définitives en accord avec les

orientations que fixera l’animateur.

Exposé du problème

Une société de courtage en bourse a commencé à réaliser une application

pour la saisie d’ordres de bourse. Pour différentes raisons il y a eu un

début de réalisation et l’équipe que vous allez constituer doit tenir compte

du système existant.

Le système existant

La société va déployer son application sur son réseau local sécurisé

(vision "intranet")

Vous disposez des composants suivants :

• Une base de données relationnelle. Le schéma de la base est déjà

défini. Pour les besoins de ce stage on opérera sur Mini-SQL

(mSQL) une petite base de données du domaine public -toutefois

le projet sera adaptable à d’autres bases-

• Un processus permanent de mise à jour de la cotation des valeurs.

Ce processus est censé fournir les évolutions de la cote en temps

réel. Pour les besoins du projet il s’agit d’un programme JAVA qui

est fourni.

• Un serveur HTTP



Réf. Sun : LJ300 Date : 20/7/98

1

Le Projet

Le système existant (suite)

Quelques informations complémentaires:

• La base de données, le serveur de cotations et le serveur HTTP

"tournent" sur un seul serveur Sun.

• Base mSQL:

• Le schéma est prédéfini et ne peut être changé

• Le processus mSQL sert les requêtes sur le port 1112 enprotocole TCP/IP .

• L’application de mise à jour de la cote est un programme JAVA

fourni :

• La cotation évolue toute les 45 secondes

• Toute modification doit être reportée dans la base de données.

• La manière dont les informations seront diffusées aux clientsreste à arréter. Si l’initiative des demandes de mises à jour resteaux clients on utilisera alors un serveur écoutant sur le port5432.

• serveur HTTP :

• écoute sur le port standard (80).

• les fichiers HTML seront disponibles sur le serveur dans unrépertoire accessible aux différentes équipes dedéveloppement..

1



Réf. Sun : LJ300 Date : 20/7/98

Le Projet

Le poste de travail d’un courtier en bourse

Spécifications (suite)

Configuration de la base :

La base existante, StockMarket , est configurée selon le schéma suivant:

Customer Table

Field Name Type Comment

ssn char (15) clef primaire

cust_name char (40)

address char (100)

Shares Table


ssn char (15) Not null

symbol char (8) Not null

quantity int

Stock Table


symbol char (8) clef primaire

price real



Réf. Sun : LJ300 Date : 20/7/98

1

Le Projet


Spécifications générales

L’outil à développer en JAVA doit être un système opérant en mode

client/serveur permettant de mettre à jour les informations contenues

dans la base de données.

Fonctionnalités principales :

• Permettre au courtier("l’utilisateur") d’ajouter ou de supprimer un

client dans la base.

Il est admis que le nombre de clients dans la base peut être très

important.

• Permettre de modifier le nom ou l’adresse d’un client (mais pas

son identifiant unique -ssn -).

• Permettre de visualiser la cotation courante d’une ou de plusieurs

valeurs. Les valeurs changeant en permanence on étudiera la

manière la plus appropriée de porter ces modifications à la

connaissance de l’opérateur.

Il est admis que le nombre de valeurs de la cote est très limité (tout

au plus quelques centaines).

• Permettre d’acheter et de vendre des actions pour un client. La

base de données et l’interface homme/machine doivent être mises

à jour en conséquence. On devra pouvoir visualiser le portefeuille

du client et le modifier.

Des spécifications complémentaires devront être arrétées au cours du

projet. On simulera ainsi les nécessaires évolutions du projet au fur et

mesure que les besoins s’affineront (bien entendu ces évolutions devront

rester dans les limites raisonnables du temps qui est imparti!)

1



Réf. Sun : LJ300 Date : 20/7/98

Le Projet


Limitations

Du fait de limitations importantes dans le temps on s’efforcera de

simplifier certains aspects du projet.

Ainsi on peut admettre que :

• Les requêtes concernant les clients utiliseront leur identifiant

unique(ssn ), alors qu’il semblerait plus normal de les rechercher

par leur nom (et même par leur nom approximatif!).

• Idem pour les valeurs de la cote qui ne seront connues que par

leur code (symbol ).

• On utilisera essentiellement des composants graphiques fournis

(AWT standard, JFC) des adaptations de ces composants sont

toutefois possibles.



Réf. Sun : LJ300 Date : 20/7/98

1

Le Projet

PHASE 1 : l’architecture générale

principes

Déterminer l’architecture générale du projet.

Cette définition s’appuie sur les principes suivants :

• Un produit peut être décomposé en quelques grands composants

qui collaborent entre eux pour rendre le service attendu.

• Ces composants principaux communiquent entre eux au moyen

d’un protocole minimum (une A.P.I.). Il est important de définir

ces protocoles car ils permettent de réaliser une architecture

adaptable et un développement incrémental basé sur la définition

de "services" abstraits.

Un exemple :

• Une demande de mise à jour de la base peut provenir d’uneinterface utilisateur interactive, d’une interface utilisateursimplifiée en mode texte, d’une requête provenant d’une lignede communication distante, etc.

• Abstraire ces diverses possibilités dans un seul concept (une

interface JAVA par exemple) permet de faire fonctionner les

requêtes à la base dans différentes situations :

- On peut ainsi valider les interrogations à la base sans

attendre la réalisation de l’interface interactive,

- On peut tester cette base à l’aide de scenarios contenus dans

des fichiers textes,

- On peut transformer un produit dans lequel l’interface et

l’interrogation à la base fonctionnent dans le même processus

en un produit dans lequel ces deux fonctions communiquent

au travers du réseau (l’interrogation à la base se fait sur le

serveur, l’interface utilisateur est sur un client distant),

- etc.

1



Réf. Sun : LJ300 Date : 20/7/98

Le Projet

réalisation

1. Former les équipes de développement

2. Au sein des équipes discuter de l’architecture générale, puis

définir d’une part les classes principales (ex. : "Client", "Valeur"

pour une valeur de la cote, "Portefeuille" pour décrire le

portefeuille d’un Client) et d’autre part décrire les grands

composants (en décrivant les méthodes d’API qui les caractérisent)

3. Proposer une politique générale pour le traitement des traces et

des Exceptions.

4. Obtenir un accord entre les équipes pour que les méthodes d’API

soient communes (objectif: un composant réalisé par une équipe

doit pouvoir être utilisé par l’autre).

5. Organiser les premiers "packages" de développement et coder les

définitions qui seront nécessaires pour la suite du projet.

6. Noter les interrogations sur la suite du projet, les différentes

options que l’on peut entrevoir, etc.

références

voir chapitres :

• recommandations de programmation : packages, convention decodage, traces et exceptions.La conception générale (UML) sort du cadre du présent cours.

• outils : les outils d’analyse et de conception sortent du cadre dece cours



Réf. Sun : LJ300 Date : 20/7/98

1

Le Projet

PHASE 2 : l’accès à la base

principes

Réaliser le module d’interrogation de la base de données au travers de

JDBC.

Ce module sera testé à l’aide d’une interface très simplifiée lisant des

requêtes en mode texte sur l’entrée standard.

réalisation

1. Eventuellement, remise à jour des connaissances sur SQL et JDBC

2. Finaliser la mise en place de l’environnement de développement.

(commencer à utiliser JavaWorkshop)

3. Réaliser le ou les modules implantant les méthodes d’interrogation

de la base.

Documenter ces modules (javadoc)

4. Réaliser un module permettant de tester simplement la réalisation

précédente par de simples requêtes sous forme texte. Tester l’effet

sur la base en réalisant des requêtes SQL sur msql.

5. Tester simplement les mécanismes d’exceptions.

6. Donner quelques exemples de spécifications fonctionnelles

complémentaires qui permettront de tester votre API (c.a.d.

quelques règles implicites que l’API doit aussi vérifier).

Si l’on dispose de l’outil JAVASPEC (et d’un peu de temps) essayer

d’implanter ces règles et de les appliquer au module d’accès à la

base de données.

1



Réf. Sun : LJ300 Date : 20/7/98

Le Projet

références

voir chapitres :

• rappels: SQL, JDBC, Entrées/Sorties

• recommandations de programmation : portabilité (100% java)

• outils : JavaWorkShop, mSQL, JAVASPEC



Réf. Sun : LJ300 Date : 20/7/98

1

Le Projet

PHASE 3 : l’interaction utilisateur

principes

Maquette graphique : concevoir et réaliser une première version

d’interface utilisateur.

En tenant compte des principes de conception d’une interface

ergonomique concevoir une interface qui permette à l’opérateur de:

• rechercher la description d’un client

• créer, détruire ou modifier la description d’un client

• visualiser le portefeuille d’un client

• modifier le portefeuille d’un client par achat, vente d’un certainnombre d’actions (prévoir option "tout vendre" correspondantà une action donnée).

• visualiser les cours d’une ou plusieurs Valeurs de la cote.(s’organiser éventuellement pour faire ressortirautomatiquement certaines valeurs).

réalisation

1. Eventuellement, remise à jour des connaissances sur les

composants, la disposition AWT, la gestion des événements

graphiques.

2. Faire un "design" général sur papier, l’affiner en codant des parties

de cette interface. Se répartir éventuellement le travail entre les

membres de l’équipe.

Tenir compte, pour le choix des composants, des limites

éventuelles (nombre de clients, nombre de valeurs à la cote).

Tenir compte également des besoins de personnalisation (taille des

police, disposition de certains champs, accélérateurs)

3. Réaliser une interface d’ensemble, l’assembler en local avec le

module d’interrogation de la base et avec le module de mise à jour

des valeurs.

Tester le fonctionnement et le faire tester par un "naïf" (un membre

d’une autre équipe).

1



Réf. Sun : LJ300 Date : 20/7/98

Le Projet

4. Tester avec des conditions erronées (analyser la mise en oeuvre

des mécanismes de récupération d’exceptions et leur effet sur

l’interface utilisateur).

5. Envisager des modifications du type : exploitation dans un

contexte d’Applet, ajout de fonctions ( identification de

l’opérateur, demande d’impression) , modifications du contenu

des tables de la base de données, améliorations cosmétiques

(couleurs, image de fond), personnalisations .

En tirer des indications sur l’organisation du code et sa

maintenabilité.

références

voir chapitres :

• rappels: composants graphiques

• recommandations de programmation : les interactionsgraphiques, le "bon" et le "beau" code : pratique AWT,internationalisation

• outils : JavaWorkShop



Réf. Sun : LJ300 Date : 20/7/98

1

Le Projet

PHASE 4 : assemblage d’un produit complet

principes

Mise en service dans des conditions réelles.

Répartition de l’application :

• Le processus de mise jour des cotations doit fonctionner demanière autonome. (Dans la phase précédente il était lié àl’application pour les besoins du test).

• Mise en oeuvre d’une application en mode client/serveur.L’interface utilisateur ne fonctionne plus forcément sur leserveur lui-même.

réalisation

1. Eventuellement, remise à jour des connaissances sur Sockets,

Threads, DataInput/OutPut, Serialisation, RMI

2. Discuter des différentes possibilités de réalisation pour la mise à

jour des valeurs de la cote sur les postes clients (initiative du

serveur, initiative du client).

3. Réaliser cette mise jour automatique et intégrer d’éventuelles

modifications de l’interface utilisateur.

4. Spécifier la réalisation du client déporté et justifier vos choix

(application autonome ou Applet, dialogue par Socket ou RMI,...)

5. Réaliser le client déporté et le mettre en oeuvre (ressources, fichier

HTML dans le cas d’une Applet, etc.)

6. Tester l’ interface en faisant intervenir les règles fonctionnelles

complémentaires définies en phase 2.

1



Réf. Sun : LJ300 Date : 20/7/98

Le Projet

références

voir chapitres :

• rappels: E/S DataInput, ObjectStreams, Socket, RMI

• recommandations de programmation : répartition

• outils : JavaWorkShop (debuger), JAVASPEC,



Réf. Sun : LJ300 Date : 20/7/98

1

Le Projet

PHASE 5 : consolidations, extensions

principes

• compléments de réalisation : impressions, journalisation locale,personnalisation de l’interface utilisateur.

• consolidations : analyse de code, mise en place de processus demaintenance.

réalisation

1. Réalisations facultatives : impression d’un document attestant

d’un ordre de bourse (vente-achat d’actions), journalisation locale

des opérations effectuées par l’opérateur, personnalisations de

l’interface utilisateur, exploration de la réalisation de code natif.

2. Faire une proposition pour une sécurité/authentification

minimum dans le système.

3. Tests et analyse de code : analyse de performance, analyse de

couverture.

4. Problématique de la fabrication et de la livraison du produit fini :

faire une proposition d’organisation.

références

voir chapitres :

• rappels: JNI

• recommandatins de programmation : performances, 100% purjava, intégration de méthodes natives,

• outils : JavaWorkShop (analyse de performances), JAVASCOPE

1



Réf. Sun : LJ300 Date : 20/7/98

Le Projet



Réf. Sun : LJ300 Date : 20/7/98

SQL (et miniSQL) 2

1

Objectifs

• introduction à l’outil mSQL

• introduction à SQL

• manipulations sur la base existante

Références

The Practical SQL Handbook, Emerson, Darnovsky, and Bowman, Addison-

Wesley, 1989.

“mSQL Manual,” Hughes, (unpublished), 1996.

2



Réf. Sun : LJ300 Date : 20/7/98

SQL (et miniSQL)

Introduction à mSQL

Généralités

Ce cours utilise une base SQL appelée mini-SQL (mSQL).

mSQLest un produit (disponible sous licence) créé par David Hughes1.

Ce produit comprend: le moteur de base de données, une interface

"terminal" simple, un programme d’administration de la base, un

visualiseur de schema et une API en langage "C". L’API et le moteur

fonctionnent dans un environnement client/serveur en utilisant les

services de TCP/IP.

mSQL est un produit simple et performant permettant de réaliser des

requêtes SQL très simples (un sous-rensemble du SQL ANSI).

1. MiniSQL nous est fourni par Hughes Technologies Pty Ltd (Australie). Pourplus d’informations ou pour une copie d’évaluation voir l’adresse :www.Hughes.com.au.



Réf. Sun : LJ300 Date : 20/7/98

2

SQL (et miniSQL)


la réalisation de mSQL

mSQL est écrit en C et la version utilisée dans ce cours a été adaptée pour

Solaris. Au coeur de mSQL il y a le daemon msqld qui écoute sur un port

TCP/IP. Voici un extrait du manuel mSQL :

[mSQL] is a single process engine that will accept multipleconnections and serialize the queries received. It utilizesmemory mapped I/O and cache techniques to offer rapid accessto the data stored in a database. It also utilizes a stack basedmechanism that ensures that INSERT operations are performedat the same speed regardless of the size of the table beingaccessed.

The server may be accessed either via a well known TCP socketor via a UNIX domain socket with the file system(/dev/msqld). The availability of the TCP socket allows clientsoftware to access data stored on machine over the network.

Les outils de mSQL

voir produit et documentation sur : http://www.Hughes.com.au

msqld – lemoteur mSQL

C’est le moteur de la base de données. Le démon est lancé sur un serveur

et peut tourner avec l’identitié de root (ou avec l’identité d’un utilisateur

local). Au cours de ce stage le démon aura l’identité de root (l’animateur

désignera la machine hôte).

2



Réf. Sun : LJ300 Date : 20/7/98

SQL (et miniSQL)


les outils mSQL (suite)

relshow - Visualiseur de schéma mSQL

relshow permet d’interroger la base pour connaître les noms des tables

ou les caractéristiques des champs. Il peut être lancé soit localement soit à

distance :

relshow [-h hostname] database

relshow [-h hostname] database tablename

msqladmin – administration de la base (pour mémoire)

Les commandes sont:

create DataBase Crée une nouvelle base nommée: DataBase

drop DataBase Détruit la base DataBase

shutdown Demande l’arrêt du serveur mSQL

reload Demande au serveur de recharger les informations de contrôle

d’accès

version Donne diverses informations sur le produit.

Le serveur mSQL acceptera les commandes d’administration uniquement

si elles sont lancées par l’utilisateur root sur la machine serveur.Seule la

commande version peut être passée par une autre personne.

msqldump – image de la base (pour mémoire)

msqldump produit une trace qui peut être utilisée en entrée par le

terminal mSQL. On peut ainsi facilement créer des copies de la base (y

compris sur le réseau avec option -h)



Réf. Sun : LJ300 Date : 20/7/98

2

SQL (et miniSQL)

Contrôle d’accès mSQL (pour mémoire)

Le contrôle d’accès est décrit dans le fichier msql.acl dans le répertoire

d’installation de la base. Le fichier est séparé en plusieurs zone (une par

base controlée par le serveur). Sans configuration les accès sont

globalement autorisés en lecture/écriture.

Voici un exemple de zone dans ce fichier

# Sample access control for mSQLdatabase=testread=bambi,paulpwrite=roothost=*.Bond.edu.au,-student.it.Bond.edu.auaccess=local,remote

Selon cette définition, la base test est accessible à la fois par des

connexions locales (local) et distantes (remote). Ces connexions peuvent

provenir de tout hôte dans le domain Bond.edu.au sauf pour la machine

student.it.Bond.edu.au .

L’accès en lecture est reservé uniquement à bambi et paulp (et personne

d’autre). L’accès en écriture est reservé à root.

Les contrôles sont basés sur la première correspondance trouvée. Ainsi

une ligne du type read=-*,bambi ne pourra permettre de retirer les

droits d’écriture à tout le monde sauf bambi (-* correspondra aussi à

bambi). L’entrée correcte serait plutôt read=bambi,-* bien que le -*soit superflu parceque c’est la politique par défaut.

Attention: si dans une ligne de configuration une entrée particulière est

absente (par ex. read ), le comportement par défaut est le plus sécurisé

(du coup personne ne pourra lire!). Ceci est en contradiction avec le

comportement par défaut si la zone réservée à la base n’est pas décrite

dans le fichier de configuration: là tous les accès sont autorisés!

A noter également: les "zones" décrivant chaque base doivent être séparés

par une ligne blanche (qui marque ainsi la fin de la description de la base

courante). Il peut y avoir plusieurs lignes portant sur la même entrée

comme dans:

read=bambi,paulpread=root

2



Réf. Sun : LJ300 Date : 20/7/98

SQL (et miniSQL)

Des caractères "jokers" (*) peuvent être utilisés dans les descriptions. Un

joker seul correspondra à toute chaîne, alors qu’un tel caractère suivi par

d’autres déclenche un "pattern matching" partiel (exemple:

*.Bond.edu.au corresond à tout ce qui peut se terminer par la chaîne

Bond.edu.au ).

Une pratique saine consiste à faire, en fin de fichier, une zone avec une

entrée database=* de manière à définir des droits par défaut pour

TOUTE base.

Les informations sur les listes de contrôle d’accès peuvent être rechargées

en cours d’éxécution par msqladmin reload . Ceci réanalysera le fichier

de configuration avant de lancer la commande reload (donc uniquement

si l’analyse s’est correctment terminée). Comme pour toutes les

commandes de msqladmin cette commande ne sera acceptée que si elle

est lancée par root sur la machine serveur.



Réf. Sun : LJ300 Date : 20/7/98

2

SQL (et miniSQL)


les outils mSQL (suite)

msql – terminal d’interaction SQL

msql lit des requêtes en mode texte et affiche les résultats. On peut le

lancer localement ou sur un site distant:

msql [-h hostname] database

Si hostname n’est pas spécifié, msql recherche la variable d’environnement

MSQL_HOST et s’il ne la trouve pas utilise le site local.

msql reconnaît quatre commande spéciales préfixées par (\) pour les

distinguer des ordre SQL.

• \g Go, execute la requête SQL en cours (ou la requête

précédente).

• \p Print, affiche le contenu du buffer d’interrogation

• \e Edite la dernière commande dans votre éditeur par défaut.

• \q Quittter mSQL.

2



Réf. Sun : LJ300 Date : 20/7/98

SQL (et miniSQL)

Commandes mSQL

Généralités

Chaque requête SQL commence par un mot-clef particulier, mSQL répond

aux commandes suivantes :

• SELECT – Recherche d’enregistrements dans une ou plusieurs

tables..

• INSERT – ajoute un enregistrement dans une table.

• DELETE– Retire des enregistrements d’une table.

• UPDATE – Modifie des champs dans des enregistrements

particuliers.

• CREATE– Crée une nouvelle table avec les champs de noms et de

types spécifiés.

• DROP– détruit une table de la base.

Exemple : recherche de tous les champs de la table "employee_data" de

l’enregistrement pour lequel le champ "employee_id" a la valeur ’10223’

(il s’agit ici d’une chaîne de caractères et non d’un nombre):2

SELECT * FROM employee_data WHERE employee_id =’10223’

2. Les requêtes mSQL sont indépendantes de la capitalisation des lettres, Lesexemples ci-après comportent toutefois des lettres majuscules chaque foisqu’on utilise un mot-clef de SQL.



Réf. Sun : LJ300 Date : 20/7/98

2

SQL (et miniSQL)

Commandes mSQL

La requête SELECT

La requête SELECT est la commande élémentaire pour rechercher des

valeurs contenues dans la base. Cette commande permet les services

suivants :

• jointure entre plusieurs tables (pas de "jointure externe")

• Modifieur DISTINCT pour la sélection des enregistrements

• Clauses ORDER BY (tris)

• Recherches par expressions régulières ("joker")

• Utilisation de comparaisons entre colonnes dans les clauses

WHERE

La syntaxe générale d’une requête SELECT en mSQL (on remarquera que

ce SQL est incomplet par rapport au SQL standard):

SELECT [table.]colonne [ , [table.]colonne ]...FROM table [ , table]...[ WHERE [table.]colonne Operateur Valeur

[ AND | OR [table.]colonne Operateur Valeur ]... ][ ORDER BY [table.]colonne [ DESC] [, [table.]colonne[DESC] ...]

Operateur peut être <, >, =, <=, >=, <>, ou LIKE .Valeur peut être une

colonne ou une constante littérale..

La syntaxe des expressions régulières est celle du SQL standard :

• A un caractère de soulignement (_) correspond n’importe quel

caractère (et un seul). A un caractère pourcent (%) correspond 0,1

ou plusieurs caractères.

• Un anti-slash (\ ) est un caractère d’échappement pour les

caractères spéicaux (par exemple, \% doit correspondre un %et \\correspond à un \ ).

• tous les autres caractères correspondent à eux-mêmes.

2



Réf. Sun : LJ300 Date : 20/7/98

SQL (et miniSQL)

commandes mSQL

La requête SELECT(suite)

Exemples

SELECT first_name, last_name FROM emp_detailsWHERE dept = 'finance'

Pour trier les résultats dans l’ordre ascendant pour le nom (last_name) et

en ordre descendant pour le prénom (first_name) :

SELECT first_name, last_name FROM emp_detailsWHERE dept = 'finance'ORDER BY last_name, first_name DESC

Lorsque des résultats comprennent les mêmes combinaisons de valeurs le

modifieur DISTINCT permet d’éliminer les "doublons" :

SELECT DISTINCT last_name FROM emp_detailsWHERE dept = 'finance'ORDER BY last_name

Pour rechercher toute personne dans le département "finance" dont le

nom ressemble à "Dupon" (tels que "Dupond" et "Dupont")

SELECT first_name, last_name FROM emp_detailsWHERE dept = 'finance' AND last_name LIKE 'Dupon_'



Réf. Sun : LJ300 Date : 20/7/98

2

SQL (et miniSQL)

Commandes mSQL

La requête SELECT(suite)

Jointures

C’est l’opération qui permet d’opérer des recherches en établissant des

relations entre deux ou plusieurs tables.

Exemple : une table décrit les employés (emp_details) et une autre table

decrit les équipes de projet (project_detail). Chaque membre d’une équipe

est repéré par un code (emp_id) qui identifie de manière unique un

employé. Pour avoir les informations détaillées sur qui travaille dans quel

projet :

SELECT emp_details.first_name, emp_details.last_name,project_details.project

FROM emp_details, project_detailsWHERE emp_details.emp_id = project_details.emp_idORDER BY emp_details.last_name, emp_details.first_name

La jointure entre les deux tables se fait par leurs champs emp_id respectifs

(on notera que ce champ est une clef dans la table emp_details).

mSQL ne limite pas le nombre de tables que l’on peut impliquer dans une

jointure.

✏✏✏✏✏✏✏✏

en mSQL tous les noms de colonnes dans une jointure doivent être

qualifiés (c’est à dire rattachés à une table). Il n’y a pas de rattachement

implicite d’une colonne à une table.

2



Réf. Sun : LJ300 Date : 20/7/98

SQL (et miniSQL)

Commandes mSQL

La commande INSERT

La commande INSERT permet d’ajouter de nouveaux enregistrements à

une table. Il faut spécifier à la fois les noms des champs (décrire le N-

uplet) et la combinaison de valeurs correspondantes (le N-uplet lui-

même) .

INSERT INTO table_name ( column [ , column ]... )VALUES (value [, value]... )

exemple:

INSERT INTO emp_details ( first_name, last_name, dept,salary)VALUES ('David', 'Hughes', 'I.T.S.','12345')

Contrairement au SQL standard on ne peut mettre une requête SELECT à

l’intérieur d’une requête INSERT..

La commande DELETE

La commande DELETE permet de détruire des enregistrements d’une

table. La syntaxe en est:

DELETE FROM table_nameWHERE column Operateur Valeur

[ AND | OR column Operateur Valeur ]...

Operateur peut être <, >, =, <=, >=, <>, ou LIKE

Exemple:

DELETE FROM emp_details WHERE emp_id = ’12345’



Réf. Sun : LJ300 Date : 20/7/98

2

SQL (et miniSQL)

Commandes mSQL

La commande UPDATE

La commande UPDATE permet de changer une ou plusieurs valeurs de

champs dans un enregistrement existant. En mSQL seules des valeurs

littérales peuvent être utilisées pour spécifier la nouvelle valeur d’un

champ (on ne peut pas indiquer un nom de colonne par ex.)

UPDATE table_name SET column= Valeur [, column= Valeur ]...WHERE column Operateur Valeur

[ AND | OR column Operateur Valeur ]...

Operateur peut être <, >, =, <=, >=, <>, ou LIKE.

Exemple:

UPDATE emp_details SET salary=30000 WHERE emp_id = ’1234’

2



Réf. Sun : LJ300 Date : 20/7/98

SQL (et miniSQL)

Commandes mSQL

La commande CREATE(pour mémoire)

En mSQL la commande CREATE peut seulement être utilisée pour créer

une table (on ne peut pas réaliser d’autres définitions comme une vue).

ATTENTION : il ne peut y avoir qu’une seule clef primaire par table. La

définition d’un champ comme étant un clef entraîne automatiquement la

propriété "not null" .

CREATE TABLE table_name (col_name col_type [ not null | primary key ]

[ , col_name col_type[ not null | primary key ]] ...)

Exemple:

CREATE TABLE emp_details( first_name char(15) not null, last_name char(15) not null,

dept char(20),emp_id int primary key,

salary int)

Les types disponibles sont:

• char (len)

• int

• real

La commande DROP(pour mémoire)

Drop permet de détruire une table dans la base:

DROP TABLE table_name

Exemple :

DROP TABLE emp_details



Réf. Sun : LJ300 Date : 20/7/98

2

SQL (et miniSQL)

Exercices

1. Lancer msql sur la base StockMarket . L’animateur doit fournir le

nom de la machine serveur. Afficher toutes les informations

présentes dans les trois tables. Exemple:

% msql -h serveur StockMarket

Welcome to the miniSQL monitor. Type \h for help.

mSQL > select * from Stock > \g

Query OK.

10 rows matched.

+-----------------+--------------+ | symbol | price | +-----------------+--------------+ | SUNW | 68.75 | | CyAs | 22.625 | | DUKE | 6.25 | | ABStk | 18.5 | | JSVCo | 9.125 | | TMAs | 82.375 | | BWInc | 11.375 | | GMEnt | 44.625 | | PMLtd | 203.375 | | JDK | 33.5 | +-----------------+--------------+

mSQL >

2



Réf. Sun : LJ300 Date : 20/7/98

SQL (et miniSQL)

Exercices

2. Créer et exécuter les requêtes suivantes:

✏✏✏✏✏✏✏✏

ATTENTION: ne créer ni détruire aucune table..

a. Afficher toutes les valeurs dont la cote est supérieure à 50.

b. Ajouter dans la base un enregistrement vous décrivant vous-

même..

c. Afficher tous les clients en les triant par ordre alphabétique.

d. Ajouter deux enregistrements dans votre portefeuille et

vérifier si la base a bien tenu compte de votre ordre.

e. Vendez toutes les parts sur une valeur de votre portefeuille et

la moitié des parts sur une autre valeur.

f. Détruisez-vous en tant que client et mettez à jour la table des

portefeuilles.

✓



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC 3

Plan du cours

L’API Java de connectivité des bases de données (JDBC) permet aux

développeurs d’écrire un code d’accès à une base de données, sans

connaître la réalisation concrète de cette base.

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Introduction

LÁPI JDBC contient une série d’interfaces conçues pour permettre au

développeur d’applications qui travaillent sur des bases de données de le

faire indépendamment du type de base utilisé. La connectivité JDBC

permet au développeur de se concentrer sur l’écriture de l’application en

s’assurant que les interrogations de la base de données sont correctes et

que les données sont manipulées conformément à leur conception.

La connectivité JDBC permet au développeur d’écrire une application en

utilisant les noms d’interfaces et les méthodes décrites dans l’API, sans

tenir compte de leur réalisation dans le pilote (driver JDBC). Le

développeur utilise les interfaces décrites dans l’API comme s’il s’agissait

de classes courantes. Le constructeur du pilote fournit une réalisation de

classe pour chaque interface de l’API. Lorsqu’une méthode d’interface est

utilisée, elle se réfère en fait à une instance d’objet d’une classe ayant

réalisé cette interface.

Bibliographie

• Caractéristiques JDBC : http://java.sun.com/products/jdbc

• The Practical SQL Handbook par Emerson, Darnovsky et Bowman

(Editions Addison-Wesley, 1989)



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

“Pilote” JDBC

Chaque pilote de base de données doit fournir une classe réalisant

l’interface java.sql.Driver . Cette classe est alors utilisée par la classe

générique java.sql.DriverManager lorsqu’un pilote est requis pour

assurer la connexion à une base de données spécifique. Cette connexion

s’opère à l’aide d’une URL (identificateur de ressources).

Vous utiliserez COM.imaginary.sql.msql.MsqlDriver 1, un pilote JDBC

écrit pour une connexion à une base de données Mini-SQL2. Le pilote

Imaginary illustre la flexibilité du langage Java.

1. API mSQL-JDBC fournie avec l’aimable autorisation de GeorgeReese.http://www.imaginary.com/~borg

2. Mini SQL fourni avec l’aimable autorisation de Hughes Technologies Pty Ltd,Australie.

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Pilotes JDBC

Pilote B

Application Java

Gestionnaire de pilotes JDBC

Pilote

JDBC-NETPilote A

Possibilités d’implémentation JDBC

Pilote de liaison

JDBC-ODBC

Pilotes ODBCet de bases

(API JDBC)

URL URLURL URL

de données



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Organigramme JDBC

L’enchainement des appels

Du point de vue du programmeur JDBC les tâches s’enchainent de la

manière suivante :

• Création d’une instance d’un driver JDBC.

• détermination de la base

• Ouverture d’une connexion à la base

• Allocation d’un contexte de requête (Statement)

• Soumission d’une requête

• Récupération des résultats

Package java.sql

Huit interfaces sont associées à l’API JDBC :

• Driver

• Connection

• Statement

• PreparedStatement

• CallableStatement

• ResultSet

• ResultSetMetaData

• DatabaseMetaData

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Organigramme JDBC

Chacune de ces interfaces permet à un programmeur d’application

d’établir des connexions à des bases de données spécifiques, d’exécuter

des instructions SQL et de traiter les résultats.

Figure 1-1 Organigramme JDBC

• Une chaîne d’URL est transmise à la méthode getConnection()du gestionnaire de pilotes (DriverManager) qui localise à son

tour un pilote (Driver ).

• Un pilote vous permet d’obtenir une connexion (Connection) .

• Cette connexion vous permet de créer une requête (Statement) .

• Lorsqu’une requête est exécutée avec une méthode

executeQuery() , un résultat (ResultSet) peut être retourné.

✓ Un objet ResultSet est toujours retourné mais il ne contient pas nécessairement dedonnées, c’est-à-dire lorsqu’une mise à jour ou une requête d’insertion est exécutée.

DriverManager

DriverDriver

ConnectionConnection

Statement

ResultSet

Connection

StatementStatementStatement

ResultSetResultSet



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Exemple JDBC

Cet exemple simple utilise la base de données Mini-SQL, ainsi que les

éléments d’une application JDBC. Les opérations réalisées seront les

suivantes : création d’une instance Driver , obtention d’un objet

Connection , création d’un objet Statement et exécution d’une requête,

puis traitement de l’objet retourné ResultSet .

1 import java.sql.*;2 import COM.imaginary.sql.msql.*;34 public class JDBCExample {56 public static void main (String args[]) {78 if (args.length < 1) {9 System.err.println ("Usage:");10 System.err.println (" java JDBCExample <db server hostname>");11 System.exit (1);12 }13 String serverName = args[0];14 try {15 // Create the instance of the Msql Driver16 new MsqlDriver ();1718 // Create the "url"19 String url = "jdbc:msql://" + serverName +20 ":1112/StockMarket";2122 // Use the DriverManager to get a Connection23 Connection mSQLcon = DriverManager.getConnection (url);2425 // Use the Connection to create a Statement object26 Statement stmt = mSQLcon.createStatement ();2728 // Execute a query using the Statement and return a ResultSet29 ResultSet rs = stmt.executeQuery30 "SELECT ssn, cust_name FROM Customer" +31 " order by cust_name");

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Exemple JDBC

32 // Print the results, row by row33 while (rs.next()) {34 System.out.println ("");35 System.out.println ("Customer: " + rs.getString (2));36 System.out.println ("Id: " + rs.getString (1));37 }3839 } catch (SQLException e) {40 e.printStackTrace();41 }42 }43 }

Résultats:

% java JDBCExample serveur

Customer: Tom McGinnId: 999-11-2222

Customer: Jennifer Sullivan VolpeId: 999-22-3333

Customer: Georgianna DG MeagherId: 999-33-4444

Customer: Priscilla MalcolmId: 999-44-5555



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Création de pilotes JDBC

Il existe deux méthodes pour créer une instance de pilote JDBC :

explicitement ou à l’aide de la propriété jdbc.drivers .

Création explicite d’une instance de pilote JDBC

Pour communiquer avec un moteur de base de données particulier en

JDBC, vous devez préalablement créer une instance pour le pilote JDBC.

Ce pilote reste en arrière plan et traite toutes les requêtes pour ce type de

base de données.

// Create an instance of Msql’s JDBC Drivernew MsqlDriver();

Il n’est pas nécessaire d’associer ce pilote à une variable car le pilote est

référencé par un objet statique.

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Création de pilotes JDBC

Chargement des pilotes JDBC via jdbc.drivers

Il est tout à fait possible que plusieurs pilotes de bases de données soient

chargés en mémoire. Il peut également arriver que plusieurs de ces

pilotes, ODBC ou protocoles génériques de réseau JDBC, soient en mesure

de se connecter à la même base de données. Dans ce cas, l’interface JDBC

permet aux utilisateurs de définir une liste de pilotes dans un ordre

spécifique. Cet ordre de sélection est défini par un paramètre de

propriétés Java, jdbc.drivers . La propriété jdbc.drivers doit être

définie sous forme de liste de noms de classes de pilotes, séparés par le

symbole deux points (“:”) :

jdbc.drivers=COM.imaginary.sql.msql.MsqlDriver:Acme.wonder.driver

Les propriétés sont définies par l’option -D de l’interpréteur java (ou

l’option -J de l’application appletviewer ). Exemple :

% java -Djdbc.drivers =COM.imaginary.sql.msql.MsqlDriver:\ Acme.wonder.driver

Lors d’une tentative de connexion à une base de données, l’API JDBC

utilise le premier pilote trouvé susceptible d’établir la connexion à l’URL

défini. L’API essaie tout d’abord chaque pilote défini dans cette

propriétés, dans l’ordre de gauche à droite. Elle essaie ensuite tous les

pilotes déjà chargés en mémoire en respectant l’ordre de chargement. Si le

pilote a été chargé par un code non sécurisé, il est alors ignoré sauf s’il a

été chargé à partir de la même source que le code tentant d’établir la

connexion.



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Pilotes JDBC

Désignation d’une base de données

Après avoir créé l’instance du pilote JDBC, vous devez à présent indiquer

la base de données à laquelle vous souhaitez vous connecter.

Dans JDBC, il vous suffit de spécifier un URL indiquant le type de base de

données. La syntaxe des chaînes d’URL proposée pour une base de

données JDBC est :

jdbc:sous_protocole:parametres

sous_protocole désigne un type spécifique de mécanisme de

connectivité des bases de données, pouvant être supporté par un ou

plusieurs pilotes. Le contenu et la syntaxe de parametres dépendent du

sous-protocole.

// Construct the URL for JDBC accessString url = new String ("jdbc:msql://" + servername

+ ":1112/StockMarket");

Cet URL vous permettra d’accéder à la base de données mSQL

StockMarket à laquelle vous vous connecterez lors des exercices.

serverName est une variable définissant le nom d’hôte du serveur de la

base de données.

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Connexion JDBC

Connexion à une base de données

Après avoir créé un URL définissant msql en tant que moteur de base de

données, vous pouvez à présent établir une connexion à la base de

données.

A cet effet, on doit obtenir un objet java.sql.Connection en appelant la

méthode java.sql.DriverManager.getConnection du pilote JDBC.

// Establish a database connection through the msql// DriverManagerConnection mSQLcon =DriverManager.getConnection(url);

Le processus est le suivant :

• Le gestionnaire de pilotes (DriverManager) appelle la méthode

Driver.getConnection pour chaque pilote enregistré, en

transmettant la chaîne d’URL sous forme de paramètre.

• Si le pilote identifie le nom du sous-protocole, il retourne alors une

instance d’objet Connection ou une valeur nulle le cas échéant.



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Pilotes JDBC

Interrogation d’une base de données

La figure 2-4 décrit la méthode permettant à un gestionnaire de pilotes

(DriverManager ) de traduire une chaîne URL transmise dans la méthode

getConnection (). Lorsque le pilote retourne une valeur nulle, le

gestionnaire appelle le pilote enregistré suivant jusqu’à la fin de la liste ou

jusqu’à ce qu’un objet Connection soit retourné.

Gestionnaire de pilotes

jdbc:A jdbc:B jdbc:msql

Connexion à la

StockMarket

StockMarket

Pilote Pilote

Explication

Le gestionnaire de pilotes appelle

getConnection(URL) qui appelle

driver.connection(URL) pour les pilotes du

vecteur jusqu’à ce qu’une correspondance soit trouvée.

L’URL est analysé (jdbc :drivername).

Lorsque le pilote du vecteur correspond au drivername analysé, une

connexion est établie.

Si le pilote ne correspond pas, la valeur NULL est retournée et le

pilote suivant du vecteur est examiné.

getConnection ( chaîne URL);

ProgrammeChaîne URL

Pilote

base de données

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Instructions JDBC

Soumission d’une requête

Pour soumettre une requête standard, créez tout d’abord un objet

Statement à partir de la méthode Connection.createStatement .

// Create a Statement objecttry { stmt = mSQLcon.createStatement();} catch (SQLException e) { System.out.println (e.getMessage());}

Utilisez la méthode Statement.executeUpdate() pour soumettre un

INSERT,un UPDATEou un DELETE.

// Pass a query via the Statement objectint count = stmt.executeUpdate("DELETE from Customer WHERE ssn=’999-55-6666’");

La méthode Statement.executeUpdate() renvoie un entier qui

représente le nombre d’enregistrements affectés.

Utilisez la méthode Statement.executeQuery() pour soumettre

l’instruction SQL à la base de données. Notez que JDBC transmet

l’instruction SQL à la connexion de base de données sous-jacente sans

modification. JDBC ne tente aucune interprétation des requêtes.

// Pass a query via the Statement objectResultSet rs = stmt.executeQuery("SELECT DISTINCT *

from Customer order by ssn");

La méthode Statement.executeQuery() renvoie un résultat de type

ResultSet pour traitement ultérieur.



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Instructions JDBC

requête préparée (non disponible sous mSQL)

En cas d’exécution répétitive des mêmes instructions SQL, l’utilisation

d’un objet PreparedStatement s’avère intéressante. Une requête préparéeest une instruction SQL précompilée qui est plus efficace qu’une

répétition d’appels de la même instruction SQL. La classe

PreparedStatement hérite de la classe Statement pour permettre le

paramétrage des instructions JDBC. Le code suivant présente un exemple

d’utilisation d’une instruction préformattée :

Exemple

public boolean prepStatement(Reservation obj){PreparedStatement prepStmnt =

msqlConn.prepareStatement( "UPDATE Flights SETnumAvailFCSeats = ? WHERE flightNumber = ?" );

prepStmnt.setInt(1,(Integer.parseInt(obj.numAvailFCSeats) - 1));

prepStmnt.setLong(2, obj.FlightNo);int rowsUpdated = prepStmnt.executeUpdate();return (rowsUpdated > 0) ;

}

Les méthodes setXXX

Les méthodes set XXX de configuration des paramètres SQL IN doivent

indiquer les types compatibles avec le type SQL de paramètre d’entrée

défini. Ainsi, si un paramètre IN est du type SQL Integer, setInt doit

être utilisé.

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Méthodes set XXX

Table 1: Méthodesset XXX et types SQL

Méthode Type(s) SQL

setASCIIStream Utilise une chaîne ASCII pour générer unLONGVARCHAR

setBigDecimal NUMERIC

setBinaryStream LONGVARBINARY

setBoolean BIT

setByte TINYINT

setBytes VARBINARY ou LONGVARBINARY (selon la taillepar rapport aux limites de VARBINARY)

setDate DATE

setDouble DOUBLE

setFloat FLOAT

setInt INTEGER

setLong BIGINT

setNull NULL

setObject L’objet Java défini est converti en type SQLcible avant d’être envoyé

setShort SMALLINT

setString VARCHAR ou LONGVARCHAR (selon la taille parrapport aux limites du pilote sur VARCHAR)

setTime TIME

setTimestamp TIMESTAMP

setUnicodeStream UNICODE



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Instructions JDBC

procédure stockée (non disponible sous mSQL)

Une procédure stockée permet l’exécution d’instructions non SQL dans la

base de données. La classe CallableStatement h érite de la classe

PreparedStatement qui fournit les méthodes de configuration des

paramètres IN . Etant donné que la classe PreparedStatement h érite de

la classe Statement , la méthode de récupération de résultats multiples

par une procédure enregistrée est supportée par la méthode

Statement.getMoreResults .

Ainsi, vous pourriez utiliser une instruction CallableStatement pour

enregistrer une instruction SQL précompilée, vous permettant

d’interroger une base de données contenant les informations sur la

disponibilité des sièges pour un vol particulier.

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Instructions JDBC

Exemple

String planeID = "727";CallableStatement querySeats =msqlConn.prepareCall("{call

return_seats(?, ?, ?, ?)}");try {

querySeats.setString(1, planeID);querySeats.registerOutParameter(2,

java.sql.Type.INTEGER);querySeats.registerOutParameter(3,

java.sql.Type.INTEGER);querySeats.registerOutParameter(4,

java.sql.Type.INTEGER);querySeats.execute();int FCSeats = querySeats.getInt(2);int BCSeats = querySeats.getInt(3);int CCSeats = querySeats.getInt(4);

} catch (SQLException SQLEx){System.out.println("Query failed");SQLEx.printStackTrace();

}

Appel de procédure

Avant d’exécuter un appel de procédure stockée, vous devez

explicitement appeler registerOutParameter pour enregistrer le type

java.sql.Type de tous les paramètres SQL OUT.



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Instructions JDBC

Récupération de résultats

Le résultat de l’exécution d’une instruction peut se présenter sous forme

de table de données accessible via un objet java.sql.ResultSet . Cette

table se compose d’une série de lignes et de colonnes. Les lignes sont

récupérées dans l’ordre. Un objet ResultSet maintient un curseur sur la

ligne de données courante et le positionne tout d’abord sur la première

ligne. Le premier appel de l’instruction next définit la première ligne en

tant que ligne courante, le second appel déplace le curseur sur la seconde

ligne, etc.

L’objet ResultSet fournit une série de méthodes get permettant

d’accéder aux nombreuses valeurs de colonne de la ligne courante. Ces

valeurs peuvent être récupérées à partir du nom de la colonne ou d’un

indice. Il est généralement plus pratique d’utiliser un indice pour

référencer une colonne. Les indices de colonne débutent à 1.

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Instructions JDBC

Réception de résultats (suite)

while (rs.next()) {System.out.println ("Customer: " + rs.getString(2));System.out.println ("Id: " + rs.getString(1));System.out.println ("");

}

Les diverses méthodes get XXX accèdent aux colonnes dans la table de

résultats. Il est possible d’accéder aux colonnes dúne ligne dans

n’importe quel ordre.

Nota: il est possible de découvir dynamiquement des informations sur la

table comme le nombre de champs dans un enregistrement, le type de

chaque champ, etc. Ce type d’information est géré par l’objet

ResultSetMetaData rendu par getMetaData( ) -service non accessible

en mSQL-

Pour récupérer des données extraites de l’objet ResultSet , vous devez

vous familiariser avec les colonnes retournées, ainsi qu’avec les types de

données qu’elles contiennent. La table 2-3 établit une correspondance

entre les types de données Java et SQL.



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Méthodes get XXX

Table 2: Méthodesget XXX et type de données Java retourné

Méthode Type de données Java retourné

getASCIIStream java.io.InputStream

getBigDecimal java.math.BigDecimal

getBinaryStream java.io.InputStream

getBoolean boolean

getByte byte

getBytes byte[]

getDate java.sql.Date

getDouble double

getFloat float

getInt int

getLong long

getObject Object

getShort short

getString java.lang.String

getTime java.sql.Time

getTimestamp java.sql.Timestamp

getUnicodeStream java.io.InputStream de caractères Unicode

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Correspondance des types de données SQL en Java

La table 2-3 présente les types Java standard pour la correspondance avec

divers types SQL courants.

Table 3: Correspondance de types SQL en Java

Type SQL Type Java

CHAR String

VARCHAR String

LONGVARCHAR String (ou Stream)

NUMERIC java.math.BigDecimal

DECIMAL java.math.BigDecimal

BIT boolean

TINYINT byte

SMALLINT short

INTEGER int

BIGINT long

REAL float

FLOAT double

DOUBLE double

BINARY byte[]

VARBINARY byte[]

LONGVARBINARY byte[]

DATE java.sql.Date

TIME java.sql.Time

TIMESTAMP java.sql.Timestamp



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Utilisation de l’API JDBC

En créant une série générique d’interfaces permettant d’établir une

connexion à tout produit de base de données grâce à l’API JDBC, vous

n’êtes limité ni à une base de données spécifique, ni à une architecture

particulière d’accès car plusieurs solutions peuvent être envisagées.

Types de conception des pilotes JDBC

La conception de l’architecture des accès base de données que vous

choisissez d’implanter dépend en partie du pilote JDBC.

• Conception en deux éléments – Utilisant le langage Java vers des

bibliothèques de méthodes natives ou Java vers un protocole de

système de gestion de base de données (SGBD) natif (tous les

codes en Java mais protocole spécifique)

• Conception en trois éléments – Utilisant tous les codes Java dans

lesquels les appels JDBC sont convertis en protocole indépendant

du système SGBD.

• Conception en deux ou trois éléments – Spécialement conçue

pour fonctionner avec les pilotes de bases de données ODBC

(connectivité ouverte aux bases de données Microsoft), dans

lesquels les appels JDBC sont effectués par le biais d’un pilote

ODBC (généralement une librairie spécifique à la plate-forme)

A ce jour, les principaux développements de pilotes de bases de données

ont été réalisés par des constructeurs indépendants, non associés à une

société de fourniture de bases de données. Cette situation est avantageuse

pour le développeur car elle implique que les solutions ne sont

généralement pas privées et que la concurrence régule les prix.

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Types d’architecture d’accès aux bases de données

Conceptions en deux niveaux

Une conception en deux niveaux permet à l’utilisateur de dialoguer avec

une application frontale (client) directement connectée à la base de

données (serveur).

Une application de base de données conçue en deux niveaux peut utiliser

l’un des deux types de pilotes JDBC suivants :

• Pilote sáppuyant sur une API native – Utilise une librairie

(généralement C ou C++) compilée et développée pour

l’équipement spécifique et le système d’exploitation sur lequel

séxécute l’application cliente. Ce type de pilote limite donc le

programme client à une application Java ou une applet (local sur

le disque dur de l’utilisateur) puisque le pilote doit effectuer des

appels de méthodes natives (ou lire des classes présentes sur le

poste client).

• Pilote de protocole natif – Utilise le protocole (en général privé)

spécifique, fourni par le constructeur de la base de données. Cela

signifie que le serveur du constructeur de base de données

contient une application de réception TCP/IP acceptant les

connexions de plusieurs applications clients. Le client utilise un

protocole spécifié par le constructeur de base de données pour

communiquer les requêtes et retourner les résultats.



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Types d’architecture d’accès aux bases de données

Conceptions en trois niveaux

Les conceptions intègrent un processus intermédiaire entre l’application

finale et le serveur de base de données. Bien que cette conception semble

augmenter le temps système, elle présente néanmoins plusieurs

avantages:

• La validation des données est transférée au middleware (le niveau

intermédiaire).

• Le client peut accéder à plusieurs bases de données par le biais

d’une seule connexion par socket. Il devient donc possible d’écrire

l’application client sous forme d’applet, téléchargé à partir d’un

browser.

• Le protocole client/middleware est défini par le constructeur et

dépend du SGBD. L’opération de connexion à la base de données

est donc transférée du client au middleware.

• Le middleware peut inclure des fonctions non offertes par une ou

plusieurs bases de données, telles que le verrouillage

d’enregistrements ou la notification de modification

d’enregistrement.

Les applications d’accès aux bases de données conçues en deux ou trois

niveaux peuvent utiliser un pilote entièrement rédigé en Java. Dans ce

cas, le pilote JDBC traduit les appels en protocole middleware. Le

middleware est alors chargé de sélectionner la base de données adéquate.

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Applets

L’applet Java a constitué l’utilisation la plus médiatique de la plate-forme

Java. L’interface JDBC peut être intégrée dans des applets pour rendre la

base de données accessible au World Wide Web (WWW). Ainsi, un

utilisateur peut télécharger un applet Java capable d’afficher les vols

disponibles à une date définie, en partance et à l’arrivée de destinations

spécifiées. Cet applet pourrait accéder à une base de données relationnelle

via Internet, pour permettre à un client de se renseigner sur les places non

réservées, d’effectuer une réservation ou une mise à jour de la base.

Les applets peuvent également être utilisées dans un scénario intranet

pour fournir l’accès aux bases de données de la compagnie, telles qu’un

répertoire d’entreprise, dans lesquelles plusieurs services travaillent sur

différentes plates-formes matérielles, mais requièrent une interface de

base de données commune.

Applets et applications de bases de données traditionnelles

Il existe plusieurs différences entre les applets et les applications de bases

de données traditionnelles :

• Les applets non sécurisées sont soumises à de sévères contraintes

dans les opérations quélles désirent effectuer. Dans la majorité des

cas, il est interdit aux Applets non sécurisées d’accéder aux fichiers

locaux et il leur est impossible d’établir une connexion de réseau

sur une station différente de celle ayant fourni l’applet.

• Les applets présentes sur Internet ne peuvent pas connaitre

lémplacement de base de données locale ou du pilote de base se

trouvant dans un fichier local de la machine client, comme dans

ODBC.

Performances

Les performances relatives aux implémentations de connectivité diffèrent

selon que la base de données se trouve ou non sur le réseau. Le temps de

réponse d’une applet de base de données Internet sera très supérieur à

celui d’une applet de réseau local.



Réf. Sun : LJ300 Date : 20/7/98

3

rappels: API JDBC

Applets

Contraintes de sécurité

Certaines contraintes de sécurité rencontrés avec des applets non

sécurisés peuvent apparaître lors de l’utilisation d’une signature digitale

ou d’un scénario à clé cryptographique. Dans ce cas, une applet est traitée

comme une application au sens sécuritaire, mais il subsistera toujours des

problèmes entre les bases de données du client en raison de la difficulté à

localiser la structure de répertoire de la base de données ou du pilote de

base de données.

Comme nous l’avons vu précédemment une conception d’accès à la base

de données en trois niveaux peut fournir un middleware de service sur le

réseau. La mise en place de middleware permet d’accéder aux bases de

données sur plusieurs hôtes reliés en réseau. Ces appels pourraient être

effectués par le biais d’invocations de procédures à distance (RPC) ou

d’un navigateur de requête d’objet (ORB). Dans chaque cas, un paradigme

d’objet permet de définir au mieux le middleware (exemple : “objets

client” avec opérations pour la facturation des clients, les réservations et

autres transactions).

3



Réf. Sun : LJ300 Date : 20/7/98

rappels: API JDBC

Evolutions

La programmation JDBC reste une programmation, parfois fastidieuse, de

relativement bas niveau.

La pratique de l’accès Java aux bases de données s’orientera à l’avenir

vers des APIs de plus haut niveau permettant de gérer automatiquement

les couches “basses” de l’accès aux bases de données à partir de la

définition de classes JAVA.

JAVA BLEND est un tel ensemble d’outils et d’API qui s’appuie du JDBC

et sur JTS (Java Transaction Service : API d’accès aux services

transactionnels).



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT 4

Objectifs

Rappels sur :

• Les interactions graphiques: composants, méthodes graphiques

• Les LayoutManager s

• La gestion des événements

• Les composants les plus courants

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Accès au manipulations graphiques

Le package AWT

Le package AWT fournit les objets pour accéder aux services du terminal

virtuel portable.

Une notion fondamentale dans ce package est la hiérarchie Component(un objet graphique) et Container (dérivé du précédent: on peut

disposer plusieurs Component s DANS un Container )

Exemples de Container : Frame (une fenêtre), Panel (un "panneau") et

son dérivé particulier qu’est l’Applet .

Exemples de Component : Button , Label (un étiquette), TextField(une zone de saisie Texte), Canvas (zone de dessin graphique).

On peut faire des opérations graphiques sur certains composants en

agissant sur le comportement des méthodes de rafraîchissement d’image:

• repaint () -demande asynchrone de remise à jour de l’imaged’affichage-,

• update (Graphics gr) -effacement du contexte graphique(Graphics ) et appel des opérations de dessin-,

• paint (Graphics gr) -réalisation effective du dessin-

Les primitives graphiques de dessin sont liées à la classe Graphics

Les primitives graphiques peuvent être utilisées pour "décorer" des

composants d’un type prédéfini ou même pour créer des "Composants

poids-plume" en agissant sur des objets créés en sous-classant directement

Component ou Container. De tels objets graphiques sont initialement

transparents et ne sont pas associés à des objets natifs du système de

fenêtrage local, il faut gérer par programme l’ensemble de leur

comportement (aspects , événements).

De tels objets constituent l’essentiel de bibliothèques d’objets d’interaction

comme les JFC (JAVA Foundation Classes)



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Les gestionnaires de Disposition (LayoutManager)

Un des points forts de JAVA est de permettre de faire exécuter le même

programme sur des plateformes différentes sans en modifier le code. Pour

les interactions graphiques une des conséquences de cette situation est

qu’un même programme va devoir s’afficher sur des écrans ayant des

caractéristiques très différentes. On ne peut donc raisonnablement

s’appuyer sur un positionnement des composants en absolu (avec des

coordonnées X et Y fixes).

La disposition relative des différents composants à l’intérieur d’un

Container sera prise en charge par un "gestionnaire de disposition"

attaché à ce container. Ce LayoutManager va savoir gérer les positions

des composants en fonctions des déformations subies par le Containercorrespondant.

A chaque Container est associé une liste des composants contenus.

Attention une instance de composant ne peut être disposée qu’à UN

SEUL endroit (il ne sert à rien de faire plusieurs opérations add() avec le

même composant -sauf si on veut explicitement le faire changer de zone

d’affichage-)

Quelques gestionnaires standard :

1. FlowLayout : dispose les composants "en ligne". C’est le

gestionnaire par défaut des Panel s.

panneau.add(new Button("bouton 1")) ;panneau.add(new Button("bouton 2")) ;

2. BorderLayout : dispose des zones dans des points cardinaux

autour d’une zone centrale qui tend à occuper la plus large place

possible. C’est le gestionnaire par défaut des Frames.

Panel panCentral = new Panel() ;Panel panBas = new Panel() ;

fenêtre.add(panCentral, BorderLayout.CENTER);fenêtre.add(panBas, BorderLayout.SOUTH);

panBas.add(new Button("OK")); // ici Flowlayout

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

3. CardLayout : permet de disposer des composants dans une "pile"

seul le composant du dessus est visible et on dispose de méthodes

spéciales pour faire passer un composant particulier sur le

"dessus" de la pile.

4. GridBagLayout : dispose les composants à l’intérieur des

"cellules" d’une table. Chaque ligne ou colonne de la table peut

avoir des dimensions différentes de celles des autres lignes ou

colonnes (quadrillage irrégulier).

Les paramètres controlant la mise en place d’un composant

particulier sont décrits par une instance de la classe

GridBagConstraints (on peut utiliser sans risque la même

instance pour plusieurs composants)

Component[][] tbComp = {.{...}, {...},...} ;this.setLayout(new GridBagLayout()) ;GridBagConstraints parms = new GridBagConstraints();parms.anchor=GridBagConstraints.WEST;parms.weightx=parms.weighty=1.0 ;for( iy= 0; iy <tbComp.length; iy++) {

parms.gridy= iy ;for (ix= 0; ix < tbComp[iy].length; ix++){

parms.gridx= ix ; this.add(tbcomp[iy][ix], parms);

}}

a. gridx, gridy : donne les coordonnées x, y de l’objet dans la grille

(celle-ci déduit automatiquement son propre nombre de lignes

et de colonnes)

b. gridwidth, gridheight : nombre de cellules occupées par le

composant

c. fill : direction du remplissage (le composant tend alors à

occuper toute sa cellule dans la direction donnée). Valeurs:

NONE, BOTH, VERTICAL, HORIZONTAL

d. anchor: lorsqu’un composant est plus petit que sa cellule, bord

d’ancrage du composant (un point cardinal: EAST,

NORTHEAST, etc..)

e. insets: détermination des "goutières" (distance minimum entre

le composant et les frontières de sa cellule)

f. weightx,weighty : "poids" relatif de la cellule (valeur entre 0 et 1)



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Les événements

Lorsque l’utilisateur effectue une action au niveau de l’interface

utilisateur, un événement est émis. Les événements sont des objets qui

décrivent ce qui s’est produit. Il existe différents types de classes

d’événements pour décrire des catégories différentes d’actions utilisateur.

Evénements sources

Un événement source (au niveau de l’interface utilisateur) est le résultat

d’une action utilisateur sur un composant AWT. A titre d’exemple, un clic

de la souris sur un composant bouton génère (source) un ActionEvent.

L’ActionEvent est un objet (une instance de la classe) contenant des

informations sur le statut de l’événement :

● ActionCommand : nom de commande associé à l’action.

● modifiers : tous modificateurs mobilisés au cours de l’action.

Traitements d’événements

Lorsqu’un événement se produit, ce dernier est reçu par le composant

avec lequel l’utilisateur interagit (par exemple un bouton, un curseur, un

textField, etc.). Un traitement d’événement est une méthode qui reçoit un

objet Event de façon à ce que le programme puisse traiter l’interaction de

l’utilisateur.

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Modèle d’événements JDK 1.1

Modèle de délégation (JDK 1.1)

JDK 1.1 a introduit un nouveau modèle d’événement appelé modèle

d’événement par délégation. Dans un modèle d’événement par

délégation, les événements sont envoyés au composant, mais c’est à

chaque composant d’enregistrer une routine de traitement d’événement

(appelé veilleur: Listener ) pour recevoir l’événement. De cette façon, le

traitement d’événement peut figurer dans une classe distincte du

composant. Le traitement de l’événement est ensuite délégué à une classe

séparée.

Applet

Panel

Bouton

Panel et Applet

Traitements d’événements

événement action

....}

Traitement d’actio

actionPerformed(ActionEvent



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

modèle d’événements JDK 1.1

Les événements sont des objets qui ne sont renvoyés qu’aux veilleurs

enregistrés. A chaque type d’événement est associé une interface d’écoute

correspondante.

A titre d’exemple, voici un cadre simple comportant un seul bouton :

import java.awt.*;public class TestButton {

public static void main (String args[]){Frame f = new Frame ("Test");Butto n b = new Button("Press Me!");b.addActionListener(new ButtonHandler());f.add(b, BorderLayout.CENTER);f.pack();f.setVisible(true);

}}

La classe ButtonHandler défini une instance de traitement de l’événement

.

import java.awt.event.*;public class ButtonHandler implements

ActionListener{public void actionPerformed(ActionEvent e) {

System.out.println("Action occured");}

}

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Modèle d’événements JDK 1.1

Modèle de délégation (JDK 1.1) (suite)

• La classe Button comporte une méthode

addActionListener(ActionListener) .

• L’interface ActionListener définit une méthode simple,

actionPerformed qui recevra un ActionEvent .

• Lorsqu’un objet de la classe Button est créé, l’objet peut

enregistrer un veilleur pour les ActionEvent par l’intermédiaire

de la méthode addActionListener , en précisant la classe d’objets

qui implémente l’interface ActionListener .

• Lorsque l’on clique sur l’objet Bouton avec la souris, un

ActionEvent est envoyé à chaque ActionListener enregistré par

l’intermédiaire de la méthode actionPerformed (ActionEvent) .



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

modèle d’événements JDK 1.1

Modèle de délégation (JDK 1.1) (suite)

Cette approche présente plusieurs avantages :

• Il est possible de créer des classes de filtres pour classifier les

événements .

• Le modèle de délégation est plus adapté à la répartition du travail

entre les classes.

• Le nouveau modèle d’événement supporte Java BeansTM.

Certains problèmes/inconvénients du modèle méritent également d’être

considérés :

• Il est plus difficile à comprendre, au moins au départ.

• Le passage du code JDK 1.0 au code JDK 1.1 est compliqué.

• Bien que la version actuelle de JDK gère le modèle d’événement

JDK 1.0 en plus du modèle de délégation, les modèles

d’événements JDK 1.0 et JDK 1.1 ne peuvent pas être mélangés.

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Comportement de l’interface graphique utilisateur Java

Catégories d’événements

Le mécanisme général de réception des événements à partir de

composants a été décrit dans le contexte d’un seul type d’événement.

Plusieurs événements sont définis dans le package java.awt.event , et

des composants tiers peuvent s’ajouter à cette liste.

Pour chaque catégorie d’événements, il existe une interface qui doit être

implémentée par toute classe souhaitant recevoir ces événements. Cette

interface exige aussi qu’une ou plusieurs méthodes soient définies. Ces

méthodes sont appelées lorsque des événements particuliers surviennent.

Le tableau de la page suivante liste les catégories et indique le nom de

l’interface correspondante ainsi que les méthodes associées. Les noms de

méthodes sont des mnémoniques indiquant les conditions générant

l’appel de la méthode.

On remarquera qu’il existe des événements de bas niveau (une touche est

pressée, on clique la souris) et des événements abstraits de haut niveau

(Action = sur un bouton on a cliqué, sur un TextField on a fait un <retour

chariot>, ...)



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Tableaux

Category Interface Name Methods

Action ActionListener actionPerformed(ActionEvent)

Item ItemListener itemStateChanged(ItemEvent)

Mouse Motion MouseMotionListener mouseDragged(MouseEvent)mouseMoved(MouseEvent)

Mouse MouseListener mousePressed(MouseEvent)mouseReleased(MouseEvent)mouseEntered(MouseEvent)mouseExited(MouseEvent)mouseClicked(MouseEvent)

Key KeyListener keyPressed(KeyEvent)keyReleased(KeyEvent)keyTyped(KeyEvent)

Focus FocusListener focusGained(FocusEvent)focusLost(FocusEvent)

Adjustement AdjustmentListener

adjustementValueChanged(AdjustementEvent)

Component ComponentListener componentMoved(ComponentEvent)componentHidden(ComponentEvent)componentResize(ComponentEvent)componentShown(ComponentEvent)

Window WindowListener windowClosing(WindowEvent)windowOpened(WindowEvent)windowIconified(WindowEvent)windowDeiconified(WindowEvent)windowClosed(WindowEvent)windowActivated(WindowEvent)windowDeactivated(WindowEvent)

Container ContainerListener componentAdded(ContainerEvent)componentremoved(ContainerEvent)

Text TextListener textValueChanged(TextEvent)

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT


Evénements générés par composants AWT

Table 4:

Composant AWT

Action adju

st

component

containe

r

focus

item keymouse

mouse

motion

textwindow

Button ● ● ● ● ● ●

Canvas ● ● ● ● ●

Checkbox ● ● ● ● ● ●

CheckboxMenuItem ●

Choice ● ● ● ● ● ●

Component ● ● ● ● ●

Container ● ● ● ● ● ●

Dialog ● ● ● ● ● ● ●

Frame ● ● ● ● ● ● ●

Label ● ● ● ● ●

List ● ● ● ● ● ● ●

MenuItem ●

Panel ● ● ● ● ● ●

Scrollbar ● ● ● ● ● ●

ScrollPane ● ● ● ● ● ●

TextArea ● ● ● ● ● ●

TextComponent ● ● ● ● ● ●

TextField ● ● ● ● ● ● ●

Window ● ● ● ● ● ● ●



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT


Obtention d’informations sur un événement

Lorsque les méthodes de traitement, telles que mouseDragged() sont

appelées, elles reçoivent un argument qui peut contenir des informations

importantes sur l’événement initial. Pour savoir en détail quelles

informations sont disponibles pour chaque catégorie d’événement,

reportez-vous à la documentation relative à la classe considérée dans le

package java.awt.event .

Récepteurs multiples

La structure d’écoute des événements AWT permet actuellement

d’associer plusieurs veilleurs au même composant. En général, si on veut

écrire un programme qui effectue plusieurs actions basées sur un même

événement, il est préférable de coder ce comportement dans la méthode

de traitement.

Cependant, la conception d’un programme exige parfois que plusieurs

parties non liées du même programme réagissent au même événement.

Cette situation peut se produire si, par exemple, un système d’aide

contextuel est ajouté à un programme existant.

Le mécanisme d’écoute permet d’appeler une méthode add*Listeneraussi souvent que nécessaire en spécifiant autant d’écouteurs différents

que la conception l’exige. Les méthodes de traitement de tous les

écouteurs enregistrés sont appelées lorsque l’événement survient.

✏✏✏✏✏✏✏✏

L’ordre d’appel des méthodes de traitement n’est pas défini. En général, si

cet ordre a une importance, les méthodes de traitement ne sont pas liées et

on ne doit pas utiliser cette fonction pour les appeler. Au lieu de cela, il

faut enregistrer simplement le premier écouteur et faire en sorte qu’il

appelle directement les autres. C’est ce qu’on appelle un multiplexeur

d’événements

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Adaptateurs d’événements

Il est évident que la nécessité d’implanter toutes les méthodes de chaque

interface d’écouteur représente beaucoup de travail, en particulier pour

les interfaces MouseListener et ComponentListener.

A titre d’exemple, l’interface MouseListener définit les méthodes

suivantes :

• mouseClicked (MouseEvent)

• mouseEntered (MouseEvent)

• mouseExited (MouseEvent)

• mousePressed (MouseEvent)

• mouseReleased(MouseEvent)

Pour des questions pratiques, Java fournit une classe d’adaptateurs pour

pratiquement chaque interface de veiller, cette classe implante l’interface

appropriée, mais ne définit pas les actions associées à chaque méthode.

De cette façon, la routine d’écoute que l’on définit peut hériter de la classe

d’adaptateurs et ne surcharger que des méthodes choisies.



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Adaptateurs d´événements

Par exemple :

import java.awt.*;import.awt.event.*;

public class MouseClickHandler extends MouseAdapter {

//Nous avons seulement besoin du traitement mouseClick, //nous utilisons donc l’adaptateur pour ne pas avoir à //écrire toutes les méthodes de traitement d’événement

public void mouseClicked (MouseEvent e) { //Faire quelque chose avec le clic de la souris . . . }}

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Les composants :

Button

C’est un composant d’interface utilisateur de base de type "appuyer pour

activer". Il peut être construit avec une étiquette de texte précisant son

rôle .

Button b = new Button(“Sample”);add(b);b.addActionListener(this);

L’interface ActionListener doit pouvoir traiter un clic d’un bouton de

souris. La méthode getActionCommand() de l’événement action

(ActionEvent ) activé lorsqu’on appuie sur le bouton rend par défaut la

chaîne de l’étiquette.



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Checkbox

La case à cocher fournit un dispositif d’entrée "actif/inactif" accompagné

d’une étiquette de texte.

Checkbox one = new Checkbox("One", false);Checkbox two = new Checkbox("Two", false);Checkbox three = new Checkbox("Three", true);add(one);add(two);add(three);one.addItemListener(new Handler());two.addItemListener(new Handler());three.addItemListener(new Handler());

La sélection ou désélection d’une case à cocher est notifiée à la réalisation

de l’interface ItemListener . Pour détecter une opération de sélection ou

de déselection, il faut utiliser la méthode getStateChange() sur l’objet

ItemEvent . Cette méthode renvoie l’une des constantes

ItemEvent.DESELECTED ou ItemEvent.SELECTED , selon le cas. La

méthode getItem() renvoie un objet de type chaîne (String ) qui

représente la chaîne de l’étiquette de la case à cocher considérée.

class Handler implements ItemListener {public void itemStateChanged(ItemEvent ev) {

String state = “deselected”;if (ev.getStateChange() == ItemEvent.SELECTED){

state = “selected”;}System.out.println(ev.getItem() + “ “ + state);

}}

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

CheckboxGroup

On peut créer des cases à cocher à l’aide d’un constructeur spécial qui

utilise un argument supplémentaire CheckboxGroup. Si on procéde ainsi,

l’aspect des cases à cocher est modifié et toutes les cases à cocher liées au

même groupe adoptent un comportement de "bouton radio".

CheckboxGroup cbg = new CheckboxGroup();Checkbox one = new Checkbox("One", cbg, false);Checkbox two = new Checkbox("Two", cbg, false);Checkbox three = new Checkbox("Three", cbg, true);add(one);add(two);add(three);



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Choice

Le composant Choice fournit une outil simple de saisie de type

"sélectionner un élément dans cette liste".

Choic e c = new Choice();c.addItem("First");c.addItem("Second");c.addItem("Third");c.addItemListener(. . .);

Lorsqu’un composant Choice est activé il affiche la liste des éléments qui

lui ont été ajoutés. Notez que les éléments ajoutés sont des objets de type

chaîne (String ).

L’interface ItemListener sert à observer les modifications de ce choix.

Les détails sont les mêmes que pour la case à cocher. La méthode

getSelectedIndex() de Choice permet de connaître l’index

selectionné.

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

List

Une liste permet de présenter à l’utilisateur des options de texte affichées

dans une zone où plusieurs éléments peuvent être visualisés

simultanément. Il est possible de naviguer dans la liste et d’y sélectionner

un ou plusieurs éléments simultanément (mode de sélection simple ou

multiple).

List l = new List(4, true);

L’argument numérique transmis au constructeur définit le nombre d’items

visibles. L’argument booléen indique si la liste doit permettre à

l’utilisateur d’effectuer des sélections multiples.

Un ActionEvent , géré par l’intermédiaire de l’interface

ActionListener, est généré par la liste dans les modes de sélection

simple et multiple. Les éléments sont sélectionnés dans la liste

conformément aux conventions de la plate-forme. Pour un environnement

Unix/Motif, cela signifie qu’un simple clic met en valeur une entrée dans

la liste, mais qu’un double-clic déclenche l’action correspondante.

Récupération: voir méthodes getSelectedObjects(),getSelectedItems( )



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Canvas

Un canvas fournit un espace vide (arrière-plan coloré). Sa taille par défaut

étant zéro par zéro, on doit généralement s’assurer que le gestionnaire de

disposition lui affectera une taille non nulle.

Cet espace peut être utilisé pour dessiner, recevoir du texte ou des saisies

en provenance du clavier ou de la souris.

Le canvas est généralement utilisé tel quel pour fournir un espace de

dessin général.

Le canvas peut écouter tous les événements applicables à un composant

général. On peut, en particulier, lui associer des objets KeyListener ,

MouseMotionListener ou MouseListener pour lui permettre de

répondre d’une façon ou d’une autre à une interaction utilisateur.

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Label

Un label affiche une seule ligne de texte. Le programme peut modifier le

texte. Aucune bordure ou autre décoration particulière n’est utilisée pour

délimiter un label.

Label lab = new Label(“Hello”);add(lab);

En général, on ne s’attend pas à ce que les Labels traitent des

événements, pourtant ils effectuent cette opération de la même façon

qu’un canvas. Dans ce cas, on ne peut capter les activations de touches de

façon fiable qu’en faisant appel à requestFocus() .

MaFrame



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

TextArea

La zone de texte est un dispositif de saisie de texte multi-lignes, multi-

colonnes. On peut le rendre non éditable par l’intermédiaire de la

méthode setEditable(boolean) . Il affiche des barres de défilement

horizontales et verticales.

TextAre a t = new TextArea(“Hello!”, 4, 30);add(t);

On peut ajouter des veilleurs d’événements de divers type dans une zone

de texte.

Le texte étant multi-lignes, le fait d’appuyer sur <Entrée> place seulement

un autre caractère dans la mémoire tampon. Si on a besoin de savoir à

quel moment une saisie est terminée, on peut placer un bouton de

validation à côté d’une zone de texte pour permettre à l’utilisateur de

fournir cette information.

Un veilleur KeyListener permet de traiter chaque caractère entré en

association avec la méthode getKeyChar(), getKeyCode() de la classe

KeyEvent .

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

TextField

Le TextField est un dispositif de saisie de texte sur une seule ligne.

TextFiel d f = new TextField(“Single line”, 30);add(f);

Du fait qu’une seule ligne est possible, un écouteur d’action

(ActionListener ) peut être informé, via actionPerformed() , lorsque la

touche <Entrée> ou <Retour> est activée.

Comme la zone de texte, le champ texte peut être en lecture seule. Il

n’affiche pas de barres de défilement dans l’une ou l’autre direction mais

permet, si besoin est, un défilement de gauche à droite d’un texte trop

long.

TextComponent

La classe TextComponent dont dérivent TextField et TextArea fourni

un grand nombre de méthodes.

On a vu que les constructeurs des classes TextArea et TextFieldpermettent de définir un nombre de colonnes pour l’affichage. Le nombre

de colonnes est interprété en fonction de la largeur moyenne des

caractères dans la police utilisée. Le nombre de caractères effectivement

affichés peut varier radicalement en cas d’utilisation d’une police à chasse

proportionnellel.



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Frame

C’est la fenêtre générale de "plus haut niveau". Elle possède des attributs

tels que : barre de titre et zones de contrôle du redimensionnement.

Frame f = new Frame(“Frame”);

La taille d’un Frame peut être définie à l’aide de la méthode setSize()ou avec la méthode pack() . Dans ce cas le gestionnaire de disposition

calcule une taille englobant tous les composants du Frame et définit la

taille de ce dernier en conséquence.

Les événements du Frame peuvent être surveillés à l’aide de tous les

gestionnaires d’événements applicables aux composants généraux.

WindowListener peut être utilisé pour réagir, via la méthode

windowClosing() , lorsque le bouton Quit a été activé dans le menu du

gestionnaire de fenêtres.

Il n’est pas conseillé d’écouter des événements clavier directement à partir

d’un Frame . Bien que la technique décrite pour les composants de type

Canvas et Label , à savoir l’appel de requestFocus() , fonctionne

parfois, elle n’est pas fiable. Si on a besoin de suivre des événements

clavier, il est plutôt recommandé d’ajouter au Frame un Canvas , Panel ,

etc., et d’associer le gestionnaire d’événement à ce dernier.

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Panel

C’est le conteneur de base. Il ne peut pas être utilisé de façon isolée

comme les Frames, les fenêtres et les boîtes de dialogue.

Panel p = new Panel();

Les Panels peuvent gérer les événements (rappel : le focus clavier doit

être demandé explicitement).



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Dialog

Un Dialog est une fenêtre qui diffère toutefois d’un Frame :

• elle est destinée à afficher des messsages fugitifs

• elle peut être modale: elle recevra systématiquement toutes les

saisies jusqu’à fermeture.

• elle ne peut-être supprimée ou icônifiée par les boutons du

gestionnaire de fenêtre, on lui associe habituellement un bouton

de validation.

Dialo g d = new Dialog(f, "Dialog", false);d.add(new Label("Hello, I'm a Dialog"),

BorderLayout.CENTER);d.pack();

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Dialog

Un dialog dépend d’une Frame : cette Frame apparait comme premier

argument dans les constructeurs de la classe Dialog .

Les boîtes de dialogue ne sont pas visibles lors de leur création.Elles

s’affichent plutôt en réponse à une autre action au sein de l’interface

utilisateur, comme le fait d’appuyer sur un bouton.

public void actionPerformed(ActionEvent ev) {d.setVisible(true);

}

✏✏✏✏✏✏✏✏

Il est recommandé de considérer une boîte de dialogue comme un

dispositif réutilisable. Ainsi, vous ne devez pas détruire l’objet individuel

lorsqu’il est effacé de l’écran, mais le conserver pour une réutilisation

ultérieure.

Pour masquer une boîte de dialogue, appelez setVisible(false) . Cette

opération s’effectue généralement en ajoutant un WindowListener , et en

attendant que la méthode windowClosing() soit appelée dans ce

gestionnaire d’événement.



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

FileDialog

C’est une implantation d’un dispositif de sélection de fichier. Elle

comporte sa propre fenêtre autonome et permet à l’utilisateur de

parcourir le système de fichiers et de sélectionner un fichier spécifique

pour des opérations ultérieures.

FileDialo g d = new FileDialog(f, "FileDialog");d.setVisible(true);String fname = d.getFile();

En général, il n’est pas nécessaire de gérer des événements à partir de la

boîte de dialogue de fichiers. L’appel de setVisible(true) se bloque

jusqu’à ce que l’utilisateur sélectionne OK. Le fichier sélectionné est

renvoyé sous forme de chaîne .Voir getDirectory(), getFile( )

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

ScrollPane

Fournit un conteneur général ne pouvant pas être utilisé de façon

autonome. Il fournit une vue sur une zone plus large et des barres de

défilement pour manipuler cette vue.

Frame f = new Frame("ScrollPane");Panel p = new Panel();ScrollPane sp = new ScrollPane();p.setLayout(new GridLayout(3, 4));sp.add(p);f.add(sp);f.setSize(200, 200);f.setVisible(true);

Le ScrollPane crée et gère les barres de défilement selon les besoins. Il

contient un seul composant et on ne peut pas influer sur le gestionnaire

de disposition qu’il utilise. Au lieu de cela, on doit lui ajouter un Panel,

configurer le gestionnaire de disposition de ce Panel et placer les

composants à l’intérieur de ce dernier.

En général, on ne gère pas d’événements dans un ScrollPane , mais on

le fait dans les composants qu’il contient.



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Menus

Les menus diffèrent des autres composants par un aspect essentiel. En

général, on ne peut pas ajouter de menus à des conteneurs ordinaires et

laisser le gestionnaire de disposition les gérer. On peut seulement ajouter

des menus à des éléments spécifiques appelés conteneurs de menus.

Généralement, on ne peut démarrer une "arborescence de menu" qu’en

plaçant une barre de menus dans un Frame via la méthode

setMenuBar() . A partir de là, on peut ajouter des menus à la barre de

menus et incorporer des menus ou éléments de menu à ces menus.

L’exception est le menu PopUpMenu qui peut être ajouté à n’importe quel

composant, mais dans ce cas précis, il n’est pas question de disposition à

proprement parler.

Menu Aide

Une caractéristique particulière de la barre de menus est que l’on peut

désigner un menu comme le menu Aide. Cette opération s’effectue par

l’intermédiaire de la méthode setHelpMenu(Menu) . Le menu à considérer

comme le menu Aide doit avoir été ajouté à la barre de menus, et il sera

ensuite traité de la façon appropriée pour un menu Aide sur la plate-

forme locale. Pour les systèmes de type X/Motif, cela consiste à décaler

l’entrée de menu à l’extrémité droite de la barre de menus.

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

MenuBar

C’est la barre de menu horizontale. Elle peut seulement être ajouté à

l’objet Frame et constitue la racine de toutes les arborescences de menus.

Frame f = new Frame(“MenuBar”);MenuBar mb = new MenuBar();f.setMenuBar(mb);

MenuBar

MenuItem MenuItem

Menu Menu



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Menu

La classe Menu fournit le menu déroulant de base. Elle peut être ajoutée à

une barre de menus ou à un autre menu.

MenuBar mb = new MenuBar();Menu m1 = new Menu("File");Menu m2 = new Menu("Edit");Menu m3 = new Menu("Help");mb.add(m1);mb.add(m2);mb.add(m3);mb.setHelpMenu(m3);

✏✏✏✏✏✏✏✏

Les menus présentés ici sont vides ce qui explique l’aspect du menu File.

On peut ajouter un ActionListener à un objet Menu, mais c’est assez

inhabituel. Normalement, les menus servent seulement à disposer des

MenuItem décrits plus loin.

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

MenuItem

Les éléments de menu MenuItem sont les “feuilles” d’une arborescence

de menu.

Menu m1 = new Menu("File");MenuItem mi1 = new MenuItem("Save");MenuItem mi2 = new MenuItem("Load");MenuItem mi3 = new MenuItem("Quit");m1.add(mi1);m1.add(mi2);m1.addSeparator();m1.add(mi3);

En règle générale, on ajoute un ActionListener aux objets MenuItemafin d’associer des comportements aux menus.



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

CheckboxMenuItem

Les éléments de menu à cocher permettent de proposer des sélections

(activé/désactivé) dans les menus.

Menu m1 = new Menu("File");MenuItem mi1 = new MenuItem("Save");CheckboxMenuItem mi2 =

new CheckboxMenuItem("Persistent");m1.add(mi1);m1.add(mi2);

L’élément de menu à cocher doit être surveillé via l’interface ItemListener.

C’est pourquoi la méthode itemStateChanged() est appelée lorsque l’état

de l’élément à cocher est modifié.

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

PopupMenu

Fournit un menu autonome pouvant s’afficher instantanément sur un

autre composant. On peut ajouter des menus ou éléments de menu à un

menu instantané.

Frame f = new Frame("PopupMenu");Butto n b = new Button("Press Me");b.addActionListener(...);

PopupMenu p = new PopupMenu("Popup");MenuIte m s = new MenuItem("Save");MenuIte m l = new MenuItem("Load");

s.addActionListener(...);l.addActionListener(...);

f.add("Center", b);p.add(s);p.add(l);f.add(p);



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

PopupMenu (suite)

✏✏✏✏✏✏✏✏

Le menu PopUp doit être ajouté à un composant "parent". Cette opération

diffère de l’ajout de composants ordinaires à des conteneurs. Dans

l’exemple suivant, le menu instantané a été ajouté au Frame englobant.

Pour provoquer l’affichage du menu instantané, on doit appeler la

méthode show. L’affichage nécessite qu’une référence à un composant

joue le rôle d’origine pour les coordonnées x et y.

Dans cet exemple c’est le composant b qui sert de référence.

public void actionPerformed(ActionEvent ev) {p.show(b, 10, 10);

}

✏✏✏✏✏✏✏✏

Le composant d’origine doit être sous (ou contenu dans) le composant

parent dans la hiérarchie des composants.

Coordonnées % composantes

d’origines

Composant de référence pour

l’affichage du popup menu

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Contrôle des aspects visuels

On peut contrôler l’apparence des composants AWT en matière de

couleur de fond et de premier plan ainsi que de police utilisée pour le

texte.

Couleurs

Deux méthodes permettent de définir les couleurs d’un composant :

• setForeground(...)

• setBackground(...)

Ces deux méthodes utilisent un argument qui est une instance de la classe

java.awt.Color . On peut utiliser des couleurs de constante désignées

par Color.red Color.blue etc. La gamme complète de couleurs

prédéfinies est documentée dans la page relative à la classe Color .

Qui plus est, on peutcréer une couleur spécifique de la façon suivante :

int r = 255, g = 255, b = 0;Color c = new Color(r, g, b);

Un tel constructeur crée une couleur d’après les intensités de rouge, vert

et bleu spécifiées sur une échelle allant de 0 à 255 pour chacune.



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT


Polices

La police utilisée pour afficher du texte dans un composant peut être

définie à l’aide de la méthode setFont() . L’argument utilisé pour cette

méthode doit être une instance de la classe java.awt.Font .

Aucune constante n’est définie pour les polices, mais on peut créer une

police en indiquant son nom, son style et sa taille en points.

Font f = new Font(“TimesRoman”, Font.PLAIN, 14);

Voici quelques noms de polices valides :

• Dialog

• SansSerif (remplace Helvetica)

• Serif (remplace TimesRoman )

• Monospaced (remplace Courier)

On peut obtenir la liste complète des polices en appelant la méthode

getFontList() de la classe Toolkit . La boîte à outils (toolkit) peut être

obtenue à partir du composant, une fois ce dernier affiché on appelle la

méthode getToolkit() . On peut aussi utiliser le ToolKit par défaut

obtenu par Toolkit.getDefaultToolkit() .

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT


Polices

Les constantes de style de police sont en réalité des valeurs entières (int),

parmi celles citées ci-après :

• Font.BOLD

• Font.ITALIC

• Font.PLAIN

• Font.BOLD + Font.ITALIC

Les tailles en points doivent être définies avec une valeur entière.



Réf. Sun : LJ300 Date : 20/7/98

4

Rappels : AWT

Impression

L’impression est gérée dans Java 1.1 d’une façon similaire à l’affichage sur

écran. Grace à une instance particulière de java.awt.Graphics toute

instruction de dessin dans ce contexte est en fait destinée à l’imprimante.

Le système d’impression Java 1.1 permet d’utiliser les conventions

d’impression locales, de sorte que l’utilisateur voit s’afficher une boîte de

dialogue de sélection d’imprimante lorsque l’on lance une opération

d’impression. L’utilisateur peut ensuite choisir dans cette boite de

dialogue les options telles que la taille du papier, la qualité d’impression

et l’imprimante à utiliser.

Frame f = new Frame("Print test");Toolki t t = f.getToolkit();PrintJob job = t.getPrintJob(f,"Mon impr.", null);if (job != null) {

Graphic s g = job.getGraphics();.....

}

Ces lignes créent un contexte graphique (Graphics) "connecté" à

l’imprimante choisie par l’utilisateur. Pour obtenir un nouveau contexte

pour chaque page :

f.printAll(g);// ou printComponents()

On peut utiliser n’importe quelle méthode de dessin de la classe

Graphics pour écrire sur l’imprimante. Ou bien, comme indiqué ici, on

peut simplement demander à un composant de se tracer. La méthode

print() demande à un composant de se tracer , mais elle n’est liée qu’au

composant pour lequel elle a été appelée. Dans le cas d’un conteneur,

comme ici, on peut utiliser la méthode printAll() pour que le conteneur

et tous les composants qu’il contient soient tracés sur l’imprimante.

Utiliser printComponents () si on utilise des composants 100% JAVA.

g.dispose();job.end();

Après avoir créé une page de sortie conforme à ce que l’on souhaite, on

utilise la méthode dispose() pour que cette page soit soumise à

l’imprimante.

4



Réf. Sun : LJ300 Date : 20/7/98

Rappels : AWT

Impression

Une fois ce travail terminé, on appele la méthode end() sur l’objet tâche

d’impression. Elle indique que la tâche d’impression est terminée et

permet au système de traitement en différé d’exécuter réellement la tâche

puis de libérer l’imprimante pour d’autres tâches.

Nota: Dans le contexte Solaris il n’existe pas d’objet standard de menu

d’impression. On peut utiliser le 3ème argument de getPrintJob () qui

est un dictionnaire de propriétés (qui peut aussi être null

Frame f = new Frame("Print test");Toolki t t = f.getToolkit();Properties pprops = new Properties();pprops.put("awt.print.paperSize","a4");pprops.put("awt.print.orientation","landscape");PrintJob job = t.getPrintJob(f,"Mon impr.", pprops);.....

Les propriétés de ce dictionnaire sont :

awt.print.destination

awt.print.printer

awt.print.fileName

awt.print.options

awt.print.orientation (portrait, landscape)

awt.print.paperSize (letter,legal,executive,a4)

awt.print.numCopies



Réf. Sun : LJ300 Date : 20/7/98

Rappels: Flots E/S, linéarisation 5

Objet

Rappels des notions fondamentales sur les Entrées/Sorties JAVA:

• Flots (Streams)

• I/OStreams et Reader/Writer

• catégories de flots

• filtres

• fichiers

Rappels spécifiques sur la linéarisation:

• Data Input/Output

• Object Input/Output

5



Réf. Sun : LJ300 Date : 20/7/98

Rappels: Flots E/S, linéarisation

E/S JAVA : concepts fondamentaux

Pour pouvoir être réalisés de manière portable sur tous les systèmes les

Entrés/Sorties Java s’appuient sur des concepts abstraits de haut niveau.

flots d’E/S (Streams)

Un flot de données (Stream ) est un dispositif qui permet d’accéder

séquentiellement des données. Dans un flot d’entrée on consomme

successivement ces données et dans un flot de sortie on les envoie.

Une abstraction comme un InputStream lit des octets et dispose d’un

petit nombre de méthodes fondamentales comme:

int read()int read(byte[])int read(byte[], int, int)

La méthode read renvoie un argument int contenant un octet lu à partir

du flot ou la valeur -1 indiquant la fin de fichier. Les deux autres

méthodes lisent dans une buffer de byte et renvoient le nombre d’octets

lus.

void close()

permet de fermer le flot.

D’autre méthodes permettent de "sauter" un nombre d’octets déterminé

ou même, si c’est possible, de "marquer" un emplacement, de faire des

lectures anticipées et de revenir ensuite à la marque initiale.



Réf. Sun : LJ300 Date : 20/7/98

5



I/O Streams et Reader/Writer

Au niveau des flots fondamentaux de bas niveau on distingue d’une part

les I/OStream qui manipulent des octets (byte ) et les Reader et Writerqui manipulent des caractères. Comme JAVA utilise des caractères 16 bits

UNICODE les réalisations de base ne sont pas les même pour ces deux

catégories.

Une situation particulière est celle où on est au confluent des mondes

JAVA (avec des caractères UNICODE) et non-JAVA (avec un codage d’un

autre type). Les classes InputStreamReader et OutputStreamWriterdisposent de convertisseurs qui permettent d’assurer un fonctionnement

corrects des flots. Il faut toutefois veiller à spécifier correctement le type

de conversion (qui, par défaut, est déduit de l’environnement local)

catégories de flots

Parmi les classes de l’API JAVA on peut classifier les flots selon:

• leur structure d’origine (c.a.d. l’endroit d’où proviennent les don-

nées) : buffers (ByteArrayInputStream, CharArrayReader,StringReader ,...), threads (PipedInputStream, PipedRea-der ), fichiers (FileInputStream, FileReader ), flots de

communications produits par des Socket , URL, Process , etc.

(InputStream produits par les méthodes getInputStream ())

ou même regroupement de Streams (SequenceInputStream )

• les particularités de leur mode de fonctionnement: bufferisation

(BufferedInputStream , BufferedReader ), possibilité de ré-

pudia t ion de lec ture (Pushback Inpu tS t ream ,

PushbackReader ), formattages particulier (DataInputStream ,

ObjectInputStream , GZIPInputStream , PrintWriter ,

StreamTokenizer ...)

L’architecture des héritages est particulièrement complexe à appréhender

mais la notion centrale est celle de filtre (exemple :

FilterInputStream )

5



Réf. Sun : LJ300 Date : 20/7/98



filtres

De nombreuses classes d’E/S -et, en particulier, les classes de type

Filter * (FilterInputStream , FilterReader ,..)- sont des

adaptateurs qui permettent de combiner les caractéristiques de plusieurs

classes d’Entrées/Sorties.

On peut ainsi contruire une instance de flot qui enchaîne différents

services d’E/S :

String str ;BufferedReader inr =new BufferedReader(new InputStreamReader(System.in);while ((str = in.readLine()) != null) {

System.out.println("Read: " + str);}

La construction ci-dessus (un filtre bufferisé avec conversion de caractères

du codage local vers UNICODE) est rendu possible par le fait que les

constructeurs des classes admettent en paramètre un ancêtre commun

(Reader pour BufferedReader , InputStream pour

InputStreamReader,... )



Réf. Sun : LJ300 Date : 20/7/98

5


Fichiers

La classe File est un abstraction permettant de créer, manipuler des

fichiers ou d’obtenir des informations sur ces fichiers.

Noms de fichiers

• String getName()

• String getPath()

• String getAbsolutePath()

• String getParent()

• boolean renameTo(File newName)

Tests de fichiers

• boolean exists()

• boolean canWrite()

• boolean canRead()

• boolean isFile()

• boolean isDirectory()

• boolean isAbsolute();

Information générale axée sur les fichiers et utilitaires

• long lastModified()

• long length()

• boolean delete()

Utilitaires en rapport avec les répertoires

• boolean mkdir()

• String[] list()

5



Réf. Sun : LJ300 Date : 20/7/98


Linéarisation

ClassesDataInputStreametDataOutputStream

Ces flots permettent la lecture et l’écriture de types de base Java. Voici une

palette de méthodes :

Méthodes DataInputStream

byte readByte()boolean readBoolean()char readChar()short readShort()int readUnsignedShort()int readInt()long readLong()float readFloat()double readDouble()String readUTF()

DataOutputStream fourni les méthodes d’écriture correspondantes.

Les méthodes *UTF permettent de lire/écrire des chaînes de caractères

UNICODE en restant dans le monde JAVA. Elles utilisent un type de

codage particulier (UTF8) qui permet de condenser des chaînes

UNICODE lors d’un transfert sur une ligne de communication.



Réf. Sun : LJ300 Date : 20/7/98

5


Linéarisation

Bibliographie

voit documentation

http://chatsubo.sun.com/current/serial/index.html

Object Input/Output

L’interface API de linéarisation d’objet Java fournit un moyen simple et

transparent permettant de transférer des objets JAVA ou de les conserver

dans un fichier.

L’API fournit des méthodes permettant de générer et d’exploiter ce flot.

Les objets que l’on souhaite utiliser sous forme de structures à linéariser

réalisent une interface permettant d’enregistrer ou de récupérer le contenu

de l’objet en un seul flot. Il s’agit des interfaces java.io.ObjectOutputet java.io.ObjectInput ..

5



Réf. Sun : LJ300 Date : 20/7/98


Architecture de linéarisation

Package java.io

L’API de linéarisation est basée sur des interfaces conçues pour introduire

ou extraire des objets (ou des types scalaires) d’un flot d’E/S..

Légende

Classe

Interface

Classe abstraite

Etend

Implante

ObjectStreamConstants

java.io.DataOutput

ObjectOutput

java.io.OutputStream

ObjectOutputStream

ObjectInput

java.io.InputStream

ObjectInputStream

java.io.DataInput

java.lang.Object

java.io.Serializable

java.io.Externalizable



Réf. Sun : LJ300 Date : 20/7/98

5



Interface Serializable

L’interface Serializable sert à identifier les classes pouvant être

linéarisées.

Toute classe peut être linéarisée dans la mesure où elle satisfait aux

critères suivants :

• La classe (ou une classe de la hiérarchie de cette classe) doit

implémenter java.io.Serializable .

• Les champs à ne pas linéariser doivent être repérés à l’aide du mot

clé transient . Parmi ces champs, citons les classes

java.io.FileInputStream , java.io.FileOutputStream et

java.lang.Threads . Si le mot clé transient n’est pas affecté à

ces champs, une tentative d’appel de la méthode writeObject()générera une exception NotSerializableException .

Eléments sérialisables

Tous les champs (données) d’un objet Serializable sont écrits dans le

flot. Sont concernés les types scalaires, les tableaux et les références à

d’autres objets.

Les champs statiques ne sont pas linéarisés.

Il est à noter que le mécanisme d’accès aux champs (private , protectedet public ) n’a aucun effet sur le champ en cours de linéarisation. Si

nécessaire on doit déclarer les champs private en tant que privatetransient .

5



Réf. Sun : LJ300 Date : 20/7/98


Ecriture et lecture d’un flot d’objets

Ecriture

L’écriture et la lecture d’un objet dans un flot de fichiers est un processus

simple. Examinons le fragment de code suivant qui transmet une instance

d’un objet java.util.Date à un fichier :

Date d = new Date();FileOutputStream f = new FileOutputStream("date.ser");ObjectOutputStream s = new ObjectOutputStream (f);try {

s.writeObject (d);s.close ();

} catch (IOException e) {e.printStackTrace();

}

Lecture

La lecture de l’objet est aussi simple que l’écriture, à une exception près —

la méthode readObject() retourne le flot sous forme de type Object et

elle doit être associée au nom de classe correspondant, avant que

l’exécution des méthodes sur cette classe soit possible :

Date d = null;FileInputStream f = new FileInputStream ("date.ser");ObjectInputStream s = new ObjectInputStream (f);try {

d = (Date)s.readObject ();} catch (IOException e) {

e.printStackTrace();}System.out.println ("Date serialized at: "+ d);



Réf. Sun : LJ300 Date : 20/7/98

5



qu’est ce qui est transferré?

Le transfert d’un objet suppose la conservation :

• de la désignation de la classe,

• de sa "signature"

• des valeurs des champs non-statiques et non-transient (y comprisles objets référencés)

Cela implique :

• que le correspondant connaisse la classe désignée pour pouvoir la

reconstituer.

• que la classe connue par le correspondant soit compatible avec la

version de la classe expédiée. La signature de la classe (voir

utilitaire serialver ) donne un identifiant caractérisant la

version. Dans la spécification du langage JAVA des règles

complexes définisse la compatibilité entre deux versions d’une

même classe.

• que le Stream courant garde trace des identifiants d’instances

transférées. Ceci a plusieurs conséquences :

• linéariser un objet peut entraîner la linéarisation d’un graphecomplexe de références (on prendra soin de mettre denombreux champs à transient si on ne veux pas transférerpar inadvertance un grand nombre d’objets)

• le graphe des références est reconstitué correctement à l’arrivée(même s’il y a des cycles!).Cette complexité peut conduire à desperformances faibles du transfert

• si le Stream est fermé puis réouvert on perd la trace correctedes instances (voir connexions client/serveur). Par contre si leStream reste ouvert il est impossible de transférersuccessivement une même instance dans laquelle il y amodification de valeurs de champs.

5



Réf. Sun : LJ300 Date : 20/7/98



personnalisation de la lecture/écriture d’objet

On peut personnaliser la linéarisation d’une classe en définissant deux

méthodes privées writeObject and readObject.

La méthode writeObject permet de contrôler quelles informations sont

sauvegardées. Typiquement on l’utilise pour envoyer des informations

complémentaires qui permettront de reconstituer correctement l’objet à

l’arrivée : supposons par exemple qu’on ait des deux cotés un mécanisme

de dictionnaire (ou de base de données) qui permette de rechercher un

objet en connaissant une clef; au lieu de transférer cet objet (qui est

référencé par l’objet courant) on peut transférer sa clef et le reconstituer à

l’arrivée en consultant le dictionnaire.

private void writeObject(ObjectOutputStream s) throws IOException { s.defaultWriteObject(); // code spécifique}

La méthode readObject doit être soigneusement conçue pour lire

exactement les données dans le même ordre.

private void readObject(ObjectInputStream s) throws IOException { s.defaultReadObject(); //lecture des données personnalisées ... // code de mise à jour de l’instance courante}

Les méthodes writeObject et readObject ne sont responsables que de

la linéarisation de la classe courante. Toute linéarisation de super-classe

est traitée automatiquement. Si on a besoin de coordination explicite avec

la super-classe il vaut mieux passer par le mécanisme de l’interface

Externalizable .



Réf. Sun : LJ300 Date : 20/7/98

5



Externalisable

Les classes implantant l’interface Externalizable , prennent la

responsabilité du stockage et de la récupération de l’état de l’objet lui-

même.

package java.io;

public interface Externalizable extends Serializable {

public void writeExternal (ObjectOutput out)throws IOException;

public void readExternal (ObjectInput in)throws IOException, ClassNotFoundException;

}

Les objets externalisables doivent :

• Implémenter l’interface java.io.Externalizable .

• Implanter une méthode writeExternal pour enregistrer l’état de

l’objet. La méthode doit explicitement correspondre au supertype

pour conserver son état.

• Implanter une méthode readExternal pour lire les données du

flot et restaurer l’état de l’objet. La méthode doit explicitement

correspondre au supertype pour conserver son état.

• Etre responsables du format défini en externe. Les méthodes

writeExternal et readExternal sont uniquement responsables

de ce format.

Des classes externalisables impliquent que la classe soit Serializable ,

mais vous devez fournir les méthodes de lecture et d’écriture d’objets.

Aucune méthode n’est fournie par défaut.

ATTENTION: les mécanismes d’externalisation sont une menace pour la

sécurité! Il est recommandé de les utiliser avec une extrème prudence!

5



Réf. Sun : LJ300 Date : 20/7/98




Réf. Sun : LJ300 Date : 20/7/98

Rappels : Programmation réseau Java 6

Objectifs

Rappels :

• Créer un code serveur sous TCP/IP.

• Créer un code client sous TCP/IP.

• utiliser UDP

• utiliser UDP en diffusion ("multicast")

6



Réf. Sun : LJ300 Date : 20/7/98

Rappels : Programmation réseau Java

Programmation réseau sous Java

Sockets

Les Sockets sont des points d’entrée de communication bi-directionnelle

entre deux applications sur un réseau.

Les différents types de Socket conditionnent la façon dont les données

vont être transférées :

• Stream sockets (TCP) – Permettent d’établir une communication

en mode connecté. Un flot continu est établi entre les deux

correspondants : les données arrivent dans un ordre correct et sans

être corrompues.

• Datagram sockets (UDP) – Permettent d’établir une connexion en

mode non-connecté, que l’on appelle aussi mode Datagramme. Les

données doivent être assemblées et envoyées sous la forme de

paquets indépendants de toute connexion. Un service non

connecté est généralement plus rapide qu’un servcie connecté,

mais il est aussi moins fiable : aucune garantie ne peut être émise

quand au fait que les paquets seront effectivement distribués

correctement -ils peuvent être perdus, dupliqués ou distribués

dans le désordre-.



Réf. Sun : LJ300 Date : 20/7/98

6


Le modèle réseau de Java.

Dans Java, les sockets TCP/IP sont implantées au travers de classes du

package java.net. Voici la façon dont ces classes sont utilisées.

:

Dans ce modèle, le fonctionnement est le suivant :

• Le Serveur enregistre son service sous un numéro de port,

indiquant le nombre de client qu’il accepte de faire "bufferiser" à

un instant T. Puis, le serveur se met en attente sur ce service par la

méthode accept() de son instance de ServerSocket.

• Le client peut alors établir une connexion avec le serveur en

demandant la création d’une socket à destination du serveur pour

le port sur lequel le service a été enregistré.

• Le serveur sort de son accept() et récupère une Socket en

communication avec le Client. Ils peuvent alors utiliser des

InputStream et OutputStream pour échanger des données.

Serveur

ServerSocket (port #, nb_cnx)

accept()

OutputStream

InputStream

close ()

Client

Socket (host, port#)

OutputStream

InputStream

close ()

Enregistrerce service.

Attendre uneconnexion du

(attempt to connect)retourne un objet Socket client.

Utiliser la Socket

6



Réf. Sun : LJ300 Date : 20/7/98


Principe d’un Serveur TCP/IP

Exemple de code de mise en oeuvre d’un serveur TCP/IP

import java.net.*;import java.io.*;

public class SimpleServer { public static void main(String args[]) {

ServerSocket s = null;Socket s1;String sendString = "Hello Net World!";OutputStream s1out;DataOutputStream dos;

// enregistrer votre service sur port 5432try {

s = new ServerSocket(5432,5);} catch (IOException e) { }

// boucle infinie listen/acceptwhile (true) {

try {// attente d’une connexins1=s.accept();// récuperér un stream d’écritures1out = s1.getOutputStream();dos = new DataOutputStream (s1out);

// envoyer la chaîne!dos.writeUTF(sendString);

// fermer la connexion mais pas l’attente de// connexiondos.close();s1.close();

} catch (IOException e) { }}

}}



Réf. Sun : LJ300 Date : 20/7/98

6


Principe d’un Client TCP/IP

Le client correspondant :

import java.net.*;import java.io.*;

public class SimpleClient {public static void main(String[] args)

throws IOException {int c;Socket s1;InputStream s1In;DataInputStream dis;

// votre connection à args[0]t, sur port 5432s1 = new Socket(args[0],5432);

✓ The above statement could potentially throw an IOException .

// récupération d’un stream en lectures1In = s1.getInputStream();dis = new DataInputStream(s1In);

String st = new String (dis.readUTF());System.out.println(st);

// on coupe la connexions1.close();

}

6



Réf. Sun : LJ300 Date : 20/7/98


échanges UDP

On n’a pas ici de connexion ouverte en permanence. Les paquets,

autonomes, sont transférés avec leur propres informations d’adresse. Le

service n’est pas "fiable" car il y a des risques de perte, ou de duplication

de paquets. L’ordre d’arrivée n’est pas garanti.

Pour limiter les incidents il vaut mieux limiter la taille des paquets

envoyés de manière à ce qu’ils n’occupent qu’un seul paquet IP.

Les objets fondamentaux :

• DatagramSocket : détermine un canal (socket) UDP. Pour un

serveur on précisera le port (pas nécessaire pour le client)

DatagramSocket serverSock = new DatagramSocket(9789); DatagramSocket clientSock= new DatagramSocket() ;

• DatagramPacket : structure d’accueil des données et des

informations d’adresse.

Les methodes getData (), getAddress (), getPort () permettent

de récupérer ces informations.

// pour un envoisendPack = new DatagramPacket(byteBuff, len, addr, port);socket.send(sendPack) ;// pour une receptionrevPack = new DatagramPacket(byteBuffer, len) ;socket.receive(recvPack);

• InetAddress : permet de produite une adresse inet à partir

d’une désignation (méthode getByName ()) ou de la machine

locale (getLocalHost ())



Réf. Sun : LJ300 Date : 20/7/98

6


Exemple de Serveur UDP

Ce serveur reçoit un objet d’un client et le renvoie suivi d’un

java.sql.Timestamp .

On utilise les données d’adressage du paquet reçu du client pour

reexpédier les données

1import java.io.* ;2 import java.net.* ;3 import java.sql.* ;45 public class DatagServer {6 public static final int PORT = 9999 ;7 public static final int DATA_MAX_SIZE = 512 ;89 public static void main (String[] tbArgs) {10 byte[] recBuffer = new byte[DATA_MAX_SIZE] ;11 try{12 DatagramSocket veille = new DatagramSocket(PORT) ;13 while (veille != null) {14 DatagramPacket recvPack = new DatagramPacket(15 recBuffer, recBuffer.length) ;16 veille.receive(recvPack) ;17 ObjectInputStream inz = new ObjectInputStream18 (new ByteArrayInputStream(recvPack.getData())) ;19 Object obj = inz.readObject() ;20 System.out.println(obj) ;21 ByteArrayOutputStream boz = new ByteArrayOutputStream();22 ObjectOutputStream oz = new ObjectOutputStream (boz);23 oz.writeObject(obj) ;24 oz.writeObject(new Timestamp(System.currentTimeMillis()));25 // consommation excessive de données (deux byte buffers!)26 DatagramPacket sendPack =27 new DatagramPacket(boz.toByteArray(), boz.size(),28 recvPack.getAddress() ,recvPack.getPort());29 veille.send(sendPack) ;30 }31 } catch (Exception exc ) {32 System.err.println(exc) ;33 }3435 }//End main

6



Réf. Sun : LJ300 Date : 20/7/98


Exemple de client UDP

Correspond au serveur précédent : on envoie un java.sql.Timestampet on le reçoit en echo suivi de celui du serveur.

1 import java.io.* ;2 import java.net.* ;3 import java.sql.* ;45 public class DatagClient {6 public static final int DATA_MAX_SIZE = 512 ;78 public static void main (String[] tbArgs) {9 byte[] recBuffer = new byte[DATA_MAX_SIZE] ;10 try{11 DatagramSocket socket = new DatagramSocket() ;12 if (socket != null) {13 ByteArrayOutputStream boz = new ByteArrayOutputStream();14 ObjectOutputStream oz = new ObjectOutputStream (boz) ;15 oz.writeObject(new Timestamp(System.currentTimeMillis())) ;16 // consommation excessive de données (deux byte buffers!)17 DatagramPacket sendPack = new DatagramPacket(18 boz.toByteArray(), boz.size(),19 InetAddress.getByName(tbArgs[0]),20 DatagServer.PORT) ;21 socket.send(sendPack) ;22 DatagramPacket recvPack =23 new DatagramPacket(recBuffer, recBuffer.length) ;24 socket.receive(recvPack) ;25 ObjectInputStream inz = new ObjectInputStream26 (new ByteArrayInputStream(recvPack.getData())) ;27 Object obj = inz.readObject() ;28 System.out.println(obj) ;29 obj = inz.readObject() ;30 System.out.println(obj) ;31 }32 } catch (Exception exc ) {33 System.err.println(exc) ;34 }3536 }//End main



Réf. Sun : LJ300 Date : 20/7/98

6


UDP en diffusion (Multicast)

Une adresse de diffusion (multicast) est une adresse comprise entre

224.0.0.0 et 239.255.255.255 .

Des MulticastSocket permettent de diffuser des données

simultanément à un groupe d’abonnés. Sur une telle socket on peut

s’abonner à une adresse multicast par joinGroup (InetAddressmcastaddr) ou se désabonner par leaveGroup (InetAddress ).

Le paramètre TTL de ces sockets permet de fixer le nombre maximum de

routeurs traversés - si ces routeurs le permettent- (important si on veut

limiter la diffusion à l’extérieur d’une entreprise)

✏✏✏✏✏✏✏✏

Actuellement les accès "Multicast" ne sont pas autorisés dans les Applet.

6



Réf. Sun : LJ300 Date : 20/7/98


Exemple de Serveur Multicast

Diffuse un java.sql.TimeStamp toute les secondes. Les paquets ne se

transmettent pas au travers des relais réseaux (TTL = 1).

1 import java.io.* ;2 import java.net.* ;3 import java.sql.* ;45 public class MultigServer {6 public static final int PORT = 9999 ;7 public static final String GROUP = "229.69.69.69" ;8 public static final byte TTL = 1 ; // pas de saut!9 public static final int DATA_MAX_SIZE = 512 ;1011 public static void main (String[] tbArgs) {12 byte[] recBuffer = new byte[DATA_MAX_SIZE] ;13 try{14 MulticastSocket veille = new MulticastSocket(PORT);15 InetAddress adrGroupe = InetAddress.getByName(GROUP) ;16 while (veille != null) {17 ByteArrayOutputStream boz = new ByteArrayOutputStream();18 ObjectOutputStream oz = new ObjectOutputStream (boz) ;19 oz.writeObject(new Timestamp(System.currentTimeMillis())) ;20 // consommation excessive de données (deux byte buffers!)21 DatagramPacket sendPack =22 new DatagramPacket(boz.toByteArray(), boz.size(),23 adrgroupe, PORT) ;24 veille.send(sendPack, TTL) ;2526 try{27 Thread.sleep(1000) ;28 } catch (InterruptedException exc) {}29 }30 } catch (Exception exc ) {31 System.err.println(exc) ;32 }33 }//End main34 }35



Réf. Sun : LJ300 Date : 20/7/98

6


Exemple de client Multicast

Reçoit 10 objets du serveur

1 import java.io.* ;2 import java.net.* ;3 import java.sql.* ;45 public class MultigClient {6 public static final int DATA_MAX_SIZE = 512 ;78 public static void main (String[] tbArgs) {9 MulticastSocket socket = null;10 InetAddress adrGroupe = null ;11 byte[] recBuffer = new byte[DATA_MAX_SIZE] ;12 try{13 socket = new MulticastSocket(MultigServer.PORT) ;14 adrGroupe = InetAddress.getByName(MultigServer.GROUP) ;15 if (socket != null) {16 socket.joinGroup(adrGroupe) ;17 // danger! on reutilise le meme buffer?18 DatagramPacket recvPack =19 new DatagramPacket(recBuffer, recBuffer.length) ;20 for( int ix = 0 ; ix < 10 ; ix++) {21 socket.receive(recvPack) ;22 ObjectInputStream inz =23 new ObjectInputStream24 (new ByteArrayInputStream(25 recvPack.getData())) ;26 Object obj = inz.readObject() ;27 System.out.println(obj) ;28 inz.close() ;29 }// for30 }31 } catch (Exception exc ) {32 System.err.println(exc) ;33 }34 finally {35 if ( socket != null) {36 try{ socket.leaveGroup(adrGroupe) ;37 } catch (IOException exc) {}38 }39 }40 }41 }42

6



Réf. Sun : LJ300 Date : 20/7/98




Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI 7

Objectifs

L’API d’invocation de méthodes à distance (RMI) permet d’écrire un code

qui accède aux objets distants comme si c’était des objets locaux.

• le présent chapitre constitue une introduction à RMI

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI

Bibliographie

Certaines parties de ce module sont extraites de :

• “The Java Remote Method Invocation Specification” disponible

sur

http://chatsubo.javasoft.com/current/doc/rmi-spec/rmi-spec.ps

• “Java RMI Tutorial” disponible sur

http://chatsubo.javasoft.com/current/doc/tutorial/rmi-getstart.ps

• “Frequently Asked Questions, RMI and Object Serialization”

disponible sur

http://chatsubo.javasoft.com/current/faq.html



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI

Fonction de l’architecture RMI en Java

L’ API RMI contient une série de classes et d’interfaces permettant au

développeur d’appeler des objets distants, déjà existants dans une

application séxécutant sur une autre machine virtuelle Java (JVM). Cette

JVM “distante” ou “serveur” peut être exécutée sur la même machine ou

sur une machine entièrement différente du “client” RMI. L’architecture

RMI en Java est un mécanisme utilisant uniquement le langage Java.

Class

Réalisation

rmic(compiler)

Method call

Method Results

Application

Stub

Client Serveur

Skeleton

ObjectImplementation

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI

Packages et hiérarchies RMI

Package java.rmi

• Naming – Cette classe “finale” est utilisée par les clients et serveurs

RMI pour communiquer avec un “aiguilleur” appelé Registre des

noms (Registry ) et situé sur la machine serveur. L’application

serveur utilise les méthodes bind et rebind pour enregistrer ses

implantations d’objets auprès du Registre, alors que le programme

client utilise la méthode lookup de cette classe pour obtenir une

référence vers un objet distant.

• Remote – Cette interface doit être étendue par toutes les interfaces

client qui seront utilisées pour accéder aux implantations d’objets

distants.

• RemoteException – Cette exception doit être générée par toute

méthode déclarée dans des interfaces et des classes de réalisation

distantes. Tous les codes client doivent donc naturellement être

écrits pour traiter cette exception.

• RMISecurityManager – Cette classe permet aux applications

locales et distantes d’accéder aux classes et aux interfaces RMI.

Remote

java.lang.Object java.io.IOException

Naming RemoteException *

java.lang.SecurityManager

RMISecurityManager

*Bien qu’il existe davantage d’exceptions dans les packagesjava.rmiet java.rmi.server , RemoteException est l’exception que vousrencontrerez le plus fréquemment.

Légende

Classe

Interface

Classe

Etend

Implante

extraite



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI


Package java.rmi.server

Légende

Classe

Interface

Classe

Etend

Implante

java . lang . Object

OperationLoaderHandler

RMIClassLoader

RMISocketFactory

RemoteObject

RemoteStub

ObjID

UID

RemoteServer

Skeleton

RMIFailureHandler

Unreferenced

java.io.Externalizable RemoteRef

ServerRef

java.io.PrintStream

LogStreamRemoteCall

extraite

java.io.Serializable

UnicastRemoteObject

java.rmi.Remote

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


Package java.rmi.server (suite)

• RMIClassLoader – ClassLoader sert à charger les stubs (talons) et

les skeletons d’objets distants, ainsi que les classes des arguments et

les valeurs retournées par les appels de méthodes à distance.

Lorsque RMIClassloader tente de charger des classes à partir du

réseau, une exception est générée si aucun gestionnaire de sécurité

n’est installé.

• UnicastRemoteObject – Classe parent de chaque classe distante

en RMI



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI

Création d’une application RMI

Exemple bancaire

Pour illustrer l’utilisation de l’invocation RMI, nous allons étudier

l’exemple simple d’une banque dans laquelle on va ouvrir un compte. Les

comptes sont contrôlés par un employé de banque : le gestionnaire de

comptes.

Après avoir ouvert un compte, on peut y déposer ou en retirer de l’argent

et vérifier le solde.

Server Client

Account Manager

Creates

AccountInstance

Open an account

Get current balance

Deposit money

Withdraw money

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


Interfaces bancaires

Si on tente de modéliser ce problème en utilisant l’invocation RMI, on

peut créer deux interfaces Java du type suivant :

• Account.java

package rmi.bank;interface Account extends Remote {

public float getBalance ();public void withdraw (float money);public void deposit (float money);

}

• AccountManager.java

package rmi.bank;interface AccountManager extends Remote {

public Account open (String name,float startingBalance);

}



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI


Interfaces bancaires (suite)

Il est à noter que ces interfaces sont conçues de sorte que l’on utilise

l’interface AccountManager pour générer une instance d’un objet

Account . AccountManager est chargé de retourner l’instance couranted’un objet Account si le compte existe déjà.

Cette approche de la création d’objet est un type de conception défini

dans la méthodologie de programmation par une méthode appelée

“Générateur (Factory).”1

Ce "Générateur" permet à un objet de contrôler la création d’autres objets

et, dans le cas considéré, il s’agit de la solution idéale car le gestionnaire

de comptes (AccountManager) doit contrôler la création de nouveaux

comptes. Si l’on se rendait dans la banque et on tentait d’ouvrir un autre

compte, on répondrait “Vous possédez déjà un compte dans notre

établissement. Utilisez-le.”

1. Design Patterns - Elements of Reusable Object-Oriented Software par Gamma,Helm, Johnson et Vlissides (Editions Addison-Wesley, 1995)

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


Procédure

Le processus permettant de créer une application accessible à distance

dans RMI est le suivant :

1. Définir les objets distants à utiliser sous forme d’interfaces Java.

2. Créer des classes de réalisation pour les interfaces.

3. Compiler l’interface et les classes de réalisation.

4. Créer des classes stubs et skeletons à l’aide de la commande rmicsur les classes de réalisation.

5. Créer une application serveur permettant de gérer et de compiler

les réalisations.

6. Créer et compiler un client permettant d’accéder aux objets

distants.

7. Lancer rmiregistry et l’application serveur.

8. Tester le client.

%java BankClient%rmi registry&%java BankServer

BankClient.java BankServer.java

Account.java(interface)

AccountManager.java(interface)

AccountInstance

AccountImpl.java

AccountManagerImpl.java



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI


Interface Account

L’exemple suivant présente l’interface Account complète :

// The Account interface// Methods for getting the account balance, depositing,and// withdrawing moneypackage rmi.bank;import java.rmi.*;public interface Account extends Remote {

// Get the account balancepublic float getBalance () throws RemoteException;// Deposit money to the account -// throw an exception if the value// is 0 or a negative numberpublic void deposit (float balance)

throws BadMoneyException, RemoteException;// Withdraw money from the account -//but throw an exception if the// amount of the withdrawal will exceed the account

balancepublic void withdraw (float balance)

throws BadMoneyException, RemoteException;}

L’interface Account doit étendre java.rmi.Remote et être déclarée

public afin d’être rendue accessible à distance (aux clients utilisant

d’autres JVM).

Il est à noter que toutes les méthodes génèrent une exception

java.rmi.RemoteException. Cette exception apparaît lorsque

survient un problème d’accès à la méthode d’un objet distant. Les

méthodes de dépôt et de retrait génèrent également une exception

BadMoneyException indiquant qu’une valeur négative a été transmise

pour un dépôt, ou qu’une tentative de retrait supérieur au solde du

compte a été effectuée.

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


Interface AccountManager

L’interface AccountManager complète inclut :

// The Account Manager interface

// Method for creating a new Account with the user's// name and initial account balance

package rmi.bank;

import java.rmi.*;

public interface AccountManager extends Remote {

public Account open (String name, floatinitialBalance)

throws BadMoneyException, RemoteException;

}



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI


réalisation de l’interface Account — AccountImpl

L’interface Account est réalisée par une classe devant à son tour

implanter toutes les méthodes définies dans Account et étendre

UnicastRemoteObject . Par convention, pour les classes réalisant des

contrats d’ interface RMI, le suffixe “Impl” sera ajouté au nom du fichier

d’interface :

// AccountImpl - Implementation of the Account interface//// This class is an instance of an Account and implements// the balance, deposit and withdraw methods specified by// the Account interface.

package rmi.bank;

import java.rmi.*;import java.rmi.server.UnicastRemoteObject;

public class AccountImplextends UnicastRemoteObjectimplements Account {

// The current balance of the accountprivate float balance = 0;

// Create a new account implementation with a newaccount balance

public AccountImpl (float newBalance)throws RemoteException {balance = newBalance;

}

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


réalisation de l’interface Account — AccountImpl (suite)

// Methods implemented from Account

// Return the current account balancepublic float getBalance () throws RemoteException {

return balance;}

// Deposit money into the account,// as long as it is a positive numberpublic void deposit (float money)

throws BadMoneyException, RemoteException {// Is the deposit amount a negative number?if (money < 0) {

throw new BadMoneyException("Attempt to deposit negative money!");

} else {balance += money;

}}

// Withdraw money from the account, up to the// value of the current account balancepublic void withdraw (float money)

throws BadMoneyException, RemoteException {// Is the deposit amount a negative number?if (money < 0) {

throw new BadMoneyException("Attempt to deposit negative money!");

} else {// Is there sufficient money in the account?if ((balance - money) < 0) {

throw new BadMoneyException("Attempt to overdraw your account!");

} else {balance -= money;

}}

}}



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI


AccountManagerImpl

La classe AccountManagerImpl est chargée de créer et d’enregistrer de

nouveaux comptes (sous forme d’objets AccountImpl ). Cette classe

utilise un vecteur (Vector ) permettant d’enregistrer les objets Accountdans une classe de conteneurs appelée AccountInfo , associée au nom

du compte String . Cette classe utilitaire facilite la recherche d’un objet

Account existant.

// AccountManagerImpl - Implementation of theAccountManager// interface//// This version of the AccountManager class stores all// instances of the Account(s) it creates in a Vector// object - if an account requested exists, it will// return that account.

package rmi.bank;

import java.util.Vector;import java.rmi.*;import java.rmi.server.UnicastRemoteObject;

public class AccountManagerImplextends UnicastRemoteObjectimplements AccountManager {

// Local storage of account namesprivate static Vector accounts = new Vector ();

// This empty constructor is required to create an// instance of this class in the serverpublic AccountManagerImpl () throws RemoteException

{}

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


AccountManagerImpl (suite)

// Implement method from AccountManager interface// Create an instance of an Account - if the account// name already exists, return that account instead// of creating a new onepublic Account open (String name, float

initialBalance)throws BadMoneyException, RemoteException {AccountInfo a;// Check if this name is in the list alreadyfor (int i = 0; i < accounts.size(); i++) {

a = (AccountInfo)accounts.elementAt(i);if (a.name.equals (name)) {

return (a.account);}

}// Check the initial account value...if (initialBalance < 0) {

throw new BadMoneyException ("Negative initialbalance!");

}// Store the new accounta = new AccountInfo();// Try to create a new account with the starting

balancetry {

a.account = new AccountImpl (initialBalance);} catch (RemoteException e) {

System.err.println ("Error opening account: "+ e.getMessage());throw (e);

}a.name = name;accounts.addElement (a);// Return and instance of an AccountImpl objectreturn (a.account);

}}



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI


AccountManagerImpl

Classe de conteneurs

La classe de conteneurs AccountInfo est utilisée par la classe

AccountManagerImpl .

// A container class for instance of Accounts// that is stored in the Vector object

class AccountInfo {String name;AccountImpl account = null;

}

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


Compilation du code

Le chemin d’accès aux classes est important pour la réussite de l’exécution

du code RMI. Il est recommandé d’envisager l’utilisation de l’option -ddu compilateur pour localiser les fichiers de classes créés :

% javac -d classDirectory *.java

Dans l’exemple de code ci-dessus, le répertoire de package rmi/bank est

créé dans le répertoire courant.



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI


Utilisation de la commande rmic

Après compilation des classes de réalisation , vous devez créer les codes

stub et skeleton permettant d’accéder aux classes de réalisation. Vous

rappellerez les classes stubs utilisées par le code client pour communiquer

avec le code skeleton du serveur.

La commande rmic créera des codes stub et skeleton à partir des

définitions des interfaces et des classes de réalisation.

Cette étape doit être exécutée après compilation des classes de réalisation

et avant exécution de l’application serveur. La syntaxe de la commande

est la suivante :

rmic [ options] package.interfaceImpl ...

Exemple :

% rmic -d classDirectory rmi.bank.AccountManagerImpl \

rmi.bank.AccountImpl

L’exemple suivant créera quatre classes supplémentaires dans le

répertoire rmi/bank (package) :

AccountImpl_Skel.classAccountImpl_Stub.classAccountManagerImpl_Skel.classAccountManagerImpl_Stub.class

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


Application BankServer

BankServer gère l’objet AccountManagerImpl . Son unique fonction

consiste à fournir une instance AccountManager à tout client

demandeur.

// BankServer - This class is run on the RMI server// and is responsible for registering the AccountManager// implementation.package rmi.bank;import java.rmi.*;public class BankServer {public static void main(String args[]) {

// Create and install the security managerSystem.setSecurityManager(new

RMISecurityManager());try {

// Create the object instance for registrationSystem.out.println

("BankServer.main: creating anAccountManagerImpl");

AccountManagerImpl acm = new AccountManagerImpl();

// Bind the object instance to the registrySystem.out.println

("BankServer.main: bind it to a name:bankManager");

Naming.rebind("bankManager", acm); System.out.println("bankManager Server

ready.");} catch (Exception e) { System.out.println

("BankServer.main: an exception occurred: " + e.getMessage());

e.printStackTrace();}

}}



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI


Application BankServer (suite)

Le serveur “publie” l’instance de l’objet AccountManagerImpl en

associant cet objet à un nom stocké dans une application “d’aiguillage”

rmiregistry .

L’affectation s’effectue à la ligne 23 du programme précédent

Naming.rebind("bankManager", acm);

par le biais de la méthode rebind de la classe java.rmi.Naming . Cette

méthode associe ou “affecte” le nom bankManager à l’objet acm, en

supprimant tout objet précédemment affecté à ce nom dans le Registre.

La classe Naming fournit deux méthodes permettant au développeur

d’enregistrer une réalisation, bind et rebind , la seule différence résidant

dans le fait que la méthode bind générera une exception

java.rmi.AlreadyBoundException si un autre objet a déjà été

enregistré sur ce serveur, à l’aide du nom transmis à la méthode en tant

que premier argument.

Les arguments d’affectation et de réaffectation se présentent sous forme

de chaîne de type URL contenant le nom d’instance de réalisation d’objet.

La chaîne URL doit respecter le format

rmi:// host: port/ name

où rmi désigne le protocole, host est le nom du serveur RMI (qui devrait

être compatible DNS ou NIS+), port est le numéro de port que le serveur

doit écouter pour les requêtes, et name est le nom exact que les clients

doivent utiliser dans les requêtes Naming.lookup pour cet objet.

Les valeurs par défaut sont rmi pour le protocole, l’hôte local pour host

1099 pour port.

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


Application rmiregistry

rmiregistry est une application fournissant un simple service

d’aiguillage sur un nom. L’application BankServer fournit à

l’application rmiregistry la référence d’objet et un nom string par le

biais de l’appel de méthode rebind .

L’application rmiregistry doit être exécutée avant que l’application

BankServer ne tente l’affectation :

% rmiregistry &

% java rmi.bank.BankServer &

Les propriétés peuvent être définies pour la machine JVM du serveur RMI

dans la ligne de commande :

• java.rmi.server.codebase – Cet URL indique l’emplacement

où les clients peuvent télécharger les classes.

• java.rmi.server.logCalls – Si la valeur retournée est “vraie”,

le serveur consigne les appels dans stderr . La valeur par défaut

est “faux”.

% java -Djava.rmi.server.logCalls=true rmi.bank.BankServer &

Après exportation de la réalisation par le Registre, le client peut expédier

une chaîne URL pour demander à ce que l’application rmiregistryfournisse une référence de l’objet distant. La recherche s’effectue par le

biais d’un appel client de Naming.lookup , en transmettant une chaîne

URL sous forme d’argument :

rmi:// host: port/ name

La page suivante présente la recherche utilisée par l’application client.



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI


Application BankClient

L’application BankClient tente de localiser un objet AccountManageren effectuant une recherche à l’aide d’un aiguilleur (Registry ). Cet

aiguilleur se situe dans host: port dans la chaîne URL transmise à la

méthode Naming.lookup() . L’objet retourné est “vu” (converti par cast)

comme un gestionnaire de compte (AccountManager) et peut servir à

ouvrir un compte avec un nom et à lancer le calcul du solde.

// BankClient - the test program for the Bank RMI example//// This class simply attempts to locate the "bankManager"// RMI object reference, then binds to it and opens an// instance to an AccountManager implementation at the// <server> location.//// Then it requests an Account with <name> andoptionally,// an initial balance (for a new account).//// The class then tests the account by depositing and// withdrawing money and looking at the account balance.package rmi.bank;import java.rmi.*;public class BankClient {public static void main(String args[]) {

// Check the argument countif (args.length < 2) {

System.err.println ("Usage:");System.err.println("java BankClient <server> <account name>

[initial balance]");System.exit (1);

}// Create and install the security managerSystem.setSecurityManager(new

RMISecurityManager());

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


Application BankClient (suite)

try {// Get the bank instanceSystem.out.println ("BankClient: lookup

bankManager");String url = new String

("rmi://"+args[0]+"/bankManager");AccountManager acm =

(AccountManager)Naming.lookup(url);// Set the account balance, if passed as an

argumentfloat startBalance = 0.0f;if (args.length == 3) {

Float F = Float.valueOf(args[2]);startBalance = F.floatValue();

}// Get an account (either new or existing)Account account = acm.open (args[1],

startBalance);// Now do some stuff with the remote object

implementationSystem.out.println ("BankClient: current balance

is: " +account.getBalance ());

System.out.println ("BankClient: withdraw50.00");

account.withdraw (50.00f);System.out.println ("BankClient: current balance


System.out.println ("BankClient: deposit100.00");

account.deposit (100.00f);System.out.println ("BankClient: current balance


System.out.println ("BankClient: deposit 25.00");account.deposit (25.00f);System.out.println ("BankClient: current balance




Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI

} catch (Exception e) { System.err.println("BankClient: an exception

occurred: " + e.getMessage());

e.printStackTrace();}System.exit(1);

}}

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI


Application BankClient (suite)

Après avoir ouvert un compte, l’application BankClient exécute les

opérations simples de dépôt et de retrait. Cette classe pourrait (et devrait

probablement) posséder une interface interactive qui permettrait au client

de saisir le nom du compte, puis d’effectuer un retrait ou un dépôt.

Exécution de l’application BankClient

L’application BankClient peut être exécutée à partir de tout hôte

autorisé à accéder au Registre et au package contenant les fichiers de

classes de l’application client, des stubs et des interfaces.



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI


Exécution de l’application BankClient

Syntaxe

java rmi.bank.BankClient hostname accountName initialBalance

Exemples

% java rmi.bank.BankClient mach1 fred 1000

BankClient: lookup bankManagerBankClient: current balance is: 1000.0BankClient: withdraw 50.00BankClient: current balance is: 950.0BankClient: deposit 100.00BankClient: current balance is: 1050.0BankClient: deposit 25.00BankClient: current balance is: 1075.0

Il est à noter que l’objet distant AccountManagerImpl situé sur le

serveur, enregistre l’instance du compte créé avec le nom fred . Par

conséquent, la réexécution de l’application BankClient avec le même

nom de compte utilisera le même objet :

% java rmi.bank.BankClient mach1 fred

BankClient: lookup bankManagerBankClient: current balance is: 1075.0BankClient: withdraw 50.00BankClient: current balance is: 1025.0BankClient: deposit 100.00BankClient: current balance is: 1125.0BankClient: deposit 25.00BankClient: current balance is: 1150.0

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI

Sécurité RMI

Chargement de classe

Pour utiliser RMIClassLoader , un gestionnaire de sécurité doit déjà

exister afin de s’assurer que les classes chargées à partir du réseau

satisfont aux critères standard de sécurité Java. Si aucun gestionnaire n’est

en place, l’application ne peut pas charger les classes à partir d’hôtes

distants.

Côté serveur RMI

Lors de l’envoi de la commande java permettant d’appeler la machine

JVM côté serveur, il est possible de définir deux propriétés (dont l’une des

deux a été précédemment évoquée dans ce module) pour déterminer

l’emplacement des classes RMI :

• java.rmi.server.codebase – Cet URL indique l’emplacement à

partir duquel les clients peuvent télécharger les classes et indique

que le serveur peut, si nécessaire, charger des classes à partir des

URL du client.

• java.rmi.server.useCodebaseOnly – Si la valeur retournée est

“vrai”, le chargement de classes à partir des URL du client est

désactivé.



Réf. Sun : LJ300 Date : 20/7/98

7

Rappels: RMI

Sécurité RMI

Chargement de classe

Côté client RMI

Si le programme client RMI est une applet, son gestionnaire de sécurité

(SecurityManager ) et son chargeur de classe (ClassLoader) sont

mandatés par le browser côté client.

Cependant, si le programme client est une application, les seules classes

qui seraient téléchargées à partir du serveur RMI seraient les définitions

d’interfaces distantes, les classes stubs , les classes d’arguments étendues

et les valeurs retournées par les appels de méthodes distants. Si une

application client tente de charger des classes supplémentaires à partir du

serveur, elle peut utiliser RMIClassLoader.loadClass , en fournissant

comme paramètres les mêmes URL et identificateur que ceux transmis

dans Naming.lookup .

Invocation RMI au travers d’un coupe-feu

La couche transport RMI tente normalement d’ouvrir des sockets directs

des clients aux serveurs. Néanmoins, s’il est impossible d’établir une

connexion directe au serveur par socket , la méthode createSocket de

la classe java.rmi.server.RMISocketFactory retentera la requête

sous forme de connexion par protocole de tranfert hypertexte (HTTP) en

expédiant l’appel RMI sous forme de requête HTTP POST.

Si la méthode createServerSocket détecte que la connexion

récemment acceptée est une requête HTTP POST, les informations

retournées seront réexpédiées dans le corps d’une réponse HTTP.

Aucune configuration spéciale n’est requise pour permettre au client

d’effectuer des appels RMI au travers d’un coupe-feu.

7



Réf. Sun : LJ300 Date : 20/7/98

Rappels: RMI



Réf. Sun : LJ300 Date : 20/7/98

Méthodes natives avec JNI 8

Objectifs

Ce chapitre introduit l’API Java Native Interface qui permet d’étendre

JAVA avec du code compilé écrit en C ou C++:

• Pourquoi réaliser du code natif?

• Les phases de génération : un exemple simple

• Les caractéristiques générales de JNI

• Exemples : emploi des types Java en C, accès aux attributs des

objets JAVA, création d’instances.

• Le problème de l’intégrité des références aux objets JAVA.

• Le traitement des exceptions JAVA

• L’invocation de JAVA à l’intérieur d’un code C/C++.

8



Réf. Sun : LJ300 Date : 20/7/98

Méthodes natives avec JNI

Pourquoi réaliser du code natif?

Il y a des situations dans laquelle le code ne peut pas être complétement

écrit en JAVA :

• Une grande quantité de code compilé existe déja et fonctionnede manière satisfaisante. La fourniture d’une interface avecJAVA peut être plus intéressante qu’une réécriture complète.

• Une application doit utiliser des services non fournis par JAVA(et en particulier pour exploiter des spécificités de la plate-forme d’exécution. Exemple : accès à des cartes).

• Le système JAVA n’est pas assez rapide pour des applicationscritiques et la réalisation dans un code natif serait plusefficiente.

Il est possible d’implanter en JAVA des méthodes natives réalisées

typiquement en C ou C++.

Une classe comprenant des méthodes natives ne peut pas être téléchargée

au travers du réseau de manière standard: il faudrait que le serveur ait

connaissance des spécificités de la plate-forme du client. De plus une telle

classe ne peut faire appel aux services de sécurité de JAVA (en 1.1)

Bien entendu pour toute application JAVA qui s’appuie sur des

composants natifs on doit réaliser un portage du code natif sur chaque

plate-forme spécifique. De plus c’est un code potentiellement plus fragile

puisque les contrôles (pointeurs, taille, etc.) et la récupération d’erreurs

sont entièrement sous la responsabilité du programmeur.

Il existe diverses manières d’assurer cette liaison code compilé-Java.

Depuis la version JAVA 1.1 le protocole JNI a été défini pour rendre cette

adaptation plus facilement indépendante de la réalisation de la machine

virtuelle sous-jacente.

D’autre part il est également possible d’exécuter du code JAVA au sein

d’une application écrite en C/C++ en appelant directement la machine

virtuelle ( JAVA "enchassé" dans C).



Réf. Sun : LJ300 Date : 20/7/98

8


un exemple : "Hello World" en C

résumé des phases :

Ecriture du code JAVA :

• Création d’une classe "HelloWorld" qui déclare une méthode(statique) native.

Création des binaires JAVA de référence :

• Compilation du code ci-dessus par javac .

Génération du fichier d’inclusion C/C++ :

• Ce fichier est généré par l’utilitaire javah . Il fournit unedéfinition d’un en-tête de fonction C pour la réalisation de laméthode native getGreetings () définie dans la classe Java"HelloWorld".

Ecriture du code natif :

• Ecriture d’un fichier source C (".c") qui réalise en C le code dela méthode native. Ce code fait appel à des fonctions et destypes prédéfinis de JNI.

Création d’une librairie dynamique:

• Utilisation du compilateur C pour générer une librairiedynamique à partir des fichiers .c et .h définis ci-dessus. (sousWindows une librairie dynamique est une DLL)

Exécution:

• Exécution du binaire JAVA (par java ) avec chargementdynamique de la librairie.

8



Réf. Sun : LJ300 Date : 20/7/98



Ecriture du code JAVA

Le code de l’exemple définit une classe JAVA nommée "HelloWorld" et

faisant partie du package "hi".

package hi ;

class HelloWorld {

static { System.loadLibrary("hello"); } public static native String getGreetings();

public static void main (String[] tArgs) { for (int ix = 0 ; ix < tArgs.length; ix++) { System.out.println(getGreetings() + tArgs[ix]) ; } }// main}

Cette classe pourrait contenir également d’autres définitions plus

classiques (champs, méthodes, etc.). On remarquera ici :

• La présence d’un bloc de code static exécuté au moment duchargement de la classe. A ce moment il provoque alors lechargement d’une bibliothèque dynamique contenant le codeexécutable natif lié à la classe.Le système utilise un moyen standard (mais spécifique à laplate-forme) pour faire correspondre le nom "hello" à un nomde bibliothèque ( "libhello.so" sur Solaris, "hello.dll" surWindows,...)

• La définition d’un en-tête de méthode native.Une méthode marquée native ne dispose pas de corps.Comme pour une méthode abstract le reste de la "signature"de la méthode (arguments, résultat,...) doit être spécifié.(ici la méthode est static mais on peut, bien sûr, créer desméthodes d’instance qui soient natives).



Réf. Sun : LJ300 Date : 20/7/98

8



Création des binaires JAVA de référence

La classe ainsi définie se compile comme une autre classe :

javac -d . HelloWorld.java

(autre exemple sous UNIX : au lieu de "-d ." on peut faire par exemple "-

d $PROJECT/javaclasses")

Le binaire JAVA généré est exploité par les autres utilitaires employés

dans la suite de ce processus.

Dans l’exemple on aura un fichier "HelloWorld.class" situé dans le sous-

répertoire "hi" du répertoire ciblé par l’option "-d"

8



Réf. Sun : LJ300 Date : 20/7/98



Génération du fichier d’inclusion C/C++

L’utilitaire javah va permettre de générer à partir du binaire JAVA un

fichier d’inclusion C/C++ ".h". Ce fichier définit les prototypes des

fonctions qui permettront de réaliser les méthodes natives de HelloWorld.

javah -d . -jni hi.HelloWorld

(autre exemple sous UNIX: javah -d $PROJECT/csources ....)

On obtient ainsi un fichier nommé hi_HelloWorld.h :

/* DO NOT EDIT THIS FILE - it is machine generated */#include <jni.h>/* Header for class hi_HelloWorld */

#ifndef _Included_hi_HelloWorld#define _Included_hi_HelloWorld#ifdef __cplusplusextern "C" {#endif/* * Class: hi_HelloWorld * Method: getGreetings * Signature: ()Ljava/lang/String; */JNIEXPORT jstring JNICALL Java_hi_HelloWorld_getGreetings (JNIEnv *, jclass);

#ifdef __cplusplus}#endif#endif

Des règles particulières régissent la génération du nom de fichier

d’inclusion et des noms de fonctions réalisant des méthodes natives.

On notera que la fonction rend l’équivallent d’un type JAVA (jstring) et,

bien qu’étant définie sans paramètres en JAVA, comporte deux paramètres

en C. Le pointeur d’interface JNIEnv permet d’accéder aux objets JAVA,

jclass référence la classe courante (on est ici dans une méthode statique:

dans une méthode d’instance le paramètre de type jobject référencerait

l’instance courante).



Réf. Sun : LJ300 Date : 20/7/98

8



Ecriture du code natif

En reprenant les prototypes définis dans le fichier d’inclusion on peut

définir un fichier source C : "hi_HelloWorldImp.c" :

#include <jni.h>#include "hi_HelloWorld.h"

/* * Class: hi_HelloWorld * Method: getGreetings * Signature: ()Ljava/lang/String; * on a une methode statique et c’est la classe * qui est passée en paramètre */JNIEXPORT jstring JNICALL Java_hi_HelloWorld_getGreetings (JNIEnv * env , jclass curclass) {

return (*env)->NewStringUTF(env, "Hello ");}

env nous fournit une fonction NewStringUTF qui nous permet de

générer une chaîne JAVA à partir d’une chaîne C.

NOTA : en C++ les fonctions JNI sont "inline" et le code s’écrirait :

JNIEXPORT jstring JNICALL Java_hi_HelloWorld_getGreetings (JNIEnv * env , jclass curclass) {

return env->NewStringUTF("Hello ");}

8



Réf. Sun : LJ300 Date : 20/7/98



Création d’une librairie dynamique

Exemple de génération sous UNIX (le ".h" est dans le répertoire courant)

#!/bin/sh# changer DIR en fonction des besoinsDIR=/usr/local/javacc -G -I$DIR/include -I$DIR/include/solaris \ hi_HelloWorldImp.c -o libhello.so

Exemple de génération sous Windows avec le compilateur VisualC++4.0:

cl -Ic:\java\include -Ic:\java\include\win32 -LD hi_HelloWorldImp.c -Fehello.dll



Réf. Sun : LJ300 Date : 20/7/98

8



Exécution

java hi.HelloWorld World underWorld Hello World Hello underWorld

Si, par contre, vous obtenez une exception ou un message indiquant que

le système n’a pas pu charger la librairie dynamique il faut positionner

correctement les chemins d’accès aux librairies dynamiques

(LD_LIBRARY_PATH sous UNIX)

8



Réf. Sun : LJ300 Date : 20/7/98


présentation de JNI

JNI est une API de programmation apparue à partir de la version 1.1 de

JAVA. Il existait auparavant d’autres manières de réaliser des méthodes

natives. Bien que ces autres APIs soient toujours accessibles elles

présentent quelques inconvénients en particulier parce qu’elles accèdent

aux champs des classes JAVA comme des membres de strcutures C (ce

qui oblige à recompiler le code quand on change de machine virtuelle) ou

parcequ’elles posent quelques problèmes aux glaneurs de mémoire

(garbage collector).

Les fonctions de JNI sont adressables au travers d’un environnement

(pointeur d’interface vers un tableau de fonctions) spécifique à un thread.

C’est la machine virtuelle elle même qui passe la réalisation concrète de ce

tableau de fonctions et on assure ainsi la compatibilité binaire des codes

natifs quel que soit la machine virtuelle effective.

Les fonctions proposées permettent en particulier de :

• Créer, consulter, mettre à jour des objets JAVA, (et opérer sur leurs

verrous). Opérer avec des types natifs JAVA.

• Appeler des méthodes JAVA

• Manipuler des exceptions

• Charger des classes et inspecter leur contenu

Le point le plus délicat dans ce partage de données entre C et JAVA et

celui du glaneur de mémoire (garbage collector): il faut se protéger contre

des déréférencements d’objets ou contre des effets de compactage en

mémoire (déplacements d’adresses provoqués par gc ), mais il faut savoir

aussi faciliter le travail du glaneur pour recupérer de la mémoire.



Réf. Sun : LJ300 Date : 20/7/98

8


JNI: types, accès aux membres, création d’objets

Soit l’exemple de classe :

package hi ;class Uni { static { System.loadLibrary("uni"); } public String [] tb ;// champ "tb" public Uni(String[] arg) { tb = arg ; }// constructeur public native String [] getMess (int n, String mess); public static native Uni dup(Uni other);

public String toString() { String res = super.toString() ; // pas efficient for (int ix = 0 ; ix < tb.length; ix ++) { res = res + ’\n’ + tb[ix] ; } return res ; } public static void main (String[] tArgs) { Uni you = new Uni(tArgs) ; System.out.println(you) ; String[] mess = you.getMess(tArgs.length, " Hello") ; for (int ix = 0 ; ix < mess.length; ix++) { System.out.println(mess[ix]) ; } Uni me = Uni.dup(you) ; System.out.println(me) ; }// main}

Exemple d’utilisation :

java hi.Uni Worldhi.Uni@1dce0764World Hellohi.Uni@1dce077fWorld

8



Réf. Sun : LJ300 Date : 20/7/98



La méthode native getMess(int nb, String mess) génère un

tableau de chaînes contenant "nb" fois le même message "mess" :

/* Class: hi_Uni * Method: getMess * Signature: (ILjava/lang/String;)[Ljava/lang/String; */JNIEXPORT jobjectArray JNICALLJava_hi_Uni_getMess (JNIEnv * env , jobject curInstance, jint nb , jstring chaine) { /* quelle est la classe de String ? */ jclass stringClass = (*env)->FindClass(env, "java/lang/String") ; /* un tableau de "nb" objet de type "stringClass" * chaque element est initialise a "chaine" */ return (*env)->NewObjectArray(env, (jsize)nb,stringClass,chaine) ;}

• La fonction NewObjectArray est une des fonctions de création

d’objets JAVA. Elle doit connaître le type de ses composants (ici

fourni par "stringClass").

L’initialisation de chaque membre d’un tel tableau se fait par

l’accesseur SetObjectArrayElement() - mais ici on profite du

paramètre d’initialisation par défaut-

• JNI fournit des types C prédéfinis pour représenter des types

primitifs JAVA (jint ) ou pour des types objets (jobject ,

jstring,.. )

• La fonction FindClass permet d’initialiser le bon paramètre

désignant la classe "java.lang.String" (la notation utilise le

séparateur "/"!).

Noter également la représentation de la signature de la fonction

"getMess": (ILjava/lang/String;) indique un premier paramètre

de type int (symbolisé par la lettre I ) suivi d’un objet (lettre L+ type + ; ) .

De même [Ljava/lang/String; désigne un résultat qui est un

tableau à une dimension (lettre [) contenant des chaînes.



Réf. Sun : LJ300 Date : 20/7/98

8



La méthode statique "dup" clone l’instance passée en paramètre :

/* Class: hi_Uni; Method: dup * Signature: (Lhi/Uni;)Lhi/Uni; */JNIEXPORT jobject JNICALL Java_hi_Uni_dup (JNIEnv * env, jclass curClass , jobject other) { jfieldID idTb ; jobjectArray tb ; jmethodID idConstr ; /* en fait inutile puisque c’est curClass !*/ jclass uniClass = (*env)->GetObjectClass(env, other) ; if(! (idTb = (*env)->GetFieldID (env,uniClass, "tb","[Ljava/lang/String;"))) return NULL ; tb = (jobjectArray) (*env)->GetObjectField(env, other,idTb) ;

/* on initialise un nouvel objet */ if(!(idConstr = (*env)->GetMethodID(env, curClass, "<init>", "([Ljava/lang/String;)V"))) return NULL ; return (*env)->NewObject(env, curClass,idConstr,tb) ;}

• La récupération du champ "tb" (de type tableau de chaîne) sur

l’instance passée en paramètre se fait par la fonction

GetObjectField . On a besoin de la classe de l’instance consultée

et de l’identificateur du champ qui est calculé par GetFieldID .

• De la même manière l’appel d’une méthode nécessite une classe et

un identificateur de méthode calculé par GetMethodID .

Ici ce n’est pas une méthode qui est appelée mais un constructeur

et l’identifiant est calculé de manière particulière ("<init>"), le type

indique un paramètre de type tableau de chaîne et un "résultat"

qui est void (lettre V ) .

JNI fournit ainsi des accesseurs à des champs

(Get< static ><type >Field , Set< static ><type >Field ) et des

moyens d’appeler des méthodes (Call< statut ><type >Method :

exemple CallStaticBooleanMethod ). Il existe, en plus, des méthodes

spécifiques aux tableaux et aux Strings

8



Réf. Sun : LJ300 Date : 20/7/98


références sur des objets JAVA:

Le passage du glaneur de mémoire sur des objets JAVA pourrait avoir

pour effet de rendre leur référence invalide ou de les déplacer en

mémoire. Les reférences d’objet JAVA transmises dans les transitions vers

le code natif sont protégées contre les invalidations (elles redeviennent

récupérables à la sortie du code natif).

Toutefois JNI autorise le programmeur à explicitement rendre une

référence locale récupérable. Inversement il peut aussi se livrer à des

opérations de "punaisage" (pinning) lorsque, pour des raisons de

performances, il veut pouvoir accéder directement à une zone mémoire

protégée :

const char * str = (*env)->GetStringUTFChars(env, javaString,0) ;.... /* opérations sur "str" */(*env)->ReleaseStringUTFChars(env, javaString, str) ;

Des techniques analogues existent pour les tableaux de scalaires primitifs

(int, float, etc.). Bien entendu il est essentiel que le programmeur C libère

ensuite la mémoire ainsi gelée.

Si on veut éviter de bloquer entièrement un tableau alors qu’on veut

opérer sur une portion de ce tableau , on peut utiliser des fonctions

comme :

void GetIntArrayRegion(JNIenv* env, jintArray tableau, jsize debut, jsize taille, jint * buffer) ;void SetIntArrayRegion(....

Le programmeur a aussi la possibilité de créer des reférences globales sur

des objets JAVA. De telles références ne sont pas récupérables par le

glaneur à la sortie du code natif, elles peuvent être utilisées par plusieurs

fonctions implantant des méthodes natives. Ici aussi il est de la

responsabilité du programmeur de libérer ces références globales.



Réf. Sun : LJ300 Date : 20/7/98

8


exceptions

JNI permet de déclencher une exception quelconque ou de recupérer une

exception JAVA provoquée par un appel à une fonction JNI. Une

exception JAVA non récupérée par le code natif sera retransmise à la

machine virtuelle .

....jthrowable exc;(*env)->CallVoidMethod(env, instance , methodID) ;/* quelque chose s’est-il produit? */exc = (*env)->ExceptionOccurred(env);if (exc) { jclass NouvelleException ; ... /* diagnostic */ /* on fait le ménage */ (*env)->ExceptionClear(env) ; /* et on fait du neuf ! */ NouvelleException = (*env)->FindClass(env, "java/lang/IllegalArgumentException") ; (*env)->ThrowNew(env,NouvelleException, message);}...

8



Réf. Sun : LJ300 Date : 20/7/98


invocation de JAVA dans du C

/*lanceur.c * usage : lanceur <classe_JAVA_en_format_/> <args> */JavaVM *jvm ;JNIEnv * env;JDK1_1InitArgs vm_args ; /* 1.2 : JavaVMInitArgs */

main(argc, argv) int argc; char ** argv; { int cnt ; jint res ; jclass mainclass ; jmethodID methodID; jobjectArray jargs ; /* ici controles de lancement a faire */ .... /* initialisation des champs de vm_args ATTENTION*/ vm_args.version = 0x00010001 ; /* CHANGE en 1.2 ! */ /* appel obsolete en JAVA 1.2 */ res = JNI_GetDefaultJavaVMInitArgs(&vm_args) ; /* APPEL OBSOLETE (non portable). CHANGE en 1.2 */ vm_args.classpath = getenv("CLASSPATH"); if (0> JNI_CreateJavaVM(&jvm, &env, &vm_args))exit(1) ;

if (!(mainclass= (*env)->FindClass(env,argv[1]))) exit(1); if(!(methodID= (*env)->GetStaticMethodID(env,mainclass, "main","([Ljava/lang/String;)V")))exit(2); .... jargs = (*env)->NewObjectArray(env,(jsize)(argc-2), (*env)->FindClass(env,"java/lang/String"), NULL) ; for (cnt = 0 ; cnt < (argc - 2) ; cnt++) { jobject stringObj = (*env)->NewStringUTF(env, argv[cnt+2]); (*env)->SetObjectArrayElement(env, jargs,(jsize)cnt,stringObj); } (*env)->CallStaticVoidMethod(env, mainclass, methodID, jargs) ; ..... (*jvm)->DestroyJavaVM(jvm) ;}

Un tel code doit être lié à la librairie binaire JAVA (libjava.so sous

UNIX).

La version de JAVA 1.2 introduit quelques modifications (voir

documentation).



Réf. Sun : LJ300 Date : 20/7/98

Recommandations de programmation 9

Objectifs

Dans ce document nous avons rassemblé quelques considérations sur la

manière de coder en JAVA.

Ces remarques sont faites pour guider vos recherches plutôt que pour

édicter des règles intangibles. JAVA étant un langage neuf l’essentiel des

savoir-faires est encore en gestation.

• organisation en "packages"

• conventions de codage

• portabilité

• performances

• traces, exceptions

• Le "bon" et le "beau" code

• les interactions graphiques

• la répartition

• l’internationalisation

• l’intégration de code natif

9



Réf. Sun : LJ300 Date : 20/7/98

Recommandations de programmation

Organisation des packages et des répertoires

• Ne pas développer de classe sans qu’elle soit rattachée à un

package . Un package regroupera un ensemble de classes reliées

par des objectifs communs.

L’instruction "package XXXX ; " doit être la première d’un

fichier ".java".

• Le package permet de créer un espace de nommage. Par exemple

ont peut utiliser plusieurs classes "Rectangle" tant que chacune

existe dans un package différent (et que l’on sait lever les

ambiguités en les désignant dans le code).

Il est recommandé de préfixer tous les packages d’une socitété ou

organisation par l’identification Internet de cette organisation.

Exemple: soit la société ACME (adresse "acme.com"); alors un

package pourra se déclarer comme :

package com.acme.finance.swap ;

• Bien que ça ne soit pas strictement obligatoire il est vivement

conseillé de faire correspondre une hiérarchie de répertoires à la

hiérarchie de packages. Exemple (sous Unix) :

package projet1.package1; // dans Fichier.javajavac projet1/package1/Fichier.javajava projet1.package1.Fichier<APPLET code="projet1.package1.Applet2.class"...

• Autre idée d’organisation utile : séparer soigneusement la

hiérarchies des répertoires contenant les sources ".java" deshiérarchies contenant les fichiers ".class"

• avantages : permet de disposer de plusieurs types de fichiers

".class" (avec debug, optimisé, avec ou sans traces, etc.), permet

de développer et tester des modifications pendant que les

autres développeurs utilisent l’ancienne version des classes,

etc.

• inconvénients : demande une bonne maîtrise des CLASSPATH

et du comportement du compilateur (en particulier au niveau

de la recherche de mise à jour des classes dépendantes)

• ATTENTION : Au sein d’une application le ClassLoader peut être

amené à charger autre choses que des ".class" (par ex. des fichiers

de ressources -images, properties,etc.-) Ces ressources font partie

des hiérarchies de package et il faut s’organiser en conséquence.



Réf. Sun : LJ300 Date : 20/7/98

9


convention de codage

références :

De nombreux sites (on constatera qu’il n’y a pas unanimité sur les règles à

suivre!), voir par ex:

http://g.oswego.edu/dl/html/javaCodingStd.html

Identificateurs (conventions standard)

• Classes et interfaces : MaClasse , MonInterface

• Constantes de Classe : MAX, MAX_SIZE

• Variables, méthodes : maVariable , maMethode ()

Identificateurs (conseils complémentaires)

• Eviter les caractères "_" et "$" au milieu des identificateurs (risques

de confusion avec des identifiants générés pour les classes internes

ou les méthodes natives)

• Certaines conventions de nommage sont standard :

• Conventions "Beans" (obligatoires pour permttrel’instrospection) : Accesseurs (propriétés), Propriétésbooléennes, Propriétés indexées, méthodes sur événements,..// Accesseur simplepublic PropertyType get PropertyName ()public void set PropertyName ( PropertyType x)

• Conventions RMI :public class Account Impl extendsUnicastRemoteObject

implements Account {

• Conventions spécifiques aux méthodes natives

9



Réf. Sun : LJ300 Date : 20/7/98


convention de codage (suite)

Nommage (conseils complémentaires)

• Eviter les excès bureaucratiques : il est souhaitable que chaque

nom soit facilement lisible et que l’on comprenne l’intention

sémantique qui lui est associé, par contre un excès de règles

formalisées n’est pas forcément un plus!

Exemple: obliger les programmeurs à mettre dans le nom une

indication qui rappelle de type de l’objet est plutot génant -

surtout si ce type est amené à changer au cours du

développement-.

• Nommage des Exceptions :

ToutVaMalException ;

• L’emploi de variables nommées "i", "j", "x", "p" etc. n’améliore pas

la lisibilité. De plus avec la plupart des éditeurs la recherche des

endroit où ces variables sont employées peut s’avérer difficile!

(préférer alors "iy", "ix", etc.)



Réf. Sun : LJ300 Date : 20/7/98

9


convention de codage (suite)

Mise en page

• Mettre en place des règles cohérentes de mise en page :

// alignements des accoladespublic void maMethode(int arg) { //indentations internes correctes ...}//End maMethode

if ( cestVrai ) { // on met les accolades // même pour une seule instruction }

• Rendre lisibles les sources : limiter le nombre de caractères par

ligne (et fixer des règles de continuation sur la ligne suivante),

penser à des règles de présentation des commentaires, etc. Penser

à écrire des squelettes standard de fichiers pour Classes, Applets,

etc. de nombreux éditeurs savent utiliser de tels modèles.

• Attention : certains éditeurs (Emacs par ex.) font de l’analyse du

code non par analyse syntaxique mais par "pattern-matching", le

non-respect de certains règles peut perturber la mise en page

automatique du code.

• Pour harmoniser la description de types (voir remarque ci-dessus)

préférer la notation :

String[] argsà

String args[] ; // pour les nostalgiques du C !

• Autre rappel aux nostalgiques du langage C : il n’est pas

nécessaire de concentrer toutes les déclarations de variables locales

en début de bloc. On peut déclarer la variable le plus près possible

de l’endroit où on l’utilise -décision à prendre en fonction de

critères de maintenabilité-.

9



Réf. Sun : LJ300 Date : 20/7/98


portabilité

références :

http://java.sun.com/100percent/

"Write once, run everywhere" tel est le slogan de JAVA. Si la portabilité est

un des points forts de JAVA elle n’est pas entièrement automatique: il est

parfaitement possible d’écrire des programmes non-portables!

On trouvera en fin de ce support une copie d’un document en Anglais

décrivant les principales précautions à prendre pour éviter d’écrire du

code non-portable.

Plus important encore: un Label "100%" JAVA peut être accordé aux

produits que vous développez.

Une autre difficulté peut surgir lorsque JAVA évolue et que les nouveaux

codes ne sont pas totalement compatibles avec les anciens. Ainsi le

passage de la version 1.0 de JAVA à la version 1.1 a donné lieu à de

nombreux problèmes d’adaptation des Applets puisque des Applets

publiées sur le WEB pouvaient être mis en oeuvre par des clients ayant

des niveaux différents de JAVA.

Le site java.sun.com publie les techniques pratiques concernant de telles

mises à jour. Même si elles donnent lieu à quelques récriminations ces

modifications sont aussi une garantie d’évolution et de recherche de

qualité! Pour ce qui est de la mise à jour des navigateurs voir JAVA

PLUGIN (module de mise à jour des JVM liées au navigateurs)



Réf. Sun : LJ300 Date : 20/7/98

9


performances

références :

Ici aussi de nombreux sites parlent des optimisations JAVA. par ex:

http://www.cs.cmu.edu/~jch/java/optimization.htm l

ou les articles spécialisés dans "JavaWorld"

Il y a de très nombreuses "recettes" pour des optimisations de détail (de

plus ceci peut varier en fonction des compilateurs et des JVM). Quelques

constantes :

• L’opération "new" coûte cher. Penser à réutiliser directement les

objets dont vous n’avez plus besoin. Toutefois ceci peut rentrer en

contradiction avec une architecture comprenant des variables

membres qui sont "final" (il y a donc des choix à faire).

• On peut aider le glaneur de mémoire (garbage collector) en mettant

explicitement des références à null ( par exemple pour des

membres inutilisés d’un tableau).

• L’exploitation des moniteurs (synchronized ,..) coûte très cher.A

utiliser avec modération (en particulier dans les classes utilitaires

de "bas niveau"). Pour des cas extrêmes de performances dans les

Threads l’utilisation de bibliothèques de Threads natifs permet

l’utilisation des architectures multi-processeurs.

• Le problème numero 1 des performances est celui de la complexitécachée : combiner l’action des plusieurs composants de haut

niveau avec une encapsulation parfaite conduit parfois à ce que

chacun fasse plusieurs fois le même travail de son coté. La

détection de ces anomalies est particulièrement ardue si on fait

collaborer plusieurs composants pour lesquels on n’a pas accès au

code. Attention donc à l’usage indiscriminé de composants "gros

consommateurs"

• Les classiques : faire des E/S bufferisées, ne pas réécrire en JAVA

ce qui existe dans les méthodes d’API (ex. arraycopy ()),

conserver certaines valeurs utiles, etc.

9



Réf. Sun : LJ300 Date : 20/7/98


traces, exceptions

• Comment laisser dans les sources du code dédié aux traces sans

que ce code soit toujours compilé et inclus dans les exécutables ?

(Rappel: il n’y a pas en JAVA de préprocesseur permettant des

compilations conditionnelles)

Solution : utiliser des variables booléennes static et final (dont la

valeur est connue au moment de la compilation), le code protégé

par une condition (if) pour laquelle le compilateur se rendra

compte qu’elle est toujours fausse ne sera pas inclus dans le

binaire.

Exemple:

if( Trace.DEBUG && (Trace.traceMask > 8)) {// code de trace

}

• La spécification des exceptions doit faire partie des spécifications

générales d’un projet. On doit, dès le départ, définir les grandes

lignes du traitement d’exception pour que les programmeurs ne

laissent pas le code correspondant dans un état mal défini (qui

n’est jamais ensuite repris!).

Quelques suggestions :

• Définir quelques classes d’exceptions de base dont toutes lesautres exceptions seront dérivées : on pourra ainsi mettre enplace, en temps utile, des mécanismes adaptés qui serontappelés au moment du déclenchement de l’exception. Ex.mettre en place une trace conditionnelle de la pile, etc.

• Déterminer quels appels de méthodes mettre en place aumoment de la récupération de l’exception. On pourra ensuitemettre au point des récupérations sophistiquées.Il est en effet dommage de se contenter d’écrire un message surla sortie d’erreur standard alors qu’on peut, par exemple, faireparvenir à l’utilisateur un message simplifié pendant que l’onenvoie (par mail) un message détaillé à l’administrateur, ou àl’équipe de maintenance.

• Pour les applications gérant des transactions critiques lemécanisme finally doit être employé avec discernement : ilfaut que toute opération de terminaison soit sans effet si elle estsans objet (exemple: envoyer un close ne fait rien si open n’apas été appelé)



Réf. Sun : LJ300 Date : 20/7/98

9


le "bon " et le "beau" code ?

Il est ici hors de question de définir ce qui caractérise un "bon" code, de

plus il n’y a pas encore de consensus sur ce que sont d’une part les

constructions potentiellement dangereuses et d’autre part ce qui

caractérise un code bien architecturé en terme d’évolutivité, lisibilité, etc.

Toutefois une équipe de développement JAVA se doit de tenir à jour un

registre des savoir-faires et d’en discuter la pertinence lors des revues de

code.

Quelques exemples de constructions à documenter :

• La redéfinition d’une variable d’instance dans un héritage (data-hiding): produit en général des effets non-évidents

• Dans une surcharge de méthode la définition de deux méthodes

qui diffèrent simplement du fait de types objet situés dans la

même hiérarchie risque de produire des effets indésirables.

methode(Pere x) { .... }methode(Fils x) {.... } ;

• Appels de méthodes dans un constructeur: à contrôler de près. En

effet on doit, dans un constructeur, se limiter à réaliser des

initialisations. Lancer des traitements peut se révéler hasardeux

car l’objet peut être dans un état incomplet (par exemple on va

appeler une méthode redéfinie dans le fils alors que l’on est dans

l’initialisation de "super").

Le problème est particulièrement délicat dans AWT où l’on peut

être tenté de tout décrire dans le constructeur d’un Frame par ex.

Il est donc de bon ton de doter ce Frame d’une méthode appelée

init(), ou go() ou autre et qui soit explicitement appelée après les

initialisations minimum du constructeur -cette méthode

contiendra l’essentiel du code qui sera en attente d’interactions-.

9



Réf. Sun : LJ300 Date : 20/7/98


• Documenter particulièrement les objets qui peuvent servir de

support à une opération synchronized ou un wait . Il serait

dommage que, par inadvertance, un programmeur oublie de

synchroniser d’autres accès.

Par ailleurs veiller à mettre un wait dans une boucle retestant la

condition (on n’est pas sûr au reveil que cette condition soit

remplie). Faire attention aux inter-blocages : ne pas utiliser

suspend /resume et préferer notifyAll .

• Eviter les effets de bord par modification du contenu d’objets

passés en paramètre à une méthode. Si une méthode doit modifier

l’état d’un de ses paramètres il vaut mieux qu’il soit rendu en

résultat.

Outre le fait que ce comportement est considéré comme

théoriquement malsain, il va être génant si cette méthode connait

une réalisation via RMI.

De même documenter la non-utilisation d’un résultat de méthode :

Object inutilisé = maMethode(ix) ;

• Il est possible que l’emploi d’un == entre objets et d’un = dans un

test ne corresponde pas à l’intention du programmeur.

Dans un cas c’est souvent un obj1.equals(obj2) qui est

recherché , dans l’autre c’est un == (le compilateur va d’ailleurs le

détecter sauf si on tente d’écrire des expressions comme " if(cond == true )" au lieu de "if (cond )" )

• Autant que possible initialiser explicitement les variables membres

class MaClasse {Vector vect = new Vector() ;

// sinon risques en accédant vect

• Bien qu’une Applet soit un Panel son utilisation dans une

application autonome (ou dans une autre Applet) demande des

précautions très particulières. En effet de nombreux services

(getDocumentBase, getImage, etc.) dépendent de la présence de

AppletStub et AppletContext.

• Penser à l’internationalisation. En AWT ne pas baser le

comportement du programme sur une valeur “en dur” d’une

étiquette : passer par “setActionCommand(), setName(),...” pour

distinguer les noms symboliques des composants et des actions

associées de leur étiquette affichée.



Réf. Sun : LJ300 Date : 20/7/98

9


le "bon " et le "beau" code ?

Quelques autres thèmes de discussion :

• Importer explicitement une classe d’un package plutôt que

d’importer avec "import pack.* ; "

• Un main de test peut accompagner chaque classe ayant une

fonction bien délimitée. Pour des points d’entrée d’application

faire une classe à part pour le main .

• Choix concernant l’encapsulation : préférer protected à

private ; ne pas définir systématiquement des accesseurs quand

des membres "blank final" (constantes en attente d’initialisation)

suffiraient:

final String clef ;// initialisée dans constructeur

• Pour les classes destinées à connaître une instanciation

dynamique faut-il systématiquement définir un constructeur sans

argument -appelable par newInstance()- doublé d’une méthode

d’initialisation des champs, ou prévoir de faire appel à la classe

Constructor? Dans le premier cas on bénéficie de contrôles au

moment de la compilation mais on ne peut pas toujours tout faire.

Un des points critiques du "beau" code : la programmation AWT. Le

débutant a souvent tendance à créer un code mal architecturé : il est

difficile de "voir" la dispositon et de la faire évoluer. Le codage demande

donc de gros efforts de discipline :

• Ne pas disperser les références à un objet graphique sur

l’ensemble du code. On crée un Container, on dispose son contenu

et ceci récursivement dans la hiérarchie des Containers. Ceci

suppose que l’on crée des blocs de code (ou des méthodes) qui

isolent chaque élément architectural de la disposition.

Ce découpage demande beaucoup de soins car il faut savoir

rapprocher les objets d’interactions des objets applicatifs : les

points critiques sont alors la définition des Listeners (utiliser

plutôt des classes internes qui ont accès aux données locales) et les

objets graphiques qui doivent avoir accès aux données locales

mais qui sont situés dans un autre zone de disposition (par ex.

dans une barre d’outils éloignée du Panel local -il faut imaginer

un échange entre ce Panel et la barre d’outils-)

9



Réf. Sun : LJ300 Date : 20/7/98


Comparer les techniques employées dans ces deux exemples :

// VERSION 1

public class ButtonPanel extends Panel { public ButtonPanel(Actor[] tAct) { super(new FlowLayout(FlowLayout.LEFT)) ; for (int ix = 0 ; ix < tAct.length; ix++) { Button but = new Button(tAct[ix].message) ; but.addActionListener(tAct[ix].act) ; add(but) ; } }

//avec Actor {String message ;ActionListener act ;...}

// VERSION 2

public class ButtonPanel2 extends Panel implements ActionListener{ Button b1, b2 ; public ButtonPanel2 () { super(new FlowLayout(FlowLayout.LEFT)) ; b1 = new Button ("Hello") ;

b1.addActionListener(this) ;b2 = new Button ("World") ;

b2.addActionListener(this) ;add(b1) ;add(b2) ;

}

public void actionPerformed (ActionEvent evt) { Object source = evt.getSource() ; if (source == b1) { // action sur b1 } else if (source == b2) { // action sur b2 } }}



Réf. Sun : LJ300 Date : 20/7/98

9


les interactions graphiques

La conception visuelle d’une interaction graphique est un véritable métier

qui fait appel à des compétences diverses concernant l’ergonomie et le

"design". L’objectif peut se résumer en un conseil particulièrement

difficile à suivre : FAIRE SIMPLE!

Quelques incitations ;

• Eviter de présenter trop de fonctions diverses sur un même écran.

L’utilisateur doit être concentré sur un petit nombre d’objectifs.

D’un autre coté il faut aussi éviter de disperser les interactions sur

une succession d’écrans de saisie (l’utilisateur ne sait plus se

situer, et la navigation est trop directive).

• Eviter la dispersion visuelle (même souci que précédemment).

Eviter les "papillotements" : objets graphiques dispersés sans que

des lignes de force apparaissent, contrastes graphiques fatigants,

arrivées d’informations ou animations intempestives.

• JAVA permet de faire de belles choses : profitez-en! Sachez

dépasser l’aspect "terminal de saisie grand systèmes" (une

succession de formulaires), l’aspect "tableau de bord d’avion" (des

informations partout, sur un fond gris) mais n’en faites pas trop

tout de même (certains designs très "mode" sont saisissants pour

vendre un produit mais insupportables pour une utilisation

journalière)

• Connaissez le métier de l’utilisateur. On ne conçoit pas de la même

manière une interaction s’adressant à un utilisateur novice (et qui

doit favoriser l’apprentissage) et une interaction pour un

utilisateur professionnel. Un "trader" qui travaille veut aller très

vite et préfére souvent pouvoir se limiter à quelques interactions

clavier, il souhaitera qu’après chaque action le "focus" aille en

priorité sur certaines zones, il souhaitera pouvoir configurer lui

même son poste pour en attendre certains comportements.

• Quelle personnalisations? Changer de police de caractères,

changer les accélérateurs, changer de palettes de couleur (vaut

mieux que de changer les couleurs trop librement),.. Pour un

"trader" ce qui est critique c’est la personnalisation de sa vision des

cours et de leur évolution, chacun a son truc et sa formule et sera

même prêt à écrire un programme JAVA spécifique! Profitez donc

de la dynamicité de JAVA pour définir une API d’extension...

9



Réf. Sun : LJ300 Date : 20/7/98


répartition

Un des points forts de JAVA est de permettre de diffuser du code

"nomade" sur le réseau et de fournir tous les mécanismes de sécurité

associés à cette exécution dynamique et locale d’un code "étranger".

On peut utiliser des mécanismes prédéfinis comme celui des Applet s,

ou on peut , au travers de RMI par ex., télécharger le comportement d’un

Objet et l’utiliser dynamiquement .

Un des choix fondamentaux de la répartition en JAVA est bien celui des

préalables : les partenaires d’un échange connaissent-ils avant l’échange le

détail du comportement des objets? par exemple RMI connait deux mode

de fonctionnement : un dans lequel les objets sont définis de chaque coté

(et l’on échange des instances), l’autre dans lequel on découvre

dynamiquement des objets nouveaux.

A chaque type de comportement sont associés des savoir-faires

spécifiques et des décisions stratégiques importantes.

Prenons le cas des Applet s:

• Avantages : pas de problème de déploiement, le code (et donc le

protocole) est automatiquement à jour (dans les systèmes

client/serveur classique l’harmonisation des versions tourne au

cauchemar); Les mécanismes de sécurité sont pleinement actifs,

cela permet de s’adapter à toute une gamme de clients plus ou

moins "proches".

• Inconvénients : le téléchargement peut prendre du temps; les

contraintes de sécurité peuvent s’avérer trop contraignantes

(impressions locales, communications avec d’autre serveurs,...); le

contrôle d’exécution au sein sein d’un navigateur peut s’avérer

insuffisant pour certaines applications (on peut se retrouver avec

une transaction incomplète parcequ’un utilisateur peut passer à

autre chose...)

Au niveau graphique, il faut beaucoup de réflexion pour définir

une interface qui découvre dynamiquement des objets (et qui soit

de plus haut niveau que l’API des Applet) .



Réf. Sun : LJ300 Date : 20/7/98

9


répartition (suite)

les protocoles

• La définition des protocoles doit permettre une évolutivité

maiximum: les actions élémentaires devraient être définies par

des interfaces; les paramètres des méthodes devraient être au

maximum encapsulés (c.a.d. être eux-même des objets ou des

interfaces); les objets passés doivent tenir compte des contraintes

de linéarisation et éviter les effets de bord (tous les paramêtres

sont passés réellement en copie); dans les types en retour prévoir

des extensions futures de code d’acceptation.

// delicat a maintenirvoid creeClient(String nom, String id, String prenom);

// plus evolutifAcceptation creeClient(Client client) throws CreationRightsException, UniqueIDException;// Acceptation peut contenir un certificat, un Objet// qui en l’occurence p.e. un Client avec mise a jour// d’un champ qui fixe un numero à ce client

• Veiller aux propriétés de linéarisation des objets (transient , etc.)

pour éviter de transférer plus d’informations que nécessaire.

• Définir le type de relation Client/Serveur :

• protocole sans état : le client établi une connexion, fait unrequête et la connexion est coupée. Le serveur ne conserveaucun contexte.

• session sans conservation de connexion : Le serveur mémorisel’appel du client et lui conserve un contexte.

• session avec conservation de connexion : une connexion resteactive pendant toute la durée du dialogue.

9



Réf. Sun : LJ300 Date : 20/7/98


internationalisation

références :

documentation JDK docs/guide/intl/index.html

Comme pour le traitement des exceptions les mécanismes

d’internationalisation d’une application doivent être arrétés avant le

démarrage du codage (la réintroduction a posteriori de code

d’internationalisation est pénible et très facilement erronée).

Les objets de type java.util.Locale permettent de désigner une "aire

culturelle" (par ex. Français sous-variété Canadienne). A partir de cette

information il est possible de paramétriser des formats (formats de date,

de nombre, etc.) et des opérations sur chaînes (recherche de "mots", tri

alphabétiques). Le package java.util.text offre aussi des outils

permettant de paramétriser des désignations (ex. dans un menu) et des

messages (ex. messages d’erreur).

Au fur et à mesure que l’on enrichira les aires culturelles pour lesquelles

une application sera susceptible d’être intelligible, il faudra mettre à jour

des ressources contenant les versions localisés des messages ou des

formats de message (c.a.d. des chaînes de caractères contenant des

emplacements pour des valeurs renseignées par le programme : montants,

numéros de ligne, etc.).

Il faut donc organiser ces ressources en utilisant le mécanisme des

java.util.ResourceBundle qui permet d’organiser des hiérarchies

de ressources : ainsi si une information n’est pas spécifique à l’aire du

Canadien Français on la retrouvera dans l’aire du Français.

Un des choix fondamentaux est la manière d’indexer les messages : faut-il

opérer en passant par un nom symbolique

("erreur.securite.droit_creation") ou en utilisant directement le message

comme clef de recherche? Ce second choix est plus facile pour le

programmeur car il n’a pas à attendre de décision sur la définition d’un

nouveau type d’erreur et peut être immédiatement opérationnel pour des

tests. Par contre il n’est pas réalisable avec le mécanisme par défaut

(PropertyResourceBundle ) et il peut conduire à une dispersion des

types d’erreurs. Il faut, de plus, construire un outil qui extraie (et qui

maintienne) automatiquement la base des messages de l’application.



Réf. Sun : LJ300 Date : 20/7/98

9


intégration des méthodes natives

Un code natif est potentiellement un point faible à la fois pour la sécurité

et pour la robustesse générale de l’application.

Sur ce dernier point quelques "recettes" concernant JNI:

• Toujours tester les résultats de retour des fonctions découvrantdynamiquement des classes, attributs, méthodes,..(FindClass, get*ID ): l’utilisation, par la suite, dedésignations JAVA inexistantes, est une garantie d’accidentgrave.

• Vérifier si une exception n’a pas a été levée chaque fois qu’unefonction d’interface appelle du code JAVA susceptible dedéclencher un exception.

• Sauf pour des "petits" codes natifs penser à protéger l’exécutionpar captation des signaux (y compris ceux signalant uneviolation mémoire grave) -voir fonctions standard C signal ..-.

• Ne pas conserver des références locales, ne pas les passer entreThreads, s’assurer de l’appariement des fonctions réservant deszones mémoires et de celles qui les libèrent (variables globales,"punaisage"). Utiliser le "punaisage" partiel pour de grostableaux.

... et, bien entendu, isoler soigneusement tout code posant des problèmes

de portabilité (facilité de maintenance, de portage) ou des problèmes de

sécurité (essayer d’avoir une politique cohérente de sécurité avec le code

JAVA lui-même -à partir de JAVA 1.2 on peut définir une politique de

sécurité pour des applications "locales"-).

9



Réf. Sun : LJ300 Date : 20/7/98




Réf. Sun : LJ300 Date : 20/7/98

L’atelier de développement 10

Objectifs

Ce chapitre constitue un aide-mémoire1 pour la réalisation d’une chaîne

de production JAVA. On y trouvera :

• Une liste des fonctions et des outils susceptibles de constituerune telle filière.

• Des indications sur les points à surveiller. Ces critères ne sontpas extensifs mais peuvent servir de point de départ à desréflexions sur le choix et le calibrage des outils.

Le marché des outils JAVA évoluant très vite il est conseillé de consulter

les sites qui les recensent (par ex. javaworld)

1. Ce chapitre ne développe pas l’architecture générale d’une chaine dedéveloppement : on reste dans le contexte d’un projet classique, lesorganisations adaptées à l’approche par composants (CBSD) nécessitent desstratégies particulières.Référence générale à consulter : http://www.sei.cmu.edu/technology/str

10



Réf. Sun : LJ300 Date : 20/7/98

L’atelier de développement

introduction : R.A.D et/ou maîtrise du code de base?

Le developpement logiciel est souvent décrit comme passant par les

phases suivantes :

• Analyse

• Conception

• Réalisation/codage

• Tests

• Révisions

Toutefois si on tente de réaliser ces phases les une après les autres tout en

appliquant des règles sévères de qualité on court des risques importants

de dérive (évolutions des besoins non prises en compte par la réalisation,

difficultés imprévues de réalisation qui obligent à revoir la conception,

etc.).

Le cycle de développement optimum est le plus souvent une "spirale"

dans laquelle on procède par itérations successives. La réalisation d’une

maquette, puis de prototypes avec raffinements successifs permettent de

réinjecter les leçons de la réalisation dans l’analyse et la conception. Les

tests, présents dans toutes ces phases, permettent de calibrer le produit en

préparation et de marquer de manière incontestable l’avancement du

projet (ce qui est éventuellement utile pour débloquer des financements!).

Pour accélérer le cycle de développement un certains nombres d’outils,

dits de R.A.D. (Rapid Application Development), permettent, au travers

d’interfaces essentiellement interactives , d’intégrer des composants

spécialisés (interactions utilisateurs, accès aux bases de données,

client/serveur, etc.).

Au delà de la grande diversité de ces produits il faut savoir apprécier

leurs limites et savoir adapter la qualité de fabrication du code en

fonction des moyens et des objectifs poursuivis: veut-on fabriquer un

logiciel pour une diffusion restreinte ou pour une diffusion large? quelles

sont les marges d’adaptabilité que l’on se fixe? quels sont les objectifs de

fiabilité ? etc.



Réf. Sun : LJ300 Date : 20/7/98

10


introduction : au delà du R.A.D?

Quelques critiques courantes concernant les outils de R.A.D :

• On est tenté de confondre "maquette" et "produit".De plus l’interaction utilisateur EST l’application : on tend àéconomiser sur la phase de conception ce qui est mauvais pourl’abstraction, l’architecture du logiciel, l’évolutivité. La mise enplace de tests systématiques devient difficile.

• L’outil de R.A.D. est indissociablement lié à des composants"proprétaires" que ce soit dans la phase de conception ou dansla phase d’exécution.L’enrichissement de la conception à l’aide de composantsdéfinis par le programmeur est limité.Par ailleurs le produit livré en clientèle suppose souvent laprésence de binaires spécifiques (problèmes de royalties, deportages, de maintenance,...). Dans d’autres cas c’est le codegénéré qui est opaque et difficile à debuguer et maintenir.De plus on ne peux pas avoir des composants interchangeaglesqui permettraient de modifier des détails de comportement (ex.modalités d’échanges client/serveur).

Une des grandes forces des environnements JAVA est de permettre de

graduer le choix des outils et de les combiner en fonction des objectifs:

le marché offre des outils très divers allant de la génération rapide de

maquettes jusqu’à la filière de production "lourde". On peut concevoir en

JAVA un outil de RAD débarrassé des défauts ci-dessus et le faire

coopérer, en amont ou en aval, avec des filières de contrôle étroit du code.

Il y a dans JAVA lui-même des dispositifs qui facilitent la production du

logiciel, citons pour exemple:

• L’organisation par "objets", la dynamicité, les APIs ("Beans" enparticulier). On a la possibilité de définir de véritablescomposants réutilisables (soit directement soit par dérivationde composants existants). Les outils eux-mêmes ont lapossibilité d’intégrer dynamiquement ces composants (ex."beanbox").

• La prise en compte des leçons de la filière C/C++ : éliminationdes constructions dangereuses, portabilité, liaisons code-documentation, etc. Par ailleurs les outils de production JAVAprofitent des démarches abordées dans ces filières précédentes.

10



Réf. Sun : LJ300 Date : 20/7/98


L’intégration des outils, les ateliers

Une chaîne de production professionnelle n’est pas destinée à un seul

acteur, elle doit impliquer des personnes ayant des rôles différents depuis

le programmeur jusqu’au chef de projet. Il est important que les outils

impliqués dans les différentes phases puissent se coordonner facilement.

De plus certaines tâches sont purement interactives, d’autres relèvent au

contraire de tâches de fond en batch.

Il est de pratique courante de lier les productions des différents outils au

travers de scripts exploitant des fichiers (sources, binaires, traces, etc.) et

des règles de déclenchement (Makefile)

Les "ateliers" de programmation, qui sont au centre de l’activité de

production, doivent faire preuve d’un minimum d’ouverture soit en

exportant leurs fichiers et des règles cohérentes d’accès à ces fichiers, soit

en publiant une API d’accès à leurs ressources.

Les API d’accès en JAVA devraient normallement connaître un fort

développement à la fois pour assurer ces liaisons et pour permettre des

personnalisations approfondies des outils.

Exemple : de nombreux ateliers sous-traitent la partie "gestion de version"

à des produits tiers; la présence d’une API permet de changer le produit à

qui cette tâche est confiée.



Réf. Sun : LJ300 Date : 20/7/98

10


analyse et conception

La notation UML va permettre d’harmoniser le langage des descriptions

des systèmes décrits à l’aide des concepts objets.

Si les outils d’analyse et de conception sortent du cadre de ce cours on

retiendra toutefois qu’ils n’échappent pas à la nécessité d’assurer une

coordination avec l’ensemble du processus de production de logiciel.

Le cas le plus délicat est celui de la génération automatique de code. Les

squelettes de code générés sont amenés à être complétés et modifiés, le

corps des méthodes va être décrit, etc. Il faut que soient facilités :

• La reprise du code existant dans des spécifications modifiées.

• La modification des spécifications elles-mêmes par reinjectiondes modifications acquises dans le code.

• La liaison avec les systèmes de gestion de version de code(établissement de la version des spécifications : voirjava.lang.Package à partir de la version 1.2)

10



Réf. Sun : LJ300 Date : 20/7/98


L’éditeur

Au delà de qualités classiques d’ergonomie un éditeur de programme

source sera plus riche s’il dispose :

• d’une connaissance de la structure des programmes JAVA.L’éditeur peut reconnaître et mettre en valeur les "blocs" dulangage et les zones réservées aux commentaires et à Javadoc.Il peut ainsi permettre de vérifier les appariements desaccolades et des parenthèses; il peut colorier de manière utile(et paramétrable!) les en-têtes de déclaration (classes et classesinternes, constructeurs, méthodes, variables); il peut filtrer leszones que l’on veut voir apparaître à l’écran (effets de "zoom" :visualisation du squelette du code, filtrages sur Javadoc); ildispose de "pretty-printing" avec colorisation et filtres; etc.Exemple : les éditeurs de la famille Emacs permettent dereconnaître des structures et de programmer descomportements.

• d’une connaissance du langage JAVA.On a une édition sous contrôle qui prépare le travail ducompilateur puisqu’on ne peut plus éditer de syntaxe illégale.La connaissance des objets du programme facilite lacomplétion automatique ou assistée (quels sont les champs ouméthodes possibles pour cette instance?).

• d’une laision aisée avec d’autres programmes : liensautomatiques avec les messages d’erreur du compilateur; suivides actions d’un debugueur; liens avec un navigateur, un outilde recherche, une aide en ligne liées à des composants, etc.

Exemple : colorisation sous Xemacs



Réf. Sun : LJ300 Date : 20/7/98

10


Outils annexes à l’éditeur

Ce sont les outils externes qui collaborent avec l’éditeur pour améliorer le

confort de la programmation.

La consultation en ligne de la documentation des classes et la qualité de la

navigation dans cette documentation sont des points essentiels.

Un outil comme SNIFF permet de rechercher des classes, de mesurer

rapidement l’impact d’une modification en recherchant dans le code

toutes les utilisations d’une méthode, etc.

10



Réf. Sun : LJ300 Date : 20/7/98


L’aide à la conception d’interaction

Il est séduisant d’envisager de générer des programmes à partir d’un

outil permettant de mettre en place interactivement des objets graphiques,

mais il convient de bien prendre en compte les points suivants :

• Il faut que l’outil sache mettre en place des LayoutManagersau lieu de faire du positionnement en absolu.

• Il faut que l’outil sache mettre en place des composants définispar des parties tierces (Beans ) sans imposer que cescomposants intègrent des classes spécifiques à l’outil.

• Il doit être facile d’intervenir dans le code généré ( enparticulier au niveau de l’architecture de gestion desévénements). Toute modification dans la disposition doitpermettre de respecter le code déjà écrit.Une solution élégante consiste en la génération d’une ressourcesous forme texte qui décrit la disposition et qui est interprétéau run-time (dans ce cas un composant spécifique d’exécutiondoit effectivement être livré avec l’outil)

• Attention à la dynamicité des composants!Exemple : l’utilisateur d’un Network Computer doit pouvoirdisposer d’un profil qui personnalise ses objets d’interactions.Ainsi on doit être capable de gérer une barre d’outils danslequel le nombre d’éléments n’est pas connu à l’avance.

L’avenir de ce type d’outils se situe du coté des assembleurs de Beans .

On a ainsi des possibilités de découverte des capacités des composants,

des personnalisations éventuelles de la mise en oeuvre, etc. Les

assembleurs de Beans vont au delà des composants graphiques et

permettent aussi de spécifier des modalités d’ échanges d’informations

entre composants.



Réf. Sun : LJ300 Date : 20/7/98

10


Gestion des sources

principes

Les outils de gestion de sources permettent :

• d’archiver les versions successives de chaque fichier source.On peut ainsi marquer un logiciel avec une indication de laversion de tous ses composants et reconstituer une versionantérieure (suivi de bug. par ex.).

• gérer la concurrence d’accès sur les sources : un développeurpeut s’assurer l’exclusivité d’une mise à jour. Les outils les plussophistiqués permettent des évolutions en parallèle entre dessites distant avec des procédures de reharmonisation.

• d’assurer des services annexes (dépend des produits) : suivides bugs et corrections, gestion de configuration (voir chapitrelivraisons), etc.

Le point clef d’une politique de gestion de version est celui de la

signification des niveaux de version et de l’ordonnancement (à un certain

niveau il n’y a plus d’ordre historique entre deux feuilles situées sur des

branches différentes de l’arbre des versions).

outils

Outils standards liés à des systèmes d’exploitation : SCCS, RCS, PVCS,

Outils spécifiques (s’appuyant éventuellement sur les précédents) :

JAVASAFE (JavaSoft),TEAMWARE, etc...

10



Réf. Sun : LJ300 Date : 20/7/98


Gestion des sources

points

JAVA pose des problèmes particuliers dans la gestion de version. En effet

une "application" peut faire appels à des composants différents. Ces

composants peuvent avoir diverses origines et donc relever chacun d’une

gestion de version qui leur est propre : chaque version d’application est

susceptible de fonctionner sur des combinaisons possibles de versions de

composants. Lorsque ces composants sont chargés dynamiquement les

incompatibilités apparaissent au run-time.

"Java Product Versionning Specification" pose des jalons pour l’émergence de

pratiques standard:

• A la base, les informations publiques de version (celles qui sontaccessibles après livraison) s’appliquent au niveau package. Lepackage constitue le niveau atomique d’objet soumis à version.Un produit est distribué en archivant des packages et estidentifié avec son propre numéro. (Les identifications sontportés dans les fichiers Manifest situés dans les archives .jar )

• Apparue à partir de la version 1.2 la classejava.lang.Package distingue les versions de spécificationsdes versions de réalisation. La version des spécificationsdésigne les interfaces d’appels des classes et permetéventuellement de gérer les compatibilités au niveau desappels des services rendus par ces classes. La version deréalisation gère les modifications dans l’implantation(corrections de bugs, etc.).



Réf. Sun : LJ300 Date : 20/7/98

10


Gestionnaires de maintenance

Le gestionnaire de version doit être exploité pour suivre la maintenance.

Les bugs, les anomalies sont reportés dans une ressource. Par la suite on

utilise cette ressource pour suivre les opérations : qualification du bug,

documentation, inscription dans une base de connaissance pour le help-desk, opérations de correction (et modification de la base de test), insertion

dans une nouvelle version (ou suivi de la livraison de corrections

d’urgence).

Des outils très complets de Help-desk ( ex. Remedy) : peuvent être

personnalisés pour assurer ces fonctions.

La coopération de différents outils par échanges d’informations est ici

aussi très importante : la gestion des anomalies doit être coordonnée avec

les autres projets d’extension/modification (planning, ressources,

WorkFlow etc.)

10



Réf. Sun : LJ300 Date : 20/7/98


Documentation de code, aide en ligne

Un projet complet génère une importante documentation. De manière

non-exhaustive citons: les documentations de spécification, la

documentation du code, la documentation d’utilisation des classes, la

documentation d’utilisation d’un produit, la documentation utilisateur en

ligne... sans compter les documentations de suivi de projet, d’évolution,

etc.

Il faut pouvoir générer cette documentation, la consulter, gérer les

versions, s’assurer qu’elle suit bien les évolutions de ce qu’elle

documente, pouvoir la filtrer (par exemple séparer la documentation

précise du code de la documentation de classe), l’analyser pour rechercher

des mots-clefs, etc.

Cette gestion devient difficile si chaque outil génère un format particulier,

ne sait pas importer/exporter la documentation générée, ne fournit pas

un format structuré analysable facilement. Un format décrit en SGML a

l’avantage de permettre ces manipulations par programme.

• Javadoc facilite une meilleure intégration code-

source/documentation de classe et fournit une construction

documentaire hyper-texte de bon niveau.

Un mécanisme de personnalisation des formats (Doclets ) est

apparu depuis la version 1.2.

Quelques possibilités généralement oubliées : filtrer la

documentation des membres en fonction de leur statut privé,

public, etc.; sortie en format PostScript.

• L’API JavaHelp permet la mise en oeuvre d’une aide en ligne. Les

ressources d’aide peuvent être situées sur le site client ou sur le

réseau, Le mécanisme sait coopérer avec d’autres logiciels comme

des moteurs de recherche.

• Les moteurs de recherche (ex. Excite ) peuvent être utilisés à la

fois dans l’atelier de programmation et dans les aides en ligne.



Réf. Sun : LJ300 Date : 20/7/98

10


Debug

Un outil de Debug permet de suivre le déroulement d’une exécution :

pose des points d’arrêt (sur incident, en un point précis, sur une

condition), exécution pas à pas, examen de la pile, de l’état d’objets

(instances, threads, groupe de thread), modifications interactives de

valeurs, appel interactif de méthodes, etc.

La concurrence (threads) à l’intérieur de Java et la répartition des

applications peut nécessiter l’intervention de débugueurs sophistiqués

capables d’observer plusieurs processus (éventuellement situés sur des

machines différentes), capables d’observer des verrous sur des instances

ou des classes, etc.

La liaison avec un debug du code de méthodes natives pose également

des problèmes complexes.

outils

Généralement fournis avec les ateliers de développement et liés à une

JVM. ex: jdb avec le JDK

Exemple de produit autonome: JWatch

10



Réf. Sun : LJ300 Date : 20/7/98


génération (make)

On peut décrire la génération d’un produit comme un enchainement de

compilations (et/ou d’autre tâches). En pratique la somme des tâches à

exécuter est trop importante pour être déclenchée chaque fois que l’on

apporte une modification au cours du développement ou de la

maintenance. On cherche donc à ne déclencher que le minimum d’actions

qui permettent d’aboutir à un état complet d’une portion du projet.

Traditionnellement la description des actions à déclencher en cas de

modification se fait par l’intermédiaire d’un utilitaire de type Make (le

fichier de description est appelé Makefile) - voir par ex. le produit domaine

public "GNU Make"("http://www.fsf.org/software/make/make.html")-..

Dans un Makefile on décrit des objectifs et des règles de dépendances entre

fichiers : un fichier B doit avoir une date de modification ultérieure à celle

d’un fichier A, dans le cas contraire (ou si B n’existe pas) on décrit les

actions qui permettent de créer ou de mettre à jour B. La formalisation de

ces règles suit une syntaxe particulière. Exemple :

.c .o: $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<

Dans un projet JAVA le Makefile n’est toutefois pas impliqué dans le

processus de compilation lui même (pour passer des ".java" aux ".class").

En tenant compte des capacités de chargement dynamique de JAVA le

compilateur assure lui-même une mise à jour plus optimisée que celle

d’un Makefile classique. Il faut donc correctement s’organiser (voir

architecture des répertoires de package) et bien comprendre ce

fonctionnement du compilateur: s’il compile une classe il vérifie les

classes immédiatement référencées dans le code courant; si la classe

référencée n’est pas à jour il tente de la recompiler MAIS il ne vérifie pas

les dépendances pour les classes qu’il ne recompile pas (sauf à préciser

l’option -depend il ne recompilera pas une classe C modifiée et

référencée par une classe B à jour et elle même reférencée par une classe A

qui fait l’objet de la compilation).

Les Makefile sont utilisés par contre pour générer des fichiers ".jar", pour

recompiler des méthodes natives, pour générer des documentations,

passer des tests, etc. Attention : les scripts associés aux règles sont

dépendants de la nature de la plate-forme de production.



Réf. Sun : LJ300 Date : 20/7/98

10


tests

principes

On peut catégoriser les tests en fonction de périmètres (tests de

composants, tests d’application), de positionnement dans la vie du

logiciel (tests de non-regression,...), de nature (tests fonctionnels, de

charge, etc.).

Bien que les catégories suivantes se recoupent elles sont commodes pour

caractériser des outils ou des procédures de tests :

• tests fonctionnels : vérifications conformité aux spécifications;productions de résultats conformes ; contrôles sur lescontraintes;...

• tests aux limites : proches du cas précédent sur les contrôlesdes cas illégaux; accent mis sur des combinaisons de valeursremarquables (grandes, petites) pour tester les capacités dulogiciel (taille des données, nombre de cas, précision descalculs, valeurs particulières...)

• tests de charge : simulation de situations réelles; calibrage dulogiciel, capacité à servir des nombreux utilisateurssimultanément, grand nombre de données, etc..

• tests d’interface : "rejouer" automatiquement des interactionsutilisateur; conformité des comportements; enchainements surdes comportements fonctionnels équivalents,..

produits

SunTest fournit des outils de tests eux-mêmes écrits en JAVA : JAVASPEC

(tests fonctionnels); JAVASTAR (tests d’interface); JAVALOAD (tests de

charge client-serveur)

10



Réf. Sun : LJ300 Date : 20/7/98


tests

points

La mise au point de tests fonctionnels est particulièrement intéressante

lorsqu’on s’adresse à des Interface JAVA . En effet, du fait du

polymorphisme, pour le même appel de méthode on pourra avoir des

réalisations effectives différentes et il peut être intéressant de controler

toutes les parties cachées du "contrat" d’interface.

Il y a des limites à une génération automatique d’une combinatoire de

tests (voir mesures de la testabilité). Il est vivement recommandé de

mettre au point pour les grands composants d’une application un

mécanisme de test prenant en entrée des scenarios décrits sous forme de

texte et produisant du texte comme résultat.

• Les scenarios pourront être enrichis rapidement dans la vie dulogiciel au fur et à mesure que de nouvelles anomalies sontdétectées. Quand ces anomalies sont corrigées on a ainsi lesmoyens de controler la non-regression des version ultérieures

• L’analyse des résultats se fait rapidement par des outils decomparaisons de texte (limite: lorsque des valeurs dépendentde la date ou de la localisation courante!)



Réf. Sun : LJ300 Date : 20/7/98

10


analyse de couverture

Il faut avoir des indications sur l’étendue de la couverture des tests : dans

quelle mesure ont-ils permis de passer par toutes les branches du code?

Avant de passer les tests fonctionnels on doit "instrumenter" de code, c’est

à dire le recompiler de manière à ce que l’exécution puisse tracer le

passage dans les différentes parties.

Un outil d’analyse de couverture (ex. JAVASCOPE de Suntest) permet

d’instrumenter puis d’analyser ensuite la couverture (production

d’informations spécifiques à des parties du code, métriques diverses -dont

taux de couverture-)

L’interprétation globale des résultats est délicate : il faut savoir filtrer des

parties exceptionnelles du code qui ne sont pas pertinentes pour obtenir

un bon taux de couverture. Par ailleurs les informations obtenues ne

préjugent pas de la pertinence fonctionnelle des tests : les informations

les plus précieuses se trouvent dans le détail des parcours des "branches"

de l’arbre des appels et il faut savoir les rechercher.

10



Réf. Sun : LJ300 Date : 20/7/98


analyses de performances

principes

En exécutant du code Java avec un moniteur spécial (par exemple en

utilisant l’option de profiling -prof de la commande java ) on peut

générer des informations donnant des indications sur la "consommation"

de chaque appel de méthode.

Pour être significatifs les tests qui servent analyser les informations de

performances doivent être représentatifs de conditions réelles d’exécution.

En effet l’objectif n’est pas d’optimiser tout le code mais les quelques

points qui peuvent réellement poser des problèmes significatifs.

La "consommation" a de multiples facettes. Tous les systèmes d’analyse

proposent des informations du type : temps cumulé passé dans une

méthode, nombre d’appels d’une méthode ( et donc des ratios: méthodes

les plus couteuses en temps cumulé, méthodes pour lesquelles chaque

appel est couteux, etc.). Selon les outils on peut aussi obtenir des

informations sur les graphes des appels, le nombre d’instances générées

par classe et l’utilisation de la mémoire, l’utilisation des Threads, etc. . On

peut également obtenir des informations de trace au cours de l’exécution

elle même.

outils

Il y a des outils qui exploitent les traces standard du profiling JAVA

(HyperProf, JWS) et d’autres plus sophistiqués (JProbe , "OptimizeIt ") qui utilisent des moniteurs spécifiques.

points

Il est essentiel de pouvoir filtrer les informations : on détecte les "points

chauds" et on élimine les données qui concernent les autres classes.

Attention: un même code java peut s’exécuter sur des JVM différentes:

interprété, JIT, "HotSpot".



Réf. Sun : LJ300 Date : 20/7/98

10


Analyses statiques du code

principes

Sans recourir à une exécution on peut avoir des informations sur la

qualité du code en ayant recours à des analyseurs statiques. On trouve ici

deux catégories d’outils : les "débourreurs" et les outils de "physique du

logiciel".

• Sur le modèle du programme standard C Lint un "débourreur"

analyse le code pour tenter de détecter des constructions

potentiellement dangereuses.

Un tel outil dispose d’une base de savoir-faires et de règles et

produit des diagnostics argumentés (et faisant référence à des

portions de code source).

• Les outils de physique du logiciel analyse la complexité et la

testabilité des programmes. Ils calculent des métriques :

complexité cyclomatique, complexité de Halstead, etc.

outils

Détecteurs de constructions critiques : CodeWizard , etc,

L’outil de test JavaPureCheck est aussi à mettre dans cette catégorie

(bien que spécialisé dans les problèmes de portabilité)

Physique du logiciel : TotalMetric ,...

points

Les qualités d’un débourreur se jugent sur la pertinence de ses règles, la

capacité à filtrer ces règles ou à désarmer localement l’application d’une

règle (dans un commentaire)

L’interprétation des mesures de complexité demande une grande

expérience.

10



Réf. Sun : LJ300 Date : 20/7/98


préparation à la livraison

Une fois que l’état d’avancement du projet est tel que l’on peut procéder à

des livraisons on ne peut directement transférer des binaires ou des

ressources directement depuis l’espace de développement. Voici quelques

suggestions pour mettre en place des procédures qualité très strictes:

1. Mettre en place un environnement "vierge" complètement étanche

par rapport aux environnements de développement existants.

2. Extraire des archives la version courante des sources et des

ressources

3. Lancer la génération des binaires avec toutes les options

appropriées (optimisations, pas de traces ni d’information de

debug, etc.)

4. Transformations éventuelles du code pour marquage, brouillage...

5. Exécution des tests et contrôles. -éventuellement sur des plate-

formes multiples-

6. Génération et contrôle des documentations

7. "Empaquetage" des livraisons et tests de la validité des procédures

de livraison/installation

8. Mise en place des liens avec les mécanismes de livraison

automatique, de Help-Desk, de gestion, etc.

Sauf exception l’enchainement est absolu : tout échec sur une phase doit

entraîner une reprise à zero de tout le processus.



Réf. Sun : LJ300 Date : 20/7/98

10


livraison/déploiement

Applet ou application autonome? Le choix est important pour organiser le

déploiement du logiciel et surtout pour garantir le suivi rapide des

évolutions :

• Avec une Applet on a un client qui charge son code avant de

s’exécuter, tous les clients sont assurés ainsi de disposer de la

dernière version du code . Toutefois :

• Il faut équilibrer les regroupements de classes et de ressourcessur plusieurs archives ".jar" et il faut éviter de charger une tropgrande quantité de code d’un seul coup.

• Les restrictions de sécurité prennent leur plein effet (ce peut-être un avantage ou un inconvénient)

• Il n’est pas garanti que toutes les librairies standard soient àjour du coté client.

• Avec une application autonome on doit mettre en place des

procédures de livaison/installation. On peut utiliser des produits

(InstallShield, InstallAnyWhere ,..) qui permettent de

packager un logiciel et d’automatiser les procédures d’installation

(avec lecture d’un contrat de licence, installation de licence, etc.).

Ces logiciels simplifient en outre la livraison par chargement direct

au travers du réseau. Toutefois :

• La mise à jour n’est pas assurée et il faut mettre en place desprocédures particulières.

• Il peut s’avérer intéressant de "packager" une application JAVA,sa JVM et ses classes standard (voir JRE)

• Pour utiliser au mieux les dispositifs de sécurité JAVA il faututiliser au minimum la version 1.2

• Une solution intermédiaire existe : l’utilisation des technologies

PUSH (ex. Castanet de Marimba). L’application autonome est

stockée sur le poste client mais avant utilisation elle se connecte au

serveur pour éventuellement faire une mise à jour différentielle

des sources.

10



Réf. Sun : LJ300 Date : 20/7/98


autres outils

décompilateurs/brouilleurs

Les fichiers "binaires" JAVA facilitent l’inspection du code et le passage

d’un bon décompilateur donne une idée assez précise du contenu du

source.

On trouve donc à la fois des décompilateurs et des brouilleurs

("obfuscator") qui transforment un code JAVA de manière à le rendre

difficile à décompiler.

Les identifiants prennant des formes bizarres il faut conserver dans

l’atelier de développement un dictionnaire permettant de reconstituer le

nom réel à partir de la forme brouillé (ceci est nécessaire si on veut

récupérer et comprendre des messages d’erreurs imprévus). Il faut savoir

aussi ne pas tout brouiller, en particulier lorsque le code contient des

recherches dynamiques par nom (introspection, Beans)

En pratique un bon décompilateur arrive à donner une image fidèle de la

structure du programme : c’est l’absence d’identifiant significatif qui

trouble la compréhension.

outils syntaxiques

• Pour des raisons de robustesse du code, Java n’utilise pas de

préprocesseur : l’utilisation de macros risque de conduire à un

texte "lisible" qui est différent du code réellement compilé.

Différents produits proposent des macro-processeurs pour JAVA :

l’utilisation doit être limitée (ex. macros de trace, marquage des

messages à internationaliser) et ne pas concerner des parties

critiques du code

• Des analyseurs acceptant des grammaires sophistiquées sont

disponibles

voir JavaCC "http://www.suntest.com/JavaCC"



Réf. Sun : LJ300 Date : 20/7/98

aide mémoire outils 11

2

Objectifs

Ce chapitre constitue un aide-mémoire simplifié d’utilisation pour des

outilsl JAVA

• JAVAWorkshop est le premier atelier “ouvert” écrit en JAVA

11



Réf. Sun : LJ300 Date : 20/7/98

aide mémoire outils

JavaWorkshop: Gestionnaire de projets

JWS connaît deux niveaux d’organisation : le projet (project) et le

portefeuille (portfolio).

Un “projet” est une unité d’organisation liée à la génération.

Un projet a pour objectif de générer un produit “livrable” (application

autonome, Applet, Bean) ou un package.

Un projet peut s’appuyer sur d’autres projets qui sont nécessaires à sa

génération : ces projets sont vus alors comme des sous-projets du projet

principal.

Un “portefeuille” est une collection de “projets”.

Mise en oeuvre du “Project Manager”

Pour obtenir la fenêtre “project manager” cliquer sur l’icône

correspondante ou lancer depuis le menu principal par :

project ➔ show project manager



Réf. Sun : LJ300 Date : 20/7/98

11



créer ou importer un portefeuille

File ➔ new ➔ portfolio

File ➔ add ➔ portfolio

Création : préciser le nom d’un fichier (suivi de .psf) ce fichier sera créé

dans le sous-répertoire “jws” du répertoire d’accueil de l’utilisateur. Il est

possible de préciser un autre répertoire

(attention référence stockée sous forme de cheminom relatif dans le fichier

$HOME/jws<version>/portfolios )

créer ou importer un projet

Sélectionner un portefeuille dans l’arbre des projets (fenêtre “project

manager”)

File ➔ new ➔ project

File ➔ add ➔ project

Il apparaît alors une fenêtre de dialogue :

• cliquer sur le type de projet (Standalone, applet, bean, package)

• cliquer sur le type de GUI (no GUI, ou “gui created manually”)

• > Next

• préciser le répertoire dans lequel sera créé le projet (et

éventuellement préciser si des fichiers existants sont à conserver

dans le projet)

• dans le cas d’un package il faut donner le nom du package, et le

nom du répertoire “racine”des classes (équivalent de celui précisé

par l’option -d de javac),

Dans le cas d’un sous-projet on opérera cette création/importation en se

positionnant dans le projet englobant.

11



Réf. Sun : LJ300 Date : 20/7/98



fixer les attributs d’un projet

Cette opération permet de fixer un ensemble de conditions pour la

génération et l’exécution d’un projet

Project ➔ edit

Il apparaît alors un dossier à onglets:

• General - informations générales : nom, type, répértoire sources,

sous-projet (informations fixées à la création)

point important : l’ordre des sous-projet fixe l’ordre des

compilations (d’ou la possiblitéde modifier l’ordre des sous-projets

dans la liste)

• Build - permet de fixer les informations utiles pour la

compilation: options du compilateur (-g pour le debugger est

proposé par défaut), répertoire d’accueil des classes (pour option -

d de javac), éléments complémentaires du CLASSPATH (nota: on

peut lancer jws avec option -classpath )

• Debug/Browse - permet de fixer les options pour l’outil de debug:

Chemins d’acces à rajouter pour visualiser les sources des classes

Point d’entrée : classe avec main, applet avec init

La page HTML associée au lancement (cas d’une Applet)

Options de l’interpréteur java (pour application autonome)

Outil de visualisation à utiliser pour une Applet

Type de debug (local ou sur machine distante)

• Run- options de lancement de tests (hors debug):

Pour un programme autonome : point d’entree, options

d’execution, paramètres de lancement

Pour une applet : definition des paramètres d’applet dans le

HMTL



Réf. Sun : LJ300 Date : 20/7/98

11


JavaWorkshop: édition, compilation, tests

édition

Dans project manager:

File ➔ new ➔ file

pour créer un fichier dans projet courant

File ➔ add ➔ file

pour l’ajouter dans projet courant

personnalisation de l’édition

Dans fenêtre édition :

Preferences ➔ source editor

Preferences ➔ keyboard

contrôle d’accès et version

Pour le choix de l’outil

Preference ➔ Version Control

enregistrement dans le système de versionnement

File ➔ version ➔ check In New

pour creation de l’enregistrement

checkIn : pour enregistrement

checkOut : pour mise en edition

Remarques: à l’enregistrement il y a demande de commentaires, mais il

n’y pas de versionnement fin.

11



Réf. Sun : LJ300 Date : 20/7/98


JavaWorkshop: édition, compilation, tests

compilation

Build ➔ Build

recompile les fichiers qui ont changé depuis la dernière recompilation du

projet

Build ➔ Build All

recompile tous les fichiers du projet

Build ➔ compile file

permet de ne compiler que le fichier en édition

Preference ➔ builder

permet de choisir le compilateur à impliquer

La fenetre Build donne les erreurs (qui sont signalées dans l’éditeur de

code lui-même)

test

Lancer

Project ➔ run

(voir options pour lancements Applets)



Réf. Sun : LJ300 Date : 20/7/98


La couverture des agences de Sun France permet de répondre à

l’ensemble des besoins de nos clients sur le territoire.

Table 11.1 Liste des agences Sun Microsystems en france

Sun Microsystems France S.A

13, avenue Morane Saulnier

BP 53

78142 VELIZY Cedex

Tél : 01.30.67.50.00

Fax : 01.30.67.53.00

Agence d’Aix-en-Provence

Parc Club du Golf

Avenue G. de La Lauzière

Zone Industrielle - Bât 22

13856 AIX-EN-PROVENCE

Tél : 04.42.97.77.77

Fax : 04.42.39.71.52

Agence de Issy les Moulineaux

Le Lombard

143, avenue de Verdun

92442 ISSY-LES-MOULINEAUX Ce-

dex

Tél : 01.41.33.17.00

Fax : 01.41.33.17.20

Agence de Lyon

Immeuble Lips

151, boulevard de Stalingrad

69100 VILLEURBANNE

Tél : 04.72.43.53.53

Fax : 04.72.43.53.40

Agence de Lille

Tour Crédit Lyonnais

140 Boulevard de Turin

59777 EURALILLE

Tél : 03.20.74.79.79

Fax : 03.20.74.79.80

Agence de Toulouse

Immeuble Les Triades

Bâtiment C - B.P. 456

31315 LABEGE Cedex

Tél : 05.61.39.80.05

Fax : 05.61.39.83.43

Agence de Rennes

Immeuble Atalis

Z.A. du Vieux Pont

1, rue de Paris

35510 CESSON-SEVIGNE

Tél : 02.99.83.46.46

Fax : 02.99.83.42.22

Agence de Strasbourg

Parc des Tanneries

1, allée des Rossignols

Bâtiment F - B.P. 20

67831 TANNERIES Cedex

Tél : 03.88.10.47.00

Fax : 03.88.76.53.63

Bureau de Grenoble

32, chemin du Vieux Chêne

38240 MEYLAN

Tél : 04.76.41.42.43

Fax : 04.76.41.42.41

Documents

Atelier Developpement Java