3 ms·

I think this is crazy, coz now you have HTTP stuff leaking into your source code. It's just clearly a different abstraction, a worse mess that implementing Call

I think this is crazy, coz now you have HTTP stuff leaking into your source code. It's just clearly a different abstraction, a worse mess that implementing Callable . You can implement Callable in a lambda now, so a wrapper can be conjured up easily when you need it. https://www.concretepage.com/java/jdk-8/java-8-runnable-and-callable-lambda-example-with-argument https://www.concretepage.com/java/jdk-8/java-8-runnable-and-... (I agree implementing Callable in the business logic was naff)

javajosh 5y ago
If I am writing an HTTP server then I do indeed expect "HTTP stuff" to "leak" into my source code.
- tlarkworthy 5y ago
  1. HTTP stuff should be an adapter for transport agnostic business logic. You want to be able to support gRPC or whatever later without disturbing the internal domain functionality. 2. this article is about using HTTP servers to provide general purpose concurrency handling in Java, so your point is off topic. Of course if you are writing a HTTP server you need HTTP server code, thats kinda obvious but not what we are talking about. We are talking about: if you need concurrency, should you bring up a HTTP server?
  - Supermancho 5y ago
    > HTTP stuff should[1] be an adapter for transport agnostic business logic. There's no reason to assign methodology or context to a software process. It's useful or it is not, for qualities of utility that are unique to use cases. With such soft terms as "adapter" and "business logic" you can rationalize anything anyway, so I'm not sure that's a compelling statement on it's face. Across various languages, this methodology has been used since the 90s. It's "an oldie but goodie". [1]"should" is a weasel word, that typically is a stand-in for "I believe this". It's unlikely that I subscribe to your specific belief.
    - melony 5y ago
      You are throwing the past two (three?) decades of research and development in software engineering if you insist on tightly coupling code structure to implementation and rejecting design patterns.
- kjeetgill 5y ago
  That's the weirdest thing about the post though. They're using an http server as a Thread Pool/ExecutorService? To avoid using Runable and Callable? It doesn't seem like they we're writing an HTTP Service.

javajosh 5y ago

If I am writing an HTTP server then I do indeed expect "HTTP stuff" to "leak" into my source code.

tlarkworthy 5y ago
1. HTTP stuff should be an adapter for transport agnostic business logic. You want to be able to support gRPC or whatever later without disturbing the internal domain functionality. 2. this article is about using HTTP servers to provide general purpose concurrency handling in Java, so your point is off topic. Of course if you are writing a HTTP server you need HTTP server code, thats kinda obvious but not what we are talking about. We are talking about: if you need concurrency, should you bring up a HTTP server?
- Supermancho 5y ago
  > HTTP stuff should[1] be an adapter for transport agnostic business logic. There's no reason to assign methodology or context to a software process. It's useful or it is not, for qualities of utility that are unique to use cases. With such soft terms as "adapter" and "business logic" you can rationalize anything anyway, so I'm not sure that's a compelling statement on it's face. Across various languages, this methodology has been used since the 90s. It's "an oldie but goodie". [1]"should" is a weasel word, that typically is a stand-in for "I believe this". It's unlikely that I subscribe to your specific belief.
  - melony 5y ago
    You are throwing the past two (three?) decades of research and development in software engineering if you insist on tightly coupling code structure to implementation and rejecting design patterns.
kjeetgill 5y ago
That's the weirdest thing about the post though. They're using an http server as a Thread Pool/ExecutorService? To avoid using Runable and Callable? It doesn't seem like they we're writing an HTTP Service.