Setting up an integration project
As with almost all things in life, the more organized you are when you start out, the better your experience. It always helps to have the following information readily available:
- Do the Java components we intend to use require a specific JRE (maker/version)?
- What's the classpath that we would be using if we were running a Java application?
- Are there any -D or -X options that we need to configure to successfully use
the Java classes?
- Do we need "all" Java classes of the API in question or only a subset?
Once you have gathered that information, you will already have a better idea of how to approach the code generation systematically.
Generating Proxy Classes
Most JuggerNET evaluators start out by drag and dropping one or more jar files onto the code generator, configuring an output directory and generating proxy classes. This works well for simple integration projects, but it will almost always be a bad approach for large or complex integration problems. Here are the reasons why:
- You almost never need to generate proxy classes for all Java types on your classpath and you usually shouldn't. When you drag and drop a bunch of jar files onto the code generator, you are indicating that you're interested in all types they contain.
Normally, you only need proxy classes for the types that you will use directly from .NET (it's a bit more complicated than that, but that's a good first approximation).
For example, if your application uses log4j (a very common Java logging provider) you will usually not want to generate proxy types for the log4j API. For most users, that API is simply an implementation detail of your Java code and does not have to be exposed to .NET.
- You typically only code to public types and public fields and methods of these types. There is usually no need to generate proxy elements for the private or protected members of your Java API. The code generator will normally take care of this for you.
- You often have one or a few jar files that contain the API that you wish to use and a lot of jar files that are used internally by your API. Don't give the internal types the same treatment as the external ones. It will at best confuse the total picture and at worst cause the code generator to run out of memory while trying to generate a lot of unnecessary proxy types.
The key to improving the code generation process is to understand the roles of your jar files. Build a little batch file that invokes the code generator with all your jar files on the classpath. Then only import the jar files that contain APIs of interest. If this still yields too large a generated .NET API, consider importing Java types by name or name pattern rather than jar file.
The code generator is smart, but it can't read your mind. Let's say you want to prevent all types in a Java package from having .NET proxy types generated for them. You could manually disable every single Java type in that package in the code generator or you could disable the package. The immediate result will be identical.
Now consider that someone adds another Java type to that package and you regenerate the proxy types. If you manually disabled every single type and you regenerate, you will end up with a proxy type for the new type. If you disabled the package, you will not end up with a proxy type for the new type. Which outcome is the right one depends on your project, but very often the latter outcome is preferable for business code and the former outcome is preferable for utility code.
GUI, command line, or ANT?
Use the GUI code generator for the initial definition of the integration problem. The GUI is great for visualizing the set and seeing where you could reduce the size of the output if so desired. Once you have the set of types that you're interested in, you can save a model file and use the commandline version to regenerate time and again after changes on the Java side.
Use ANT for overnightly or host-portable builds. Modelfiles don't transport easily from one host to another because they persist local filenames and paths. ANT scripts allow you to parametrize and use build variables, consequently they "travel well."
Building the generated code
JuggerNET generates VisualStudio project files as well as batch files. You can use the generated project files to debug an application that combines generated and user-written code. Use the batchfiles or ANT/NANT scripts for building assemblies in the context of an automated build.