I have been working with the Java platform for a long time and I know its strengths and weaknesses very well. In this article I want to tell you how the story could have turned out if it weren't for. After all, we could use a Java machine instead of docker systems. And the Java machine itself could well completely replace the OS.
This is an overview article, I will just outline a few considerations. Their complete analysis would take up a lot of space.
So Java machine is an OS. Even cooler than the OS in places. In fact, this is not such an outrageous statement. After all, everyone is well aware of an example of a full-fledged OS, significantly based (initially) on Java - Android . In addition, there is an OS in the classical sense entirely based on the JVM.
So, what OS features do we have in the JVM? Memory management, no doubt. Thread control - yes, but usually based on existing local threads of the underlying OS. However, threads are an essential, intrinsic and highly developed subsystem of the machine, providing much more service facilities than the underlying OS threads.
I / O is also very advanced in terms of the entire Java infrastructure, with all the servers and libraries. In this sense, the I / O of the base OS - roughly like the old BIOS for the latter, performs low-level operations.
Java has a philosophy. If in Unix - everything is a file, then in Java everything (almost) is an object.
There is an important part of the system that many people either do not know or forget about. Java is an environment with powerful means of access control. That is why, among other things, it is widely used in the banking sector.
The presence of these tools, coupled with full-fledged multithreading at the language level, creates the prerequisites for creating a multitasking AND multiuser environment. Many people know about multithreading. As for access control, let's dwell in more detail.
-, JVM – (managed) . . , . .. , - ( ) . . - , . - - -.
, - ( ) – . . , , . , , , . ( private, protected ..) – , . . . (SecurityManager) , , . . , , - ( ) - + . - ?
. , , , .. . - OSGi.
, . , . -, – . , .
- ? , , – – - -. , (). . . , – , , ( ), - – ejb, , protoBuf & gRPC – RMI Corba & RMI-IIOP. .
The only thing missing is beautiful pictures and graphs (although it depends on the implementation here) and the deployment of infrastructure from the drawn diagram. But no one will put the latter in a box with Kuber for free.
And to illustrate, let's look at the standard modularity of an application server. There is a loading hierarchy: system -> server -> application -> application module.
Well, that's all for now. We will be delighted with the release of the next version of Jakarta EE 9 and wish them success.