Return to Answer

So the important point in your question is why a new VM and not a java VM. ok let's choose a Java VM instead, what do we get? :

1- complex and voluminous Bytecode => how to store it, in the blockchain for which cost? (Knowing that a single java method can have a size up to 64KB) thus such VM or language isn't space-saving.

2- useless features and security concerns: Network access,I/O stream, File W/R ... =>each of these features implies big security issues. think of it, you can write a code which ping (of death) another machine or access protected files, or even steal the miner's private keys. Even sandboxed a flaw could occur and file "write/read" feature could break the whole system's security. so we'll need to get rid of all these features, which is a hard task to achieve for a licensed VM. We need to remember that a Blockchain VM should be isolated without the capacity to communicate with the external environment.

3- if you have a JVM, you would use Java or another JVM language, which are not adapted to the blockchain context (lack of determinism, memory and hardware access, higher execution latency,floating-point, etc...). Imagine you have a Java bytecode with a rand(), what would be the result and how to reach the consensus then?.

4- Weak DDos resistance (how to set a gas-like system in a complex VM like Java VM? ).

3- JAVA VM is a licensed Sun product, so you can't customize it to integrate it to the Ethereum's environment (for example how would you calculate the gas cost to avoid Dos attacks?)? to overcome this problem you need to write your own Java VM which is a complex task read: https://softwareengineering.stackexchange.com/questions/71561/java-and-jvm-license.

Besides, you can check out this answer about why to create a new contract language : What is the merit of creating new smart contract languages like Solidity instead of using other languages?

So the important point in your question is why a new VM and not a java VM. ok let's choose a Java VM instead, what do we get? :

1- complex and voluminous Bytecode => how to store it, in the blockchain for which cost? (Knowing that a single java method can have a size up to 64KB) thus such VM or language isn't space-saving.

2- useless features and security concerns: Network access,I/O stream, File W/R ... =>each of these features implies big security issues. think of it, you can write a code which ping (of death) another machine or access protected files, or even steal the miner's private keys. Even sandboxed a flaw could occur and file "write/read" feature could break the whole system's security. so we'll need to get rid of all these features, which is a hard task to achieve for a licensed VM. We need to remember that a Blockchain VM should be isolated without the capacity to communicate with the external environment.

3- if you have a JVM, you would use Java or another JVM language, which are not adapted to the blockchain context (lack of determinism, memory and hardware access, higher execution latency,floating-point, etc...). Imagine you have a Java bytecode with a rand(), what would be the result and how to reach the consensus then?.

4- Weak DDos resistance (how would you set a gas-like system in a complex VM like Java VM? ).

3- JAVA VM is a licensed Sun product, so you can't customize it to integrate it to the Ethereum's environment (for example how would you calculate the gas cost to avoid Dos attacks?)? to overcome this problem you need to write your own Java VM which is a complex task read: https://softwareengineering.stackexchange.com/questions/71561/java-and-jvm-license.

Besides, you can check out this answer about why to create a new contract language : What is the merit of creating new smart contract languages like Solidity instead of using other languages?

So the important point in your question is why a new VM and not a java VM. ok let's choose a Java VM instead, what do we get? :

1- complex and voluminous Bytecode => how to store it, in the blockchain for which cost? (Knowing that a single java method can have a size up to 64KB) so such VM or language isn't space saving.

2- useless features and security concerns: Network access,I/O stream, File W/R ... =>each of these features implies big security issues. think of it, you can write a code which ping (of death) another machine or access protected files or even steal the miner's private keys. Even sandboxed a flaw could occur and file "write/read" feature could break the whole system's security. so we'll need to get rid of all these features, which is a hard task to achieve for a licensed VM. We need to remember that a Blockchain VM should be isolated without the capacity to communicate with the external environment.

3- if you use JVM that means you will use Java or another JVM language, which are not adapted to the blockchain context (lack of determinism, memory and hardware access  ,higher execution latency,floating point, etc...). Imagine you have a Java bytecode with a rand(), what would be the result and how to reach the consensus then?.

4- Weak DDos resistance (how to set a gas-like system in a complex VM like Java VM? ).

3- JAVA VM is a licensed Sun product, so you can't customize it to integrate it to the Ethereum's environment (for example how would you calculate gas cost to avoid Dos attacks?)? to overcome this problem you need to write your own Java VM which is a complex task read  : https://softwareengineering.stackexchange.com/questions/71561/java-and-jvm-license.

Besides, you can check out this answer about why to create a new contract language : What is the merit of creating new smart contract languages like Solidity instead of using other languages?

