none
technical differences between JVM and CLR?

    Question

  • I read lots of things about jvm and clr but still i can't understand the technical differences.Much of them are about "c# is more powerful than java" or  "c# is copy of java" etc..(some benchmark tests).

    But i want to learn the techinical and algorithmic differences between these two technologies.I don't want to learn which technology is more powerful.I want only technical details.

    How do they execute source codes differently step by step?I mean ;what are the different  ways(methods) which they use while execution.

    Your help is greatly appreciated.


    Saturday, November 05, 2005 8:40 PM

Answers

  • Hello,

    Responding to your question seems fraught with peril by starting a flame war, so I'll proceed cautiously.

     

    There are a number of fundamental technical similarities between the Java Runtime and the Common Language Runtime, including garbage collected memory, an intermediate language (Microsoft IL versus Java ByteCode), core system libraries, and support for fairly high level languages, code security, and deployment.

    However, each of these 'similar' areas also have a number of sizable and small differences, and it's beyond the scope of a simple Forum post to describe most of them.

    I would suggest asking a more targetted question about any of the various runtime features and component areas (e.g. memory management, compilation, system libraries, security, etc.) and then we can provide a more targetted response (e.g. a blog, a technical article, or some books).

     

    If you go to your favourite search engine (YFSE), and type in "Java versus CLR comparison", you can probably find a wide variety of responses!

     

    Hope that helps,

    Stephen [Microsoft Common Language Runtime: Security - Developer]

    http://blogs.msdn.com/stfisher

    Monday, November 28, 2005 11:33 PM
  • Hello,

    I can't speak for the rationale behind the Java design, but I can tell you that the CLR was specifically designed to allow for a high-level of interopability with native code. We designed the CLR with the knowledge that existing developers could not be expected to simply throw out millions of lines of tested and operational code, simply because we released a new development product. We made the choice to allow for interop via pointers and marshalling [PInvoke] to allow for intra-process integration [beyond out-of-process COM and Remoting boundaries].

    However, allowing direct memory manipulation and interop with native code has significant development tradeoffs, both for the CLR and developers.

    The CLR must manage reliability and security when native memory is accessed and modified (e.g. UnmanagedCode security permission demanded), garbage collector integration (marking memory pressure), and marshalling between GC and CLR-based data structures (string, numbers, 'object') and native data structures (e.g. unicode characters, byte buffers, COM interfaces).

    I would recommend the book by Adam Nathan, .NET and COM.

    Hope that helps,
    Stephen [Microsoft Common Language Runtime: Security - Developer]
    http://blogs.msdn.com/stfisher

    Sunday, December 04, 2005 5:20 AM

All replies

  • Hello,

    Responding to your question seems fraught with peril by starting a flame war, so I'll proceed cautiously.

     

    There are a number of fundamental technical similarities between the Java Runtime and the Common Language Runtime, including garbage collected memory, an intermediate language (Microsoft IL versus Java ByteCode), core system libraries, and support for fairly high level languages, code security, and deployment.

    However, each of these 'similar' areas also have a number of sizable and small differences, and it's beyond the scope of a simple Forum post to describe most of them.

    I would suggest asking a more targetted question about any of the various runtime features and component areas (e.g. memory management, compilation, system libraries, security, etc.) and then we can provide a more targetted response (e.g. a blog, a technical article, or some books).

     

    If you go to your favourite search engine (YFSE), and type in "Java versus CLR comparison", you can probably find a wide variety of responses!

     

    Hope that helps,

    Stephen [Microsoft Common Language Runtime: Security - Developer]

    http://blogs.msdn.com/stfisher

    Monday, November 28, 2005 11:33 PM
  • ok.
    Firstly,
    You know, in .net we can use unsafe code(pointers) so Pinvoke and interoperability concepts are the part of the .net framework but not in JVM.How can CLR achieve this?What is incomplete in JVM so there is no way to use pointers.


    Thursday, December 01, 2005 7:00 AM
  • Hello,

    I can't speak for the rationale behind the Java design, but I can tell you that the CLR was specifically designed to allow for a high-level of interopability with native code. We designed the CLR with the knowledge that existing developers could not be expected to simply throw out millions of lines of tested and operational code, simply because we released a new development product. We made the choice to allow for interop via pointers and marshalling [PInvoke] to allow for intra-process integration [beyond out-of-process COM and Remoting boundaries].

    However, allowing direct memory manipulation and interop with native code has significant development tradeoffs, both for the CLR and developers.

    The CLR must manage reliability and security when native memory is accessed and modified (e.g. UnmanagedCode security permission demanded), garbage collector integration (marking memory pressure), and marshalling between GC and CLR-based data structures (string, numbers, 'object') and native data structures (e.g. unicode characters, byte buffers, COM interfaces).

    I would recommend the book by Adam Nathan, .NET and COM.

    Hope that helps,
    Stephen [Microsoft Common Language Runtime: Security - Developer]
    http://blogs.msdn.com/stfisher

    Sunday, December 04, 2005 5:20 AM