The opposite direction is even easier and you should look into IKVM which is an open source implementation of compiling bytecode from Java to.Net. Grasshopper is tuned for Java where you'd like to add new applications to a J2EE application server. We wanted a non-intrusive solution that does not replace the VM of an application server that could be mission critical. Deploying Java class files (in jars that are inside wars, inside ears, etc.) is much less intrusive. When something doesn't work it is only the deployed application that throws an exception and not the whole application server crashing.
We also rely upon the more mature Java VM implementations that exist in good shape in all the platforms we need. Mono is still young, and we are sure it will reach the same quality level and spread as the platforms we need, but this will take significant time. It will take even more time to convince the world that it can replace its Sun (or JRockit, or IBM) Java VM) with Mono!
It's too difficult to compare IDE's and say this one is the best or that one is the best. The point is that Visual Studio has its community of developers that like it very much, know it very well and as you said look at it as if it was a Godsend to them.
For this community opening Linux and cross platfrom from Visual Studio is a great innovation. They can now utilize their skills and knowldege and reach beyond what they could reach before. Mono does it and Grasshopper (from Mainsoft) does it as well. Grasshopper is the J2EE configuration for Mono allowing.Net developer to target Java & J2EE from Visual Studio.Net. Suddenly, your average VB.Net developer can develop a Web application using ASP.Net with Visual Studio.Net WYSIWYG and deploy on WebSphere! This opens new frontiers...
You can add to the list of Languages C# & VB.Net. We at Mainsoft (see http://dev.mainsoft.com/) have a compiler that compiles the.Net bytecode to Java bytecode and supports the C# & VB.Net languages (.Net 1.1 version with Whidbey and Generics support in the working). We do have some limitations - the most notable is no support for unsafe code, but apart from that we support the whole package, unsigned types, structs, delegates, you name it. And we could support in the same manner any language (e.g. IronPython) that is compiled to safe managed code. As for the issue of interoperability with Java - subclassing, passing classes built in C# or VB.Net to Java and vice versa, the interoperability is complete. You can inherit in VB.Net from Java classes, Java classes can inherit from C# classes, you can use Java classes without any bridge or intermediate layer, etc.
The byte code converter is probably not too far. After all J2ME uses the same Java byte code as Java. However, the runtime that comes with it was not designed with J2ME in mind and uses non J2ME runtime classes
Porting is by no means ment for toy applications. We have customers that successfully ported using Grasshopper large applications (over 500,000 lines of code).
Regarding your questions about what the product can or cannot, why don't you download it, try it and see for yourself?
The more specific answers are:
* SOAP web services are supported.
* Delegates are supported. We couldn't compile the Mono code without such a basic language feature!
* Out-of-process sessions are supported. The ASP.Net is deployed as a Java servlet and can utilize all the features the J2EE application server provides, including, especially session persistence.
* Http Handlers are supported (although they require some tweaking).
* Http Modules are supported.
* Remoting will be supported in our next release.
We actually asked ourselves indeed the same exact question. What is better - a new VM, or - compiling.Net byte code to Java byte code.
The case that decided for us the issue was how do you convince an organisation to replace the application server VM he is using with out new VM?
A solution with a new VM is simply too intrusive for a product that is looking for integrating Java and.Net.
As for the performance, one has to look at what the converter itself is doing to see that in the common cases it produces identical code to what a Java compiler would and thus does not create an overhead. In cases where we handle new.Net features (like structs) we create an overhead compared to a.Net VM, but these are much less commonly usd then classes.
We ran for instance, our System.Xml code using.Net and using the converter and the Java VM of Sun. The Java run was faster(!) since the Sun VM outperformed the.Net VM.
Slashdot Mirror
The opposite direction is even easier and you should look into IKVM which is an open source implementation of compiling bytecode from Java to .Net. Grasshopper is tuned for Java where you'd like to add new applications to a J2EE application server. We wanted a non-intrusive solution that does not replace the VM of an application server that could be mission critical. Deploying Java class files (in jars that are inside wars, inside ears, etc.) is much less intrusive. When something doesn't work it is only the deployed application that throws an exception and not the whole application server crashing.
We also rely upon the more mature Java VM implementations that exist in good shape in all the platforms we need. Mono is still young, and we are sure it will reach the same quality level and spread as the platforms we need, but this will take significant time. It will take even more time to convince the world that it can replace its Sun (or JRockit, or IBM) Java VM) with Mono!
It's too difficult to compare IDE's and say this one is the best or that one is the best. The point is that Visual Studio has its community of developers that like it very much, know it very well and as you said look at it as if it was a Godsend to them. For this community opening Linux and cross platfrom from Visual Studio is a great innovation. They can now utilize their skills and knowldege and reach beyond what they could reach before. Mono does it and Grasshopper (from Mainsoft) does it as well. Grasshopper is the J2EE configuration for Mono allowing .Net developer to target Java & J2EE from Visual Studio.Net. Suddenly, your average VB.Net developer can develop a Web application using ASP.Net with Visual Studio.Net WYSIWYG and deploy on WebSphere! This opens new frontiers...
You can add to the list of Languages C# & VB.Net. We at Mainsoft (see http://dev.mainsoft.com/) have a compiler that compiles the .Net bytecode to Java bytecode and supports the C# & VB.Net languages (.Net 1.1 version with Whidbey and Generics support in the working). We do have some limitations - the most notable is no support for unsafe code, but apart from that we support the whole package, unsigned types, structs, delegates, you name it.
And we could support in the same manner any language (e.g. IronPython) that is compiled to safe managed code.
As for the issue of interoperability with Java - subclassing, passing classes built in C# or VB.Net to Java and vice versa, the interoperability is complete. You can inherit in VB.Net from Java classes, Java classes can inherit from C# classes, you can use Java classes without any bridge or intermediate layer, etc.
The byte code converter is probably not too far. After all J2ME uses the same Java byte code as Java. However, the runtime that comes with it was not designed with J2ME in mind and uses non J2ME runtime classes
Porting is by no means ment for toy applications. We have customers that successfully ported using Grasshopper large applications (over 500,000 lines of code).
Regarding your questions about what the product can or cannot, why don't you download it, try it and see for yourself?
The more specific answers are:
* SOAP web services are supported.
* Delegates are supported. We couldn't compile the Mono code without such a basic language feature!
* Out-of-process sessions are supported. The ASP.Net is deployed as a Java servlet and can utilize all the features the J2EE application server provides, including, especially session persistence.
* Http Handlers are supported (although they require some tweaking).
* Http Modules are supported.
* Remoting will be supported in our next release.
We actually asked ourselves indeed the same exact question. What is better - a new VM, or - compiling .Net byte code to Java byte code. .Net. .Net features (like structs) we create an overhead compared to a .Net VM, but these are much less commonly usd then classes. .Net and using the converter and the Java VM of Sun. The Java run was faster(!) since the Sun VM outperformed the .Net VM.
The case that decided for us the issue was how do you convince an organisation to replace the application server VM he is using with out new VM?
A solution with a new VM is simply too intrusive for a product that is looking for integrating Java and
As for the performance, one has to look at what the converter itself is doing to see that in the common cases it produces identical code to what a Java compiler would and thus does not create an overhead. In cases where we handle new
We ran for instance, our System.Xml code using