[Proposal]Support JDK17 and springboot3 in Dapr Java SDK

[skyao]

• Author(s): Sky Ao (@skyao)
• State: Ready for Implementation
• Updated: 2024-01-08

Overview

This document is a design proposal to support JDK17 and springboot 3.0 in Dapr Java SDK.

This proposal will allow customers to use the Dapr Java SDK with JDK17 and springboot3.0 while trying to maintain compatibility with existing implementations: continue to support JDK8/JDK11, continue to support springboot2.x.

Background

Current Versions Overview

In this proposal, I will refer to the following four subprojects by "SDK Core" for convenience:

• sdk-autogen
• sdk
• sdk-actors
• sdk-workflows

The following picture shows the overview of current JDK versions and springboot versions in the Dapr Java SDK:

In this picture, we've ignored third-party dependencies other than springboot, as well as the dependencies of the internal subprojects examples and sdk-tests on sdk-workflows/sdk-actors/sdk subprojects.

I will describe the details of this overview picture.

JDK versions in java-sdk now

Currently, the Dapr Java SDK is compiled with JDK11, but for Java8 compatibility, set both the compiler source and target to 8:

<!-- pom.xml in root -->  
<properties>
    <maven.compiler.source>8</maven.compiler.source>
    <maven.compiler.target>8</maven.compiler.target>
</properties>

The examples and sdk-tests subprojects have no need for Java8 compatibility because they do not need to be published to customers, so their source and target are set to 11:

<!-- pom.xml in sdk-tests and examples -->   
<properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
</properties>

Therefore, the current Java versions supported in Dapr Java SDK are Java8 and Java11:

In this proposal, We focus only on the LTS(Long-Time-Support) versions of Java: Java8/Java11/Java17 and possibly Java21 in the future.

Springboot versions in java-sdk now

Currently, Dapr's springboot support is integrated with springboot 2.x. The specific version is 2.7.8, which is set in the pom.xml:

<!-- pom.xml in root -->  
<properties>
    <springboot.version>2.7.8</springboot.version>
</properties>

Theoretically, there should be no springboot dependencies in the SDK Core, but in fact, springboot is introduced in the sdk-actors and sdk sub-projects for testing purposes. The good thing is that these dependencies are test dependencies and will not passed on to the users:

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
      <version>2.7.8</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-autoconfigure</artifactId>
      <version>2.7.8</version>
      <scope>test</scope>
    </dependency>

There may be an optimization strategy here to move test code depends on springboot to the sdk-tests sub-project, thus removing the dependency of springboot from SDK Core. However, this is out of the scope of this proposal. I will put it in the appendix for subsequent discussion.

More specifically, in the sdk-tests subproject, in order to test the compatibility of multiple springboot versions, several other 2.x versions will be tested in addition to the 2.7.8 version:

• 2.6.14
• 2.5.7
• 2.4.0
• 2.3.6.RELEASE

These are sub-versions of springboot 2.x. The JDK version requirements are basically the same as 2.7.8 and will not affect the solution of this proposal.

This is a summary of the spring versions in Dapr java-sdk now:

For details on how the sdk-tests subproject defines and validates these springboot versions, see the appendix section at the end of this proposal.

Summary

JDK versions and springboot versions in Dapr Java SDK:

	JDK8	JDK11
SDK Core	Supported	Supported
sdk-springboot(springboot 2.x)	Supported	Supported
examples(springboot 2.x)	Not covered	Supported
sdk-tests (springboot 2.x)	Not covered	Supported

New requirements from customers

The new requirement from customers is to add JDK17 and springboot 3.0 support in Dapr Java SDK.

During implementation, we need to refine this requirement:

• SDK Core

  Required: SDK Core must add support for Java17 and keep support for JDK11.

  Special Reminder: After discussion, we decided that Java8 is no longer supported in Dapr Java SDK after this proposal, the minimal Java version in Dapr Java SDK will be Java 11.

• sdk-springboot (2.x)

  Required: Springboot integration for springboot 2.x versions must keep support for JDK11.

  Special Reminder: After discussion, we decided that we don't support sprintboot2.x + JDK17 in the compatibility list of Dapr Java SDK (springboot version matrix), it means that in sdk-tests subproject we will only cover JDK11 + springboot 2.x and JDK 17 + springboot 3.x.

  springboot java version compatibility:

  • Springboot 3.0 - 3.2: Java17 - Java21
  • sprintboot 2.7: Java8 - Java20
  • sprintboot 2.6: Java8 - Java19
  • sprintboot 2.5: Java8 - Java18
  • sprintboot 2.4: Java8 - Java16

• sdk-springboot3 (3.0)

  Required: The support of springboot 3.0 versions must be added.

  Springboot 3.0 (also related spring framework 6.0) requires JDK17; it doesn't support JDK8 and JDK11 anymore.

  In this proposal, only the compatibility support for springboot 3.0 is considered; how to utilize springboot 3.0-specific features is not in the scope of this proposal. However, this proposal will prepare the solution to support springboot3.0-specific features in the future.

• examples(springboot 3.0)

  Required: upgrade current examples to run with springboot 3.0

• sdk-tests(both springboot 2.x and springboot 3.0)

  Required: sdk-tests must add support for springboot 3.0 and keep support for springboot 2.x.

  Special Reminder: After discussion, we decided that we will use ONLY springboot 3.0 in examples subproject.

In summary, JDK versions and springboot versions in Dapr Java SDK should be updated to:

	JDK8	JDK11	JDK17
SDK Core	Not supported	Keep	Required
sdk-springboot(springboot 2.x)	Not supported	Keep	Not covered
sdk-springboot3(springboot 3.0.x)(New Added!)	Not supported	Not supported	Required
examples (springboot 3.0)	Not supported	Not covered	Required
sdk-tests (springboot 2.x)	Not supported	Keep	Not covered
sdk-tests (springboot 3.0)(New Added!)	Not supported	Not supported	Required

Note: "Not covered" means that while it may be technically possible to implement it, we do not consider providing support for it in the Dapr Java SDK.

Motivation

• Satisfy customer requirements to use Dapr Java SDK with JDK17 and springboot3.0

