Je travaille avec la plate-forme Java depuis longtemps et je connais très bien ses forces et ses faiblesses. Dans cet article, je veux vous dire comment l'histoire aurait pu se dérouler si ce n'était pas le cas. Après tout, nous pourrions utiliser une machine Java au lieu de systèmes docker. Et la machine Java elle-même pourrait bien remplacer complètement le système d'exploitation.
Ceci est un article de synthèse, je vais juste souligner quelques considérations. Leur analyse complète prendrait beaucoup de place.
La machine Java est donc un système d'exploitation. Encore plus cool que le système d'exploitation par endroits. En fait, ce n'est pas une déclaration aussi scandaleuse. Après tout, tout le monde connaît un exemple de système d'exploitation à part entière, largement basé (initialement) sur Java - Android . De plus, il existe un OS au sens classique entièrement basé sur la JVM.
Alors, quelles fonctionnalités OS avons-nous dans la JVM? Gestion de la mémoire - sans aucun doute. Contrôle des threads - oui, mais généralement basé sur les threads locaux existants du système d'exploitation sous-jacent. Cependant, les threads sont un sous-système essentiel, intrinsèque et hautement développé de la machine, offrant beaucoup plus de services que les threads du système d'exploitation sous-jacents.
Les E / S sont également très avancées en termes de toute l'infrastructure Java, avec tous les serveurs et bibliothèques. En ce sens, les E / S du système d'exploitation de base - à peu près comme l'ancien BIOS pour ce dernier, effectuent des opérations de bas niveau.
Java a une philosophie. Si sous Unix - tout est un fichier, alors en Java, tout est (presque) un objet.
Il y a une partie importante du système que beaucoup de gens ignorent ou oublient. Java est un environnement doté de puissants moyens de contrôle d'accès. C'est pourquoi, entre autres, il est largement utilisé dans le secteur bancaire.
La présence de ces outils, associée à un multithreading complet au niveau du langage, crée les conditions préalables à la création d'un environnement multitâche ET multi-utilisateur. Beaucoup de gens connaissent le multithreading. Quant au contrôle d'accès, revenons plus en détail.
-, JVM – (managed) . . , . .. , - ( ) . . - , . - - -.
, - ( ) – . . , , . , , , . ( private, protected ..) – , . . . (SecurityManager) , , . . , , - ( ) - + . - ?
. , , , .. . - OSGi.
, . , . -, – . , .
- ? , , – – - -. , (). . . , – , , ( ), - – ejb, , protoBuf & gRPC – RMI Corba & RMI-IIOP. .
La seule chose qui manque est de belles images et graphiques (bien que cela dépende de l'implémentation ici) et le déploiement de l'infrastructure à partir du diagramme dessiné. Mais personne ne mettra ce dernier dans une boîte avec Kuber gratuitement.
Et pour illustrer, regardons la modularité standard d'un serveur d'application. Il existe une hiérarchie de chargement: système -> serveur -> application -> module d'application.
Bon, c'est tout pour l'instant. Nous serons ravis de la sortie de la prochaine version de Jakarta EE 9 et leur souhaitons plein succès.