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.
The time out in AllRingsFinder has been replaced by a treshold that reflects
the percentage of PubChem for which the algorithm finishes. Use the new
AllRingsFinger(Treshold) constructor, instead.
This section highlights the important API changes between the CDK 1.4 and 2.0 series. Innovations of CDK 2.0 are described in [Q30149558].
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.
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 missinghydrogens.
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 atomtypePerception.
Some previously static methods are no longer, and now require the instantiation of the class.
The UniversalIsomorphismTester is an example class that now needs to be instantiated. However, the class is easy to instantiate. For example:
Isomorphism
A major API change happened around the IsotopeFactory. Previously, this class was used to get isotope information, which it gets from an configurable XML file. This functionality is now available from the XMLIsotopeFactory class. However, to improve the speed of getting basic isotope information as well as to reduce the size of the core modules, CDK 1.6 introduces a Isotopes class, which contains information extracted from the XML file, but is available as a pure Java class. The APIs for getting isotope information is mostly the same, but the instantiation is much simpler, and also no longer requires an IChemObjectBuilder:
IsotopesDemo
The IFingerprinter API was changed to accomodate for two types of fingerprints:
the bit fingerprint, outlined by the IBitFingerprint interfaces, and
the count fingerprint, defined in the ICountFingerprint interface. The
IFingerprinter interface now defines getRawFingerprint(IAtomContainer),
getCountFingerprint(IAtomContainer), and getBitFingerprint(IAtomContainer).
These methods returns various kind of fingerprints. For example,
getRawFingerprint(IAtomContainer) returns a Map with strings representing
the various parts of the fingerprint as well as the matching count, and it is this
map that is used as input to the getCountFingerprint(IAtomContainer) method,
which returns this information as a ICountFingerprint implementation. If the
count for each bit is not important, the getBitFingerprint(IAtomContainer) method
can be used, which returns a IBitSetFingerprint implementation.
Because the previous Fingerprinter interface did not include the counting of
how often a bit was set, implementing the new getRawFingerprint(IAtomContainer) method
will likely take some effort, but the other two methods can in many cases just wrap
other methods in the class, as shown in this example code:
FingerprinterMigration
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:
UniqueSMILES
Because SMILES with lower case element symbols reflecting aromaticity has less
explicit information, it is not my suggestion to use. Still, I know that some of you
are keen on using it, for various sometimes logical reasons, so here goes. Previously,
you would use the setUseAromaticityFlag(true) method for this, but you can now
use instead:
AromaticSMILES
Aromaticity is differently calculated now, see Section aromaticity.