Goals

1. Functionality:
   • Adding support for JDK17 and springboot3.0
   • keeping support for JDK11 and springboot2.x
2. Non-Functionality:
   • Smooth upgrades, try not to make broken changes;
     • Exception case: removing Java8 support
   • Try not to change the existing code too much to control the workload

Scope

• The scope of this proposal will be limited to add support for JDK17 and springboot3.0.

  • Other non-LTS versions of the JDK are out of scope.
  • springboot 3.1 and the required JDK21 are out of scope.

Related Items

Related issues

• Support Dapr Java SDK with JDK 17 and Spring boot version 3.0 · Issue #886 · dapr/java-sdk (github.com) : requirement and community discussion about JDK17 and spring boot 3.0 support
• [WIP] Spring Boot 3 and Java 17 by krizsan · Pull Request #894 · dapr/java-sdk (github.com)： this PR was closed because it updated the Dapr Java SDK to ONLY support JDK17 and not support JDK8/JDK11 any more. It doesn't match our requirements.
• Deprecate Java 8 support and move to Java 11 · Issue #626 · dapr/java-sdk (github.com): Community discussion to deprecate java8 support so that the native http client in newer versions of java can be used instead of OKHTTP.

Implementation Details

Support JDK17

Considering that the Dapr Java SDK is currently compatible with Java8 and Java11, adding support for Java17 should theoretically be natural.

Assuming JDK8/JDK11/JDK17 have perfect compatibility. Each JDK upgrade only adds new features, and the old ones continue to be supported. And our Dapr Java SDK code is fully compatible with JDK8/JDK11/JDK17 because it only uses some of the features of Java8. As shown in the figure below:

In reality, the JDK upgrade is not perfect, but there are some BROKEN changes like renaming or removing.

https://github.com/johanjanssen/JavaUpgrades

Referring to the instructions on this site, the JDK broken changes include:

• Removal of VM flags/options: -XX:+AggressiveOpts and -Xoptimize
• Removed (root) certificates: "The T-Systems Deutsche Telekom Root CA 2 certificate has expired and was removed from the cacerts keystore"
• Removed encryption algorithms: Algorithms deemed unsafe are removed.
• Removed garbage collectors: For instance the Concurrent Mark and Sweep (CMS) garbage collector was removed in 14.
• Removed from API: Parts of the API such as methods can be deprecated and later removed.
• Removed tools: Some are no longer available, others such as JDK Mission Control and JavaFX now are available as separate builds from various vendors.

The challenge of upgrading JDK17, therefore, lies in whether these broken changes affect our Dapr Java SDK code. If not, then we can upgrade smoothly. If they exist, they must be found and fixed.

For the issues introduced by each Java version and detailed solutions, please refer to this section, "Issues and solutions per Java version" of the above site.

Fortunately, after detailed examination and verification, I found that the Dapr Java SDK avoids most of the broken changes. JDK17 will be supported with only a few changes, which are listed below.

Upgrade jacoco plugin version

When building an existing Dapr Java SDK project(master branch) using JDK17, it fails with a large number of similar errors:

Caused by: java.io.IOException: Error while instrumenting org/jcp/xml/dsig/internal/dom/XMLDSigRI.
	at org.jacoco.agent.rt.internal_f3994fa.core.instr.Instrumenter.instrumentError(Instrumenter.java:160)
	at org.jacoco.agent.rt.internal_f3994fa.core.instr.Instrumenter.instrument(Instrumenter.java:110)
	at org.jacoco.agent.rt.internal_f3994fa.CoverageTransformer.transform(CoverageTransformer.java:92)
	... 107 more
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 61
	at org.jacoco.agent.rt.internal_f3994fa.asm.ClassReader.<init>(ClassReader.java:196)
	at org.jacoco.agent.rt.internal_f3994fa.asm.ClassReader.<init>(ClassReader.java:177)
	at org.jacoco.agent.rt.internal_f3994fa.asm.ClassReader.<init>(ClassReader.java:163)
	at org.jacoco.agent.rt.internal_f3994fa.core.internal.instr.InstrSupport.classReaderFor(InstrSupport.java:280)
	at org.jacoco.agent.rt.internal_f3994fa.core.instr.Instrumenter.instrument(Instrumenter.java:76)
	at org.jacoco.agent.rt.internal_f3994fa.core.instr.Instrumenter.instrument(Instrumenter.java:108)
	... 108 more

To fix this, upgrade jacoco-maven-plugin to the latest version:

 <plugin>
        <groupId>org.jacoco</groupId>
        <artifactId>jacoco-maven-plugin</artifactId>
        <!-- upgrade version from 0.8.6 to 0.8.11
        <version>0.8.6</version>
        -->
        <version>0.8.11</version>
</plugin>

Upgrade spotbugs-maven-plugin version

Similarly, spotbugs-maven-plugin will report errors under JDK17:

Couldn't get class info for java/util/Set
java.lang.IllegalArgumentException: Unsupported class file major version 61
  At org.objectweb.asm.ClassReader.<init>(ClassReader.java:189)
  At org.objectweb.asm.ClassReader.<init>(ClassReader.java:170)
  At org.objectweb.asm.ClassReader.<init>(ClassReader.java:156)
  At edu.umd.cs.findbugs.asm.FBClassReader.<init>(FBClassReader.java:35)
  ......
at edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:395)
at edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1231)

Refer to this issue from spotbugs: Fails with OpenJDK 17-ea: Unsupported class file major version 61 · Issue #1570 · spotbugs/spotbugs (github.com)

To fix this, upgrade spotbugs-maven-plugin to the latest version 4.8.2.0:

 <plugin>
        <groupId>com.github.spotbugs</groupId>
        <artifactId>spotbugs-maven-plugin</artifactId>
        <!-- upgrade version from 4.1.4 to 4.8.2.0
        <version>4.1.4</version>
        <dependencies>
          <dependency>
            <groupId>com.github.spotbugs</groupId>
            <artifactId>spotbugs</artifactId>
            <version>${spotbugs.version}</version>
          </dependency>
        </dependencies>
        -->
        <version>4.8.2.0</version>
