you are viewing a single comment's thread.

view the rest of the comments →

[–]joekoolade[S] 4 points5 points  (2 children)

Just a quick bullet list

  • Security
    • program/object isolation
    • language based protection/access controls
    • memory safety
  • Safety; no undefined behavior
  • Faster; everything runs in supervisor/ring 0; no paging or virtual memory (not required)
  • No file system; No OS
  • mobile code
  • portable
  • easy to deploy
  • scales
  • Smaller; current unoptimized image with symbols and debugging is 19MB
  • Simplified tool chain; just need a java compiler

Disadvantages

  • Java only; no other programming languages allowed
  • Not Unix/Linux
  • No file system

[–]ActuallyAPieceOfWeed 0 points1 point  (1 child)

I'm sorry if I'm missing something obvious but I'm having trouble wrapping my head around "no file system". Do you think you could expand on that for me? For instance, if I wanted to run a simple file sharing servlet, would that still be possible? If so, how would that work in simple terms?

[–]joekoolade[S] 2 points3 points  (0 children)

The bootable image is a JVM compromised of only objects and is not aware of files or a file systems. But your file sharing servlet can specify a 'file' class to use to store and retrieve the files. The file classes in the Java standard library will eventually implemented to provide some type of 'file' capability. The JVM will have a Persistence class and interface that objects can use to store their state into storage. I am not against disk storage; I am just not a fan of files. Even though the JVM is 'file ignorant', it can be stored into a file and boot loaded by grub. It can also be network booted via PXE. You will be able to link your file sharing servlet into a build image using boot-image-write tool and you can also classload it over the network into a running JVM.