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 a video interview I did with Oved Yavine, Director of customer services at Mainsoft. He talks about Mainsoft for Java EE, Portal Edition, and how you can use Visual Studio 2005 to develop ASP.NET apps that run natively on WebSphere Portal as JSR-168 Compliant portlets:
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)
I’ll be presenting a 3 hour tutorial at the upcoming Agile Practices Conference in December on .NET and Java, the interop gap and various solutions to interoperate between them. Grasshopper will also be introduced as well as other solutions such as Codemesh. Here’s the abstract:
Java and .NET - Bridging the Interop Gap
Many development shops have huge investments in Java, .NET, or both. When it’s time to get programs in one language talking with programs in another, or even being fully deployed in a foreign environment, what options do you have? How do you make sure your programming language skills, along with the investment that gave you those skills, aren’t lost when trying to target another platform or re-use existing code instead of rewriting it? Roy Osherove will present various approaches to interoperability between .NET and Java. These approaches include: cross compilation, single-sourced applications, cross language interoperability, JNI, SOAP and web services, and architectural patterns. Roy will also demonstrate tools such as CodeMesh, Mainsoft Grasshopper, Janet, JNBridge and more.
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”
I’m continuing on with my quest for installing Tomcat and Java on my Ubuntu machine. Next thing I need: Java.
At first look, I found it hard to believe that you need to go through so many steps in order to install the java runtime on Ubuntu (probably since it’s part of a Debian Linux distribution, so somehow installation should occur differently? that’s what I somehow “got” from my readings). After looking here and here I finally got it to install Java.
But then, I noticed (as is the case many times) that I’m doing things in a much more manual way than I needed to. I cam upon this in the wiki which explains that using the terminal mode (took me some time to find the terminal on ubuntu..) all i had to do was:
sudo apt-get install sun-java6-bin
sudo apt-get install sun-java6-jdk
I really love the fact that the “windows update” idea is built into the OS. It’s very easy to get updates, assuming you have the “repositories” installed. Still, I’d love for there to be a visual way to select these updates for the user who does not want to use the terminal. I would have expected it to be searchable here:
I just finished installing Ubuntu Linux on my VMWare machine. It was a painless experience (I’m a windows developer with almost zero experience working on Linux), but then I got this little notification:
Let it not be said that just windows has a zillion updates to run when you first install it.
I’m going to be running Tomcat on an Ubuntu installation, so I can run my Grasshopper generated applications (DotJava apps?) there. I’ll be using this manual to do so.
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.
