From time to time I encounter the use of internal Web Dynpro classes or interfaces based on forbidden type casts. This means the application developer utilizes the Java Browsing Perspective in the SAP NetWeaver Developer Studio for finding more information on type hierarchies. With this information one can then hijack framework-internal classes and interfaces not starting with the prefixes WD or IWD in order to get access to non-public functionality. There are several reasons why such an approach could be highly risky.
This WebLog explains why you should strictly adhere to the following contract:
Only use interfaces that start with IWD and only use classes that start with WD.
Never ever hijack internal Web Dynpro classes and interfaces.
Web Dynpro Runtime API:
Only Web Dynpro (WD) interfaces, that begin IWD*, and classes, that begin WD*, are part of the published Web Dynpro API, which is documented in the Online Help of the NetWeaver Developer Studio.
There are a few packages which were mistakenly included in the Web Dynpro Runtime API documentation:
- com.sap.tc.webdynpro.clientserver.session, com.sap.tc.webdynpro.services.cal.core.exceptions, com.sap.tc.webdynpro.services.exceptions and com.sap.tc.webdynpro.services.sal.util.cache.
These packages are not part of the Web Dynpro API and will consequently be withdrawn with the first new Net Weaver release.
In this respect I also want to remind that you should never use the prefixes wd, IWD or WD in your own application coding. The various forms of the “wd” prefix are used by the Web Dynpro Tools during the generation of internal coding entities. Therefore it is very likely that a naming conflict might occur if user-defined names start with one of the above prefixes.
Source-Code Compatability
Only for those types starting with IWD or WD the Web Dynpro runtime developers guarantee that they will remain source-code compatible, meaning that older Web Dynpro applications can run against a newer Web Dynpro runtime after a rebuild. All other classes and interfaces are private and they do not belong to the API.
Changes in Future Releases
Furthermore, the internal interfaces and classes can and will change their semantics or even disappear from support package to support package or release to release without further notice. There is no commitment to backward compatibility for these types in any way. It may happen at any point in time, without prior warning, that the names, packages or behaviour of the non-public classes change. In addition, applications might no longer be able to access any other Web Dynpro classes or interfaces in future releases at all!
Extension and Implementation of Public Web Dynpro API
In NetWeaver 04 the Web Dynpro Runtime API provides the possibility to extend and/or implement a specified subset of the public Web Dynpro API inside own application components without losing backward compatability. This subset of classes and interfaces is part of the Web Dynpro programming model API in package com.sap.tc.webdynpro.progmodel.api:
- WD-Classes: The following types can be called or extended by applications using Web Dynpro:
WDSimpleValueSupplier, WDOVSNotificationAdapter and WDOVSContextNotificationAdapter. - IWD-Interfaces: The following types can be called, extended or implemented by applications using Web Dynpro:
IWDValueSetSource, IWDOVSNotificationListener, IWDValueSupplier, IWDOVSContextNotificationListener, IWDNodeCollectionSupplier, IWDNodeCollectionDisposer and IWDBoundValueSet.
So to prevent any trouble and to keep the compatibility of your Web Dynpro applications unaffected in future releases we strongly suggest that every Web Dynpro application developer strictly observes the described rules.