Disable Spring Cloud Stream support for testing

TestSupportBinder is a minimal binder that does nothing and is not useful for integration test between services


A short time ago we started the development of a project based on Microservices Architecture. The intent is to create services based on REST Api, which receive messages and write them on Kafka topics. Other services read messages from the Kafka topics and write them to the database.

The environment is as follows:

  • Java 11
  • Spring Core 5.1
  • Spring Boot 2.1
  • Spring Cloud Stream 2.1
  • Spring Web 5.1
  • Apache Kafka 2.0.1

The IDE is the new STS 4.  By default, if you use Spring Initializer to create a Spring Cloud Stream based project, support for the Spring Cloud Test dependency is added:


the dependency ensures that the TestSupportBinder class can be used for the test phase. TestSupportBinder is a minimal binder that does nothing about binding consumers.
I find that class not very useful, even for the test phase itself. Surely it is not useful for integration test between the various services.
In fact, in our case, by launching services from STS, you could write on the topic but the listeners received no messages. By launching services via maven instead, everything worked fine. This is because the scope test of the dependency assures that by launching the command

mvn spring-boot:run

the TestSupportBinder class is not loaded by Spring Boot autoconfiguration. However, if we run the application from STS (in RUN or DEBUG), TestSupportBinder is loaded, and not Kafka as desired. To disable the test from STS, you need to add the annotation

@SpringBootApplication(exclude = TestSupportBinderAutoConfiguration.class)

as in this example:

@SpringBootApplication(exclude = TestSupportBinderAutoConfiguration.class)
public class StreamsConfig {


or, even better, add the following line in the application.properties file:


in this way, the integration test between the various services will go well!

Performance tuning for File Reading with Java 8 and Parallel Streams

Is it always convenient to use parallel streams?

Java 8 has introduced with the Stream the possibility of using in a very simple way all the resources made available by the hardware, in particular the cores of the multicore architectures. And all this with the paradigm of declarative and non-imperative programming.

For example, suppose you have to do a batch that looks for a string in all the files that have a certain prefix in a certain directory. The batch must notify in a log in which files the string is found.

It is interesting to compare the two approaches, pre java 8 and java 8 with the streams.

I used my dev computer, a Samsung laptop with this features:

  • Intel Core i7-4500U (2 Core, 4 Thread) 1.8GH
  • 8 GB RAM
  • 256 GB SSD
  • Windos 8.1 Pro 64 Bit
  • Java 1.8.0_101

Having 4 Threads I expect the performance of the parallel stream solution to be 400% better than the classic pre java 8 version.

The code that uses the pre java style 8 is as follows: StringMatchingOld

The code that uses the streams is as follows: StringMatching

The code that uses the parallel streams is as follows: ParallelStringMatching

These are the results (4 files read):

File Reading Performance

What is going on? Truly strange, there is no benefit in the use of the stream (I think also from the point of view of the code… I don’t think it’s more readable but this is another story… I’m getting older…). Furthermore, we see that using parallel streams does nothing but make things worse.


It seems that reading the files does not find any improvement in the use of the streams. However, the fact remains that declarative programming makes it possible to abstract from current hardware, so maybe on a server with better hardware than my development pc, parallel streams performance is better.

Or maybe I’m doing something wrong … I’m looking forward to that.