Ho capito che la JVM è implementata come interprete, ma è a tutti gli effetti una macchina virtuale.
ok, tieni conto ancora che è uno strato del Sistema Operativo, è un ospite.
Le variabili di classe, quelle static tanto per esser chiari, sono variabili consivise tra tutte le istanze di quella classe specifica in tutta la JVM in esecuzione.
Quindi ho il rischio di sporcare lettura e scrittura di queste variabili.
Sono istanze nell'eseguibile, ma non sono condivise in TUTTA la JVM.
Se avvii un eseguibile C che ha delle variabili globali (non-static), che forse ti è più familiare, in più shell secondo te le varibili andranno in conflitto nell'OS? (PS: parliamo di layer utente, layer kernel è un altro mondo).
Quindi mi stavo chiedevo se era possibile ovviare a questo problema lanciando 1a1 primo.jar --> jvm1, secondo.jar -->jvm2, etc ... Isolando la computazione de facto.
Questo "shell> java -jar file.jar" pare proprio l'attuazione di quanto sopra descritto.
Per ogni java -jar pippo.jar è istanziata una nuova jvm. Anche se "pippo.jar" è lo stesso, ognuna ha la sua fettona di memoria, classi nominalmente identiche sono entità diverse e non interagiscono.
ok, la JVM è unica, ma ogni applicativo ha la sua fetta di memoria indipendente.
Devi sostituire "istanza di una nuova jvm" con "un'istanza di un'applicazione java che utilizza la UNICA jvm".
Quello che dici sulle static o le variabili di classe non ha senso. Quando lanci l'eseguibile java si crea un nuovo ambiente pulito Java che ha scope solo in questo ambiente. Non puoi interagire con altre classi che hai lanciato in un altro ambiente; ovvio se utilizzi artifizzi ad-hoc come tunnelling, socket, ovvio che puoi interagire, ma sono veri e proprie unità monolitiche.
Una variabile static di un eseguibile, con lo stesso nome di un altro eseguibile, non andranno mai in conflitto perchè sono indipendenti.