 |
|
| |
 |
James Gosling
CTO
Sun Microsystems |
|
James Gosling (Sun Microsystems)
"Dans le sens large, Java est déjà Open Source"
Rencontré à l'occasion de JavaOne Paris, le père du Java exprime notamment ses reticences sur le passage en Open Source du langage, et donne les raisons pour lesquelles les langages de script n'ont pas sa préférence.
06/07/2006 |
| |
 |
|
JDN
Développeurs. Quel est votre rôle aujourd'hui au sein de Sun Microsystems ?
James Gosling. Je suis le CTO (ndlr : Chief Technology Officer - directeur technique) des technologies Java. Je passe environ le quart de mon temps à travailler avec les entreprises utilisant Java, à faire de l'évangélisation, des interviews avec la presse comme en ce moment même... Je passe autant de temps que possible à faire de la veille technologique, et de temps à autre, j'ai le loisir d'écrire un peu de code. Le plus gros de mon temps se passe à discuter de ce que nous devrions faire du point de vue technologique, ce qui requiert parfois beaucoup de psychologie.
Avez-vous un droit de veto sur certains aspects ? Ou êtes-vous plutôt considéré comme un parrain bienveillant ?
Il n'y a jamais eu de possibilité de veto dans les processus Java. La réalité tient plutôt au fait que personne n'est vraiment responsable de rien. Je ne suis qu'une partie de la communauté du JCP (ndlr : Java Community Process, organisation chargée de coordonner l'évolution de la plate-forme Java), au même niveau qu'un autre. Certains même diraient que je n'ai pas beaucoup d'influence, avec tellement de gens prenant des décisions sur tellement de points techniques. Je peux sûrement être considéré comme un parrain, mais pas dans le sens mafieux du terme.
La dernière bêta de Java 6 inclue dans le JDK une implémentation d'Apache Derby, sous le nom de JavaDB, ce qui a provoqué quelques remous. Qu'est-ce qui a mené à l'inclusion spécifiquement de cette base de données ?
Il y a beaucoup de gens qui travaillent avec des bases de données, ils voulaient que le processus de mise en place d'une base de données soit mieux intégré. Ils voulaient voir disparaître certains aspects douloureux de l'utilisation d'une base de données avec Java. Avoir un tel composant dans le JDK (ndlr : Java Development Kit, kit de développement Java) signifie que les développeurs peuvent en profiter et expérimenter avec, mais que les utilisateurs n'en souffrent pas. Nous voulions vraiment faciliter un tel déploiement pour ceux utilisant le JRE (ndlr : Java Runtime Environment, environnement d'exécution Java), mais au final c'est surtout un ajout pour les développeurs, améliorer la manière de travailler, retirer les quelques barrières qu'ils rencontrent.
N'est-ce pas un risque que de mettre l'accent sur une seule base de données, au détriment d'autres ?
Simplement, quelles autres bases de données existe-t-il qui sont écrites en Java ? Il nous était impossible d'ajouter Oracle, et ce serait cette fois au détriment des développeurs de MySQL.
|
|
 La JVM de Java 6 intégrera un véritable service que pourront exploiter tous les langages" |
|
Une des autres avancées de Java 6 est d'ouvrir son bytecode aux langages dynamiques...
En fait, la machine virtuelle Java fonctionne plutôt bien pour un grand nombre de langages, qui peuvent déjà être compilés pour la JVM (ndlr : Java Virtual Machine) : Lisp, Cobol ou des versions de Python, Ruby, Visual Basic... Le problème qui existe dans certaines de ces implémentations est la reconnaissance des méthodes dynamiques. C'est pourquoi nos travaux sur la prochaine version du moteur de la JVM se portent sur cette problématique. Nous espérons ainsi accueillir d'autres langages. Nous n'essayons pas favoriser tel ou tel langage dynamique, mais de créer un véritable service que pourront exploiter tous les langages.
Cette annonce n'est donc pas une manière de se promouvoir face au multilinguisme de .Net ?
Sincèrement, la JVM a toujours été en mesure d'accueillir les bytecodes d'autres langages. Il y a présentement des centaines de langages implémentés pour la JVM - il y a même un site très bien fait qui les recense -, mais il est vrai qu'ils ne sont pas vraiment populaires. Pas parce qu'ils ne fonctionnent pas, mais parce que Java était celui dont on parlait le plus pour la JVM. C'est donc plus une question de reconnaissance auprès des développeurs. Ils ont depuis longtemps les moyens d'utiliser la JVM avec d'autres langages.
Les programmeurs de grandes organisations ne sont pas intéressés par le multilinguisme, ils n'ont pas le même intérêt que la grande majorité des gens pour les nouveaux langages.
Face à la récente popularité de langages syntaxiquement plus simples comme Python et Ruby, diriez-vous que Java est toujours un bon choix pour apprendre à programmer, et intégrer les concepts objets ?
Java reste un excellent langage si l'on considère la programmation Objet, surtout si l'objectif est de construire des systèmes complexes. Apprendre avec Java permet de construire sa connaissance des méthodologies Objet, dont l'utilisation est cruciale dès lors que l'on se lance sur des projets conséquents.
Pour les réfractaires à la syntaxe, il y a cet IDE nommé BlueJ qui vise à enseigner la programmation orientée Objet aux débutants, par le biais de graphiques interactifs. Il se trouve qu'il est plus facile d'enseigner l'Objet à quelqu'un qui n'a jamais programmé, que de l'enseigner à quelqu'un qui a auparavant appris la programmation procédurale. Si vous avez appris Visual Basic, C ou Prolog, passer à l'Objet peut être relativement difficile.
|
|
Les premières versions de Java avaient quelques aspects proches des langages de script actuels" |
|
Cependant, Java semble avoir perdu de son panache face à débutants, par exemple quand ils voient la verbosité d'un premier "Hello World"...
C'est possible, et l'IDE BlueJ est une réponse à cela. Bien entendu, nous aurions pu rendre "Hello world" bien plus facile à programmer - d'ailleurs, les toutes premières versions de Java permettaient d'écrire un tel programme en une ligne. Mais il existe une certaine limite entre rendre les choses faciles à tout un chacun, et avoir un langage robuste pour les projets d'envergure industrielle. Les premières versions de Java avaient quelques aspects proches des langages de script actuels, mais au final, cela mettait plus de bâtons dans les roues du programmeur que cela ne l'aidait pour les grands projets.
Nous n'avons pas vraiment choisi la verbosité, nous avons choisi la manière la plus claire de créer une structure Objet. Si le programmeur n'est pas à même de comprendre comment les pièces s'imbriquent, il devient rapidement compliqué de construire de grands projets. Une telle structure syntaxique est pour beaucoup dans la robustesse de Java, et l'informatique industrielle en général.
Au sujet du passage de Java à l'Open Source, vous avez indiqué que vous considériez Java suffisamment ouvert...
Oui, pour la plupart des usages, Java est extrêmement ouvert. Le source est disponible depuis des années, l'évolution de Java suit un processus proche de celui-ci d'un gouvernement avec le JCP, les gens autorisés à modifier le code ne sont pas tous employés de Sun, nous recevons des milliers de nouvelles fonctionnalités et de correctifs depuis les quatre coins du monde...
Dans le sens large, Java est déjà Open Source. Nous travaillons beaucoup avec la communauté, celle-ci ne se gêne pas pour modifier et tester ses idées avec le source.
Que reprochez-vous au passage de Java l'Open Source ?
Le grief que nous pouvons avoir avec le fait de passer Java en Open Source concerne surtout le testage et la fiabilité de Java. En fait, la plupart des programmeurs Java apprécient le fait que nous insistions sur les tests que nous pratiquons.
Mais comme cela a déjà été dit, il s'agit plus d'une question de temps, le temps qui nous est nécessaire pour passer à l'Open Source sans abîmer les propriétés les plus importantes de Java, celles qu'apprécient tous les programmeurs.
Nous approcherons probablement cela de la même manière que l'a fait Apache. La licence Apache fait la différence entre le nom du logiciel et son code source, donc seul le code est Open Source, et vous ne pouvez pas utiliser le source et appeler votre prochet Apache. Notre idée serait la même pour Java. Savoir comment exactement nous allons nous y prendre, c'est difficile à dire. Ce sur quoi les utilisateurs tiennent, c'est le nom "Java", qui retient des idées de solidité et de fiabilité, idées que ne mériterait pas forcément un projet utilisant les sources de Java. Il nous est donc important de conserver des droits sur le nom.
|
|
En créant Java, nous avons dû choisir entre facilité d'utilisation et robustesse face à de lourds projets" |
|
C# et le CLR sont tous deux passés par les comités de l'ECMA et de l'ISO pour y être certifiés. Je crois que qu'il y avait eu des tentatives similaires avec Java ?
Nous sommes également passés par ces deux instances avec Java, mais nous avons fini par nous retirer du processus dans les deux cas. ECMA et ISO sont des instances très politisées, et très facilement manipulées. Les discussions se sont assez mal passées...
Pour ECMA, leur processus est surtout affaire de documentation. Nous avions déjà eu de très bons rapports avec l'IETF, et en travaillant avec eux nous étions parvenus à l'idée d'une implémentation de référence, idée qui nous semblait très bonne. Par ailleurs, nous croyons fortement dans le fait d'avoir une suite de tests. Nous voulions que l'un des documents de la spécification soi l'implémentation de référence, et qu'un autre soi la suite de tests. Au début, ECMA annoncait qu'ils était d'accord pour que ces éléments fassent partie intégrante du standard, mais au dernier moment, ils ont changé d'avis.
À part Java, quel est votre langage de choix, ou celui qui vous passionne à l'heure actuelle ?
Cela va vous paraître bizarre, mais je n'aime vraiment que Java ces temps-ci. J'ai travaillé un peu avec Groovy, PHP et Perl, mais pour la sorte de programmation que je fais généralement, aucun d'entre eux ne me convient.
Il fut un temps où moi aussi j'essayais un nouveau langage tous les six mois, ou j'en créais un de bout en bout, mais vous savez, après l'avoir fait une poignée de fois, ça devient rapidement ennuyeux en fait. Ce que j'aime vraiment, c'est créer des systèmes.
Je trouve dans l'inspiration quotidiennement dans les manières de fonctionner des autres langages. Vous savez, quand Java a été créé, nous avons vanté sa syntaxe proche de C et C++, mais c'était surtout pour rassurer les développeurs. Derrière les rideaux, ça ressemble beaucoup plus à Pascal, Modula, Simula ou Lisp, liés entre eux - et ça a plutôt bien marché . J'en suis assez content.
|
| |
Propos recueillis par Xavier Borderie, JDN Développeurs |
|
|
PARCOURS
|
|
 |
| |
James Gosling, 51 ans, est directeur technique des produits de développement chez Sun Microsystems.
1994 Fait partie de l'équipe ayant créé Java. En a implémenté le premier compilateur et la première machine virtuelle, en 1995.
|
|
|
|
|
|
|
Dossier 