So the important point in your question is why a new VM and not a java VM. ok let's choose a Java VM instead, what do we get? :

1- complex and voluminous Bytecode => how to store it, in the blockchain for which cost? (Knowing that a single java method can have a size up to 64KB) thus such VM or language isn't space-saving.

2- useless features and security concerns: Network access,I/O stream, File W/R ... =>each of these features implies big security issues. think of it, you can write a code which ping (of death) another machine or access protected files, or even steal the miner's private keys. Even sandboxed a flaw could occur and file "write/read" feature could break the whole system's security. so we'll need to get rid of all these features, which is a hard task to achieve for a licensed VM. We need to remember that a Blockchain VM should be isolated without the capacity to communicate with the external environment.

3- if you have a JVM, you would use Java or another JVM language, which are not adapted to the blockchain context (lack of determinism, memory and hardware access, higher execution latency,floating-point, etc...). Imagine you have a Java bytecode with a rand(), what would be the result and how to reach the consensus then?.

4- Weak DDos resistance (how to set a gas-like system in a complex VM like Java VM? ).

3- JAVA VM is a licensed Sun product, so you can't customize it to integrate it to the Ethereum's environment (for example how would you calculate the gas cost to avoid Dos attacks?)? to overcome this problem you need to write your own Java VM which is a complex task read: https://softwareengineering.stackexchange.com/questions/71561/java-and-jvm-license.

Besides, you can check out this answer about why to create a new contract language : What is the merit of creating new smart contract languages like Solidity instead of using other languages?

So the important point in your question is why a new VM and not a java VM. ok let's choose a Java VM instead, what do we get? :

1- complex Bytecode (class) => how to store it, in the blockchain for which cost? (Knowing that a single java method can have a size up to 64KB) so such VM or language isn't space saving.

2- useless features and security concerns: Network access,I/O stream, File W/R ... =>each of these features implies big security issues. think of it, you can write a code which ping (of death) another machine or access protected files or even steal the miner's private keys. Even sandboxed a flaw could occur and file "write/read" feature could break the whole system's security. so we'll need to get rid of all these features, which is a hard task to achieve for a licensed VM. We need to remember that a Blockchain VM should be isolated whitout the capacity to communicate with the external environement.

3- if you use JVM that means you will use Java or another JVM language, which are not adapted to the blockchain context (lack of determinism, memory and hardware access ,higher execution latency,floating point, etc...). Imagine you have a Java bytecode with a rand(), what would be the result and how to reach the consensus then?.

4- Weak DDos resistance (how to set a gas-like system in a complex VM like Java VM? ).

3- JAVA VM is a licensed Sun product, so you can't customize it to integrate it to the Ethereum's environment (for example how would you calculate gas cost to avoid Dos attacks?)? to overcome this problem you need to write your own Java VM which is a complex task read : https://softwareengineering.stackexchange.com/questions/71561/java-and-jvm-license.

Besides, you can check out this answer about why to create a new contract language : What is the merit of creating new smart contract languages like Solidity instead of using other languages?

So the important point in your question is why a new VM and not a java VM. ok let's choose a Java VM instead, what do we get? :

1- complex and voluminous Bytecode => how to store it, in the blockchain for which cost? (Knowing that a single java method can have a size up to 64KB) so such VM or language isn't space saving.

2- useless features and security concerns: Network access,I/O stream, File W/R ... =>each of these features implies big security issues. think of it, you can write a code which ping (of death) another machine or access protected files or even steal the miner's private keys. Even sandboxed a flaw could occur and file "write/read" feature could break the whole system's security. so we'll need to get rid of all these features, which is a hard task to achieve for a licensed VM. We need to remember that a Blockchain VM should be isolated without the capacity to communicate with the external environment.

3- if you use JVM that means you will use Java or another JVM language, which are not adapted to the blockchain context (lack of determinism, memory and hardware access ,higher execution latency,floating point, etc...). Imagine you have a Java bytecode with a rand(), what would be the result and how to reach the consensus then?.

4- Weak DDos resistance (how to set a gas-like system in a complex VM like Java VM? ).

3- JAVA VM is a licensed Sun product, so you can't customize it to integrate it to the Ethereum's environment (for example how would you calculate gas cost to avoid Dos attacks?)? to overcome this problem you need to write your own Java VM which is a complex task read : https://softwareengineering.stackexchange.com/questions/71561/java-and-jvm-license.

Besides, you can check out this answer about why to create a new contract language : What is the merit of creating new smart contract languages like Solidity instead of using other languages?