The ORM Foundation

 Hi all,

I wonder if it is possible to get java source from my orm schema entities?

Some friend tells me I can generate java source from my entities.

I’m working on nORMa on MSVS2010 and I have to build an enterprise system using JPA.

Thanks!

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:

1. 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.)
2. 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.
3. 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).
4. Obviously, the support classes and associated methods from runtime support libraries are different between .NET and Java (String, List, Dictionary, etc.).