views:

406

answers:

5

What mainstream frameworks, patterns, and tools would you choose to develop two projects in parallel, one in C#, one in Java, in order to minimize the total effort. (Disregard the obvious cases of interchangeable or equivalent tools, like SCC, Unit Testing, etc. Also assume generic broad RDBMS support.)

"Mainstream" means the market in general won't disregard the result because it uses something untested they've never heard of, or arcane skills are required to implement and support it.

Assume a broadly applicable tactical business appication.

+1  A: 

That's tough. While there are some good libraries available ported to both platforms, when it comes to frameworks, there doesn't seem to be much commonality.

The drift I've gotten here on SO is that there isn't much deviation from the company line in the .NET world. It would be as if everyone in Java used only EJB, JSF, and JNDI, and never came up with Guice, Struts, or Hibernate.

If I could, I'd take a different tack: instead of developing the same system in parallel, develop one system, and put a wrapper around it to support the other platforms. The drawback to this is that the other platforms are doomed to lag behind the primary, e.g. Mono. This drawback also applies to ports of some libraries themselves, like Spring.net or Guice.net.

Or you could invent your own Wasabi.

erickson
They've invented a 'Wasabi' for .NET and Java: http://www.fandev.org/
Corbin March
I think Joel mentioned on the podcast that they spent six months moving away from Wasabi. The concept is intriguing, but I wonder if the practical limitations proved too taxing. It'll be interesting to see how Fan matures.
erickson
+3  A: 

db4o uses an in house tool called sharpen to maintain one source repository (Java I think) and convert it automatically to C#.

As they say in thier blog post:

Before you start dreaming: sharpen is not a "magic wand". Don't expect to feed it an arbitrary Java app and receive a running .NET version at the push of a button. The translation process will require some design compromises on the Java side, and parts of the .NET code still have to be hand crafted and integrated into the converted sources.

However it is still quite a cool project. Also, I think it would work best for a new project. Released under the GPL but you have to register with developer.db4o.com to download it.


Edit: Here is an example blog post too.

Luke Quinane
+1  A: 

I've read good things about Mainsoft applications, although I never had to use it myself.

ykaganovich
A: 

Why would you want to develop for Java and C# in parallel?

You could just use Java and J#. The only problem is, that J# is stuck at Java 1.4 level, so you have two choices:

  • don't use this fancy stuff like enums, generics, for-each
  • use a tool like retroweaver to convert 1.5 back to 1.4

I've just finished building a mid-size application (about 80 classes / 30.000 lines) that runs nicely on Java and .NET this way.

As far as I know, the Java Classes compiled by J# are .NET-bytecode that is like any other .NET-bytecode, and can be used in C#. But you don't have to code your core classes twice.

Brian Schimmel
A: 

Depending on the scale of the project I would suggest the following technologies and approaches:

  1. Since UI in Java and C# are so different I would build an XML representation of UI for both projects... And then decide on one of two options a) Static and single generatios of the source of UI classes for both projects on the basis of the common XML (this might be somehow integrated with your building process so that the whole process would ignite automatically) b) Dynamic generation of UI in both cases (probably harder to realise)

  2. To make the architecture of both project similar I would use Spring and Spring.NET

  3. Also to draw as many similiarities I would decide on NHibernate and Hibernate
Marcin Rybacki