> >1. Not break any security features in validated JVMs
> Understood. Not at all clear. That's why "eventually" it would need to
> all be written in Ada.
I'm not talking about the security features designed into Ada such as type
safety, modularity, and readability. I'm talking about the security
features the Java guys thought of ahead of time (or discovered the hard
way and fixed) such as no access to local files, no tricking the JVM into
replacing any of its own classes--oops, I forgot that one's not fixed
> >2. Not lose the ability to have it validated as a "compliant" JVM.
> Can't answer this one. My suspicion is "politics" will be the biggest
> obstacle here.
Probably. But does the spec say, "here is the list of features and any
so-called JVM capable of doing more is non-compliant" ?
I remember hearing that HP was producing a JVM but not calling it a JVM
because allegedly certification would prevent certain features they
thought were necessary for their target customers.