Einige Komponenten enthalten nichtmodellierte Klassen. Für jede dieser Klassen gibt es ein Javadoc, in dem die Verwendung der externen Schnittstelle oder Klasse beschrieben wird.
In einigen nichtmodellierten Klassen sind Eclipse-Zugriffsbeschränkungen vorhanden, so dass der Kunde eine Leitlinie hat, welche APIs er aufrufen oder anpassen kann. Bestimmte Klassen und Pakete sind als eingeschränkt markiert. Diese Klassen dürfen nicht verwendet werden, da es sich bei ihnen um interne Klassen handelt, die sich mit der Zeit verändern können. Zugriffsbeschränkungen sollten nicht aus der Datei 'Eclipse.classpath' entfernt werden, weil das zur Verarbeitung von eingeschränkten Klassen führen könnte, was wiederum Probleme beim Upgraden verursachen kann.
Einige nichtmodellierte Komponenten enthalten package-geschützte Klassen, die nicht mit einem Kundencode verwendet werden sollten. Der Kunde darf in dieselbe Package-Struktur keinen Kundencode einfügen, um package-geschützte Klassen aufzurufen oder zu referenzieren.
Viele nichtmodellierte APIs lassen sich nicht direkt anpassen. Nur Schnittstellen oder Klassen, die mit der Anmerkung @Implementable versehen sind, können erweitert oder implementiert werden. Solche Klassen verfügen über ein Javadoc, in dem ihre Anpassung oder Implementierung detailliert beschrieben wird. Nichtmodellierte Klassen, die nicht mit der Anmerkung @Implementable versehen sind, dürfen nicht erweitert oder implementiert werden, da mit der Zeit neue Operationen hinzugefügt werden könnten, die sich möglicherweise auf das Upgraden auswirken.
Für Klassentypen, die mit der Anmerkung @Implementable versehen sind, sind Ereignisse und Strategien die typischen Anpassungsmechanismen.
Ereignisse ermöglichen es dem Kunden, an unterschiedlichen Punkten der Anwendung angepasste Logik hinzuzufügen. Details dazu, wie man Ereignislistener hinzufügt, finden Sie im Dokument 'Persistence Cookbook'. Ereignisklassen sind typischerweise mit ‘xxxEvent’ benannt und lassen sich auf diese Weise leicht ermitteln.
Strategiemuster ermöglichen es dem Kunden, das Standardverhalten bestimmter Funktionen innerhalb der Anwendung zu ändern. Jede Strategieklasse ist mit einer Standardimplementierung versehen; der Kunde kann jedoch wählen, ob er mithilfe von Guice-Bindungen die Standardimplementierung einer beliebigen Strategieoperation überschreiben will. Weitere Details dazu, wie Guice-Bindungen verwendet werden, finden Sie im Dokument 'Persistence Cookbook'. Strategieklassen sind typischerweise mit ‘xxxStrategy’ benannt und lassen sich auf diese Weise leicht ermitteln.