</plugin>

After version updated, spotbugs-maven-plugin reports a lot of EI_EXPOSE_REP/CT_CONSTRUCTOR_THROW/SS_SHOULD_BE_STATIC issues in various subprojects.

These code issues are not in the scope of this proposal, so this proposal will temporarily ignore these issues by setting up to exclude these rules in the configuration of spotbugs. These issues are recorded in detail in the appendix section of this proposal, and we can resolve them later: update the source code to meet the rule requirements or exclude them as inapplicable.

Other maven plugins version upgrade

There are also some other maven plugins that have been upgraded to new version. While some of these upgrades may not be necessary, they have all been updated along with above plugins to be safe.

Maven plugin name	Current version	New version
animal-sniffer-maven-plugin	1.20	1.23
maven-gpg-plugin	1.6	3.1.0
nexus-staging-maven-plugin	1.6.8	1.6.13
maven-checkstyle-plugin	3.1.1	3..3.1
maven-failsafe-plugin	3.1.2	3.2.2

Broken changes must be handled

In JDK11, some of the Java features and API are deprecated, but for the time being, they can continue to be used. After upgrading to JDK17, these features and API are dropped, so we must update our code to handle these broken changes.

For the items of Java removed, please reference to:

• Java general challenges

According to my testing, the main things that affect our Dapr Java sdk include (but are not limited to, it's possible I didn't check it thoroughly):

• JEP 320: Remove the Java EE and CORBA Modules

In Dapr Java SDK, we used two javax API:

• javax.annotation
• javax.servlet

In JDK17, these javax API are replaced with:

• jakarta.annotation
• jakarta.servlet

javax.annotation

In our Dapr Java SDK, javax.annotation used are:

• javax**.annotation.**concurrent.Immutable
• javax.annotation.Nullable
• javax.annotation.Generated

We have two options for these javax.annotation:

1. replace

   Update the source code to replace javax.annotation with jakarta.annotation. To support Java8/Java11, add jakarta.annotation-api as dependency.

2. Keep

   Continue to use javax**.annotation. To support JDK17, add javax.**annotation-api as denpendency.

   These annotations are mainly used as "markup", and as long as they are compiled, there is no need to add the javax annotation-api even in JDK17 (where javax has been replaced by jakarta) if you don't actively manipulate them.

   For example, javax.annotation.Generated are mainly used in grpc-generated code, such as in sdk-autogen subproject:

   @javax.annotation.Generated(
       value = "by gRPC proto compiler (version 1.59.0)",
       comments = "Source: dapr.proto")
   @io.grpc.stub.annotations.GrpcGenerated
   public final class DaprGrpc {}

   Because we set sdk-autogen's source and target to JDK8, so there won't be a compilation problem here.

There is a special case that requires additional treatment. In examples subproject, if we change examples subproject to use JDK17, this will result in an error because javax.annotation cannot be found.

@javax.annotation.Generated(
    value = "by gRPC proto compiler (version 1.59.0)",
    comments = "Source: helloworld.proto")
@io.grpc.stub.annotations.GrpcGenerated
public final class HelloWorldGrpc {......}

This needs to be improved with gRPC and protocolBuffer to generate the code with jakarta.annotation. But so far this has not been supported, see: grpc/grpc-java#9179

To compile these auto-generated source code, we have no choice but to add javax.annotation as a dependency in examples subproject:

    <dependency>
      <groupId>javax.annotation</groupId>
      <artifactId>javax.annotation-api</artifactId>
      <version>1.3.2</version>
    </dependency>

In this proposal, I propose to keep these javax.annotation unchanged, and in the appendix section I will record the javax.annotations that found in Dapr Java SDK, so that we can change them in the future, if necessary.

javax.servlet

"javax.servlet" API is not a simple markup, they are used in runtime, so we can not only consider compiling. The common approach is to modify the source code to replace javax.servlet API to the corresponding jarkarta.servlet API.

Fortunately, we don't use javax.servlet in SDK Core, so this issue doesn't affect SDK Core. In our Dapr Java SDK, javax.servlet is used in examples and sdk-tests subproject.

import javax.servlet.DispatcherType;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

If we change to use JDK17 and springboot3.0, then we need to update the source code to use jakarta.servlet, like:

import jakarta.servlet.DispatcherType;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

For examples subproject, if we decide to develop examples based on JDK17 and springboot3.0 only, then we only need to support JDK17 in the examples sub-project, we can udpate the source code to use jakarta.servlet.

challenges in sdk-tests subproject

For sdk-tests subproject, things are much more complicated.

In order to verify the compatibility of different springboot versions, the sdk-tests sub-project uses multiple springboot versions for testing, for example, the current verified versions (see springboot version metrics in appendicse) are: 2.7 / 2.6 / 2.5 / 2.4 / 2.3. After adding JDK17 and springboot 3.0 support, this springboot version metrics will have both springboot 3.0 and several springboot 2.x versions.

In the sdk-tests subproject we need to test for compatibility with multiple springboot versions at the same time, our testing code has to be considered to run on both JDK17 and JDK11. The Design to reuse the same testing code to cover different springboot versions runs into a very big challenge:

• To run on springboot 2.x with JDK8/JDK11, the source code must use javax.servlet
• To run on springboot 3.0 with JDK17, the source code must use jakarta.servlet

A typical example is the following OpenTelemetryInterceptor, which implements the HandlerInterceptor interface provided by the spring framework:

public class OpenTelemetryInterceptor implements HandlerInterceptor {}

In springboot 3.0/spring6.0, it used jakarta.servlet:

package org.springframework.web.servlet;

import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

public interface HandlerInterceptor {
  boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
			throws Exception {}
  .....
}

In springboot 2.x / spring5, it used javax.servlet:

package org.springframework.web.servlet;

import java.servlet.http.HttpServletRequest;
import java.servlet.http.HttpServletResponse;

public interface HandlerInterceptor {
  boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
			throws Exception {}
  .....
}

The best way to meet the requirements of the interface definition is to write two copies of the code for OpenTelemetryInterceptor, using javax.servlet and jakarta.servlet. This also means that we need to split the sdk-tests subproject into multiple projects.

