Un premier aperçu de l'IDE JBuilder de Borland

En juin 1995, quand j'ai appris que Borland allait créer un outil Java, j'étais très content. Borland était la seule entreprise à avoir entravé la franchise Visual Basic créée par Microsoft. De plus, l'environnement de développement Delphi de Borland est considéré par beaucoup (y compris moi-même) comme le meilleur outil de développement rapide d'applications (RAD) sur le marché. C'est donc avec beaucoup d'enthousiasme que j'ai acheté Borland C ++ 5.0 avec support Java à la fin de 95.

Malheureusement, l'effort de Borland a laissé beaucoup à désirer. L'un des plus gros inconvénients du produit était que le support Java était un module complémentaire au C ++, plutôt qu'un outil à part entière. Le problème avec cette approche est que Java ne ressemblait pas du tout au C ++ en termes d'unités de compilation, de fichiers objets et de cibles de compilation. En Java, vous compilez un fichier de classe en un objet que vous pouvez immédiatement instancier avec d'autres objets déjà présents sur le système. Il n'y a pas de cibles ".exe" et ".dll", qui sont le modèle utilisé par l'EDI C ++ générique. Ainsi, les classes de construction étaient encombrantes, la documentation était presque inexistante et l'expérience était totalement insatisfaisante. Le compilateur C ++ fonctionnait très bien cependant.

Dans la foulée du produit add-on C ++, le mot est rapidement sorti à propos de "Latte", le nom de code d'un environnement IDE sur lequel les ingénieurs du groupe Delphi allaient travailler et qui a été entièrement écrit en Java. Le projet ambitieux a été entaché de retards; il a fait une démonstration lors de la première JavaOne Developer Conference à San Francisco en 1996, puis à nouveau à JavaOne '97. Enfin, il a été publié sous le nom de JBuilder.

Un rapide tour d'horizon de JBuilder

JBuilder partage de nombreux thèmes communs avec le monde Delphi et se sent assez similaire aux outils Symantec Visual Cafe. Il était donc facile pour moi de démarrer avec JBuilder - même sans lire la documentation fournie. (Quand je fait une question, la documentation était assez complet en termes de description des options disponibles.)

L'environnement se compose d'une «barre de contrôle», qui est une fenêtre de barre d'outils flottante, une «fenêtre de navigation» avec un contrôle d'arborescence en couches sur la gauche et une fenêtre de visualisation sur la droite. Il n'y a qu'une seule barre de contrôle, mais plusieurs fenêtres de navigateur peuvent être ouvertes.

La barre de contrôle, illustrée ci-dessous, se compose des commandes de menu standard en haut, d'une palette d'outils sur la gauche qui fournissent des raccourcis vers les éléments de menu et d'une collection de composants (JavaBeans) qui sont disponibles pour une utilisation dans votre application visuelle ou applet. Sous la palette d'outils et les composants se trouve une ligne d'état qui est mise à jour avec l'activité en cours.

La fenêtre du navigateur est illustrée ci-dessous. Cette fenêtre est l'endroit où vous interagissez avec votre code source, HTML ou Java. Au-dessus se trouve la barre de contrôle, qui vous permet de démarrer des actions (comme une reconstruction) et contient vos collections de JavaBeans à utiliser dans vos propres applications. De plus, chaque fenêtre de navigateur peut afficher un projet en cours, donc si vous travaillez sur plusieurs projets - comme un nouveau JavaBean et une application qui l'utilise - vous pouvez ouvrir les deux projets en même temps et vous déplacer facilement entre eux. . Cette capacité m'a impressionné car elle prend en charge la forme la plus courante de développement Java, en changeant plusieurs éléments différents à la fois. Dans une fenêtre de navigateur, il peut y avoir un projet de classes utilitaires, dans un autre navigateur l'applet qui utilise ces classes et dans une troisième un ensemble de pages HTML qui utilisent l'applet.

La fenêtre du navigateur est divisée verticalement - avec l'arborescence des fichiers à gauche et le visualiseur à droite. La division verticale est appelée le «rideau». L'interface utilisateur de Borland vous permet de retirer le rideau lorsque vous souhaitez une vue plein écran du code source sur lequel vous travaillez. Sous chaque moitié de la fenêtre du navigateur se trouvent des onglets de contrôle qui modifient la sémantique de la vue elle-même.

Lors de l'affichage du code source Java, les onglets de la moitié de la visionneuse du navigateur sont étiquetés source, conception et doc.

  • L'onglet source vous montre simplement le code source et vous pouvez le modifier à l'aide de l'éditeur de coloration syntaxique inclus.

  • L'onglet Conception affiche un espace de travail visuel dans lequel se trouvent les informations d'interface utilisateur que vous avez définies. Ainsi, par exemple, si votre code source contenait des définitions de panneau, des boutons, etc., ce panneau est la zone de glisser-déposer dans laquelle vous pouvez composer ces informations.

  • L'onglet doc vous montre le document HTML qui est généré à partir des commentaires imbriqués dans le code source. Le document HTML peut être extrait en utilisant JavaDoc, cependant, il n'y a aucun moyen automatisé que je pourrais trouver pour générer ce document.

