@deprecatedcode from API, it is still desirable to retain backward binary compatibility. Because of JVM method/field/class resolution mechanism, it is permitted to move the implementation upwards the inheritance hierarchy. However, the superclass that receives the methods must not be visible in the sources (otherwise the change would not serve any good) and specifically, must not be referenced from extends clause of the changed class. The compatibility superclass ought to reside in a different module to allow reduce type dependencies and should be only injected into inheritance chain if and only if some of enabled modules depend on the obsolete version of the API module.
PatchForclasses must be defined as module fragment, since it has to share classloader with the patched module: put
into the Module's manifest. TheOpenIDE-Module-Fragment-Host: codenamebase
codenamebasemust identify the host module which contains the class(es) to be patched. Note that it is not possible to support removed constructors this way; the constructor has to be physically present on the API class. To provide backward-compatibile code injection for constructors, please use
ConstructorDelegateannotation. For examples, plese see the NetBeans Wiki
Built on December 17 2017. | Portions Copyright 1997-2017 Oracle. All rights reserved.