<#198 Literaltype as sdktype> Pull request opened ...
# flyte-github
a
#198 Literaltype as sdktype Pull request opened by narape TL;DR Use SdkLiteralType to create SdkType with low overhead. Type ☐ Bug Fix ☑︎ Feature ☐ Plugin Are all requirements met? ☑︎ Code completed ☐ Smoke tested ☑︎ Unit tests added ☑︎ Code documentation added ☐ Any pending items have an associated Issue Complete description Currently the way to create custom
SdkType<T>
in Java is using
JacksonSdkType
. For example If a developer wants to define a task equivalent to (String str) -> str.toUpperCase() currently he/she needs to write it as
Copy code
@AutoService(SdkRunnableTask.class)
public class ToUpperCaseTask extends SdkRunnableTask<ToUpperCaseTask.Input, ToUpperCaseTask.Output> {
  public ToUpperCaseTask() {
    super(JacksonSdkType.of(Input.class), JacksonSdkType.of(Output.class));
  }

  @AutoValue
  public abstract static class Input {
    public abstract SdkBindingData<String> in();
  }

  @AutoValue
  public abstract static class Output {
    public abstract SdkBindingData<String> out();

    public static Output create(String out) {
      return new AutoValue_ToUpperCaseTask_Output(out);
    }
  }

  @Override
  public Output run(Input input) {
    return Output.create(SdkBindingDataFactory.of(input.get().toUpperCase()));
  }
}
For such trivial task, defining the AutoValues to define the types takes the majority of the lines. With this PR the developer could write the task this way instead
Copy code
@AutoService(SdkRunnableTask.class)
public class ToUpperCaseTask extends SdkRunnableTask<SdkBindingData<String>, SdkBindingData<String>> {
  public ToUpperCaseTask() {
    super(SdkTypes.of(SdkLiteralTypes.strings(), "str"), SdkTypes.of(SdkLiteralTypes.strings(), "upr"));
  }

  @Override
  public SdkBindingData<String> run(SdkBindingData<String> input) {
    return input.get().toUpperCase();
  }
}
Defining the types for the task now takes one line only and the run is simplified too as no need to create or access AutoValues Tracking Issue fixes flyteorg/flyte#3378 Follow-up issue NA flyteorg/flytekit-java All checks have passed 3/3 successful checks