0

Java has java.util.concurrent for multithreading. Why is there no parallelism libraries (which use process instead of thread) in Java Standard Libraries?

There are some reasons I can think of, which are specific to Java:

  • Creating seperate processes which run java code requires a JVM in that process, so there is lot of overhead.

  • Process management and inter-process communication might vary across platforms and might be going against platform independence.

    According to this IPC is done using Internet Protocol's (IP) loopback network. This is understandable as using network calls is platform independent, but it is another overhead.

What could be the reasoning for this decision?

PS: This question is not about whether its better than multithreading. It is not in most cases (except when you need isolation). If it is "opinion-based", I'm asking what is/could be the reason behind that decision.

Edit 2: From the discussion in the comments, the reason for not having a built-in lib has less to do with pros and cons, principles of Java, or implementational complexity. It's just that they have decided not to include it in their scope, and we can't guess it.

hiru007
  • 110
  • 3
  • 6
  • 4
    Because it is not necessary in the sense that it is necessary in Python. Java's multi-threading can *effectively* use all cores that are available. – Stephen C Aug 26 '23 at 07:21
  • In Java, the only point of using something like Python's parallelism with multiple processes would be if it allowed you to spread computations over multiple machines ... and that is beyond the scope of Java. Even Python's parallelism doesn't support that. What you need is something like a batch scheduler or a grid computing or message passing framework like MPI. – Stephen C Aug 26 '23 at 07:27
  • 1
    The fundamental difference between threads and processes is that threads share an address space but processes do not. – Stephen C Aug 26 '23 at 07:30
  • @StephenC I know that java multithreading can use all core, unlike python which is limited by GIL. You mentioned "and that is beyond the scope of Java". My question is precisely why its beyond the scope of java. – hiru007 Aug 26 '23 at 07:35
  • 1
    Because they **decided** it was. It is entirely 100% up to the designers of Java to decide what is in scope and what is out of scope. And that's why the Java ecosystem has *thousands* of 3rd party libraries, frameworks and so on. The reason for ruling things out of scope is to make sure that what is >in< scope is not unmanageably large. (Note how they have recently made JavaFX, all of JavaEE and so on ... out of scope for Oracle. Scope is a >business< decision.) – Stephen C Aug 26 '23 at 07:40
  • Anyway ... what difference does it make if the parallel computing features you want are part of "core Java" or provided by a (good) 3rd-party framework? – Stephen C Aug 26 '23 at 07:50
  • 3
    *"If it is "opinion-based", I'm asking what is/could be the reason behind that decision."* - That is obviously an opinion too ... because Oracle management are not going to open up their business decision making processes to the rest of the world. – Stephen C Aug 26 '23 at 07:51
  • @StephenC So the reasoning is that they didn't include it in the scope as they wanted to have a concise, more-focused set of things that Java offers. This is what I wanted to know – hiru007 Aug 26 '23 at 07:59
  • 2
    @StephenC Actually, JavaFX is a *separate* scope for Oracle, not *out-of-scope*. The [*OpenJFX*](https://openjdk.org/projects/openjfx/) implementation of JavaFX is housed as a sub-project at Oracle’s *OpenJDK* site. Development is co-led by Oracle and [Gluon](https://gluonhq.com/). And source-code copyright is owned by Oracle. (But your overall point is valid.) – Basil Bourque Aug 26 '23 at 08:00
  • 1
    What I finally make out of this discussion is that this has less to do with pros and cons, principles of Java, or implementational complexity. It's just that they have decided not to include it, and we can't guess it. – hiru007 Aug 26 '23 at 08:09
  • 2
    @hiru007 - That is correct. We *could* guess, but our guesses will just be opinion. – Stephen C Aug 26 '23 at 09:43
  • 1
    You could always [pray to Brian Goetz to answer your question](https://stackoverflow.com/questions/27368432/why-does-java-8-not-allow-non-public-default-methods), but I suspect the authoritative answer is "other things were of higher priority", "this was never a JEP", or "fell off the backlog". Occasionally the answer is "how dare you". – Rogue Aug 26 '23 at 14:51
  • Regarding inter-process communication, Java 16 brought [Unix-domain sockets](https://en.wikipedia.org/wiki/Unix_domain_socket). This facility is a standard component of POSIX operating systems. This enables direct communications between processes without the overhead of going through the TCP/IP stack (localhost). See [*JEP 380: Unix-Domain Socket Channels*](https://openjdk.org/jeps/380). – Basil Bourque Aug 28 '23 at 05:28
  • 1
    Also regarding inter-process communication, I wonder if [*JEP 442: Foreign Function & Memory API (Third Preview)*](https://openjdk.org/jeps/442) will provide for shared memory access between processes. – Basil Bourque Aug 28 '23 at 05:36

0 Answers0