L'un des aspects les plus intelligents de l'implémentation du navigateur est peut-être que lorsque vous parcourez un fichier de classe, le navigateur lit le fichier de classe et le décompile suffisamment pour vous montrer la structure du code source. Cela peut être très utile si vous avez l'habitude de lire la source plutôt que de regarder un diagramme d'objets. De plus, lorsque vous sélectionnez l'une des classes standard Java ou les classes personnalisées Borland, cliquer sur l'onglet doc renverra la page JavaDoc pour cette classe. Cela vous permet de faire des choses comme: mettre en évidence une classe système, sélectionner "parcourir le symbole sélectionné", et voir à la fois la source reconstruite ou la documentation de la classe. Je préfère cette méthode, qui préserve le formatage HTML qui est intégré dans les données JavaDoc, aux systèmes qui convertissent la documentation Java en fichiers «d'aide» Microsoft.

Le débogueur JBuilder

Bien sûr, écrire du code est facile. Il est difficile de le faire fonctionner. La fonctionnalité la plus importante de tout IDE est peut-être son débogueur. Heureusement, le débogueur Borland JBuilder ne déçoit pas. Une capture d'écran du débogueur est présentée ci-dessous.

Lors du débogage, la fenêtre du navigateur est reconfigurée pour prendre en charge l'analyse de l'état de votre classe. La vue de fichier structurée en arborescence est divisée en une fenêtre supérieure contenant l'état du thread et une fenêtre inférieure contenant des informations sur les variables actives. En outre, la moitié gauche du navigateur gagne des contrôles d'onglet supplémentaires en bas qui contrôlent le fonctionnement du débogueur.

De plus, les fenêtres contextuelles afficheront la valeur d'une variable dans la fenêtre source de la même manière que le débogueur de Symantec fonctionne. Toutes les fonctionnalités de débogage standard sont présentes: étape unique, points de surveillance, points d'arrêt, points d'arrêt conditionnels, etc. Il convient de noter le support de thread, qui est exceptionnel. Dans la fenêtre de thread dans le coin supérieur gauche, vous pouvez cliquer sur la ligne en cours d'exécution de n'importe quel morceau de code dans n'importe quel thread, et la fenêtre source apparaîtra à cet endroit dans le code. En outre, la fenêtre en bas à gauche affichera tout état local et global visible par ce thread. Le débogueur de JBuilder représente définitivement le nouveau standard par rapport auquel les autres débogueurs Java seront mesurés.

Sur le côté gauche de la fenêtre source, de petits points indiquent les lignes où les points d'arrêt peuvent être installés. Cliquer sur le point met la ligne en surbrillance et le symbole du point d'arrêt apparaît. Une autre fonctionnalité utile est "exécuter au curseur" - pour les moments où vous ne voulez pas parcourir chaque itération d'une forboucle. Cliquez simplement sur la ligne, sélectionnez «exécuter jusqu'au curseur» et l'exécution s'arrête là.

Gestion de la sortie

Un dernier domaine dans lequel j'ai trouvé JBuilder particulièrement utile était sa gestion de la sortie de l'exécution d'une application Java. Le journal d'exécution est une fenêtre qui contient toutes les données envoyées à System.outpartir de l'exécution en cours. Cependant, lorsque plusieurs projets sont ouverts, le journal d'exécution conserve des onglets séparés pour chaque projet! Un exemple de ceci est montré ci-dessous.

Comme vous pouvez le voir sur l'image, il y a deux onglets, un pour "exemple" et un pour "BASIC", le projet en cours. Cette séparation est essentielle lors de la création de plusieurs bibliothèques de classes en même temps, car elle vous empêche de mélanger la sortie des deux projets.

Ce que j'aime chez JBuilder

Parfois, ce sont les petites choses. J'aime beaucoup le fait que l'on puisse imprimer le code source Java sur une imprimante couleur et le faire sortir avec ses polices et sa coloration syntaxique intacte. Si je pouvais personnaliser les en-têtes et les pieds de page et spécifier une sortie "double" (deux pages de code source imprimées côte à côte sur une page de sortie paysage), ce serait parfait.

Le support de Java 1.1 est très agréable. Alors que JDK 1.1 est sorti depuis un certain temps et que Symantec a pris en charge la version bêta de la version 1.1, rien de tel que d'avoir un IDE conçu dès le départ pour fonctionner avec la version 1.1.

Comme je l'ai dit plus tôt, le débogueur est également très agréable: il donne une grande quantité d'informations d'une manière facile à comprendre. Une grande partie du débogage est de style "pointer-et-tirer", que certains utilisateurs aiment (je le fais) et d'autres pas (croyant que "gdb" signifie DeBugger de Dieu). Je pense que c'est suffisant pour trouver même les bogues de blocage de thread les plus difficiles.