Another tricky way is to use both javax.servlet and jakarta.servlet in the code implementation:

// for springboot 3.0, jakarta.servlet is required
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;

// for springboot 2.x, javax.servlet is required
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.web.servlet.HandlerInterceptor;

@Component
public class OpenTelemetryInterceptor implements HandlerInterceptor {
   @Override
  // implmentation for springboot 3.0, which uses jakarta.servlet instead of javax.servlet
  // Note that you can't use the @override tag, or it won't compile at the same time!
  // @overvide 
  public boolean preHandle(
    HttpServletRequest request, HttpServletResponse response, Object handler) {
  		......
  	}
  
  	// implmentation for springboot x.0, which uses javax.servlet
    // Note that you can't use the @override tag, or it won't compile at the same time!
  	// @overvide 
    public boolean preHandle(
      javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response, Object handler) {
      ......
    }
}

In this way, a single copy of the OpenTelemetryInterceptor code (which actually comes with both implementations) can work with both JDK17 and JDK8/jdk11.

Considering long-term planning, it is definitely more reasonable to split it into multiple sub-projects. The special code treatment above can only be a temporary solution. But this is the only special case in the entire sdk-tests sub-project (and really the entire Dapr Java SDK project). Splitting the subproject only for this one class is a suspicion of over-design, so I suggest to use the temporary solution in this proposal first, and then consider splitting sdk-tests into multiple subprojects if there are more similar scenarios.

Conclusion & Upgrade Plan

For the core subprojects (sdk / sdk-autogen / sdk-actros / sdk-workflow), since they were previously restricted to be compatible with Java8, adding support for JDK17 looks simple at the moment, requiring only upgrading individual maven plugins to the latest version / handing some javax annotation, with no other additional work required, especially almost no changes to existing Java code.

For examples and sdk-tests subproject, things will be a little more complicated, but the good news is that there is still a suitable solution.

Through above tests and verify, we got two good news:

1. Java8 support can be maintained with almost no effort unless we have other special considerations, such as using the new features of JDK11. Technically speaking, it is recommended to keep the support for Java8. But if we have other considerations and wish to upgrade the minimum version of JDK to Java11, this is a good opportunity to do so. At least for the solution of this proposal, it won't make a big difference whether Java8 is supported or not.
2. Springboot 2.x code can also run in Java17 with almost no modification: so if customers want to upgrade Jdk17 separately and continue to use the Dapr Java SDK in springboot 2.x, we support that case as well (except for springboot 2.3 and 2.4 because they don't support JDK17, please reference the Appendices section at the end of this proposal).

Special Reminder: After discussion, we decided to remove Java8 support and don't support Springboot 2.x + Java17 in Dapr Java SDK.

	JDK8	JDK11	JDK17
SDK Core	Not supported	Keep	supported
sdk-springboot(springboot 2.5/2.6/2.7)	Not supported	Keep	Nice to have supported
sdk-springboot(springboot 2.3/2.4)	Not supported	Keep	Not supported

Upgrade Plan: the solution to add support for JDK17 would be very similar to the current solution that supports both Java8/Java11. JDK17 will replace the previous role of JDK11.

• Build with JDK17 （upgraded from JDK11 to JDK17) for Dapr Java SDK
• Keep up the Java11 support by set source and target to11 in Dapr Core subprojects (upgraded from JDK8 to JDK11)
• examples and sdk-tests updated to use JDK17 (upgraded from JDK11 to JDK17)

Support Springboot 3.0

After completing the JDK17 support, we went on to add springboot 3.0 support to the Dapr Java SDK.

Similar to the Java upgrade, the compatibility between springboot 3.0 and springboot 2.x is not perfect, and there are a lot of broken changes. A detailed description can be found in:

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide

However, since there are only a few essential functions used in the Dapr Java SDK, we are again lucky to avoid all the broken changes. Through my testing and validation, the code in the Dapr Java SDK is perfectly compatible with springboot 2.x and springboot 3.0, and we don't need to change any of the existing Java code.

From this point of view, it's OK to let customers using jdk17 and springboot3 continue to use the current sdk-springboot.

However, considering that we may use new features of springboot 3.0 later or encounter problems that must be handled differently in springboot2 or springboot3, it is still necessary to add a sdk-springboot30 subproject for springboot 3.0 support.

In order to make the responsibilities of the sub-projects clear, it is better to split another sdk-springboot-common sub-project to store the shared code, and sdk-springboot/sdk-springboot30 to store only the code or configurations that are specific to springboot2.x and springboot3.0.

In the future, if there is a need to support springboot3.1 and jdk21, then we can continue to follow this design by adding the sdk-springboot31 sub-project.

Note: OSS support of springboot 3.0 ended on 2023-12-24, and its commercial support will end on 2025-2-24. The need for springboot 3.1 and JDK21 support in Dapr Java SDK is expected to occur within the next two years.

For more information, please refer to: https://endoflife.date/spring-boot

Therefore, we currently have three solutions to choose from, as shown below:

Short-term Solution 1

Do not change anything, and let springboot 3.0 users use the existing sdk-springboot directly. as shown above on the left.

The main disadvantage of the short-term solution 1 is that when we have to split the subproject, users of the springboot3.0 will have to modify their dependency from sdk-springboot to sdk-springboot30.

Short-term Solution 2

Add a new sdk-springboot30 sub-project for springboot 3.0 users, as shown in the middle of the image above.

The steps of the implementation are as follows:

1. Create a new subproject named sdk-springboot30 and set its JDK to JDK17.
2. Make it dependent on the existing sdk-springboot subproject to reuse all the existing code.
3. Change the springboot dependency version to springboot3 in the sdk-springboot30 subproject.

At the moment, this sub-project is almost empty, but the advantage of introducing it is that springboot 3.0 users can use this dependency from now on and will not need to modify it in the future.

One thing to keep in mind during implementation is to avoid version conflicts of spring/springboot. The sdk-springboot30 subproject itself depends on springboot3.0/spring6, and since it depends on the sdk-springboot subproject, it also indirectly depends on springboot2.x/spring5.

