anchor.diff:  `java.util`), and their parametric types can be String or POJO. A
   `Function` is exposed as an HTTP POST if `spring-cloud-function-web`
   is on the classpath, and as a Spring Cloud Stream `Processor` if
  -`spring-cloud-function-stream` is on the classpath, and a
  +`spring-cloud-function-stream` is on the classpath and a
   `function.name` is configured in the Spring environment. A `Consumer`
   is also exposed as an HTTP POST, or as a Stream `Sink`. A `Supplier`
  -translates to am HTTP GET, or a Stream `Source`.
  +translates to an HTTP GET, or a Stream `Source`.
   
   Functions can be of `Flux<String>` or `Flux<Pojo>` and Spring Cloud
   Function takes care of converting the data to and from the desired
  -types, and long as it comes in as plain text or (in the case of the
  +types, as long as it comes in as plain text or (in the case of the
   POJO) JSON. TBD: support for `Flux<Message<Pojo>>` and maybe plain
  -`Pojo` types (fluxes implied and implemented by the framework).
  +`Pojo` types (Fluxes implied and implemented by the framework).
   
   Functions can be grouped together in a single application, or deployed
   one-per-jar. It's up to the developer to choose. An app with multiple
  
positive.code: 
    @Bean
    public Function<Flux<String>, Flux<String>> uppercase() {
      return value -> value.toUppercase();
    }
  
    public static void main(String[] args) {
      SpringApplication.run(Application.class, args);
    }
  
  }
  ```
  
  
negative.code: 
  1. Wrappers for `@Beans` of type `Function`, `Consumer` and
  `Supplier`, exposing them to the outside world as either HTTP
  endpoints and/or message stream listeners/publishers with RabbitMQ, Kafka etc.
  
  2. Compiling strings which are Java function bodies into bytecode, and
  then turning them into `@Beans` that can be wrapped as above.
  