Grasshopper 2.0 IL to Java bytecode Compiler Technology Preview

Posted by Jonathan Allen on Sep 23, 2006 12:32 AM

Community

.NET,

Java

Topics

Java plus .NET Integration,

Interop,

.NET Framework

Tags

Mono,

Visual Studio,

Tomcat,

ASP.NET,

Java EE

Mainsoft has released a preview of Grasshopper 2.0 that is compatible with Visual Studio 2005. Grasshopper allows Visual Studio developers to cross-compile IL into Java bytecode. Developers can then run their applications on a J2EE/Tomcat stack.

While Mainsoft has written its own core library (mscorlib) that works in conjunction with its cross-compiler, it relies on the Mono project for most of the .Net class library.

The current release version of Grasshopper is free on the Tomcat platform. If you want to run it on IBM WebShere, BEA Weblogic, or JBoss, a license for their enterprise offering, Visual WinMain for J2EE, will be needed.

 

1. Back to top

   Limitations / optimizations?

   Sep 23, 2006 10:59 AM by Patrick Linskey

   It's my understanding that there are some subtle but significant differences between classloading and language-level security (and probably other areas) in the CLR vs. the JVM. But the Grasshopper site docs are pretty devoid of any discussion of limitations. Does anyone have a low-level CLR to JVM comparison? Any idea how Grasshopper handles the discrepancies? (In fact, on closer examination, it looks like the site mostly talks about IL / Java bytecode, and not much about CLR / JVM differences.) Also, the Java bytecode spec has a few neat extra instructions; does Grasshopper convert overly-verbose IL bytecodes into functionally-equivalent Java bytecodes? Is this necessary given the optimizers in modern JVMs? -Patrick -- Patrick Linskey http://bea.com

   Reply

2. Back to top

   Re: Limitations / optimizations?

   Sep 27, 2006 2:28 PM by Eyal Alaluf

   Thank you Patrick for taking us to the fundamental architectural level of the .NET and J2EE platforms. Since your question is of general interest for all our developer community I have posted your comment and the following reply in our developer forum. I invite you to continue this dialog from there. The link is http://dev.mainsoft.com/default.aspx?tabid=27&forumid=19&view=topic&postid=1252&tpage=1 Now with regards to your comments - my (somewhat long) reply: Indeed there are several subtle and significant differences and our product Visual MainWin for J2EE address them. You've raised the following issues in your post: 1. Language protection levels 2. Class loading semantics 3. Special Java byte code and optimizations The main point that we need to put in front is that we don?t aim to be a CLR implementation on top of a Java Virtual Machine and to be capable to compile and run any .Net DLL as is on a Java VM. Our goal is to connect the .NET developers within their natural environment: development environment: languages, IDE and framework to the Java platform. Visual MainWin for J2EE primary requirement is to produce applications that complies to the J2EE specifications and that are fully integrated within the Java platform. Therefore we do not aim to hide all the discrepancies, and indeed the .NET developers has to be aware they are developing for the J2EE architecture and have to modify slightly their source code (statistic average around 0.5% percent). This is why our tool works only when you have the source code of your application and not just the DLL s. We are indeed focused on two main subjects related to compiling CLR assemblies into Java class files and running them 1. The translation of the .Net IL byte code into Java byte code 2. The behavior at runtime of the application once hosted on Java. The runtime behavior is most significantly affected by the underlying Java framework capabilities and the extent and quality of Grasshopper .Net framework implementation. Language protection levels .Net defines a model that has subtle differences and extra complexities when compared to Java. We basically map the .Net protection levels to less strict protection levels in Java. Take into account that during the compilation process, first the Microsoft C# compiler compiles the C# source and then our binary compile compiles the .NET DLL into java class files. Most of the language protection levels enforcement is done at the source compilation level and our .Net to Java mapping can be less strict the runtime and may not detect a few cases of code that tries to access an inaccessible method or class. For example of this less strict mapping let's consider the following cases * .Net protected - we map it to Java protected. Java protected allows sub classes AND classes from the same namespace to access the resource (class, method, field, etc.). This is less strict then .Net but seems strict enough. * .Net internal - We map it to java public. Internal in .Net allows any class within the same assembly to access the resource. In Java the closest match is to allow package access (same namespace) but this is stricter then the .Net semantics in the common cases where an assembly contain more then one namespace As can be seen we prefer to be more ?forgiving? then .Net in order to prevent code changes on the application side. Class loading semantics Again we have the same approach on this topic. Since Application domains are significantly different that the Java class loaders, and since there is usually a limited dependency the extended AppDomain functionalities we have only a partial support for .Net app domains. We allocate an app domain for each web application and thus can support multiple web applications that share the framework but we do not support creation of multiple app domains from the application code. On .Net if two app domains use the same class each app domain will have its own copy of the class static data. This is not supported with Visual MainWin . Since we do not allow the creation of app domains and different web applications on J2EE do not share jars (normally) we hit this limitation only in our .Net framework implementation where in certain cases we modify the code to get and set values from the current app domain instead of using a static variable. In short our app domain support is limited and tailored for web application support. Java byte code optimization There are some special Java byte codes like iinc that can be represented only by a sequence of IL byte codes. We do not look for such sequences of IL byte code in order to translate them into the more succinct Java byte code. We have not seen the point in doing so; our performance analysis has shown Java VM optimizers to be very strong. Performance analysis had shown us that memory usage and GC tuning are important, the quality of our implementation of the .Net framework is critical (e.g. is System.Xml.XmlTextReader well implemented and efficient or not?). We definitely need to look for specific issues like arrays of structs where we incur a performance overhead and if they are centric we recommend modifying the application. More on performance tuning can be found at http://dev.mainsoft.com/Default.aspx?tabid=32&src=OptimizingNETcode.html . Bottom line, with all real life applications we conduct performance analysis for, we succeed to reach equivalent performance than the original .NET code. Eyal. Eyal Alaluf, V.P. Technology Mainsoft.com

   Reply

• Older >