There are two options:

1. Override the value of the springboot version property

   <springboot.version>3.0.13</springboot.version>

2. When setting up the dependency on sdk-springboot, exclude springboot and spring

       <dependency>
         <groupId>io.dapr</groupId>
         <artifactId>dapr-sdk-springboot</artifactId>
         <version>${project.version}</version>
         <exclusions>
           <exclusion>
             <groupId>org.springframework</groupId>
             <artifactId>*</artifactId>
           </exclusion>
           <exclusion>
             <groupId>org.springframework.boot</groupId>
             <artifactId>*</artifactId>
           </exclusion>
         </exclusions>
       </dependency>

   To be safe, both options can be implemented at the same time.

Long-term Solution

In addition to the short-term solution 2, add a sdk-springboot-common sub-project to store the shared code.

The steps of the implementation are as follows:

1. Create a new subproject named sdk-springboot-common
2. Migrate the shared code from sdk-springboot subproject to sdk-springboot-common subproject
3. Make sdk-springboot/sdk-springboot30 dependent on sdk-springboot-common

In the future, to support springboot3.1 and jdk21:

4. Create a new subproject named sdk-springboot31 and set its JDK to JDK21.
5. Make it dependent on the sdk-springboot-common subproject.

In this scenario, sdk-springboot-common's dependency on springboot2.x will be set to [provided scope](Maven – Introduction to the Dependency Mechanism (apache.org)), so dependencies on springboot2.x and spring5 will not be passed to the sdk-springboot / sdk-springboot30 / sdk- springboot31 subprojects.

The adoption of this long-term solution depends on the code and configuration specific to springboot 2.x / springboot 3.0 (and springboot 3.1 in the long term).

Conclusion & Upgrade Plan

Currently we only need to be compatible with springboot 3.0, will not use springboot3.0-specific features for the time being, so my suggestion is to adopt the Short-term solution 2.

In the future, if necessary, then migrate to the long-term solution.

Upgrade Plan:

• Adding new sdk-springboot30 subproject
• Update springboot version metric in sdk-tests to add springboot 3.0

Update examples subproject

For the examples subproject, I recommend upgrade the springboot version to 3.0, and let examples subproject depend on the sdk-springboot30 subproject. The upgrade is shown below:

The main reason for the upgrade is: it is not recommended to write duplicate examples for springboot 2.x and springboot 3.0.

Compatibility with springboot 2.x will be handled by the sdk-tests subproject.

From the practice of upgrading, the source code of the examples sub-projects can run directly with JDK17 and springboot 3.0, except for the broken changes related to the renaming of javax to jakarta.

For more implementation details, see PR: https://github.com/dapr/java-sdk/pull/975/files

Update sdk-tests subproject

In the previous section, "challenges in sdk-tests subproject", we discussed the fact that in order to perform compatibility tests on multiple springboot versions, the sdk-tests subproject needs to support both springboot 2.x and springboot 3.0.

Since springboot 2.x and springboot 3.0 use javax.x and jakarta.x respectively, the sdk-tests subproject should theoretically be split into 3 subprojects:

1. common test code that do not involve javax.x and jakarta.x: these code can run with springboot 2.x and springboot 3.0.
2. test code using javax.x: these codes are affected by springboot 2.x, e.g. if the interface definition of springboot 2.x uses javax.servlet, the implementation class in the test code must also use javax.servlet
3. test code using jakarta.x: these codes are affected by springboot 3.0, e.g. if the interface definition of springboot 3.0 uses jakarta.servlet, the implementation class in the test code must also use jakarta.servlet

However, in the practice of upgrading, it was found that only one test case needed to be split. Almost all other test cases are compatible and should remain in the sdk-tests sub-project. And we found a somewhat strange but working solution to get the test code to use both javax.x and jakarta.x (see previous section, "challenges in sdk-tests subproject").

I suggest to use the temporary solution in this proposal first, and then consider splitting sdk-tests into multiple subprojects later if there are more similar scenarios:

Overview after Update

After completing the above update to add JDK17 and springboot 3.0 support, the version of JDK and springboot in the Dapr Java SDK project will be updated from:

to:

and ready for long-term evolution:

Appendices

Removing dependency of springboot from SDK Core

As mentioned earlier, springboot is introduced in the sdk-actors and sdk sub-projects for testing purposes.

There may be an optimization strategy here to move test code depends on springboot to the sdk-tests sub-project, thus removing the dependency of springboot from SDK Core:

After this improvement is made, the dependencies of the SDK Core will be clearer:

Note: This improvement is not in the scope of this proposal.

Springboot version matrix in sdk-tests

In the sdk-tests subproject, in order to test the compatibility of multiple springboot versions, several other 2.x versions will be tested in addition to the 2.7.8 version:

These springboot versions are defined in .github/workflow/build.xml as matrix.spring-boot-version:

    name: "Build jdk:${{ matrix.java }} sb:${{ matrix.spring-boot-version }} exp:${{ matrix.experimental }}"
    runs-on: ubuntu-latest
    continue-on-error: ${{ matrix.experimental }}
    strategy:
      fail-fast: false
      matrix:
        java: [ 11, 13, 15, 16 ]
        spring-boot-version: [ 2.7.8 ]
        experimental: [ false ]
        include:
          - java: 11
            spring-boot-version: 2.6.14
            experimental: false
          - java: 11
            spring-boot-version: 2.5.7
            experimental: false
          - java: 11
            spring-boot-version: 2.4.0
            experimental: false
          - java: 11
            spring-boot-version: 2.3.6.RELEASE
            experimental: false

Then set to env PRODUCT_SPRING_BOOT_VERSION :

    - name: Integration tests using spring boot version ${{ matrix.spring-boot-version }}
      id: integration_tests
      run: PRODUCT_SPRING_BOOT_VERSION=${{ matrix.spring-boot-version }} ./mvnw -B -f sdk-tests/pom.xml verify

And got by maven to override the default spring-boot.version property :

<!-- pom.xml in sdk-tests -->  
   <profile>
      <id>custom-spring-boot-version</id>
      <activation>
        <property>
          <name>env.PRODUCT_SPRING_BOOT_VERSION</name>
        </property>
      </activation>
      <properties>
        <spring-boot.version>${env.PRODUCT_SPRING_BOOT_VERSION}</spring-boot.version>
      </properties>
    </profile>

  <properties>
    <spring-boot.version>2.7.8</spring-boot.version>
  </properties>
  <dependencyManagement>
    <!-- Reproduce a product fixing its own spring boot version -->
    <dependencies>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>${spring-boot.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
  </dependencyManagement>
  ......

So the versions of springboot that are verified in the sdk-tests project are:

• 2.7.8
• 2.6.14
• 2.5.7
• 2.4.0
• 2.3.6.RELEASE

After adding springboot 3.0 support, we need to update the springboot version matrix to add springboot 3.0.

In addition, after sdk-tests is compiled and run with JDK17, springboot versions 2.3 and 2.4 can't be tested because they don't support jdk17. So there are two options:

1. Remove springboot 2.3 and 2.4 from springboot version matrix: no more compatibility testing for these versions. Note that this does not mean that springboot 2.3 and 2.4 are no longer supported by the Dapr Java SDK, just that we no longer validate them in CI.
2. Fallback to JDK11: The downside of this is that we can't test springboot 3.0 in the sdk-tests subproject, we need to create a sub-project like sdk-tests-springboot3.

I personally recommend option 1: springboot 2.3 and 2.4 are very old.

This is the springboot version matrix after the upgrade:

      matrix:
        java: [ 17 ]
        spring-boot-version: [ 3.0.13 ]
        experimental: [ false ]
        include:
          - java: 17
            spring-boot-version: 2.7.8
            experimental: false
          - java: 17
            spring-boot-version: 2.6.14
            experimental: false
          - java: 17
            spring-boot-version: 2.5.7
            experimental: false

Spotbugs bug pattern

After updating version of spotbugs-maven-plugin to support JDK17 , spotbugs-maven-plugin reports a lot of EI_EXPOSE_REP/CT_CONSTRUCTOR_THROW/SS_SHOULD_BE_STATIC issues in various subprojects.

Since no Java source code was changed during the JDK17 upgrade, these issues should have existed before and just been discovered this time.

Below are some of the issue reports collected:

[ERROR] Medium: io.dapr.client.domain.ConfigurationItem.getMetadata() may expose internal representation by returning ConfigurationItem.metadata [io.dapr.client.domain.ConfigurationItem] At ConfigurationItem.java:[line 77] EI_EXPOSE_REP
[ERROR] Medium: io.dapr.client.domain.GetBulkStateRequest.getKeys() may expose internal representation by returning GetBulkStateRequest.keys [io.dapr.client.domain.GetBulkStateRequest] At GetBulkStateRequest.java:[line 55] EI_EXPOSE_REP
[ERROR] Medium: io.dapr.client.domain.GetBulkStateRequest.getMetadata() may expose internal representation by returning GetBulkStateRequest.metadata [io.dapr.client.domain.GetBulkStateRequest] At GetBulkStateRequest.java:[line 68] EI_EXPOSE_REP
[ERROR] Medium: io.dapr.client.domain.GetConfigurationRequest.getKeys() may expose internal representation by returning GetConfigurationRequest.keys [io.dapr.client.domain.GetConfigurationRequest] At GetConfigurationRequest.java:[line 49] EI_EXPOSE_REP
[ERROR] Medium: io.dapr.client.domain.PublishEventRequest.getMetadata() may expose internal representation by returning PublishEventRequest.metadata [io.dapr.client.domain.PublishEventRequest] At PublishEventRequest.java:[line 69] EI_EXPOSE_REP
[ERROR] Medium: io.dapr.client.domain.SaveStateRequest.getStates() may expose internal representation by returning SaveStateRequest.states [io.dapr.client.domain.SaveStateRequest] At SaveStateRequest.java:[line 43] EI_EXPOSE_REP
[ERROR] Medium: io.dapr.client.domain.SubscribeConfigurationRequest.getKeys() may expose internal representation by returning SubscribeConfigurationRequest.keys [io.dapr.client.domain.SubscribeConfigurationRequest] At SubscribeConfigurationRequest.java:[line 49] EI_EXPOSE_REP
[ERROR] Medium: Exception thrown in class io.dapr.client.domain.query.filters.InFilter at new io.dapr.client.domain.query.filters.InFilter(String, Object[]) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.dapr.client.domain.query.filters.InFilter, io.dapr.client.domain.query.filters.InFilter] At InFilter.java:[line 54]At InFilter.java:[line 54] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Exception thrown in class io.dapr.utils.TypeRef at new io.dapr.utils.TypeRef() will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.dapr.utils.TypeRef, io.dapr.utils.TypeRef] At TypeRef.java:[line 63]At TypeRef.java:[line 63] CT_CONSTRUCTOR_THROW
[INFO] 

[ERROR] Medium: Exception thrown in class io.dapr.utils.TypeRef at new io.dapr.utils.TypeRef() will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.dapr.utils.TypeRef, io.dapr.utils.TypeRef] At TypeRef.java:[line 63]At TypeRef.java:[line 63] CT_CONSTRUCTOR_THROW

