3.java

// Hello.java
public class Hello {
  public String helloWorld() {
    return "Hello World";
  } 
}

// HelloEndpoints.java
public class HelloEndpoints {
  private Endpoint helloWorldEndpoint(Hello hello) { 
    return Endpoint
      .withPath("/hello")
      .method(GET)
      .produces(MediaType.TEXT_PLAIN)
      .invoke(hello::helloWorld);
  }

  public List<Endpoint> endpoints(Hello hello) {
    return Arrays.asList(helloWorldEndpoint(hello), ...);
  }
}

Btw. as for the specific example with extracting path parameters, I think a Java API could be sth like this:

return Endpoint
  .withPath("hello")
  .withPathSegment(Parsers.string)
  .withPathSegment(Parsers.integer)
  .withBody(Parsers.json)
  .method(PUT)
  .produces(MediaType.APPLICATION_JSON)
  .invoke(Logic::helloWorld);

Here, the first invocation of withPathSegment would be on Endpoint0, and yield an Endpoint1<String> (an endpoint, which requires a single string parameter - in this case, read from the path, but could be read from the query as well).

The second would be on Endpoint1<String> and yield an Endpoint2<String, Integer>, etc. Then, the invoke method can be properly typed to expect a method reference with the right signature.

That's of course just a sketch, and would require the library author to define a number of EndpointN classes (or maybe auto-generate them?). In Scala, you have have a single Endpoint class which can accumulate the input/output parameters with some combinators (again, see Tapir for details).