1

To make development portable to Java, does it make sense to do the whole development on J# vs C#? What happens to missing bits in Java that exist in C# like lambda expression and so on?

What is the best way to achieve portability?

Romano Zumbé
  • 7,893
  • 4
  • 33
  • 55
iCode
  • 4,308
  • 10
  • 44
  • 77
  • 1
    If you target is Java why not start there? (.NET and Java are very different in many respects – despite the use of curly braces – and portability would require a common subset, that doesn't exist, of the framework.) – Richard Jun 28 '11 at 09:41

3 Answers3

3

I definitely wouldn't use J# - it's not supported any more, and it only supported Java 1.1.4 anyway, IIRC.

I would personally recommend keeping the overall architecture consistent between the two languages, but then write the code separately, manually, taking into account the different idioms in the different languages.

If your codebase uses data-driven tests, it would be good to share that data between the two languages, as a way of helping to ensure data portability.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
2

I suggest you don't use J# anymore as it has been discontinued. The last version has been shipped with Visual Studio 2005.

Daniel Hilgarth
  • 171,043
  • 40
  • 335
  • 443
0

In addition to J#-specific language extensions and .NET CLR support, its runtime library implements Java 2 Collections Framework (without the java.util.concurrent extensions, though) and even some JFC/Swing, via the Supplemental UI Library.

So you'll be limited to the Java 1.4 API.

Given that J# has been discontinued long ago, I wouldn't suggest you invest your time into it.

If you really need portability between JVM and CLR, I'd take a look at IKVM (implements Java 1.7 API on top of CLR), Scala for .NET (discontinued circa Scala 2.10) or languages like Ruby (JRuby/IronRuby) or Python (Jython/IronPython).

Alternatively, you can generate your C# for .NET -- there're Java to C# converters available.

Bass
  • 4,977
  • 2
  • 36
  • 82