[ERROR] Medium: Exception thrown in class io.dapr.actors.ActorId at new io.dapr.actors.ActorId(String) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.dapr.actors.ActorId, io.dapr.actors.ActorId] At ActorId.java:[line 42]At ActorId.java:[line 42] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Unread field: io.dapr.actors.ActorId.errorMsg; should this field be static? [io.dapr.actors.ActorId] At ActorId.java:[line 31] SS_SHOULD_BE_STATIC
[ERROR] Medium: Exception thrown in class io.dapr.actors.client.ActorProxyBuilder at new io.dapr.actors.client.ActorProxyBuilder(String, Class, ActorClient) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.dapr.actors.client.ActorProxyBuilder, io.dapr.actors.client.ActorProxyBuilder] At ActorProxyBuilder.java:[line 71]At ActorProxyBuilder.java:[line 71] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Exception thrown in class io.dapr.actors.runtime.ActorRuntime at new io.dapr.actors.runtime.ActorRuntime() will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.dapr.actors.runtime.ActorRuntime, io.dapr.actors.runtime.ActorRuntime] At ActorRuntime.java:[line 86]At ActorRuntime.java:[line 86] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Exception thrown in class io.dapr.actors.runtime.ActorRuntime at new io.dapr.actors.runtime.ActorRuntime(ManagedChannel) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.dapr.actors.runtime.ActorRuntime, io.dapr.actors.runtime.ActorRuntime] At ActorRuntime.java:[line 95]At ActorRuntime.java:[line 95] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Exception thrown in class io.dapr.actors.runtime.ActorRuntime at new io.dapr.actors.runtime.ActorRuntime(ManagedChannel, DaprClient) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.dapr.actors.runtime.ActorRuntime, io.dapr.actors.runtime.ActorRuntime] At ActorRuntime.java:[line 106]At ActorRuntime.java:[line 106] CT_CONSTRUCTOR_THROW
[INFO] 

To reproduce these errors, modify the "spotbugs-exclude.xml" file to remove the following bug patterns:

    <!--Temporarily ignoring checking after upgrade to new spotbugs version-->
    <Match>
        <Package name="~io\.dapr.*"/>
        <Bug pattern="EI_EXPOSE_REP"/>
    </Match>
    ......

I would recommend reviewing these source code and spotbugs bug patterns. But that is not in the scope of this proposal, we can schedule the review later.

Update opentelemetry implementation

The opentelemetry currently used in the Dapr Java SDK is a very old version 0.14.0.

The result of running mvn dependency:tree is as follows:

......
[INFO] +- io.opentelemetry:opentelemetry-sdk:jar:0.14.0:compile
[INFO] |  +- io.opentelemetry:opentelemetry-api:jar:0.14.0:compile
[INFO] |  |  \- io.opentelemetry:opentelemetry-context:jar:0.14.0:compile
[INFO] |  +- io.opentelemetry:opentelemetry-sdk-common:jar:0.14.0:compile
[INFO] |  \- io.opentelemetry:opentelemetry-sdk-trace:jar:0.14.0:compile
[INFO] |     +- io.opentelemetry:opentelemetry-semconv:jar:0.14.0:compile
[INFO] |     \- io.opentelemetry:opentelemetry-api-metrics:jar:0.14.0-alpha:compile
[INFO] +- io.opentelemetry:opentelemetry-exporter-logging:jar:0.14.0:compile
[INFO] |  \- io.opentelemetry:opentelemetry-sdk-metrics:jar:0.14.0-alpha:compile
[INFO] +- io.opentelemetry:opentelemetry-exporter-zipkin:jar:0.14.0:compile
......

After upgrade to JDK and springboot 3.0, some versions of opentelemetry will change to a very new version 1.19.0:

[INFO] +- io.opentelemetry:opentelemetry-sdk:jar:0.14.0:compile
[INFO] |  +- io.opentelemetry:opentelemetry-api:jar:1.19.0:compile
[INFO] |  |  \- io.opentelemetry:opentelemetry-context:jar:1.19.0:compile
[INFO] |  +- io.opentelemetry:opentelemetry-sdk-common:jar:1.19.0:compile
[INFO] |  |  \- io.opentelemetry:opentelemetry-semconv:jar:1.19.0-alpha:runtime
[INFO] |  \- io.opentelemetry:opentelemetry-sdk-trace:jar:1.19.0:compile
[INFO] +- io.opentelemetry:opentelemetry-exporter-logging:jar:0.14.0:compile
[INFO] |  \- io.opentelemetry:opentelemetry-sdk-metrics:jar:1.19.0:compile
[INFO] +- io.opentelemetry:opentelemetry-exporter-zipkin:jar:0.14.0:compile
[INFO] |  +- io.zipkin.reporter2:zipkin-reporter:jar:2.16.3:runtime
[INFO] |  |  \- io.zipkin.zipkin2:zipkin:jar:2.23.2:runtime
[INFO] |  \- io.zipkin.reporter2:zipkin-sender-okhttp3:jar:2.16.3:runtime

Note: I don't understand why the versions of some of the opentelemetry dependencies here are automatically changed to 1.19.0, I don't find any other dependencies in the mvn dependency:tree output that use opentelemetry 1.19.0.

Anyone who understands here, please advise.

And there are very significant differences and incompatibilities between these two versions that cause existing code to fail to compile.

To resolve this issue, this proposal temporarily enforces the use of opentelemetry version 0.14.0.

<opentelemetry.version>0.14.0</opentelemetry.version>
......
		<dependency>
      <groupId>io.opentelemetry</groupId>
      <artifactId>opentelemetry-api</artifactId>
      <version>${opentelemetry.version}</version>
    </dependency>
    <dependency>
      <groupId>io.opentelemetry</groupId>
      <artifactId>opentelemetry-context</artifactId>
      <version>${opentelemetry.version}</version>
    </dependency>
    <dependency>
      <groupId>io.opentelemetry</groupId>
      <artifactId>opentelemetry-sdk-common</artifactId>
      <version>${opentelemetry.version}</version>
    </dependency>
    <dependency>
      <groupId>io.opentelemetry</groupId>
      <artifactId>opentelemetry-sdk-trace</artifactId>
      <version>${opentelemetry.version}</version>
    </dependency>
    <dependency>
      <groupId>io.opentelemetry</groupId>
      <artifactId>opentelemetry-sdk-metrics</artifactId>
      <version>${opentelemetry.version}-alpha</version>
    </dependency>

I would recommend upgrading the version of opentelemetry to 1.19.0, but that is not in the scope of this proposal. We can schedule the upgrade later.

[skyao]

To summarize in one sentence, this proposal is a plan to improve from

to (in dapr v1.13):

and ready for (perhaps in dapr v1.14)

[Tejasker]

Hii @skyao
I'm also intrested and excited in migrating the current version of JDK & Springboot version , it really helps my knowledge so in-case of approval of the project committer I am very much glad to join in contributing for the upgrade

Thanks In Advance

[skyao]

Great!! @Tejasker you're welcome!

