Kopretinka: Comments on The role of JVM

Comment by Stefan Tilkov

2005-12-02T22:06:54Z

I'm not a language designer, but compiling to different target machines is pretty much a solved problem AFAIK. The value, though, would be questionable -- it's not the VM that is the problem, it's the libraries. Even if java.* were solved, javax.* is pretty much open-ended and not cleanly mappable to .NET frameworks.

Comment by Jacek

2005-12-03T13:55:30Z

Stefan, I think that the new, VM-independent language, might have its own set of extension libraries that would be implemented over javax.* or the .NET equivalent, and that's the hard part, not the actual compilation.

Comment by Tobbi

2005-12-14T15:15:12Z

Hi Jacek,

I think there was such a "mistake" - remember CISC, RISC and post-RISC generation of processors. RISC architecture is even simpler than JVM bytecode. The result now - processors having RISC core and CISC layer over it. Why? I think that experience proved it is too difficult (low effectivity, hard to use...) to implement an "all-in-one" architecture like your proposed one.

The next argument plays against your model. My laptop is Dell. Well, how many "providers" created it? Surely many. My software is compiled using many compilers. My software is made by many authors...

Having this fact and looking at work of e.g. W3C - I see standardization is a dinosaur offen producing useless crap. (In fact, I think the only good "standardization" is done by power of MS - everything on their own, the others accept it silently.)

If standardization process were put to CPU's world ten years ago, we would use calculators today (never mind - standardized).

And one more note:
Writing .NET app (in C#) I took a Java library (using sockets and other java.* stuff) and was very surprised when the code was compiled and run without any problem.