Internal APIs

Whereas it is possible to invoke and subclass Internal APIs from custom code, this is discouraged from version 6.0.3. Such APIs are annotated with @Accesslevel(INTERNAL).

Important: 'Discouraged' in this context means that their use continues to be supported, but that such APIs may be changed or removed in future releases, once a minimum notice period of 1 year has been given to customers in respect of any such change or removal.

Note: No such notice is being given for any of the APIs marked as Internal in version 6.0.3. (i.e. there are no current plans to change any of the APIs marked as Internal in 6.0.3), and so there should be adequate time for customers to plan any such migrations.

Existing customer references to APIs which are marked as Internal from version 6.0.3 will continue to function as before, with the exception that discouraged warnings will be generated within Eclipse projects which have such dependencies.

Projects should endeavor to move away from such dependencies on Internal APIs over time, and should not introduce new dependencies on them (within reason - depending on where a customer project is in its design/development process, it may be inevitable in the short term). Most existing customers will see discouraged references reported after taking on version 6.0.3 or later versions, and it is not expected that customers fix these immediately as part of the take on activity. As mentioned above, this will not affect their support entitlements.

Note that as with previous versions of the application, some Internal APIs have been configured to produce 'access restriction' errors in Eclipse if referenced (these APIs are annotated with @Accesslevel(RESTRICTED)), and such references will not be supported in customer projects. These APIs have always been Internal, and were never supported for customer use; it will be obvious which are which - access restricted APIs produce Eclipse errors, discouraged APIs produce Eclipse warnings.