Pourquoi j'ai besoin de charger la définition de la classe comme:
classe.forname ("ClassName");
Quel est le besoin et l'avantage de cela .typiquement qui est utilisé pour charger la classe de pilotes dans JDBC.
3 Réponses :
Vous ne le faites pas vraiment. classname.class fonctionnera aussi bien. Quoi qu'il en soit, obtenir la définition de la classe de cette manière est généralement la façon dont Les implémentations SPI sont injectées dans < un href = "http://fr.wikipedia.org/wiki/application_programming_interface" rel = "Nofollow Noreferrer"> API .
Quel est le besoin et l'avantage de cela. Typiquement qui est utilisé pour charger la classe de pilotes dans JDBC.
Il vous permet de créer vos applications afin que des dépendances externes clés ne soient pas compilées dans le code source de l'application.
Par exemple, dans le boîtier JDBC, il vous permet de basculer entre différentes implémentations de pilote et (en théorie) différents fournisseurs de base de données sans modifier votre code source.
Un autre cas d'utilisation est lorsque certains fournisseurs développent une forme générique d'une application avec des points d'extension permettant aux clients de "brancher" leurs propres classes personnalisées. Les classes personnalisées sont généralement chargées avec
class.forname (...) .Un troisième cas d'utilisation est des cadres d'application et des conteneurs qui utilisent généralement
class.forname (...) sous la hotte pour charger de manière dynamique les classes des haricots, des servlets, etc. .Un quatrième cas d'utilisation est l'endroit où l'application (ou une bibliothèque d'applications) comporte des modules non utilisés dans une exécution d'application typique. En utilisant
class.forname (...) en interne, l'application ou la bibliothèque peut éviter la dépendance de la CPU et de la mémoire de chargement et d'initialisation d'un grand nombre de classes indésirables. (Les bibliothèques Sun Swing font apparemment cela pour réduire les temps de démarrage des applications et je suis sûr qu'il existe d'autres exemples.)Cependant, si vous ne le faites pas besoin pour pouvoir faire ce genre de chose, les dépendances statiques sont plus simples à mettre en œuvre.
suivi
Mais ici, tout en se compilant, le paramètre "CLASSNAME" est connu .SO La plus grande dépendance externe est compilée dans le code source d'application ??
Nope. Évidemment, cela défait le but. L'application (ou le cadre) détermine généralement les noms des classes à charger dynamiquement à partir d'un fichier de configuration.
Mais ici, tout en se compilant, le paramètre "CLASSNAME" est connu .SO La plus grande dépendance externe est compilée dans le code source d'application ??
Je n'ai pas pu vérifier votre 4ème cas d'utilisation. La spécification de langue Java, à la section 12.4.1, définit que la machine virtuelle ne doit pas initialiser une classe avant la création d'une instance de cette classe, un élément statique utilisé ou une déclaration d'affirmation lexiquement dans la classe exécutée. Simplement se référer à une classe ne l'initialise pas. L'heure du chargement est à la discrétion de la machine virtuelle, cependant, selon -verbose: classe, le client de Sun et le serveur VM pour Windows diffèrent le chargement jusqu'à ce que l'initialisation soit requise.
Pas sûr de votre commentaire de suivi: Même si le nom de la classe commence à charger de manière dynamique est cueilli à partir d'un fichier de configuration / propriété, le nom sera verrouillé en bytecode compilé. S'il est possible que l'on puisse spécifier une classe de base ou une interface.
@ scientifique.rahul - oui, eh bien c'est ce que je voulais dire. Le modèle standard pour les classes de plugin chargés dynamiquement consiste à mettre en place une interface ou à étendre une classe de base de l'application / cadre. Ou éventuellement une interface / classe Java standard; par exemple. Runnable .
La raison la plus simple Pourquoi classe.forname (String ClassName) est utilisé sont