I reported earlier that the CDK has been updated in CVS to use\nCML from the new Jumbo 5.0. The transition actually involved a lot of changes in the CDK, some I would like to address in the following comments.\nOne thing is that CML write support (not reading!) uses the new Jumbo library which requires Java 1.5. Thus, if Java 1.5 is not available,\nthen CML writing should not be compiled. This is how this is done.
\n\nThe CDK makes extensive use of JavaDoc taglets.\nCDK uses tags of type @cdk.SOMETAG. And an important tag in this case, is the @cdk.require tag, becuase it allows us to make the CDK build\nsystem aware that the class requires Java 5.0 to be compiled. Thus, we have for example\nthis code in CVS, of which bits are:
/**\n * Serializes a SetOfMolecules or a Molecule object to CML 2 code.\n * Chemical Markup Language is an XML based file format {@cdk.cite PMR99}.\n * Output can be redirected to other Writer objects like StringWriter\n * and FileWriter.\n *\n * @cdk.module libio-cml\n * @cdk.builddepends xom-1.0.jar\n * @cdk.depends jumbo50.jar\n * @cdk.require java1.5\n */\npublic class CMLWriter extends DefaultChemObjectWriter {\n}\nAs probably is clear compiling this jars requires a two jars to be present, of which the jumbo50.jar itself is not required for compiling\nthe class source code. It also shows the use of the @cdk.require tag.
Because the CDK still does not require Java 1.5, the CDK is supposed to be buildable with Java 1.4 (the oldest supported Java release). The\nAnt build.xml script is quite\nable to conditionally leave out compiling parts of the CDK, if configured correctly using proper JavaDoc tags, as explained earlier.
\n\nFirst, the build.xml checks what libraries are available for compiling certain parts of the CDK. For example, the build.xml code to check for Java 1.5 looks like:
\n\n<condition property=\"isJava15\">\n <contains string=\"${java.version}\" substring=\"1.5\"/>\n</condition>\nRun ant info to see what is being checked for, or look at the build.xml source code for the check target.
All compiling is done by the compile-module target, and there it in- and excludes bits of the CDK depending on the checked conditions:
\n\n<javac srcdir=\"${build.src}\" destdir=\"${build}\" optimize=\"${optimization}\" \n debug=\"${debug}\" deprecation=\"${deprecation}\">\n\n <excludesfile name=\"${src}/java1.4+.javafiles\" if=\"isJava13\"/>\n <excludesfile name=\"${src}/java1.4.javafiles\" unless=\"isJava14\"/>\n <excludesfile name=\"${src}/java1.5.javafiles\" unless=\"isJava15\"/>\n <excludesfile name=\"${src}/ant1.6.javafiles\" unless=\"hasAnt16\"/>\n <excludesfile name=\"${src}/r-project.javafiles\" unless=\"rispresent\"/>\n\n <includesfile name=\"${src}/${module}.javafiles\"/>\n</javac>\nKeep in mind that the *.javafiles are created with JavaDoc based on the CDK JavaDoc tags mentioned earlier.
While the above mechanism has been present since for some time now, having jumbo50.jar in CVS made the situation a bit trickier:\nthe jumbo50.jar uses the 49.0 class format used in Java 1.5, and cannot be processed by Java 1.4 systems. Since the classpath\nused when compiling CDK source code, is defined in configuration files for those modules in\nsrc/META-INF, the problem did not occur when compiling the modules.\nHowever, it did show an error in the reallyRunDoclet target today, when I was creating the *.javafiles with JavaDoc.\nThe solution was trivial:
<target name=\"reallyRunDoclet\" id=\"reallyRunDoclet\"\n depends=\"compileDoclet\" unless=\"dotjavafiles.uptodate\">\n <javadoc private=\"true\" maxmemory=\"128m\">\n <classpath>\n <fileset dir=\"${lib}\">\n <include name=\"*.jar\" />\n <!-- some jars require some Java version -->\n <exclude name=\"jumbo50.jar\" unless=\"isJava15\"/>\n </fileset>\n <fileset dir=\"${lib}/libio\">\n <include name=\"*.jar\" />\n </fileset>\n <fileset dir=\"${devellib}\">\n <include name=\"*.jar\" />\n </fileset>\n </classpath>\n\n <doclet name=\"net.sf.cdk.tools.MakeJavaFilesFilesDoclet\"\n path=\"${doc}/javadoc\"/>\n\n <packageset dir=\"${src}\">\n <include name=\"org/openscience/cdk/**\"/>\n </packageset>\n\n</javadoc>\nThere is another area of interest: the FileConvertor, which is, sort of, CDK’s\nOpenBabel’s babel variant. The FileConvertor must\nbe compiled in all cases, so we need to conditionally instantiate the CMLWriter, which is not really a problem. However, compiling\nthe source code is more troublesome: the CMLWriter class must be loaded on runtime, and not occur hardcoded in the source code.
In the past I have solved this by using .getInstance() constructs, but the\nChemObjectWriter interface does not define this\nfunctionality, so I decided to use the java.lang.reflect mechanism:
} else if (format.equalsIgnoreCase(\"CML\")) {\n Class cmlWriterClass = this.getClass().getClassLoader().\n loadClass(\"org.opscience.cdk.io.CMLWriter\");\n if (cmlWriterClass != null) {\n writer = (ChemObjectWriter)cmlWriterClass.newInstance();\n }\n Constructor constructor = writer.getClass().getConstructor(new Class[]{Writer.class});\n writer = (ChemObjectWriter)constructor.newInstance(new Object[]{fileWriter});\n} else {\nNow, this has been, by far, the longest blog item I have written so far. I hope it gave you good insight in some techniques CDK uses to deal with\nsituations where functionality might, or might not, be present at build and at run time.
", "summary": "I reported earlier that the CDK has been updated in CVS to use CML from the new Jumbo 5.0. The transition actually involved a lot of changes in the CDK, some I would like to address in the following comments. One thing is that CML write support (not reading!) uses the new Jumbo library which requires Java 1.5. Thus, if Java 1.5 is not available, then CML writing should not be compiled. This is how this is done.", "date_published": "2005-12-10T00:00:00+00:00", "date_modified": "2023-08-05T00:00:00+00:00", "tags": ["cdk","cml","java"], "authors": [ { "name": "Egon Willighagen", "url": "https://orcid.org/0000-0001-7542-0286" } ] } ] }