Préface▲
J'ai suggéré à mon frère Todd, qui est en train de migrer du hardware vers le software, que la prochaine grande révolution serait l'ingénierie génétique.
Nous créerons bientôt des organismes dédiés à la fabrication de nourriture, de carburant, de plastique ; ils digéreront la pollution et, de manière générale, nous permettrons de maîtriser la manipulation du monde réel, ceci pour un coût minime comparé à celui d'aujourd'hui. J'ai prétendu que la révolution informatique serait vraiment peu de chose au regard de cela.
Puis j'ai réalisé que j'étais en train de commettre une erreur triviale chez les auteurs de science-fiction : oublier le propos de la technologie (ce qui est évidemment très facile à faire en science-fiction). Un écrivain expérimenté sait qu'on ne raconte jamais une histoire à propos de choses, mais de gens. La génétique aura un très grand impact sur nos vies, mais je ne suis pas persuadé qu'elle éclipsera la révolution informatique (qui d'ailleurs rend possible la révolution génétique) - ou au moins la révolution de l'information. L'information, c'est essentiellement se parler les uns les autres : bien entendu, les voitures, les chaussures, et surtout les maladies génétiques sont importantes, mais en définitive ce ne sont que des faux semblants. La vraie question est notre relation au monde. Ainsi en est-il de la communication.
Ce livre est un cas. Une majorité d'amis pensa que j'étais soit vraiment hardi, soit légèrement dérangé pour mettre tout cela sur le Web. « Pourquoi quelqu'un voudrait-il l'acheter ? » me disaient-ils. Si j'avais eu un tempérament plus conservateur, je ne m'y serais pas pris de cette manière ; en réalité je ne voulais pas écrire un livre supplémentaire de style traditionnel sur les ordinateurs. Je ne savais ce qui en aurait résulté si je n'avais pas agi ainsi, mais en tout cas ce fut la meilleure chose que j'ai jamais réalisée avec un livre.
Tout d'abord, chacun commença à m'envoyer des correctifs. Ce fut un processus très amusant, parce que mes amis avaient fureté dans chaque coin et recoin et repéré les erreurs techniques aussi bien que grammaticales, ce qui me permit d'éliminer les fautes de toutes sortes que j'aurais laissé passer sans cela. Dans ce travail, ils ont été tout simplement formidables, commençant très souvent par me dire « bon, je ne dis pas ça pour critiquer… » pour me mettre ensuite sous le nez un ensemble d'erreurs que je n'aurais jamais été capable de trouver par moi-même. Je crois que ce fut une espèce de travail de groupe, et cela a réellement ajouté quelque chose de spécial à ce livre. Ainsi, du fait de la valeur de ces corrections, j'ai créé un système de backtrack pour être en mesure de rassembler et classer les éventuels commentaires qui pourraient être faits.
Mais ensuite, j'ai commencé à entendre ceci : « OK, très bien, c'est bien gentil vous avez fait une version électronique, mais moi j'aurais préféré une version complète imprimée chez un vrai éditeur ». Alors j'ai beaucoup travaillé afin que chacun puisse l'imprimer dans un format adéquat, mais cela n'a pas suffi à résorber la demande d'un livre « publié ». La plupart des gens n'ont pas envie de lire le livre à l'écran dans son intégralité, et l'idée de transporter un paquet de feuilles volantes, même impeccablement imprimées, ne leur conviendrait pas davantage (de plus, je pense que ce n'est pas forcément économique en terme de toner). Après tout il semblerait que la révolution informatique ne risque pas de mettre les éditeurs au chômage. Un étudiant suggéra toutefois que cela pourrait servir de modèle pour l'édition du futur : les livres seraient d'abord publiés sur le Web, et, à condition qu'ils rencontrent un certain intérêt, on les coucherait sur papier. Actuellement, une grande majorité de livres représentent des désastres financiers, et cette nouvelle approche pourrait peut-être rendre l'industrie de l'édition plus rentable.
Ce livre a été par ailleurs une expérience enrichissante pour moi. Ma première approche de Java fut « juste un nouveau langage de programmation », ce qu'il est de fait par ailleurs. Mais, le temps passant, et au fur et à mesure que je l'étudiais plus en profondeur, je commençais à m'apercevoir que son propos fondamental était différent de celui de tous les langages que j'avais abordé auparavant..
Programmer, c'est gérer la complexité : complexité du problème que l'on veut résoudre, superposée à la complexité de la machine sur laquelle il va être résolu. Bien des projets de programmation ont avorté à cause de cette complexité. Je voudrais maintenant dire que, de tous les langages de programmation que je connaisse, aucun n'a été conçu pour gérer la complexité du développement et de la maintenance de programmes. (1) Bien entendu, dans la conception des langages, beaucoup de décisions ont été prises en gardant la complexité présente à l'esprit, mais, dans chaque exemple et à partir d'un certain moment, d'autres problèmes ont surgi qui furent considérés comme essentiels et par suite intégrés à la mixture. Fatalement, ces nouveaux problèmes furent de ceux qui envoyèrent finalement les programmeurs « droit dans le mur » avec ce langage. Par exemple, C++ se devait de posséder une compatibilité ascendante avec C (afin de favoriser la migration des programmeurs C), ainsi qu'une certaine efficacité. Ces deux buts étaient très utiles et ont grandement participé au succès de C++, mais dans le même temps ils ont généré une complexité supplémentaire qui a eu pour résultat d'empêcher certains projets d'arriver à terme (bien entendu, vous pouvez toujours vous en prendre à la responsabilité des programmeurs et/ou de leur encadrement, mais, si un langage pouvait vous aider à repérer vos erreurs, pourquoi ne le ferait-il pas ?). Autre exemple, Visual Basic (VB) était lié à BASIC, lequel n'était pas vraiment conçu comme un langage extensible, et par suite toutes les extensions superposées à VB se sont traduites par une syntaxe vraiment horrible et impossible à maintenir. Perl a une compatibilité ascendante avec Awk, Sed, Grep ainsi que d'autres outils Unix qu'il était censé remplacer, le résultat est qu'il est souvent accusé de produire du « code-à-écrire-seulement » (c'est-à-dire qu'on est incapable de se relire quelques mois plus tard). D'un autre côté, C++, VB, Perl, et d'autres langages comme Smalltalk, de par leur conception, ont abordé le problème de la complexité, et par là se révèlent remarquablement efficaces dans la résolution de certains types de problèmes.
Ce qui m'a le plus frappé alors que je commençais à comprendre Java est le fait que, parmi les nombreux objectifs de conception de Sun, il s'avère qu'il y avait le but de réduire la complexité pour le programmeur. Un peu comme si l'on disait « rien n'est important, mis à part réduire le temps et la difficulté pour produire un code robuste ». Dans les premières versions de Java, cette finalité s'est traduite par un code qui ne tournait pas très vite (bien que l'on ait fait de nombreuses promesses concernant la vitesse de Java), mais il n'empêche que cela a réduit le temps de développement de manière stupéfiante : la moitié, ou moins, du temps nécessaire à la création d'un programme équivalent en C++. Ce seul résultat pourrait déjà se traduire par une incroyable économie de temps et d'argent, mais Java ne s'arrête pas là. Il s'attache à encapsuler toutes les tâches complexes qui ont pris de l'importance, comme le multithreading et la programmation réseau, au moyen de fonctionnalités du langage ou de bibliothèques rendant parfois ces tâches triviales. Et pour finir, il traite quelques problèmes d'une réelle complexité : programmes multiplates-formes, changements dynamiques de code, sans oublier la sécurité, chacun d'entre eux pouvant s'adapter à votre gamme de difficultés, depuis un « obstacle » jusqu'à un « point bloquant ». Ainsi, malgré les problèmes de performance que nous avons vus, les promesses de Java sont énormes : il est capable de faire de nous des programmeurs encore plus productifs.
Le Web est l'un des lieux où cela se révèle le plus. La programmation réseau a toujours été difficile, et Java la rend facile (et les concepteurs du langage Java travaillent à la rendre encore plus facile). La programmation réseau, c'est ce qui fait que nous parlons entre nous de manière plus pertinente et meilleur marché que nous ne l'avons jamais fait avec le téléphone (l'email à lui seul a révolutionné bien des entreprises). Alors que nous nous parlons de plus en plus, des choses sensationnelles commencent à émerger, peut-être plus incroyables que celles promises par l'ingénierie génétique.
Dans tous les cas - en créant des programmes, en travaillant en groupe pour créer des programmes, en concevant des interfaces utilisateur permettant aux programmes de dialoguer avec l'utilisateur, en faisant tourner des programmes sur différents types de machine, en écrivant facilement des programmes qui communiquent au travers de l'Internet - Java accroît la bande passante de la communication entre les gens. Je pense que les résultats de la révolution de la communication ne peuvent sans doute pas être déduits des effets de la transmission de grandes quantités de bits ; la vraie révolution sera là lorsque nous serons tous capables de nous parler plus facilement : de personne à personne, mais aussi en groupe, et, pourquoi pas, sur la planète entière. J'ai entendu dire que la prochaine révolution verra l'émergence d'une espèce d'esprit global associant un grand nombre de personnes à un grand nombre d'interconnexions. Il se peut que Java soit, ou pas, l'outil de cette révolution, mais en tout cas cette possibilité m'a fait comprendre qu'il n'était pas insensé de tenter d'enseigner ce langage.
Préface à la 3e édition▲
La plus grande partie de la motivation et de l'effort pour cette édition a porté sur la mise à niveau du livre pour se conformer à la version 1.4 du JDK. Cependant, il est devenu clair que la plupart des lecteurs utilisent ce livre pour avoir une solide compréhension des concepts fondamentaux, ainsi, ils peuvent ensuite se consacrer aux points plus complexes. Parce que le langage continue à évoluer, il est devenu nécessaire - en partie pour que le livre ne déborde pas de ses reliures - de réévaluer la portée des « fondamentaux ». Cela signifie, par exemple, de réécrire complètement le chapitre sur la « Concurrence » (précédemment nommé « Multithreading ») pour qu'il vous apporte une connaissance de base sur les fondements du threading. Sans cela, il est difficile de comprendre les problèmes plus complexes liés aux threads.
J'en suis également venu à me rendre compte de l'importance des tests du code. Sans un framework de test intégré, avec des cas de tests exécutés à chaque fois que vous recompilez votre projet, vous n'avez aucun moyen de savoir si votre code est fiable ou non. Pour accomplir cela dans le livre, j'ai créé un framework spécial de tests unitaires pour montrer et valider les sorties de chaque programme. Cela a été placé dans le chapitre 15, un nouveau chapitre, au côté d'explications sur ant (le système, standard de facto, de compilation Java, similaire à make), JUnit (le framework de tests unitaires, également devenu standard de facto), une évocation de la consignation (logging) et des assertions (nouvelles dans le JDK 1.4), et enfin une introduction sur le débogage et le profilage. Pour englober tous ces concepts, le nouveau chapitre s'intitule « Découvrir les problèmes », et il introduit ce que je crois être les compétences fondamentales que tous les programmeurs Java se devraient d'avoir dans leur trousse à outils de base.
De plus, j'ai revu chaque exemple dans le livre et je me suis demandé, « pourquoi ai-je fait cela de cette manière ? » Dans la plupart des cas, j'ai effectué quelques modifications et améliorations, aussi bien pour rendre les exemples plus cohérents en eux-mêmes, mais aussi pour montrer ce que je considère être les bonnes pratiques dans la programmation Java (du moins, dans les limites d'un texte d'introduction). Les exemples qui n'avaient plus aucun sens pour moi ont été ôtés, et de nouveaux ont été ajoutés. Beaucoup d'exemples existants ont été repensés et réimplémentés.
Les 16 chapitres dans ce livre représentent ce que je considère être une introduction fondamentale au langage Java. Le livre peut raisonnablement être employé comme un cours d'initiation. Mais que dire des sujets plus avancés ?
Le projet initial pour ce livre était d'y ajouter une nouvelle section couvrant les bases de « Java 2 Entreprise Edition » (J2EE). Beaucoup de ces chapitres auraient été rédigés par des amis et des associés qui travaillent avec moi sur des séminaires et d'autres projets, tels qu'Andrea Provaglio, Bill Venners, Chuck Allison, Dave Bartlett, et Jeremy Meyer. Quand j'ai constaté l'avancement de la rédaction de ces nouveaux chapitres par rapport à la date de clôture du livre, j'ai commencé à devenir un peu nerveux. Après, j'ai remarqué que la taille des 16 premiers chapitres était effectivement identique à celle de la seconde édition de ce livre. Et les gens qui se plaignent parfois que le livre est déjà trop gros !
Les lecteurs des 2 premières éditions de ce livre ont fait énormément de commentaires élogieux à leur propos, ce qui m'a apporté beaucoup de satisfaction. Toutefois, de temps à autre, l'un ou l'autre s'est plaint, et l'une des critiques récurrentes est « le livre est trop gros ». Dans mon esprit, je dois dire que si « trop de pages » est votre seule plainte, c'est une faible critique (on se souvient de l'empereur d'Autriche se plaignant du travail de Mozart : « trop de notes ! », mais n'allez pas penser que je cherche d'une manière ou d'une autre à me comparer à Mozart). De plus, je peux seulement supposer qu'une telle demande provient d'une personne qui en est encore à prendre conscience de l'étendue du langage Java lui-même, et qui n'a pas encore vu ou lu les autres livres traitant du sujet. Malgré cela, une des choses que j'ai essayé de faire dans cette édition a été d'éliminer les parties obsolètes, ou tout au moins non essentielles. Je n'ai pas eu de scrupules en faisant cela, car l'original existe toujours sur le site Web (www.BruceEckel.com) ainsi que sur le CD ROM qui accompagne ce livre, sous la forme de la première et de la seconde édition du livre, librement téléchargeable. Si c'est l'ancienne version qui vous intéresse, elle existe encore, et ceci est un merveilleux soulagement pour un auteur. Par exemple, le chapitre « Design Patterns », devenu trop gros, a fait l'objet d'un livre séparé : Penser en Design Patterns (avec Java) (également téléchargeable sur le site Web).
J'avais d'ores et déjà décidé que lorsque Sun rendra disponible la prochaine version de Java (JDK 1.5), qui contiendra sans doute une nouvelle fonctionnalité majeure nommée Programmation Générique (inspirée par les fameux templates de C++), je serais dans l'obligation de scinder le livre en 2 pour être en mesure d'ajouter de nouveaux chapitres. Or une petite voix m'a dit « Pourquoi attendre ? » Ainsi, je me suis décidé à le faire dans cette édition et tout à coup, tout a pris un sens. J'étais en train d'essayer de fourrer beaucoup trop de choses dans un livre d'introduction.
Le nouveau livre n'est pas un second volume, mais traite plutôt un sujet plus complexe. Il s'intitulera Penser en Java Entreprise, et est actuellement disponible (sous différentes formes) en libre téléchargement sur www.BruceEckel.com. Parce que c'est un livre séparé, il peut être étendu pour traiter chaque sujet aussi précisément que nécessaire. Le but, tout comme Penser en Java, est d'expliquer de façon compréhensible les bases des technologies J2EE de façon à ce que l'utilisateur soit préparé à aborder ces sujets plus en profondeur. Vous pouvez vous référer à l'Annexe C pour plus de détails.
Je dois m'excuser auprès de ceux qui persistent dans leur critique à propos de la taille du livre. Que vous me croyiez ou non, j'ai travaillé dur pour le rendre plus mince. Malgré sa taille, je pense qu'il existe assez d'alternatives pour vous satisfaire. D'une part, le livre existe sous forme électronique (sur le site Web, ainsi que sur le CD ROM accompagnant ce livre), ainsi lorsque vous prenez votre ordinateur portable vous pouvez également emporter le livre sans supplément de poids. Si vous êtes réellement partisan de la minceur, il existe des versions Palm Pilot (quelqu'un m'a dit qu'il lirait le livre au lit sur l'écran rétroéclairé de son Palm afin de ne pas déranger sa femme. Je ne peux qu'espérer que cela l'aidera à glisser dans les bras de Morphée). Si vous le préférez sur papier, je connais des personnes qui impriment un chapitre à la fois et l'emmènent dans leur attaché-case afin de le lire dans le train.
Java 2, JDK 1.4▲
Les versions du JDK Java sont numérotées 1.0, 1.1, 1.2, 1.3, et pour ce livre, 1.4. Même si ces numéros de version sont toujours dans les « uns », l'usage, pour se référer à n'importe quelle version du langage à partir du JDK 1.2 et supérieur, est de l'appeler « Java 2 ». Cela indique les changements majeurs entre le « vieux Java » - qui avait énormément de défauts dont je me plaignais dans la première édition de ce livre- et la version plus moderne et améliorée du langage qui souffre de beaucoup moins de défauts et comporte de nombreux ajouts, dont des cadres de conception plaisants.
Ce livre est écrit pour Java 2, en particulier pour le JDK 1.4 (pas mal de code ne compilera pas avec des versions antérieures, le système se plaindra et s'arrêtera si vous essayez). J'ai pris le luxe de me débarrasser de toutes les anciennes syntaxes et d'écrire uniquement en utilisant le nouveau langage amélioré, parce que l'information sur celles-ci existe encore dans les anciennes éditions, sur le Web, et sur le CD ROM. Ainsi, vu que n'importe qui peut librement télécharger le JDK sur le site java.sun.com, cela signifie qu'en écrivant sur le JDK 1.4, je n'impose pas de contraintes financières en forçant une mise à niveau.
Les versions précédentes de Java étaient lentes à sortir sur Linux (visitez le site www.Linux.org), cependant cela semble avoir été réglé, et les nouvelles versions sont disponibles sur Linux en même temps que pour les autres plateformes - maintenant même Macintosh commence à être au point avec les versions plus récentes de Java. Le système Linux est un développement très important en conjonction avec Java, parce qu'il en train de devenir rapidement la plus importante plateforme serveur - rapide, fiable, robuste, sûre, bien maintenue et surtout libre, c'est une vraie révolution dans l'histoire de l'informatique (je ne crois pas que nous ayons déjà vu de telles fonctionnalités dans un autre outil auparavant). Et Java a trouvé une niche très importante dans la programmation côté serveur sous la forme de Servlets et JavaServer Pages (JSPs), technologies qui constituent une énorme amélioration par rapport à la traditionnelle programmation des Common Gateway Interfaces (CGI) (ce sujet et les sujets associés sont traités dans Penser en Java Entreprise).