Certains composants contiennent des classes non modélisées. Pour ces classes, l'utilisation de chaque interface ou classe externe est décrite dans le Javadoc de la classe.
Certaines classes non modélisées sont associées à des restrictions d'accès Eclipse en place pour fournir aux clients des conseils relatifs aux API qu'ils peuvent et ne peuvent pas appeler ou personnaliser. Certains packages et classes sont marqués comme restreints ; ces classes ne doivent pas être utilisées puisqu'il s'agit de classes internes pouvant changer au fil du temps. Les restrictions d'accès ne doivent pas être supprimées du fichier Eclipse.classpath car cela peut provoquer la consommation de classes restreintes pouvant entraîner des problèmes lors des mises à niveau.
Certains composants non modélisés contiennent des classes protégées de package ; ces classes ne doivent pas être utilisées en mode personnalisé. Les clients ne doivent pas placer de code personnalisé dans la même structure de package pour appeler ou référencer des classes protégées de package.
De nombreuses API non modélisées ne sont pas directement personnalisables. Seules les interfaces/classes marquées par l'annotation @Implementable peuvent être étendues ou implémentées. Pour ces classes, le Javadoc détaille leur personnalisation ou leur implémentation. Les classes non modélisées qui ne sont pas marquées avec l'annotation @Implementable ne doivent pas être étendues ou implémentées, car de nouvelles opérations peuvent être ajoutées au fil du temps et entraîner des répercussions sur la mise à niveau.
Pour les classes marquées avec l'annotation @Implementable, les mécanismes de personnalisation typiques pour ces types de classes sont les événements et les stratégies.
Les événements permettent aux clients d'ajouter une logique personnalisée à divers points de l'application. Pour plus de détails sur l'ajout de programmes d'écoute d'événements, veuillez consulter le document Guide de Persistence. Les classes d'événement s'appellent généralement ‘xxxEvent' afin d'être facilement identifiées.
Les modèles de stratégies permettent aux clients de changer le comportement par défaut de certaines fonctions dans l'application. Chaque classe de stratégie dispose d'une implémentation par défaut fournie. Cependant, les clients peuvent choisir de substituer l'implémentation par défaut de l'une des opérations de stratégie grâce à l'utilisation de liaisons Guice. Pour plus de détails sur l'utilisation des liaisons Guice, veuillez consulter le document Guide de Persistence. Les classes de stratégie s'appellent généralement ‘xxxStrategy', afin d'être facilement identifiées.