Re: Is it possible to generate java class source from VS2010/Norma?

Unfortunately, we don't currently have a Java code generator from NORMA. Although a Java class would not work directly in a Visual Studio project, there is no theoretical reason that NORMA couldn't generate one. The structure of the classes would be very similar to the .NET classes--at least those spit by the PLiX Implementation generator, which doesn't use LINQ--and we could share much of the infrastructure. The issues are as follows:

All of our code generators go through the PLiX generation framework, meaning that we generate an XML representation of the code first [manipulate the XML if needed] and format to text as the very final stage of the code generation process. We don't have a PLiX (Programming Language in XML) formatter for Java. There are also some language extensions/retractions that would need to be transformed and/or blocked for Java. It is likely we would end up with a Java-specific PLiX schema given the differences. However, the basic formatting of the language will be very similar to C#. Given the similarities, a generator is likely no more than two or three days of work. (I actually need to do a similar exercise for JavaScript.)

Code generation for .NET makes extensive use of partial classes. This means that the generated and hand written code for a given class can exist in separate files, and a generator can fully replace or delete a file without fear of overwriting hand-written code. This is not the case for Java, where there is a 1-1 relationship between a class and a file, and the file location is significant. This means that an integrated code generator needs to locate the real class, do some basic parsing to figure out where 'inside the class' is as well as where any previous spit from the same generator occurred, and insert/replace the generated code. Obviously, there are also issues when a generator is removed. This code injection (plus protecting the code in the generated region) will be different for each Java tool and editor. This would not be low-hanging fruit, and it is unlikely that NORMA or PLiX would attempt this any time soon. You would need to manually take any generated code and paste it into the appropriate .java file. Alternately, you have to make major changes to the class to support double derivation.

The generated .NET code makes extensive use of delegates and generics. Delegates are, of course, not supported in Java, nor is the construct ever likely given the massive legal stink the J folks made when Microsoft added this support to J# (a contract lawsuit which Microsoft eventually won, by the way, although the preliminary injunction (based on the non-legally binding contract preamble) is what got all of the press and drove MS out of the Java business). This is very unfortunate given that every other modern (and many not-so-modern) language supports both typed (instance-bound) and untyped function pointers, which is all that a delegate is (delegate-or-equivalent support is native to all of the .NET languages, all of the modern functional languages, JavaScript, C++ (although typed function pointers are messy), and even VB5/6 with the extensions I published in my 2000 Advanced Visual Basic book). In any case, given the central use of this primitive construct in the generated code patterns, a Java generator would need a significant redesign. We would also want to look at the use of generics (generics are real classes in .NET, not the late-bound boxing-intensive mess that Java came up with).

Obviously, the support classes and associated methods from runtime support libraries are different between .NET and Java (String, List, Dictionary, etc.).

So, while generating the language parts would be relatively easy, different levels of conceptual support in the languages (especially when dealing with delegates, events and partial classes) will require some major reworking. Determining how you want to integrate the classes would also be interesting.

I am likely to need ORM-generated Java for an upcoming contract, so some of these areas may progress, but I can't given any timeframe. I would be happy to work with anyone who wants to suggest the Java patterns they want to see generated. Note that the generated MODELFILE.CLIProperties.xml file is an intermediate input for the plix implementation classes and I don't see any major issues using this to spit other class models.