This article summarizes all API changes in KNIME 3.0 and shortly explains what actions should be taken for existing code. If you are a developer please read this article carefully and if applicable change your plug-ins accordingly.
Eclipse 4.5
KNIME 3.0 is based on Eclipse 4.5 instead of 3.7 now. If you have only been using official Eclipse API then very likely no changes to your code are necessary. If you see compiler errors in your code related to Eclipse classes please check back with the Eclipse documentation and release notes how to fix them.
Java 8
KNIME 3.0 used Java 8. No changes to your code are necessary. However, if you have been using HashMaps in your nodes you should double-check if the results are still the same as with Java 7. The hash functions in Java 8 have slightly changed which means that the order when iterating over elements in a HashMap may now be different. This can affect the order of output rows but also the contents of individual cells, depending on your node. Consider using LinkedHashMaps in such cases or explicitly sort the results by some property of the data.
KNIME 3.0 Dependency Declaration
In order to make your Plug-In KNIME 3.0 aware, you likely need to change the "Require-Bundle" section in your plug-in's MANIFEST file. Here is a typical change that needs to be performed.
Require-Bundle: org.knime.base;bundle-version="[2.5.0,3.0.0)", org.knime.chem.types;bundle-version="[2.5.0,3.0.0)", org.knime.bio.types;bundle-version="[2.5.0,3.0.0)"
becomes
Require-Bundle: org.knime.base;bundle-version="[3.0.0,4.0.0)", org.knime.chem.types;bundle-version="[3.0.0,4.0.0)", org.knime.bio.types;bundle-version="[3.0.0,4.0.0)"
(The version change can be done via the MANIFEST eclipse editor by using the "Properties" button.)
If you do not need to change this block then your MANIFEST does not require any minimal or maximal (or both) version, which is considered bad practice as you can't guarantee forward compatibility. It's highly recommended to use the version range shown in the above example.
Row count
BufferedDataTable#getRowCount is now deprecated because it limits the number of rows to 2 billion. There is a new method BufferedDataTable.size which returns a long. Existing code will still work, so there is no immediate action required. However, you should still update your code to use the new size method. As the Java Collections API currently does not support more than 2 billion elements, not all nodes are able to process larger tables. Therefore you should check the table size at the beginning of NodeModel.execute. ConvenienceMethods.checkTableSize may be handy in such cases.
The rarely used method DataContainer.size now returns a long instead of an int.
Extension point for data types
Data types should now be registered at the new extension point org.knime.core.DataType. Existing code will still work but coding problems are reported when run with enabled assertions. The extension point lists a cell class and its serializer. The static method in the DataCell subclasses for returning the serializer is now deprecated and not used any more when a data type is registered via the extension point.
Also the static method getPreferredValueClass in a DataCell implementation is deprecated now. Instead the first implemented DataValue interface is now the preferred value class. Coding errors will be reported when this method is still present.
Additionally a DataCellFactory can be registered which allows creating cells from several input sources (String, InputStream, Reader) in input nodes. Please have a look at the description of the extension point and the JavaDoc of DataCellFactory for details. All our data types have been ported to the new API therefore there are lots of examples available.
Comparing DataCells
In some cases there is more than one DataCell implementation for a DataValue, e.g. SdfCell, SdfBlobCell, or SdfAdapterCell. In KNIME 2.x is was not possible to compare the contents of different cell classes even if the value interfaces were the same (e.g. SdfValue) because DataCell.equalsDataCell was only called for two cells of the same class. This makes it impossible to e.g. join tables with the same contents but different cell implementations. Therefore a new method DataCell.equalContent was added which is called when two cells are from different classes but their preferred value is the same. If you implement this method make sure that the implementation in all classes is the same. One approach is to create a static method in the corresponding DataValue interface that is called by all cell implementations.
DataCell.equals performs some additional consistency checks (e.g. if equals and hashCode are compatible) if assertions are enabled.
Adapter cells
The abstract class AdapterCell does not implement DataCell.equalsDataCell any more. Subclasses must implement this method themselves. Also a sensible implementation of hashCode is required now. This is required for a proper comparison with non-adapter cells having the same preferred value (see the section above).
Extension point for port types
Similar to the new extension point for data types, also port types are now registered at the new extension point org.knime.core.PortType. It lists the port object class, the port object spec class and their serializers. Additionally the port type now has a name and you can define a color that is used in the workflow editor (for instance in the meta node creation wizard). Existing port object implementation continue to work, however coding problems are reported when the static getPortObjectSerializer and getPortObjectSpecSerializer methods are still present. All registered port types are available in the meta node wizard. Therefore the extension point org.knime.workbench.editor.metanode_porttype has been removed completely. Using the new extension point serves the same purpose.
The public constructors of org.knime.core.node.port.PortType are now deprecated because they don't use the port type information from the extension point. Use PortTypeRegistry.getPortType instead which returns a singleton created from the extension point information. If you don't update your code, the port colors in the workflow editor will not be correct.
Node extension point
The org.knime.workbench.repository.nodes extension point has a new flag for deprecating nodes. Such nodes are not shown in the node repository any more but are still loaded in existing workflows. There is no need to change the XML node description any more, once the flag has been set in the extension point. All deprecated nodes from previous version should be re-added to the extension point with the deprecated flag set before KNIME 4.0. In one of the next major releases KNIME will rely on deprecated nodes being properly registered as we will no longer use eclipse's "buddy classloading" to find non-registered nodes. Buddy classloading has been causing trouble in the past as 3rd party plug-ins possibly interfere with the KNIME core; hence it's subject to be removed.
The expert-flag has been removed from the nodes extension point, it hasn't been used for some releases any more. Simply remove the flag from your plugin.xml (compiler warnings will be reported otherwise).
Row filter
The class org.knime.base.node.preproc.filter.row.rowfilter.RowFilter is deprecated because it only supports tables with 2 billion rows. Use org.knime.base.node.preproc.filter.row.rowfilter.AbstractRowFilter instead. The class org.knime.base.node.preproc.filter.row.rowfilter.RowFilterFactory now creates instances of org.knime.base.node.preproc.filter.row.rowfilter.IRowFilter instead of the deprecated row filter. Change the type in your assignments if necessary.
Adapter cells in molecule readers
All standard molecule readers (SDF Reader, Mol Reader, ...) now create adapter cells (SdfAdapterCell, MolAdapterCell, ...). Nodes consuming and auto-converting molecules should not create their own adapter cells any more but add their representations to the existing adapter cell. Only if you are creating new molecules you create new adapter cells. The preferred value of the adapter cells is meant to indicate the source format of a molecule.
RSyntaxTextArea
RSyntaxTextArea was updated to version 2.5.7 for Java 8 support. The packaging has changed because we are now using bundles provided by Maven Central. The bundle org.fife.rsyntaxtextarea is not part of the KNIME update site any more. The new bundles are named com.fifesoft.*. A common set of required bundles is com.fifesoft.autocomplete, com.fifesoft.languagesupport, com.fifesoft.rstaui, and com.fifesoft.rsyntaxtextarea.
POI
The Apache POI library for processing Excel files was updated to version 3.9. No changes to existing code should be necessary.
ChemAxon JChemLib
The free Marvin extension provided by Infocom now ships with a more recent version of JChemLib which is not compatible with previous versions. You may need to adapt your code.
