The Old Joel on Software Forum: Part 4 (of 5) - MSIL to Java bytecode converter

MSIL to Java bytecode converter

I recently came across this product:
http://www.mainsoft.com/products/vmw_j2ee.html

Does anyone have any experience using it? Does it really work? Are there any hidden "gotchas"?

We are hoping that the developers who favor .NET can write applications in .NET and then deploy to a Java platform to make the business analysts happy.

T.S.
Tuesday, March 2, 2004

All I can say is this:

Watch out for Mainsoft products. Try before you buy,

Sassy
Tuesday, March 2, 2004

Well, if they don't work, just wait until they release the source...

Mark Tetrode
Wednesday, March 3, 2004

Sales blurb: "Until now, the Java platform has been a mono-language platform accessible exclusively to highly skilled Java developers"

Uh, Does that mean that the people behind http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html and all the languages listed there are lying b*st*rds then?

I thought not
Wednesday, March 3, 2004

If you read the documentation, you'll understand how they do it.

Here are some limitations:
- You can create something that "accesses" an EJB through a layer/facade they create, but you can't create full blown container-managed EJBs or Message Beans.

- You can use ADO.net and ASP.net but don't even think about System.EnterpriseServices, System.Messaging, using the windows event log and anything else that .net/windows has as an advantage over java. If it's j2ee compliant, the whole thing should run on Linux or AIX without any issues.

- It might be j2ee compliant but it's not as if you are really using any of the features of j2ee like jsp tags or JAX-RPC or JMS or JCA or JTA, etc etc. You CAN create a back-end that uses this IN JAVA and expose it through a servlet, but then you're basically doing java development in a java IDE.

In the end, you'd be better off creating a web service layer between your asp.net front-end and the j2ee back-end.

AEB
Wednesday, March 3, 2004