Going from one CDK release to another brings in API changes. While the project tries to keep the number of changes minimal, these are inevitible. This chapter discusses some API changes, and shows code examples on how to change your code. The following sections discuss the migration between various versions.
The set of changes include changed class names. For example, the CDK 1.2
class MDLWriter is now called MDLV2000Writer to reflect the
V2000 version of the MDL formats.
This section highlights the important API changes between the CDK 1.4 and 2.0 series. Innovations of CDK 2.0 are described in [1].
Several classes have been removed in this version, for example, because they are superceeded by other code or were considered redundant.
The NoNotificationChemObjectBuilder and the matching implementation
classes are removed. Please use the SilentChemObjectBuilder instead.
The same, of course, applies to all implementation classes. For example,
NNMolecule is removed.
The IMolecule interface and all implementing classes have been
removed. They were practically identical in functionality to the
IAtomContainer interface, except the implication that the
IMolecule was for fully connected structures only. This separation
was found to be complicated, and was therefore removed. Please use the
IAtomContainer interface instead.
Generally, IMolecule, IMoleculeSet, Molecule,
and MoleculeSet can be replaced with the ‘atomcontainer’ equivalents.
Additionally, for IMoleculeSet you may also have to replace
use of methods like getMoleculeCount() with their matching getAtomContainerCount().
Strictly speaking the MDL files span a set of files and a SD file is different
from a molfile. This is reflected in the reader name change:
IteratingMDLReader is now called IteratingSDFReader.
The method findMatchingAtomTypes of the CDKAtomTypeMatcher
gained a ‘s’ and was previously called findMatchingAtomType. The new
name is more consistent, reflecting the fact that it perceives atom types
for all atoms.
Some classes and methods have the same API, but have slightly different
behavior as before. For example, the SmilesGenerator now requires
that all atoms have implicit hydrogen counts set. This can be done with
the CDKHydrogenAdder as explained in Section ??.
The advantage of the builders in the CDK is that code can be independent of
data class implementations (and we have three of them in CDK 1.6, at this
moment). Over the past years more and more code started using the approach,
but that does involve that more and more class constructors take a
IChemObjectBuilder. CDK 1.6 has two more constructors that now take
a builder.
The DescriptorEngine constructor is changed to now take a
IChemObjectBuilder which is needed to initialize descriptor instances.
The second constructor that now needs a IChemObjectBuilder is that of the
SMARTSQueryTool. Here it is passed on to the SMARTSParser which
needs it for its data structure for the matching.
The getInstance() method of the ModelBuilder3D class now also
requires a IChemObjectBuilder.
A significant change in the CDKAtomTypeMatcher behavior is that it now
returns a special ‘X’ atom type when no atom type could be perceived.
See Section ??.
The SMILES stack is replaced in this CDK version. This introduces a few API changes,
outlined here. The new code base is much faster and more functional that what the CDK
had before. Below are typical new SmilesGenerator API usage.
Generating unique SMILES is done slightly differently, but elegantly:
Script code/UniqueSMILES.py
mol = MoleculeFactory.makePhenylAmine()
AtomContainerManipulator.percieveAtomTypesAndConfigureAtoms(mol);
CDKHueckelAromaticityDetector.detectAromaticity(mol);
hAdder = CDKHydrogenAdder.getInstance(mol.getBuilder())
hAdder.addImplicitHydrogens(mol)
generator = SmilesGenerator.unique()
smiles = generator.createSMILES(mol)
print(f"{smiles}")