We are proud to announce a preview release of Grasshopper with AJAX Extensions support.
This release contains an implementation of System.Web.Extensions, and a sample containing the AJAX Control Toolkit together with its sample web site, all running on Tomcat.
It is worth pointing out that the entire development of this feature is completely open source:
The System.Web.Extensions implementation was contributed to Mono and is available at
svn://anonsvn.mono-project.com/source/trunk/mcs/class/System.Web.Extensions
The Microsoft AJAX Library is based on the Microsoft implementation that was released under the MS-PL
Also the AJAX Control Toolkit, together with its sample are also available for download on CodePlex under the MS-PL
We are currently using the debug version of the Microsoft AJAX Library. This has some performance implications due to the size of the JavaScript files and other differences compared to the optimized JavaScript.
We have invested some energy in different performance optimizations by preserving the rendering flow without any difference between AJAX and non-AJAX requests. Same for JSON de/serialization (we avoid creating an intermediate dictionary and perform single pass de/serialization).
Porting the AJAX Control Toolkit succeeded without any runtime source code changes. We did need to disable the designer code that is not supported in Grasshopper.
We are interested in feedback. Please give this preview a test drive and let us know what you think. You can ask technical questions, report bugs, or just let us know what you think and what other features you would like to see in the next Grasshopper release by posting in the Grasshopper developer forums at http://dev.mainsoft.com/default.aspx?tabid=27&view=topics&forumid=19
Here’s another vide that we’ve shot featuring Noam Lampert (Head of R&D) and Roei Erez (Core Team Lead). I’m Using Viddler to show this video so let me know if you have any problems watching it in the comments.
(If it says “loading” for a long time, clicking on the “Progressive” word on the bottom of the movie to change it to streaming mode)
Topics in this video:
What’s the idea behind Grasshopper
How does Grasshopper work?
What types of challenges do you encounter when trying cross-compile (translate) .NET IL code to Java Bytecode?
What does the future hold for Grasshopper?
(for example .NET Generics Vs. Java Generics)
(or 3rd party dependencies you need to convert)
what kinds of tests do you have?
Stuff I should worry about as a .NET developer that is compiling using Grasshopper
What are you working on right now?
I’ve also added a Grasshopper TV Logo animation to start out the video (I used Sony Vegas to edit it and add the various TV related effects, although the actual logo was done by our graphics artist)
One question that really bogged me about Mainsoft when I first heard about it was “Where does Mono fit in?”. What do I mean by that?
Mainsoft helps “cross-compile” your .NET Code into Java Bytecode. The process means you use .NET (Microsoft, not Mono) to write your code, but you compile to java bytecode using the Grasshopper addin and the Mainsoft project templates. All fine and dandy, for sure. But Mainsoft is also a big contributor to the open source .NET implementation on Linux called Mono. Where does contributing to mono fit into the Mainsoft business? more specifically, where is the technological dependency that requires Mainsoft to use mono as part of grasshopper? clearly, you don’t see mono as a .NET developer writing grasshopper enabled applications, so where can it be found in the process?
After a relatively long lunch discussion with Kosta (who’s blogged here before) the answer lies here:
One of the things Mainsoft does is create a .NET framework API written in Java
that API is used by your cross-compiled code when you compile it in visual studio 2005 (for example, when you add a reference to System.Xml in your Grasshopper project, you are actually adding two references - one for system.xml and the other is a jar reference to the system.xml implementation in java)
That API implementation had to come from somewhere. it is based on the Mono implementation of the .NET framework (no, we don’t use Reflector to copy .NET framework code. It’s strictly prohibited).
So, Mainsoft Contribute to the Mono Implementation ,and then implement the same thing in Java, based on the “reference implementation” found in Mono. That Java implementation is used and referenced from your grasshopper cross compiled applications, so that the APIs you use for System.Xml will transfer seamlessly into the Java world.
Here’s an image I made that I hope can help clarify this:
Update: As kosta explains in the comment, there is obviously a compilation step of mono to IL, and from that the java source code is generated. As he says (with my own little slant in there) “when developing mono we are effectively developing our own library references for the Java API as well”
Jack Vaughan posted in his interoperability blog about CodeMesh, and how they try to enable (and succeed to a degree) interoperability between Exiting Java code and external code written in an language like C++ (They also have a product for .NET). Their approach is to use code generation that creates wrappers around the Java code which lets you talk to the java code from the external language, and vice versa ,
Read the interview he did with Alexander Krapf in 3 parts (first, second, third) where he also refers to JuggerNET, one of their products.
On the Codemesh site they have a comparison with other methods of achieving interoperability (JNI, Web Services, hand written code, CORBA).
It’s interesting to note that on some level, both Codemesh and Mainsoft are sharing the same set of problems:
Keeping up with new versions of the frameworks on both sides
“As people switch compilers, new issues come up, bindings must be updated. Meanwhile, certainly, new versions of .NET have to be studied for elements that it would be useful – or necessary – to update. This was interesting to me – to see platform and framework change from the point of view of an Independent Software Vendor [ISV] who must ensure the fit and finish for customers. Of course, the backdrop is a software landscape now highly influenced by open-source and free software, where end users often must take on the role of Versioning Meister.”
Amen. Mainsoft is coming to grips with the .NET framework 3.0 and 3.5, but it’s a struggle to keep up. The same goes for Java. It’s comforting to know we’re in the same boat..
Generics
“Updates in .NET, particularly, have led Krapf to consider how Generics can play in the new interoperability milieu. It is worthwhile to consider, he said, taking Java Generics and translating them into .NET. But, to do it for all APIs, he adds, “is not as trivial as it sounds.”
I spent some time talking with Noam Lampert, Dev lead here, and he explained to me some of the difficulties and challenges involved in making .NET generics to translate nicely to the java platform. For example, in .NET creating a generic type of of some sort (IList<int>) and then creating another one for a different type (IList<string>) actually creates two separate classes at .NET runtime. In Java, Generics play differently and you have to make sure you get it right or stuff just won’t work as expected or not compile at all. I hope to explain this more deeply in a alter post.
They generate code
“And the other major piece is in the code generator, which knows how to map from Java Type A to the corresponding part in .NET. That’s what many people miss when they do proof of concept on things like this.“
Grasshopper doesn’t actually generate code, but it actually compiles IL code into Java Byte code. That means that you have two main use cases for Grasshopper Compiled code :
Write in .NET but actually run natively in Java - no interop at all. Your code is actually Java code.In this use case you can also migrate existing .NET code to Java.
Federate, or reuse your existing .NET code from Java or vice versa, via web services or uses remoting. For instance, you can write code in .NET that uses your existing objects through web service or remoting interface. Because you are still writing in .NET, you will not have to modify your existing code to be WS-I compliant when you expose it as a web service. You will still be able to use .NET types like DataSet even when running in Java. This is the interop scenario grasshopper enables.
They have a bunch of utility classes to help with interop translations issues and such
We also have utility classes that are used when you write code in .NET. stuff like translating BigInteger to .NET integer values and so on. If you are programming only in .NET languages you usually do not need to use these classes directly. If you want to call from your C# code a class that was written in Java, you may need to use these to marshal specific types to the types Java expects (e.g. a DateTime to a java.util.Calendar).
Overall I’d say the main difference between grasshopper and Codemesh JaggerNet are:
Codemesh enables native cross language interop. it allows in process interop between platforms, but does not try to solve the skill problem (where you need to learn another language to interoperate with it) . It does not support or try to support web service or remoting scenarios. in fact, it is compared against those (either-or) as a different solution.
Grasshopper enables native code compilation to Java (solving the skill problem - I don’t need to learn java to create code or use code on the java platform . all I know is .NET)
Grasshopper also allows writing interoperating code using web services and remoting from and to .NET without needing to translate or rewrite parts of your .NET code in Java. It is done for you. The skill barrier is taken care of, but interop at the web service or remoting level between two different platforms is possible.
The interop solution the you can use with Grasshopper compiled code could be slower than the native calls performed by Codemesh APIs (since Codemesh uses the JNI interface, a low level C interface for the java language which is fast, and runs in process) because we support web service calls and remoting interop between .NET and java - slower than direct calls using JNI.
Codemesh does not solve the skill problem - if I want to use Java objects from .NET or C++ I need to learn the Java API stack. with Grasshopper you only need to know .NET. the skill barrier is lower.
At Mainsoft we are using unit testing extensively as one of the means of assuring product quality. Typically we use NUnit, but I like JetBrains’ UnitRun because it allows me to run the test suite right from the development environment, along with making it easy to select which tests you want to execute. UnitRun also makes it more convenient to navigate to failed tests.
So far, JetBrains and NUnit have been playing nice together. That’s until recently, when I found out that one test that passed UnitRun failed on NUnit. After some trial & error it became obvious that there was a unwanted dependency between two of the tests in my TestFixture. If the test was being run isolated it succeeded under both systems, but under NUnit it failed when running the whole TestFixture.
xUnit (the general unit testing framework) doesn’t specify in which order to run the tests; it is up to each implementation to decide. NUnit sorts the methods in alphabetical order while UnitRun uses the order in which they occur in the TestFixture class. My test method A() was running before B() in NUnit while UnitRun had it the other way around. The inconsistency was created because A() was failing if B() had already been run.
In the end I fixed the inter-test dependency and moved around the methods inside the TestFixtures so that they now occur in alphabetical order.
We’ve just released a new knowledge base article about testing grasshopper (.Java?) applications on Linux without using a full Linux server. the idea is to use a (free) virtual appliance from VMWare to test on.
“If you’re not yet ready to start installing, administering, and configuring a full-blown Linux® distro, but you would like to see how a .NET application compiled with Grasshopper to Java bytecode runs on a Linux machine, this is the article for you. We will use VMware Player, a product that runs a virtual machine inside your Windows system and Apache Tomcat Virtual Appliance, a nano-sized Linux virtual machine with the Tomcat application server, which is accessible through VMware. In this article we’ll show you how to create a Grasshopper Web application and run it on a Linux server inside your Windows system.”
Mike Dolan likes what he’s read about compared performance of cross-compiled .NET applications to Java using Grasshopper. (Mainsoft is an advanced IBM business partner and works with several teams within IBM, including the Linux team).
“I was looking through the report and was amazed that in most of the testing scenarios, the .NET applications ran better on Linux than on Windows! Yes, faster. “
I agree, it’s pretty darn cool. Actually, the sentence he’s referring to has more to do with the WebSphere platform than anything else:
“The Java EE version of the application also showed that in multi-CPU environments, the scalability characteristics of Java EE and WebSphere Application Server began to show marked improvements over the original .NET application”
But the thing worth noting is this:
“The ported version of the application showed equivalent performance in average response time, and equivalent performance in server throughput. Thus, an SLA could be met using the ported version of the application without additional hardware investment”
