FWD » Core Development » Conversion Tools

There are some customers that prefer C# to Java.

The core of both languages have nearly identical syntax and C# was certainly modeled on Java. Java evolves more slowly than C#. C# has more support for functional programming idioms and some additional features like property support and events (I'm not a fan of this one). Under the covers some features work differently (e.g. reified generics vs Java's type erasure). Java has more stability, is more widely used and has a much larger base of 3rd party technology. Projects using Java are nearly always platform neutral where C# projects need to take more care to ensure they are portable.

Regardless, it would not be difficult to support .NET, nor is it especially hard to deliver C# code considering that we already can deliver Java.

This task is to implement that support. First, we will discuss approaches. These are the most obvious ones for me:

1. Anti-Parse to C# from .jast

We could write an alternative to brew.xml to anti-parse a .jast to C# instead of Java. This would be the "naive and quick" approach. The primary downside is that some syntactic features that are possible in C# but not in Java would be harder to support or could not be supported easily. An example would be to leverage the native C# property and/or event support for those OO features in the 4GL.

2. Conversion Backend Rework

Rework the conversion rules to write to an intermediate AST form that is a generic OO language (neither Java or C#). Then write transformaton rules to generate a .jast or .cast (C# AST). Implement a C# anti-parser from the .cast to C#.

An alternative would be to abstract the conversion rules to conditionally generate .jast or .cast directly and then anti-parse them. I think this is just as much work and it would break badly the moment we decide to add a 3rd backend language target.

3. Automated Transformation of Java to C#

If we add Java and C# parsers, we could easily use TRPL to transform Java to C# or C# to Java. This would be a little more work up front, but does leave us with a lot of new tools/capabilities. Automating the transformation would also have benefit with #11539, which could be a big deal. On the other hand, it would make it harder to implement native C# support for things like properties (similar to the drawback of option 1 above).

This is long awaited feature. The conversion architecture was built with thin in mind. When I first read about it, I was thinking of C++, but C# is more suited for this job.

I vote for 2nd solution.

In details:
1st: The good part: this is probably the fastest approach to get a running prototype for small testcases, but the most difficult to maintain. The JAST tree is optimised for Java. Even if some nodes are similar, there are some which are not similar. We will want to add some nodes which are specific to C# and the file structure will get more complicated, with unneeded tree-branches. The TRPL will continuously need to decide whether the result is Java or C#.

2nd: We go with normal TRPL annotations for both target languages (I am sure we will add a few). Near the end of the pipeline we split brew process according to desired target. The simultaneous output will probably be an option, as we do with the SQL dialect now;

3rd: That's like adding an extender to the pipeline. But some nuances of 4GL may be lost and we will have difficulties passing annotation through Java code. Maybe encoding them in comments, or using the .jast in parallel (if that's available). It might contain heuristic solutions. There is a good part here: this tool will be able to convert manually written code in Java to C#.