The proposal is basically ready, I'm fighting with CI and nearing completion. There will be a lot of legacy issues after this upgrade work that will need to be followed up with incremental improvements （as I marked in the proposal "out of scope"） and you can pick what you like.

[rahulpoddar-fyndna]

The proposal looks good. It describes of immediate as well as long term plan and ensures code does not break when released. Looking forward for this release...

[kaibocai]

Thanks @skyao for this great proposal. I think all the points you made here make sense to me. I agree with all the short and long-term directions. This is a great migration plan. Thanks!

[yaron2]

LGTM (non-binding). cc @artursouza @mukundansundar

[skyao]

There are some important matters that need to be decided together and I will give multiple options in my proposal and then I will give my recommendation. But these decisions definitely need to be taken together.

I will list the most important ones:

1. whether we need to continue to support java8 or make jdk11 the minimum version?
2. is it necessary to support springboot2.x + jdk17?
3. does the examples sub-project just need to be written in jdk17 + springboot3.0? Or must it be split into jdk11 + springboot2.x and jdk17 + springboot3.0?
4. should we split the sdk-tests sub-project, or should I leave it as it is for now, using the strange solution I gave in the proposal?

[kaibocai]

Share some of my thoughts.

whether we need to continue to support java8 or make jdk11 the minimum version?

If I remember correctly from the proposal, supportting java8 as the minimum version doesn't require much effort right. So I think we can keep it.

is it necessary to support springboot2.x + jdk17?

Can we post a vote to the community just to collect more data from users on this one?

does the examples sub-project just need to be written in jdk17 + springboot3.0? Or must it be split into jdk11 + springboot2.x and jdk17 + springboot3.0?

I think jdk17 + springboot3.0 should be enough for examples, too many redundant samples may cause confusion to users.
We can add jdk11 + springboot2.x example if the community is asking for it later as well. But for now, I prefer to keep it simple and clean.

should we split the sdk-tests sub-project, or should I leave it as it is for now, using the strange solution I gave in the proposal?

I prefer to split it, it will be easy for others to understand it and we can easily add more similar tests in the future if we split them into sub-projects. It's easier to maintain as well.

[skyao]

@mukundansundar @artursouza @yaron2 I need your input to make decision list above.

In my proposal, I have considered multiple solutions for each decision, and I have also technically verified the feasibility of those options, also I have given my recommendations.

At this point all we need to do is to make agreement about which options to adopt as soon as possible.

[skyao]

@mukundansundar @artursouza @yaron2 I need your input to make decision.

[artursouza]

There are some important matters that need to be decided together and I will give multiple options in my proposal and then I will give my recommendation. But these decisions definitely need to be taken together.

I will list the most important ones:

1. whether we need to continue to support java8 or make jdk11 the minimum version?
2. is it necessary to support springboot2.x + jdk17?
3. does the examples sub-project just need to be written in jdk17 + springboot3.0? Or must it be split into jdk11 + springboot2.x and jdk17 + springboot3.0?
4. should we split the sdk-tests sub-project, or should I leave it as it is for now, using the strange solution I gave in the proposal?

Let me answer these:

1. Let's make JDK11 as the minimum. It is already planned for us.
2. I don't think so. We can move to springboot3 and JDK17.
3. For examples project, I recommend we move to springboot3. If someone needs springboot2 examples, we can create a separate examples folder.
4. For sdk-tests, I recommend we keep it as a single project if possible, let's use your proposal as a first try.

Great proposal, BTW. Thanks!

[magnus-larsson]

I am new to dapr and dapr’s java-sdk, but have been working with Spring Boot since v1.0. I have read through this issue’s proposal and would like to give some feedback from a Spring Boot perspective, i.e., without much understanding of dapr’s java-sdk at this time.

Based on my experiences with Spring Boot, I have a few high-level recommendations:

1. Add a subproject for Spring Boot 3, sdk-springboot3, not specific subprojects for 3.0, 3.1, etc. Given Spring Boot’s track record of being backward compatible within each major version, there should be no need for minor version-specific subprojects.

2. Consider replacing Java packages from Java EE (javax…) with Jakarta EE equivalents (jakarta…), or isolate them from dependencies that also are used by Spring Boot 3. Spring Boot 3 depends on Jakarta EE, so retaining Java EE packages might cause compatibility problems with Spring Boot 3. Users of dapr’s java-sdk will also be required to migrate to Jakarta EE packages to be able to use its Spring Boot 3 support.

   Note: The JDK itself, since v11, no longer depends on either Java EE or Jakarta EE packages. Spring Boot 3, however, depends on Jakarta EE packages.

3. For inspiration on how to support Spring Boot 3, I recommend looking at other open-source projects that already have added support for Spring Boot 3. For example:

   a. https://github.com/resilience4j/resilience4j.
   They have one subproject for Spring Boot 2 and one for Spring Boot 3.
   Version 1.x releases are based on Spring Boot 2, and version 2.x releases are based on Spring Boot 3.

   b. https://github.com/springdoc/springdoc-openapi.
   They do not have any “Spring Boot major version”-specific subprojects, but they have the same versioning strategy, i.e., version 1.x releases are based on Spring Boot 2, and version 2.x releases are based on Spring Boot 3.

I hope this helps to some extent; once I have learned more about dapr and its java-sdk, I hope to be able to contribute more.

[skyao]

@artursouza @mukundansundar I have updated the proposal and the PR code according to our discussion and agreement.

• answer of question1: Remove Java8 support
• answer of question2: don't support jdk17 +springboot3.0. So, it means that in sdk-tests subproject we need to use jdk11 to test springboot2.x.
• answer of question3: Using jdk17 and springboot3.0 in examples subproject
• answer of question4: don't split sdk-tests subproject

And then there will be a problem that we can't use jdk11 to test sprintboot 2.x in sdk-tests subproject:

Error:  Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project dapr-sdk-examples: Fatal error compiling: error: release version 17 not supported -> [Help 1]

The root cause is that the answers of question2/3/4 conflict.

The simplest solution is to change the answer of question2, let us use jdk17 to test springboot2.x in sdk-tests subproject.