Non. En effet, le JDT offre plusieurs fonctions sophistiquées, dont la recompilation incrémentielle entièrement automatisée, l'évaluation de fragments de code, l'assistant de saisie de code, les hiérarchies des types et le remplacement de code à chaud. Or ces fonctions utilisent un support spécial intégré au compilateur Java du plan de travail (qui fait partie intégrante du générateur de projet incrémentiel du JDT), mais qui n'existe pas dans les compilateurs Java standard.
Un projet ne contient que des fichiers et des dossiers. La division en packages Java est introduite par le chemin d'accès aux classes d'un projet Java (dans l'interface utilisateur, la vue Packages présente les packages définis par le chemin d'accès aux classes). Conseil : si la structure des packages n'est pas conforme à votre attente, vérifiez le chemin d'accès aux classes. En effet, l'infrastructure de recherche Java ne recherche les déclarations des éléments Java et les références à ces éléments que dans le chemin d'accès aux classes.
Les ressources internes résident dans les projets du plan de travail et sont donc gérées par ce dernier. Comme pour toutes les autres ressources, leurs versions peuvent être gérées par le plan de travail. En revanche, une ressource externe ne fait pas partie du plan de travail et ne peut donc être utilisée que par l'intermédiaire d'une référence. Par exemple, un environnement JRE est souvent externe et très volumineux, et il n'est pas nécessaire de l'associer à un système VCM.
Chaque projet Java localise ses fichiers source Java à l'aide d'une ou plusieurs entrées de types source du chemin d'accès aux classes du projet. Vous pouvez utiliser des dossiers source pour regrouper les packages d'un grand projet afin de faciliter leur organisation, ou pour conserver le code source à part des autres fichiers qui composent le projet. En outre, utilisez des dossiers source lorsque certains fichiers (par exemple, de la documentation) n'ont pas besoin de figurer dans le chemin de compilation.
Les bibliothèques sont stockées sous forme de fichiers JAR contenant des fichiers classes binaires (et éventuellement d'autres ressources). Ces fichiers classes binaires fournissent les informations de signature des packages, des classes, des méthodes et des zones. Ces informations sont suffisantes pour une compilation ou une exécution, mais elles sont beaucoup moins riches que le code source original. Afin de faciliter l'exploration et le débogage des bibliothèques binaires, il existe un mécanisme qui permet d'associer un fichier source JAR (ou ZIP) au fichier JAR binaire correspondant.
Lors de la compilation des fichiers source du projet, si votre projet Java utilise des dossiers source, le compilateur Java copie également les ressources non Java dans le dossier de sortie afin qu'elles soient disponibles dans le chemin d'accès aux classes du programme lors de l'exécution de celui-ci.
En utilisant des dossiers source et en plaçant les ressources que vous ne voulez pas voir copier dans le dossier de sortie dans un dossier séparé qui ne figure pas dans le chemin d'accès aux classes.
Ce n'est pas nécessaire. Les fichiers qui se trouvent dans le dossier racine d'un projet ou d'un dossier source sont considérés comme faisant partie du package par défaut. Chaque dossier source peut ainsi posséder un fragment du package par défaut.
La fonction de propagation des modifications permet de modifier un programme tout en préservant son comportement. Le JDT permet un certain nombre de transformations, décrites dans le livre de Martin Fowler Refactoring: Improving the Design of Existing Code, publié par Addison Wesley en 1999.
Lorsque vous voulez déterminer à l'aide du compilateur quel élément Java correspond à un segment de code source.
Les informations concernant un programme Java sont indépendantes du générateur Java. Elles sont automatiquement mises à jour lorsque vous modifiez une ressource ou que vous effectuez des opérations Java. En outre, les fonctions du JDT (par exemple, les hiérarchies des types, l'assistant de saisie de code et la recherche) restent pleinement opérationnelles lorsque la fonction de génération automatique est désactivée. Ainsi, lorsque vous procédez à une propagation des modifications importante qui nécessite la désactivation des générateurs, vous pouvez toujours utiliser l'assistant de code, lequel reflétera les dernières modifications (non encore générées). En dehors du lancement (c'est-à-dire l'exécution et le débogage) d'un programme, la seule fonction qui fait appel au générateur Java est l'évaluation de fragments de code.
Lorsque vous fermez le plan de travail, le générateur de projet incrémentiel Java enregistre son état interne dans un fichier. Lors de la première génération qui suit la réouverture d'un projet, le générateur restaure son état interne. Lorsque le fichier correspondant est volumineux, l'utilisateur peut constater un délai de génération inhabituellement long.
Vérifiez que votre chemin des classes de compilation est correct. La définition du chemin des classes de compilation correct est une étape importante du développement en Java. Si ce chemin est incorrect, vous ne pourrez pas compiler votre code. En outre, vous ne pourrez pas visualiser les hiérarchies des types ni y rechercher des éléments Java.