Saturday, December 06, 2003

Re: the next JVM (Java Virtual Machine)

Microsoft is trying to faze out Win32 and move to managed code. So anything new that is added is not just a layer on top of the real thing.

that is the main worry for any application, be it either the jvm, or any standard c++ app or acy other language which you would want to compile in a different platform. will these api's have to make calls to the .net api?

the java vm just like any app it relies heavily on the undelying os. the vm for example has to perform actions like memory management.
i am not sure about the other swing api's etc. but if an app has to catch mouse actions etc it has to invoke the os mouse methods, which are all C right now.
consider this article from eclipse swt. swt is an alternative ui api for java. but the break the java cross-platform feature to offer much better os based ui. the article shows how dependant the java api/code is on the os. basically everything.

I don't think anything will happen to Java. It will still be very much alive and kicking.

and so only if the jvm etc has to make calls to a .net api, its dead. basically performance of the jvm would be killed (obviously). now i have considered on the jvm. but i guess this situation would be no different for other languages trying to work outside the .net compiler. if your app wants to use new longhorn functionality it has to be .net. sounds really scary.

I just dunno how it will work in Longhorn - we will have a managed managed world.

are you trying to say yu agree with vm in vm??

No comments: