Java UDFs

All UDFs must implement the TrifactaUDF interface. This interface adds the four methods that each UDF must override: init, exec, inputSchema, and finish.

The following code example concatenates two input strings in the List<Object>. This UDF can be easily modified to concatenate more strings by modifying the inputSchema function.

Example UDF: ConcatUDF

package com.trifacta.trifactaudfs;
import java.io.IOException;
import java.util.List;


/**
 * Example UDF that concatenates two columns
 */
public class ConcatUDF implements TrifactaUDF<String> {
  @Override
  public String exec(List<Object> inputs) throws IOException {
    if (inputs == null) {
      return null;
    }
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < inputSchema().length; i += 1) {
      if (inputs.get(i) == null) {
        return null;
      }
      sb.append(inputs.get(i));
    }
    return sb.toString();
  }
  @SuppressWarnings("rawtypes")
  public Class[] inputSchema() {
    return new Class[]{String.class, String.class};
  }
  @Override
  public void finish() throws IOException {
  }
  @Override
  public void init(List<Object> initArgs) {
  }
}

Notes:

In this example, the input value is added by a constant, which is defined in the init method.

Example UDF: AdderUDF

package com.trifacta.trifactaudfs;
import java.io.IOException;
import java.util.List;

/**
 * Example UDF. Adds a constant amount to an Integer column.
 */
public class AdderUDF implements TrifactaUDF<Long> {
  private Long _addAmount;
  @Override
  public void init(List<Object> initArgs) {
    if (initArgs.size() != 1) {
      System.out.println("AdderUDF takes in exactly one init argument");
    }
    Long addAmount = (Long) initArgs.get(0);
    _addAmount = addAmount;
  }
  @Override
  public Long exec(List<Object> input) {
    if (input == null) {
      return null;
    }
    if (input.size() != 1) {
      return null;
    }
    return (Long) input.get(0) + _addAmount;
  }
  @SuppressWarnings("rawtypes")
  public Class[] inputSchema() {
    return new Class[]{Long.class};
  }
  @Override
  public void finish() throws IOException {
  }
}

The UDF must handle any error that should occur when processing the function. Two ways of dealing with errors:

To avoid an Unsupported major.minor version error during execution, the JDK version used to compile the UDF JAR file should be less than or equal to the JDK version on the Hadoop cluster.

If this is not possible, then set the value of the Compatibility properties in the local build.gradle file to the JDK version on the Hadoop cluster prior to building the JAR file.

Example:

If the Hadoop cluster is on JDK 1.8, then add the following to the build.gradle file:

targetCompatibility = '1.8'
sourceCompatibility = '1.8'

If you execute a Java UDF, you may see an error similar to the following in the Transformer page:

Please reload page (query execution failed).pp::WebSocket::Receive() error: Unspecified failure.

When you check the udf.log file on the server, the following may be present:

UDFWebsocket closed with status: CloseStatus[code=1009, reason=The decoded text message was too big for the output buffer and the endpoint does not support partial messages]

During the execution of a UDF, the Photon client can crash. Possible errors include:

Error in changeCurrentEdit Error: Transformation engine has crashed. Please reload your browser (exit code: null; message ID: 161)

Solution:

This crash can be caused by a number of issues. You can try the following:

When running a job on a Databricks cluster, you may receive an error message that the cluster has either stale or unknown libraries.

This issue is caused by a change that was made to the custom UDFs code for Databricks. Prior to Release 7.10, custom UDF jobs were checked for use in the Designer Cloud Powered by Trifacta platform based on when the JAR file was created. However, this timestamp presented inconsistencies in the following cases:

Solution:

The platform now uses a built-at timestamp instead. This timestamp is assigned in the manifest file when the JAR is assembled for the first time on a developer's local desktop. That timestamp remains consistent when the JAR is delivered to the cluster or to different nodes or services.

After you have executed a job, you may receive an error similar to the following in the Job Summary page:

Build Timestamp is missing in <filename>.jar. Please rebuild your jars and try again.

Solution:

In this case, the referenced JAR file does not have a build timestamp in it. You must rebuild and redeploy the custom UDF JAR file. See the previous Troubleshooting section for details.