Ce que je n'aime pas chez JBuilder

L'IDE configurable de JBuilder n'est en fait pas configurable de deux manières cruciales:

  • Tout d'abord, vous ne pouvez pas définir les couleurs d'arrière-plan et de premier plan par défaut dans l'affichage. Au lieu de cela, vous devez d'abord les définir pour l'ensemble de votre bureau, puis JBuilder remarquera les changements. Vous pouvez, cependant, les définir en utilisant certains de leurs schémas de couleurs "prédéfinis".

  • Le deuxième problème sérieux est que vous ne pouvez pas personnaliser les frappes de l'éditeur. Mes deux éditeurs préférés à cet égard sont EMACS et l'éditeur de fichiers du programmeur (PFE). L'onglet de personnalisation de l'éditeur de JBuilder consiste à pouvoir sélectionner des mappages de touches pré-emballés - par défaut, Brief, Classic et Epsilon sont inclus - et à pouvoir sélectionner le fonctionnement des éléments tels que l'indentation automatique, la mise en évidence et le bouclage. Je suis toujours à la recherche de l'éditeur qui vous permet de définir des packages de macros en Java.

Dans le domaine de la présentation, JBuilder souffre de quelques bugs simples qui, je pense, seront corrigés dans la première version du patch. Par exemple, si votre bureau a sélectionné "Grandes polices" (ce que Microsoft insiste sur le fait de prendre Arial 10 et de le "multiplier" par un certain facteur), le calcul de l'espace requis par la barre d'outils est interrompu et les icônes des bibliothèques de composants sont coupées de. Si, en revanche, vous définissez les apparences de police explicitement dans la section "Apparence" des propriétés de votre bureau, par exemple Arial 14 points, la barre de composants est rendue correctement. De toute évidence, c'est une bogosité Microsoft (où une police 10pt n'est pas toujours rendue comme une police 10pt), mais les gens de Borland doivent s'en occuper.

Un autre domaine que je n'aime pas dans tous les IDE pour Java est le recours à leur propre machine virtuelle Java "personnalisée" pour le développement. J'espère qu'à l'avenir, les IDE seront utilisables avec le Java Runtime Environment (JRE) standard et quelques bibliothèques personnalisées. Personne n'a encore fait celui-ci correctement.

Ce que j'aurais aimé

Bien sûr, aucun produit ne convient parfaitement à tout le monde, donc ce que j'aimerais voir peut être considéré comme du bruit pour les autres. Mais, dans l'esprit de parler, voici les trois choses principales que j'aimerais voir dans JBuilder (ou dans tout IDE solide d'ailleurs):

  • Contrôle de configuration IDE plus fin - mappages de touches, couleurs d'affichage et disposition

  • Prise en charge du profilage dans le débogueur - suivi / minutage des appels, utilisation du tas, mappages de mémoire, etc.

  • Contrôle du code source - c'est un domaine où Java est faible (contrôle de version), et un système de contrôle intelligent qui notait quand le contrat a changé (changements de classe incompatibles) et ce qui a changé quand, serait un vrai régal

Emballer

L'outil JBuilder est une entrée très efficace sur le marché de plus en plus encombré des IDE. Il offre des capacités extraordinaires dans certains endroits - tels que les JavaBeans, le débogage, plusieurs projets et la conception d'interface utilisateur. Cette version de JBuilder a quelques aspérités autour de la présentation et de la configurabilité de l'EDI, cependant, cela est à prévoir dans une version 1.0. Son support de Java 1.1 est également supérieur. Mon avis est que, pour la première fois, les gars et les filles de Symantec ont une concurrence sérieuse pour leur produit Visual Cafe Pro.

Chuck McManis est actuellement directeur des logiciels système chez FreeGate Corp., une start-up financée par capital-risque qui explore les opportunités sur le marché Internet. Avant de rejoindre FreeGate, Chuck était membre du groupe Java. Il a rejoint le groupe Java juste après la formation de FirstPerson Inc. et était membre du groupe OS portable (le groupe responsable de la partie OS de Java). Plus tard, lorsque FirstPerson a été dissous, il est resté avec le groupe pendant le développement des versions alpha et bêta de la plate-forme Java. Il a créé la première page d'accueil «tout Java» sur Internet lorsqu'il a programmé la version Java de la page d'accueil de Sun en mai 1995. Il a également développé une bibliothèque cryptographique pour Java et des versions du chargeur de classes Java permettant de filtrer les classes. basé sur des signatures numériques. Avant de rejoindre FirstPerson,Chuck a travaillé dans le domaine des systèmes d'exploitation de SunSoft, développant des applications réseau, où il a réalisé la conception initiale de NIS +. Consultez sa page d'accueil.